Terraform 1.4: обновляем CI-пайплайны и тестируем связку с GitFlic вместо GitHub

Terraform 1.4 вышел в RC1 в конце февраля, и мы почти сразу начали перекатывать его в CI-пайплайны нескольких клиентов. Не потому что сгорели - просто в этом релизе есть изменение, которое тихо ломает устоявшиеся сценарии с remote state, и лучше наткнуться на него на стейджинге самим, чем получить звонок от клиента в пятницу вечером.

Что изменилось в state locking

Основное - поведение locking при работе с Terraform Cloud и remote backend. До 1.4 блокировка снималась автоматически при любом завершении terraform apply, включая аварийное. В 1.4 логика чуть изменилась: при прерывании (SIGINT, таймаут в CI) lock теперь удерживается агрессивнее, и terraform force-unlock стал чуть ближе к штатному инструменту, а не к аварийному.

На практике это вылезло так: в одном из пайплайнов стоял таймаут 30 минут на весь job. Apply укладывался в 20, но иногда не успевал - чаще всего из-за ожидания provisioner-ов. При таймауте GitLab Runner убивал процесс, lock не снимался, следующий запуск падал на попытке захватить блокировку. Раньше такое бывало редко, в 1.4 воспроизвелось стабильно.

Решение - не лечение симптома через уменьшение таймаута, а явный terraform force-unlock в after_script блоке с передачей lock ID из артефактов. Немного костыльно, но надёжно. Альтернатива - переехать на нативный cloud блок вместо remote backend, там управление блокировкой устроено иначе.

Новый CLI workflow для cloud workspaces

В 1.4 Terraform официально разделил конфигурацию на два режима: старый remote backend и новый блок cloud. Функционально они пересекаются, но cloud даёт доступ к нескольким workspace через workspaces с фильтрацией по тегам - это удобно для мультиенвайронментных схем.

terraform {
  cloud {
    organization = "example-org"
    workspaces {
      tags = ["app:billing", "env:prod"]
    }
  }
}

Казалось бы, удобная штука. Но нюанс: при переходе с remote на cloud нужно явно мигрировать state - terraform init это делает, но спрашивает подтверждение, и в неинтерактивном CI без -input=false зависает. Поймали на двух пайплайнах, где инициализация шла без этого флага - привычка из времён когда init не задавал вопросов.

GitFlic вместо GitHub: тестируем в реальном пайплайне

Параллельно с обновлением Terraform один из клиентов попросил проверить работу CI на GitFlic. Требование не новое - у них регулятор давит на замену иностранных инструментов, а GitFlic сейчас активно продвигается как отечественная альтернатива GitHub/GitLab. Мы уже смотрели на отечественные registry в контексте DevSecOps-стека, и вот следующий шаг.

Технически GitFlic поддерживает webhooks и CI/CD через GitFlic CI - собственный runner. Для Terraform-пайплайна нас интересовало: можно ли запустить стандартный flow init -> validate -> plan -> apply без существенной переделки?

Что получилось:

• Синтаксис пайплайна отличается от GitLab CI, хотя концепция похожа. Нет прямого способа «скопировать .gitlab-ci.yml и поменять пару строк» - надо переписывать. Документация на GitFlic по CI неполная: нашли несколько параметров, которые в документации упомянуты, но на практике игнорируются runner-ом.
• Secrets/переменные - хранятся в репозитории, передаются в env. Базово работает, но нет группового уровня переменных как в GitLab (group variables). Для клиента с несколькими репозиториями это означает ручное дублирование переменных, что не масштабируется.
• Артефакты - terraform plan -out=tfplan сохраняется как артефакт, передаётся в apply-стадию. Работает, но максимальный размер артефакта оказался ограничен - для больших планов надо либо сжимать, либо использовать внешнее хранилище.

Итог по GitFlic: для простого учебного репозитория или небольшого проекта - работает. Для продакшн Terraform-пайплайна с несколькими окружениями и командой из пяти человек - пока сыровато. Мы это честно написали в отчёте клиенту, предложили промежуточный вариант: репозиторий на GitFlic, CI на GitLab-совместимом runner поверх него через API.

Где мы сейчас

По самому Terraform 1.4 - обновили три окружения, пайплайны работают. Изменение поведения locking при таймаутах стало понятным и управляемым после явного force-unlock в cleanup-шаге. На переход с remote backend на cloud блок времени пока не нашли - функционально remote справляется, и переезд без очевидной срочной выгоды откладывается.

По GitFlic - наблюдаем. Инструмент развивается, и если за ближайшие месяцы CI-движок подтянется до уровня группового управления переменными и нормальной документации, вернёмся к оценке для более серьёзного пилота.

Всё это - часть нашей работы по managed-сопровождению инфраструктуры: не просто накатить обновление, а разобраться что именно изменилось и не выстрелить себе в ногу через неделю.