Мы продолжаем серию статей о применении подхода GitOps к инфраструктуре нашей организации. Первую часть можно почитать тут.  

Я – ведущий DevOps инженер в IT-хабe группы компаний Dyninno. Мы (команда больше 300 человек) занимаемся разработкой ПО и отвечаем за IT инфраструктуру всех компаний группы. Dyninno – международный холдинг, который работает в трех сегментах бизнеса: авиаперелеты, финансовый сектор и индустрия развлечений (кастинг актеров). В прошлой статье я рассказывал о нашем переходе на GitOps, а сегодня хочу остановиться подробнее на управлении инфраструктурой в рамках этого перехода. Эта статья может быть интересна тем, кто задумывается о внедрении GitOps в свою инфраструктуру.   

Для большей связанности повествования повторим два ключевых тезиса из предыдущего материала:  

1. Все наши сервисы в процессе миграции на Kubernetes.  

2. Мы используем подход GitOps с ArgoCD для управления Kubernetes. 

Уже написано много материалов о том, что такое “Инфраструктура-как-Код” (IaC), поэтому я не буду останавливаться на общих вещах, и расскажу подробнее про наш опыт. 

Итак, когда зашла речь о том, какое же IaC решение использовать, мы остановили свой выбор на Terraform, а не на CloudFormation или других аналогах, даже несмотря на то, что большая часть нашей инфраструктуры расположена в AWS. Главный плюс Терраформа в том, что мы можем использовать унифицированное решение для всех сред.  

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

C чем мы столкнулись 

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

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

В результате мозгового штурма на тему улучшения workflow мы решили запускать Терраформ через GitLab-ci пайплайн. Такой подход сразу же показал качественное улучшение процесса по сравнению с локальным запуском Терраформа. Так, больше не нужно было предоставлять всем учетные данные для доступа к облаку. Но мы не были полностью удовлетворены таким решением. Во-первых, было неудобно каждый раз заходить в детали пайплайна, и искать в логах джоба результаты исполнения Терраформ команд. Это занимало много времени, особенно когда изменения вносились десятки раз в день. Во-вторых, конфигурацию пайплайна нельзя было назвать user-friendly. Например, один из темплейтов пайплайн джобов выглядел вот так: 

.plan: 
  stage: plan 
  rules: 
    # run on merge requests, when TF folder changes 
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" 
      changes: 
        - $TF_ROOT/* 
    # run on default branch, when TF folder changes 
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH 
      changes: 
        - $TF_ROOT/* 
  script: 
    # run terraform 
    - cd ${TF_ROOT} 
    - terraform init -input=false -reconfigure 
    # create plan for apply 
    - terraform plan -input=false -out="${PLAN_CACHE}" 
    # print plan for gitlab reports 
    - terraform show -json "${PLAN_CACHE}" | jq -r "${JQ_PLAN}" > "${PLAN_JSON}" 
  artifacts: 
    paths: 
      - ${TF_ROOT}/${PLAN_CACHE} 
    reports: 
      terraform: ${TF_ROOT}/${PLAN_JSON}

Такая конфигурация — это не бином Ньютона, но все же хотелось использовать что-то более простое. И в-третьих, нам нужно было передавать кеш Терраформа между джобами init/plan/apply, что требовало дополнительной конфигурации, а этого хотелось бы избежать. К тому же, поскольку мы используем временные поды, которые поднимаются только для исполнения конкретного пайплайна, нам пришлось выделить внешнее хранилище кеша, что усложнило сетап еще больше. И чем больше команд начинало работать в этом сетапе, тем больше не самых положительных отзывов мы получали. Поэтому мы начали искать другой подход.

К чему мы пришли

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

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

version: 3 
projects: 
  - dir: terraform/provision 
    terraform_version: v1.2.0 
    workflow: terraform 
    autoplan: 
      enabled: true 
      when_modified: ["**/*.tf", "**/*.tfvars"]

В итоге мы пришли к следующей схеме, которая полностью перекрывает наши потребности: 

Что мы получили в результате  

Приведу несколько преимуществ, которые мы ощутили, перейдя на подход Инфраструктура-как-Код (IaC) с помощью Терраформа и Atlantis:  

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

• Все изменения легко отслеживаются и ими можно управлять через IaC с Терраформом. Вся история доступна через контроль версий, что улучшило управляемость.  

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

Используя Терраформ и IaC в целом, мы смогли оптимизировать управление нашей инфраструктурой и снизили влияние человеческого фактора.

Автор:  
Вадим Гедзь, ведущий DevOps инженер, Dyninno Group 
https://github.com/shini4i