Atlantis — это предпочтительный инструмент для инженеров, которые запускают terraform apply со своих ноутбуков. Вы размещаете сервер в своей сети, настраиваете вебхуки, и изменения в инфраструктуре применяются через pull-реквесты, как обычный код.

Эта модель отлично работает некоторое время, но по мере роста организации, увеличения количества репозиториев и одновременного открытия PR несколькими людьми, процессы начинают казаться медленными и ненадежными. В этой статье мы разберем, что такое Atlantis, где он начинает давать сбои при масштабировании, как выглядит серьезное промышленное развертывание и когда имеет смысл перейти на что-то другое.

Что мы рассмотрим:

Что такое Atlantis?
Где Atlantis не справляется при масштабировании
Как развернуть Atlantis в масштабе
Почему стоит использовать Spacelift как альтернативу Atlantis
Atlantis помещает terraform plan и apply внутрь ваших pull-реквестов, и это работает до тех пор, пока каждый клон, инициализация, план и применение не выстраиваются в очередь за одним сервером.
Вы можете преодолеть это с помощью блокировок Redis, хранения планов в S3, списков разрешенных команд для команд и альфа-версии API для обнаружения дрейфа (drift), но планировщик, скрипт разрешений и обеспечение доступности — это то, что вам придется создавать и поддерживать самостоятельно.
Spacelift предоставляет тот же рабочий процесс с pull-реквестами, но с уже встроенными функциями обнаружения дрейфа, политиками как кодом (policy as code), зависимостями между стеками и полноценным управлением доступом на основе ролей.

Atlantis — это инструмент с открытым исходным кодом, который автоматизирует Terraform через pull-реквесты. Это единый бинарный файл на GO, который прослушивает вебхуки от вашего Git-провайдера, выполняет команды Terraform и публикует результат в виде комментария к PR.

Процесс прост и понятен:

Вы изменяете свои файлы Terraform и открываете pull-реквест.
Как только pull-реквест открыт, Atlantis получает вебхук, клонирует репозиторий и запускает terraform plan.
Результат выполнения плана появляется в виде комментария к вашему PR.
Ревьюер одобряет изменения, кто-то пишет в комментариях atlantis apply, и Atlantis выполняет применение.
PR объединяется (merge), и Atlantis разблокирует проект.

Внедрение Atlantis очень простое, так как все происходит там, где ваша команда уже работает. Вам не нужно изучать новый интерфейс; достаточно прочитать комментарий и написать другой.

В настоящее время Atlantis является проектом CNCF (уровень зрелости sandbox), последняя версия — v0.47.1, а версия 1.0.0 все еще находится в дорожной карте.

Обзор архитектуры Atlantis в масштабе

Из множества способов развертывания Atlantis самым распространенным является Kubernetes. По умолчанию у Atlantis нет внешней базы данных, и он хранит файлы планов на локальном диске. Официальные манифесты Kubernetes используют StatefulSet с количеством реплик: 1 и постоянным томом (persistent volume).

Таким образом, архитектура Atlantis включает:

Один HTTP-сервер, который принимает вебхуки и обслуживает небольшой веб-интерфейс.
Рабочую директорию на диске, куда клонируется каждый репозиторий для каждого PR и рабочего пространства.
Уровень блокировки, который помогает предотвратить одновременное планирование или применение изменений для одного и того же проекта из двух разных PR.
Бинарные файлы Terraform, которые Atlantis загружает и выполняет как подпроцессы на той же машине.

Взгляните на этот список еще раз и представьте сценарий, в котором у вас десятки конфигураций: каждая загрузка плагина провайдера, каждый клон, каждый план и каждое применение происходят на одной машине, совместно используя CPU, память, диск и сеть. Atlantis выполняет работу последовательно, так как нет очереди, вы не можете распределять нагрузку между узлами, и нет планировщика, который решал бы, где выполняется работа.

Давайте рассмотрим некоторые режимы сбоев, с которыми вы обязательно столкнетесь, примерно в том порядке, в котором большинство команд с ними сталкивается.

