«Spacelift» - это специализированная совместимая с Terraform платформа CI/CD для подхода «Инфраструктура как код». Она была разработана и внедрена опытными DevOps-инженерами на основе их предыдущего опыта с крупномасштабными ПО - а именно с помощью нескольких десятков команд, сотен инженеров и десятков тысяч облачных ресурсов.

При этом стартовать работу со Spacelift очень легко. Можно начать с нуля, и менее чем за одну минуту перейти к полному управлению вашего облачного хранилища без какой-либо предварительной подготовки. Она прекрасно интегрируется с такими крупными платформами как GitHub и AWS.

Нужен ли другой CI/CD для вашей инфраструктуры?

Да, мы уверены, что это хорошая идея. Мы не живем в идеальном мире, где одной CI-системы будет достаточно, чтобы охватить все варианты использования. Обычные CI-настройки помогут вам начать легко, но Terraform имеет довольно необычную модель исполнения и тяготеет к сохранению состояния. Также остерегайтесь значительных радиусов поражения, если что-то пойдет не так. Мы думаем, что «Spacelift» предлагает идеальное сочетание универсальности обычного CI и методологическую строгость специализированного, ориентированного на безопасность инфраструктурного инструмента – этого достаточно, чтобы попробовать платформу, даже если в настоящее время вы довольны настройкой CI/CD в формате «Инфраструктура как код».

В следующих разделах мы попытаемся отразить главные вызовы в запуске Terraform в системе CI общего назначения, а также покажем, как Spacelift отвечает на них. В конечном счете, всё это, в основном, про два аспекта – коллаборацию и безопасность.

Коллаборация

Погодите, разве CI строится не ради коллаборации?

Да, предполагая инструменты и настройки без сохранения состояния. Управление сборкой с отсутствием состояния и их тестирование – это то, в чём обычный процесс CI чрезвычайно хорош. Но многие из нас знают, что правильное развертывание осуществить сложнее. И вряд ли это сюрприз. Они могут быть с отслеживанием состояния, так как могут зависеть от того, что уже было запущено. «Terraform» и ваша инфраструктура в целом - это наиболее яркий пример системы с сохранением состояния (“state” даже  отдельно прописано как одна из ключевых концепций продукта).

В CI обычно возникают трудности с этим. В действительности они не понимают рабочие процессы, которыми управляют, поэтому они не могут, например, преобразовать определенные виды задач, как «terraform apply», который внедряет действительные изменения в вашу инфраструктуру. Поскольку ваша CI-система озадачена, управляя ими параллельно, она становится уязвимой. Но то, что она делает с terraform, не что иное, как катастрофа – ваше состояние запутано и больше не представляет какую либо реальность. Распутывание этой неразберихи может занять целую вечность.

Но вы можете добавить этапы утверждения вручную

Да, вы можете. Но весь смысл вашей CI/CD-системы - автоматизировать вашу работу. Прежде всего, для высококвалифицированного и мотивированного профессионала становиться человекосемафором для ПО не есть самое лучшее применение. Кроме того, чрезмерная зависимость от людей для отслеживания процессов неизбежно приведет к ошибкам с высокими затратами, потому что мы, люди, гораздо больше подвержены ошибкам, чем хорошо запрограммированные машины. В конечном итоге, использовать правильный инструмент для выполнения задачи намного дешевле, чем становиться частью этого инструмента.

Но вы можете сделать состояние заблокированным!

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

И это только применение изменений. По умолчанию, выполнение “terraform plan” блокирует состояние тоже. Поэтому в действительности вы не можете управлять множественными CI задачами параллельно, даже если они предназначены только для предварительного просмотра изменений, потому что каждый из них попытается заблокировать состояние. Да, вы можете работать в обход, не блокируя состояние напрямую в CI-задачах, которые, вы знаете, не внесут каких-либо изменений состояния, но на этом этапе вы уже вложили столько работы в создание пайплайна, который при лучшем раскладе является ненадежной и требует от вас ручной синхронизации.

И это мы еще даже не обсудили безопасность.

Безопасность

«Terraform» используется, чтобы управлять инфраструктурой, которая, как правило, нуждается в учетных данных. Обычно в очень привилегированных, иногда - в административных учетных данных. И они могут причинить много вреда. Особенность CI в том, что вам нужно предоставить эти учётные данные, и, сделав это однажды, у вас не будет способа проконтролировать, как они используются.

И это то, что делает CI важным – в конце концов, он позволяют вам запускать произвольный код, как правило, основанный на некоторых конфигурационных файлах, которые вы зарегистрировали в вашем коде «Terraform». Ну, и что же остановит какого-нибудь шутника при добавлении terraform destroy -auto-approve как дополнительного CI-шага? Или распечатки учетных данных и использования их для майнинга выбранной криптовалюты?

Способы уволиться есть и получше

…Скажете вы, и мы согласны. Всё-таки, эти задачи проверяются. И даже если бы мы были недовольными работниками, мы бы все равно не сделали что-то настолько глупое. Мы получили бы «SSH session» и таким образом утекли бы эти драгоценные учетные данные. Поскольку вы вряд ли меняете их каждый день, мы приятно проведем время до использования их в наших пагубных целях. Но это всё будет невозможно с «Spacelift BTW», который генерирует одноразовые временные полномочия для главных облачных провайдеров.

Но никто не делает так!

Да, не сказать, что такие истории у всех на слуху. Много ошибок возникает с благонамеренными людьми. Но в мире инфраструктуры даже крошечная ошибка может быть причиной огромных сбоев - как та опечатка, которую мы однажды допустили в конфигурации DNS. Вот почему Spacelift добавляет дополнительный уровень политики, который позволяет вам контролировать – отдельно от вашего инфраструктурного проекта – какой код может быть выполнен, какие изменения могут быть совершены, когда и кем. Это полезно не только для вашей защиты от злоумышленников, но и позволяет вам применить систему автоматической проверки кода.

P.S.: В telegram-канале DevOps FM мы публикуем новости мира DevOps - присоединяйся!