Как управлять инфраструктурой при переходе на GitOps

[trublast]

>Главный плюс Терраформа в том, что мы можем использовать унифицированное решение для всех сред

Поделитесь, как вы переносите свою IaC, описанную терраформом, например из AWS в GCP, или в какой-нибудь OpenStack?

[Numen_Divinum]

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

[Ezhische]

Можно и код унифицировать через собственные модули с интерфейсом независимым от облачного провайдера

[smarthomeblog]

Terraform-ом можно описывать не только инфраструктуру в AWS, но и сопутсвтующие сервисы тоже - дашборды в Sumo Logic, алерты в PagerDuty или Grafana. Ну и так далее. Плюс подозреваю, найти инженера, знающего Terraform и имеющего опыт работы с ним проще, чем на вендорозависимый CloudFormation.

[ALexhha]

Плюс подозреваю, найти инженера, знающего Terraform и имеющего опыт работы с ним проще, чем на вендорозависимый CloudFormation

Легче, только опыт работы с тераформом в aws не особо поможет в gcp или azure. Слишком все разное. Ну а сам по себе terraform, без привязки к провайдеру, осваивается за пару недель.

[Hledacek]

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

[smarthomeblog]

Мы сделали проще. В PR при создании или любом последующем коммите добавляем план, сгенерированный Терраформом. При мерже, идет автоматический apply. Крутится все на self-hosted runners, прибитых к AWS аккаунтам. Так что никаких кредов не нужно.

      - name: Terraform Plan
        id: plan
        run: |
          terraform plan -refresh=false -no-color -out out.plan

      - name: Comment PR
        if: github.event_name == 'pull_request'
        uses: peter-evans/create-or-update-comment@v2
        with:
          issue-number: ${{ github.event.pull_request.number }}
          body: ${{steps.plan.outputs.stdout}}

      - name: Terraform Apply
        if: github.ref == 'refs/heads/develop' && github.event_name == 'push'
        run: terraform apply -auto-approve

[kroks]

Мы планировали использовать такой подход в нашем сетапе (например используя https://github.com/kharkevich/issue-ops-approval для аппрувов из комментов), но когда вы делаете все на GitHub actions остается вопрос с дополнительными фичами (drift detection, защита от workflow который может быть сконфигурирован лезть в production etc.).

У Atlantis с другой стороны есть проблемы со скейлированием (да, все еще все хранится в файловой БД) и до enterprise применения еще не дотягивает без костылей

[smarthomeblog]

Спасибо за развернутый комментарий. Можно немного подробнее про защиту от лазанья в продакшен? Про drift detection уже нагуглил. Спасибо за наводку.

[teamfighter]

Тоже используем atlantis, но терраформ сверху ещё обмазали terragrunt. План для атлантиса можно составлять автоматически, с помощью terraform-atlantis-config.