1. Единственный сервер становится «бутылочным горлышком»

Atlantis запускает каждый клон, план и применение как подпроцесс на машине, которая получила вебхук. Это нормально, когда работают два человека.

Это перестает быть нормальным, когда в вашем монорепозитории 70 проектов, а PR затрагивает общий модуль, потому что автоплан запускается для каждого затронутого проекта. Умножьте это на четыре открытых PR, и пул воркеров будет перегружен. Комментарий с планом приходит с опозданием на 20 минут, кто-то пишет вам в Slack с вопросом, не упал ли Atlantis, и вы проводите вторую половину дня, подтверждая, что сервер был в порядке, просто занят.

Второй PR, затрагивающий ту же директорию, тоже не будет тихо ждать своей очереди. Он получит ошибку блокировки, указывающую на PR, который удерживает блокировку, и кому-то придется ее очищать.

2. Вертикальное масштабирование — единственный простой рычаг

Очевидное решение — более мощная машина, и это работает некоторое время. Вы добавляете CPU и память, а затем увеличиваете --parallel-pool-size, который управляет тем, сколько планов и применений выполняется одновременно (по умолчанию 15 на одной машине).

Подвох в том, что именно насыщается первым. Команды в конечном итоге используют очень мощные инстансы, где CPU большую часть времени простаивает, а диск перегружен операциями git clone и загрузкой провайдеров, при этом вы платите за пиковую мощность каждое утро.

Увеличение размера пула без добавления ресурсов диска и сети лишь перемещает проблему конкуренции, а не устраняет ее.

3. Вы можете масштабироваться горизонтально, но это нужно настроить вручную

По умолчанию Atlantis хранит блокировки во встроенной базе данных, которую может открыть только один процесс, что годами удерживало его на уровне одной реплики. Переход на --locking-db-type=redis позволяет нескольким репликам совместно использовать состояние блокировки.

Файлы планов по-прежнему находятся на локальном диске, поэтому реплика, которая получает вебхук atlantis apply, может не иметь ничего для применения. Решение — внешнее хранилище планов. Включите --enable-external-stores, укажите S3-совместимый бакет, и Atlantis будет загружать планы после выполнения команды plan и восстанавливать их там, где выполняется apply.

Redis плюс объектное хранилище — это документированный путь к отказоустойчивости без сохранения состояния, и это работает. Но это также добавляет еще два элемента инфраструктуры, которые вам нужно запускать, защищать, отслеживать и обновлять вместе с Atlantis.

4. Загрузка провайдеров и модулей доминирует во времени выполнения

Каждый запуск получает новую рабочую директорию для каждого PR и рабочего пространства, поэтому terraform init запускается снова, и провайдеры загружаются заново.

Atlantis по умолчанию кэширует плагины, но документация рекомендует отключать этот кэш, когда несколько проектов планируются и применяются в одном PR, потому что в Terraform известна проблема состояния гонки (race condition) при работе с общей директорией кэша. Две вещи, которые вам больше всего нужны при нагрузке — параллелизм и кэширование — противоречат друг другу.

При небольшом объеме это стоит несколько секунд, но при десятках проектов в день это становится основной частью длительности выполнения и заметной строкой в счете за исходящий трафик.

5. Управление доступом слишком ограничено

Atlantis дает вам два способа решить, кто и что может запускать. Первый — --gh-team-allowlist, который сопоставляет команды GitHub с командами глобально, так что вы можете сказать, что эта команда выполняет apply, а все остальные — только plan.

Второй — внешняя команда авторизации. Atlantis передает ей команду, репозиторий, проект и команды пользователя, а ваш скрипт отвечает «пройти» или «отказать». Этот скрипт — часть промышленного управления доступом, которую вы пишете, тестируете и поддерживаете вечно.

В продукте нет ролей, нет сред и нет модели на уровне аккаунтов. Правило вроде «команда данных может применять изменения только к своему аккаунту AWS и ни к какому другому» превращается либо в этот скрипт, либо в отдельное развертывание Atlantis со своими учетными данными.

