Ух как т9 наисправлял. :)

Можно ли терраформ заставить создавать aws instances один за другим, а не все сразу пачкой?

-parallelism=1 ?

Хм... Посмотрю в эту сторону. Чет не подумал. Спасибо. :)

Медленновато будет, но гарантировано последовательно

Ну мне для первой инициализации кластера.

Чтоб первая тачка проинитила кластер. А остальные уже к ней прицепятся

Завтра протестим. Спасибо

Есть
- CI который собирает Docker и публикует в репозиторий
- сервер который должен забрать Docker image и запустить

как автоматизировать второе после первого

как вариант внутри CI дополнительный stage который заходит по SSH на сервер и выполняет docker pull

Именно так. У меня так сделано и вполне работает

Подскажите, почему TF пытается переписать access_policies в aws_elasticsearch_domain.es если изменений в нем не было?

Конфиг такой:

resource "aws_elasticsearch_domain" "es" {
 domain_name           = "test"
 elasticsearch_version = "5.3"
 cluster_config {
   instance_type = "m4.large.elasticsearch"
   instance_count = 1
 }

 advanced_options {
   "rest.action.multi.allow_explicit_index" = "true"
 }

 ebs_options {
   ebs_enabled = true
   volume_type = "gp2"
   volume_size = "10"
 }

 access_policies = «CONFIG
{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Action": [
           "es:ESHttpGet",
           "es:ESHttpPut",
           "es:ESHttpPost",
           "es:ESHttpHead"
         ],
         "Effect": "Allow",
         "Principal": "*",
         "Condition": {
             "IpAddress": {"aws:SourceIp": ["${aws_eip.eip.public_ip}"]}
         }
       },
       {
           "Action": "es:*",
           "Effect": "Allow",
           "Principal": "*",
           "Condition": {
               "IpAddress": {"aws:SourceIp": ["192.168.1.1", "192.168.1.2"]}
           }
       }
   ]
}
CONFIG

 snapshot_options {
   automated_snapshot_start_hour = 8
 }

 tags {
   Domain = "Test"
 }
}

Где я накосячил, что он считает, что политика меняется?

Сорри. :) Нашел причину.

Здраствуйте. Не могу понять суть вот этой ошибки:

The plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag

То есть либо не используйте этот флаг, либо дестройте целевые сущности? А в чём тогда суть флага?
Я тестирую конфигурацию и хотел бы дестроить часть ресурсов на ночь и выходные, а часть (s3 и кое-что ещё) оставлять. А потом приходить, делать apply и воссоздавать сущности снова, а которые остались - будут неизменёнными

Или prevent_destroy - это не флаг "не удалять при дестрое", а защита от кривых рук самого разработчика? :)

Это флаг не для терраформа, на сколько я понимаю. Этот флаг можно руками поставить в вебморде aws. Это такая себе защита от дурака.

Ноя могу и ошибаться. Если не прав, то пусть меня поправят.

Это флаг для терраформа, потому как работает не только с aws. Мы используем других ресурсов - балансеров, вольюмов и т.д.