GitOps: Определение дрейфа вашей инфраструктуры Terraform / Terragrunt / Habr

Всем привет.

Дисклеймер: сказу скажу, что пишу статью по ходу дела, "код" в ней рабочий, но не претендует на какие-либо best practices, поэтому не придирайтесь :) Цель статьи: донести до интересующейся русскоязычной части населения общие принципы, возможно разбудить интерес поразбираться самостоятельно и сделать что-то гораздо лучше и интереснее. Итак поехали!

Допустим Вы работаете с Terraform / Terragrunt (второе здесь непринципиально, но лучше изучайте, если ещё не используете) и автоматизируете инфраструктуру, например, в AWS (но совершенно необязательно AWS). Инфраструктура в коде репозитория, разворачивается из него же, казалось бы вот оно GitOps счастье :)

Всё идёт хорошо, пока какой-то пользователь не поменял что-то руками через консоль / UI и конечно забыл об этом кому-либо сказать. А то и сделал что-то нехорошее намеренно. И вот он ваш дрейф: код и инфраструктура больше не совпадают! :(

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

Как обычно, есть много различных путей добиться желаемого. Например, недавно на горизонте появилась неплохо развивающаяся утилита https://github.com/cloudskiff/driftctl , которая может даже больше, чем предложу Вашему вниманию чуть ниже я, но на момент написания статьи driftctl как минимум не поддерживает работу с aws provider v2, а также не умеет в multi region, что делает его использование невозможным в большинстве серьёзных проектов. Но ребята обещают доделать её через месяц-два.

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

создаём pipeline, который или по расписанию (в Gitlab можно воспользоваться Pipeline schedules) или по кругу будет делать terraform plan
при нахождении дрейфа (diff в плане) pipeline будет, например, отправлять сообщение с его содержанием в Slack.

Аналогично можно реализовать и, например, создание issue в любом из используемых вами репозиториев, где поддерживается их создание через api и любое другое действие, например apply, который вернёт инфраструктуру к её эталонному состоянию. Или всё-таки импортировать изменение в state, если оно действительно необходимо.

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

account_1/
├── eu-central-1
│   ├── dev
│   │   ├── eks
│   │   │   ├── terragrunt.hcl
│   │   │   └── values.yaml
│   │   └── s3-bucket
│   │       ├── terragrunt.hcl
│   │       └── values.yaml
│   ├── prod
│   │   ├── eks
│   │   │   ├── terragrunt.hcl
│   │   │   └── values.yaml
│   │   └── s3-bucket
│   │       ├── terragrunt.hcl
│   │       └── values.yaml
│   └── staging
│       ├── eks
│       │   ├── terragrunt.hcl
│       │   └── values.yaml
│       └── s3-bucket
│           ├── terragrunt.hcl
│           └── values.yaml
├── us-east-1
│   ├── dev
│   │   ├── eks
│   │   │   ├── terragrunt.hcl
│   │   │   └── values.yaml
│   │   └── s3-bucket
│   │       ├── terragrunt.hcl
│   │       └── values.yaml
│   ├── prod
│   │   ├── eks
│   │   │   ├── terragrunt.hcl
│   │   │   └── values.yaml
│   │   └── s3-bucket
│   │       ├── terragrunt.hcl
│   │       └── values.yaml
│   └── staging
│       ├── eks
│       │   ├── terragrunt.hcl
│       │   └── values.yaml
│       └── s3-bucket
│           ├── terragrunt.hcl
│           └── values.yaml
└── terragrunt.hcl

В приведённом выше примере в папке account_1 находятся 2 папки: us-east-1 и eu-central-1 , по имени регионов AWS. Иногда удобно организовать структуру именно так и тогда имена папок можно использовать как значение для передачи в модуль с помощью Terragrunt функции/й, например, таких "${basename(get_terragrunt_dir())}"

Аналогичная логика с папками имеющими в названии окружение и далее идут названия самих компонентов, которых в этом примере 2: eks и s3-bucket

Если смотреть от корня репозитория, то путь до каждого из файлов внутри папки компонента

<account_name>/<region>/<environment>/<component>/*

Т.е. "в общих чертах" */*/*/<component>/*

Выберем, например, компонент s3-bucket (на самом деле конечно можно реализовать это для всего сразу, но бывают нюансы и здесь интересно показать принцип).

Не забудьте подключить Incoming WebHooks в Slack и записать полученный Webhook URL. Делается это так: https://api.slack.com/messaging/webhooks

Тогда вот такой скрипт может выполнять требуемое планирование в pipeline и отправку в Slack diff'а при его нахождении:

#!/bin/bash

ROOT_DIR=$(pwd)

plan () {
  echo -e "$(date +'%H-%M-%S %d-%m-%Y') $F"

  CURRENT_DIR=$(pwd)
  PLAN=$CURRENT_DIR/plan.tfplan

  terragrunt run-all plan --terragrunt-non-interactive -lock=false -detailed-exitcode -out=$PLAN 2>/dev/null || ec=$?
  
  case $ec in
    0) echo "No Changes Found"; exit 0;;
    1) printf '%s\n' "Command exited with non-zero"; exit 1;;
    2) echo "Changes Found! Reporting!"; 
  
       MESSAGE=$(terragrunt show -no-color ${PLAN} | sed "s/\"/'/g");    # let's replace the double quotes from the diff with single as double quotes "break" the payload
       curl -X POST --data-urlencode "payload={\"channel\": \"#your-slack-channel-here\", \"username\": \"webhookbot\", \"text\": \"DRIFT DETECTED!!!\n ${MESSAGE}\", \"icon_emoji\": \":ghost:\"}" https://hooks.slack.com/services/YOUR/WEBHOOK/URL_HERE;;
  esac
}

N="$(($(grep -c ^processor /proc/cpuinfo)*4))"    # any number suitable for your situation goes here

for F in */*/*/s3-bucket/*; do
  ((i=i%N)); ((i++==0)) && wait    # let's run only N jobs in parallel to speed up the process
  cd $ROOT_DIR
  cd $F
  plan &    # send the job to background to start the new one
done

Меняем что-нибудь руками, запускаем pipeline или ждём его выполнения и радуемся :)

На этом на сегодня всё!

Если Вы решали подобную задачу иначе, есть конкретные замечания/предложения, или просто хочется что-то спросить, то, по мере возможности, готов выслушать либо в комментариях, либо в личке, например, в телеграм @vainkop

P.S.: имхо проект https://github.com/cloudskiff/driftctl мне лично кажется действительно полезным и решающим правильную задачу и хороших аналогов ему нет, так что прошу поддержать ребят, а по возможности внести свою лепту ибо open source.

Всем хорошего настроения!

GitOps: Определение дрейфа вашей инфраструктуры Terraform / Terragrunt

{{ titleHtml }}

{{ titleHtml }}