6. Все учетные данные оказываются на одной машине

Если Atlantis управляет инфраструктурой в десяти аккаунтах AWS, то этот единственный сервер обладает доступом ко всем десяти. Это самая привилегированная машина, которую вы используете, обладающая наибольшим радиусом поражения в случае компрометации, и именно ее ваша платформа-команда обновляет вручную.

Разделение развертываний по радиусу поражения — это стандартный ответ, и он действительно сдерживает риски. Но это также означает, что теперь вы управляете четырьмя серверами Atlantis, каждый из которых имеет свою конфигурацию, учетные данные, вебхуки и график обновлений.

7. Существует простая альфа-версия обнаружения дрейфа (drift detection)

Atlantis видит только те изменения, которые приходят через PR. Когда кто-то вносит изменения в консоли AWS, Atlantis не узнает об этом до следующего плана по этому проекту, до которого могут оставаться недели.

Начиная с версии v0.45.0, доступен альфа-API для обнаружения дрейфа. Включите --enable-drift-detection, и вы получите эндпоинты для запуска сканирования, чтения кэшированного результата и исправления, а также вебхуки, которые могут отправлять уведомления в Slack при обнаружении дрейфа.

Однако у вас нет планировщика. Что-то вне Atlantis должно вызывать этот эндпоинт по расписанию, и это ваша зона ответственности; автоматическое исправление требует дополнительного флага, а поскольку API находится в стадии альфа-тестирования, структура его запросов и ответов может меняться между релизами.

8. Отсутствие графа зависимостей между проектами

Если ваш сетевой стек должен быть применен до стека EKS, Atlantis не будет этого принудительно контролировать. В рамках одного PR вы можете группировать проекты в порядке выполнения, что покрывает случай, когда одно изменение затрагивает оба.

Между PR и репозиториями нет ничего. Нет графа, нет общих выходных данных, нет способа объявить, что один проект зависит от другого.

Порядок выполнения в итоге оказывается в ранбуке, оберточном скрипте или в голове одного инженера, и вы узнаете, что он был неверным, только когда apply завершится ошибкой.

9. Видимость ограничена комментариями в PR

Atlantis предоставляет небольшой веб-интерфейс для блокировок и потоковой передачи логов в реальном времени во время выполнения, что действительно полезно в моменте.

После закрытия PR ваш аудиторский след представляет собой набор комментариев, разбросанных по репозиториям, некоторые из которых свернуты или отредактированы. Чтобы ответить на вопрос «кто применил это, когда и что именно было в плане», приходится просматривать каждый pull request по отдельности.

Нет централизованной истории запусков, нет хранилища логов с возможностью поиска и нет дашборда для каждой команды, если только вы не создадите его и не будете поддерживать его работу.

Истинная стоимость использования Atlantis в масштабе

Atlantis можно скачать бесплатно, но его использование не является бесплатным. Вам следует оценить, за что вы на самом деле платите:

Вычисления и хранилище — у вас всегда будет один или несколько серверов, рассчитанных на пиковую нагрузку, вместе с постоянными томами и Redis.
Работа по обеспечению доступности: StatefulSet с одной репликой — это единая точка отказа. Обеспечение высокой доступности — это отдельный проект.
Время платформенных инженеров — вам нужен как минимум один постоянный инженер для обработки обновлений, отладки вебхуков, пользовательских рабочих процессов, ротации учетных данных, кэширования плагинов и оберточных скриптов вокруг Terragrunt или настроек для нескольких аккаунтов.
Время ожидания разработчиков — когда 20 инженеров ждут лишние десять минут на каждый план несколько раз в день, это обходится гораздо дороже, чем любой тип инстанса.
Риск — отсутствие обнаружения дрейфа и контроля политик означает, что ошибки обнаруживаются в продакшене, а не на этапе планирования.

Прежде чем решать, что Atlantis слишком дорог, измерьте свои реальные показатели. Вы можете отслеживать время от открытия PR до комментария с планом, а также считать, сколько раз в неделю кто-то спрашивает о зависшем запуске.

