Про Terraform и CI/CD

Самое время для прохладной истории с полей сражений DevOps, которая научит нас паре важных вещей о Terraform и CI/CD. #terraform #cicd #debug

Вторник, 17:45. Дорабатываю рабочий день. Заглядываю в мессенджер, вижу сообщение:

Привет, Саш, нам нужно в dev-окружении в кластере Kafka поднять максимальный размер сообщения по аналогии с pre-prod. Там такая настройка уже стоит.

Захожу в репозиторий с TF-кодом, смотрю в ветку preprod, вижу в файле kafka.tf настройки для ресурса. Действительно, в препроде есть, в деве нет. Надо добавить в конфиг message_max_bytes:

 kafka {
   ...
   kafka_config {
      auto_create_topics_enable = var.auto_create_topics_enable
      message_max_bytes         = 31457280
      replica_fetch_max_bytes   = 31457292
    }
...
}

А теперь маленькая ремарочка. Проект делали аутстафф-девопсы летом до моего прихода в компанию, а мне передали на поддержку. Сам я там ещё ничего не настраивал, пришла пора сделать первые изменения. "Ну я-то в Terraform шарю, что тут разбираться, тут пару строчек добавить, ща быстренько сделаю, чтобы на утро не откладывать" 🤡

На всякий случай бегло по диагонали пробежался по .gitlab-ci.yml. Стандартные validate-plan-apply, не вижу подвоха. Добавляю две строчки и без задней мысли делаю коммит. Прошёл validate, иду смотреть в plan. А там вот такое (вырезал лишнее):

# yandex_mdb_kafka_cluster.kafka01 must be replaced
-/+ resource "yandex_mdb_kafka_cluster" "kafka01" {
      ~ health              = "ALIVE" -> (known after apply)
    ...
      ~ status              = "RUNNING" -> (known after apply)
        # (6 unchanged attributes hidden)
      ~ config {
            # (6 unchanged attributes hidden)
          ~ disk_size_autoscaling (known after apply)
          ~ kafka {
              ~ kafka_config {
                  + auto_create_topics_enable = false
                  + message_max_bytes         = "31457280"
                  + replica_fetch_max_bytes   = "31457292"
                }
                # (1 unchanged block hidden)
            }
          ~ kraft (known after apply)
          + zookeeper {
              + resources {
                  + disk_size          = 20
                  + disk_type_id       = "network-ssd" # forces replacement
                  + resource_preset_id = "s2.micro"
                }
            }
            # (3 unchanged blocks hidden)
        }
      ~ maintenance_window (known after apply)
      - maintenance_window {
          - hour = 0 -> null
          - type = "ANYTIME" -> null
            # (1 unchanged attribute hidden)
        }
        # (1 unchanged block hidden)
    }
  # yandex_mdb_kafka_user.developer must be replaced
-/+ resource "yandex_mdb_kafka_user" "developer" {
    ...
        name       = "developer"
        # (1 unchanged attribute hidden)
        # (1 unchanged block hidden)
    }

Отлично конфиг поправил! Действительно, почему бы не пересоздать кластер кафки вечерком, потеряв данные. Понимаю, что apply тут прожимать будет неверно, начинаю втыкать в код, план и облако, в чём дело. Тут мне в чатик прилетает:

У нас в деве кафка недоступна, это ты?

Чувствую, как на лбу проступает пот. Хоть это и dev-кластер, а заново поднимать кафку вряд ли будет приятным удовольствием. Смотрю в GitLab CI, а там apply пошёл автоматически исполняться после plan. Просто красота, какой хороший пайплайн :) Конечно, тут была моя главная ошибка, что я невнимательно посмотрел в .gitlab-ci.yml. Откуда-то была уверенность, что apply "уж точно ручной, кто их на автоматы-то ставит?" 🤡

Смотрю в логи apply, вижу:

Error: error reading Kafka Cluster "kafka": client-request-id ... rpc error: code = FailedPrecondition desc = The operation was rejected because cluster has 'deletion_protection' = ON