Если вы решили остаться на Atlantis, вот несколько решений, которые помогут вашему развертыванию масштабироваться и пережить рост:

Принимайте решения централизованно, а не для каждого репозитория: укажите серверу центральный конфиг репозитория с помощью --repo-config и установите там свои значения по умолчанию: какой рабочий процесс запускается, какие требования должны быть выполнены перед apply и насколько репозиторий может переопределять настройки. В противном случае каждая команда устанавливает свои правила, и никто не несет ответственности за результат.
Кэшируйте загрузку провайдеров: загрузка плагинов Terraform занимает значительную часть времени выполнения. Лучшая практика здесь — настроить каталог кэша плагинов и обеспечить его постоянным хранилищем.
Устанавливайте параллелизм исходя из реальности: количество планов и применений, работающих одновременно, контролируется параметром --parallel-pool-size, который по умолчанию равен 15 и применяется к одной машине. Увеличение этого значения без добавления CPU и памяти просто переместит очередь, а не устранит ее.
Отключите опасные сокращения: кто-то может написать комментарий atlantis apply без аргументов и применить все проекты в PR сразу. Использование --disable-apply-all заставляет их указывать, что именно они применяют, и это стоит вашим инженерам три секунды.
Следите за тем, что запускает план: ужесточите шаблоны файлов для автоплана, чтобы изменение документации не запускало 20 запусков. Сузьте шаблоны для каждого проекта, и ваш сервер перестанет выполнять работу, о которой никто не просил.
Держите диск в Kubernetes: планы живут на локальном диске, поэтому официальные манифесты используют StatefulSet с постоянным томом, без которого перезапуск стирает все планы в процессе выполнения. Масштабирование за пределы одной реплики добавляет блокировку на основе Redis и требует либо общей файловой системы, либо внешнего хранилища планов.

В какой-то момент вы можете начать задаваться вопросом: «Хочу ли я продолжать строить платформу или просто использовать готовую?» Spacelift — это альтернатива Atlantis, потому что он предлагает тот же рабочий процесс PR. Помимо поддержки Terraform/OpenTofu и Terragrunt, Spacelift также поддерживает CloudFormation, Pulumi, Kubernetes и Ansible.

То, что вам пришлось бы строить вокруг Atlantis, уже есть здесь:

Policy as code с использованием OPA может применяться в нескольких точках принятия решений, а не только во время применения. Вы можете контролировать, какие ресурсы могут создавать пользователи, какие параметры они могут иметь, сколько одобрений нужно для запуска, куда отправлять уведомления, что происходит при открытии или слиянии pull request и многое другое.
Встроенное обнаружение дрейфа помогает вам понимать изменения, внесенные в ваши стеки, по расписанию, которое вы определяете, но вам не нужно настраивать для этого специальный планировщик, так как это встроено.
Зависимости стеков позволяют создавать связи между вашими конфигурациями и даже обмениваться выходными данными между ними. Это работает и для разных инструментов, поэтому вы можете легко реализовать рабочие процессы Terraform+Ansible или даже Terraform+Kubernetes. Эти зависимости представляют собой направленный ациклический граф, и они могут иметь столько вложенных уровней, сколько вы захотите.
Настоящий RBAC и SSO с SAML 2.0, что дает вам прозрачность в том, кто может применять что и где. Это настройка конфигурации, а не отдельное развертывание для каждой команды.
Управляемое состояние с учетными данными, ограниченными одним запуском, или ваш собственный бэкенд, если вы предпочитаете размещать состояние самостоятельно.
Частные пулы воркеров, которые работают внутри вашей сети, когда они вам нужны, плюс частный реестр модулей с тестированием версий.
Полная история запусков и аудиторский след в одном месте, а не разбросанные по комментариям PR.
Самообслуживаемая инфраструктура через Blueprints и Templates. Blueprints могут автоматизировать все, что связано с вашими стеками: от конфигурации VCS и используемых инструментов до хуков жизненного цикла и многого другого, и они даже интегрируются нативно с ServiceNow и Backstage. В то же время вы также можете использовать Templates, которые предоставляют неизменяемую инфраструктуру самообслуживания.
Поддержка ИИ встроена в Spacelift Intelligence: у вас есть ИИ-помощник в продукте, который поможет вам с первого взгляда понять состояние ваших ресурсов Spacelift, а также поможет создавать новые. Кроме того, вы можете использовать Spacelift Intent для генерации инфраструктуры с помощью естественного языка, что также отслеживается так же, как и ваша обычная инфраструктура. Это чрезвычайно полезно в средах разработки и тестирования, когда разработчикам нужно быстро и легко что-то создать, не обращаясь к вашим командам платформенной инженерии.

Благодаря Spacelift вы перестаете обслуживать сам сервер, что минимизирует рабочую нагрузку вашей платформенной команды.

Более подробное сравнение продуктов можно найти здесь. Если вы предпочитаете смотреть, ознакомьтесь с видео ниже:

Как перейти с Atlantis на Spacelift

Процесс миграции прост, так как ваш код Terraform не меняется.

Каждый проект Atlantis требует собственного стека. Все, что перечислено в разделе projects: в файле atlantis.yaml, становится стеком Spacelift, указывающим на тот же репозиторий, ветку и директорию. Если у вас их десятки, определите их с помощью провайдера Spacelift Terraform, чтобы вся настройка была кодом, который можно проверять и версионировать.
Импортируйте свое состояние. Если вы хотите, чтобы Spacelift управлял вашим состоянием, импортируйте существующий файл состояния во время создания стека или на вкладке истории состояний существующего стека. Кроме того, вам следует полностью удалить блок backend из вашего кода Terraform, потому что Spacelift внедряет свою собственную конфигурацию во время выполнения, а существующий backend приведет к ошибке при инициализации. Если вы хотите сохранить свой backend S3, вы можете это сделать, и тогда здесь ничего не изменится.
Перенесите свои учетные данные. Вы можете заменить статические облачные учетные данные с вашего сервера Atlantis на облачные интеграции Spacelift.
Преобразуйте свои правила в политики. Ваши apply_requirements становятся политиками одобрения, а специальные правила, которые рецензенты ранее применяли вручную, становятся политиками планирования, которые автоматически прерывают выполнение, если что-то не так.
Некоторое время запускайте оба решения параллельно. Сначала вам следует перенаправить пару стеков с низким уровнем риска на Spacelift, а Atlantis оставить для всего остального. Затем сравнивайте вывод плана в одном и том же PR, пока не начнете ему доверять.
Отключите autoplan в Atlantis, отключите ручной доступ, удалите вебхуки и отзовите учетные данные для каждого репозитория, а затем выведите сервер из эксплуатации, как только будет перенесен последний стек.

У Spacelift также есть инструмент миграции под названием liftoff, который в настоящее время поддерживает Terraform Cloud и Terraform Enterprise, с планами по добавлению других источников.

Большинство команд переходят с Atlantis на Spacelift в течение нескольких недель, а не за один большой переход на выходных.

Atlantis — отличный инструмент с простым дизайном: один сервер, локальный диск и комментарии к PR в качестве интерфейса. Именно эта простота делает его таким легким для начала работы. Его ограничения носят структурный характер: выполнение на одном сервере, файлы планов, привязанные к диску, грубые разрешения, отсутствие готового к корпоративному использованию обнаружения дрейфа и отсутствие графа зависимостей.

Вы можете масштабировать его с помощью блокировки Redis, кэшей плагинов, настроенных параллельных пулов, конфигурации репозитория на стороне сервера и раздельных развертываний по радиусу поражения. Вам всегда следует оценивать реальную стоимость, прежде чем принимать решение об использовании Atlantis, а задержка планирования и часы работы платформенных инженеров значат гораздо больше, чем счет за экземпляр.

Если вам нужна готовая к корпоративному использованию альтернатива, запишитесь на демонстрацию с одним из наших инженеров, чтобы узнать больше о том, как Spacelift может вам помочь.