Координация двух рабочих каталогов Terraform

Введение

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

Вам нужны знания об удалённом состоянии S3 и обычных планах и применениях Terraform. Эта новая среда предоставляет обе инициализированные рабочие копии, контролируемое изменение с задержкой, хранилище отчётов и финансовое эталонное хранилище; предыдущая VM или личная учётная запись AWS не нужны.

Связь с сертификацией

Обзор лабораторной работы

Определение двух копий одной среды

На этом шаге установите, что два рабочих каталога намеренно управляют одной средой. Это не отдельные развёртывания dev и preview: обе конфигурации backend выбирают reports/shared.tfstate в coordination-team-state.

cd /home/labex/project/shared-state-operators
cat operator-a/shared.s3.tfbackend
cat operator-b/shared.s3.tfbackend

Обе используют use_lockfile = true. Пока работает процесс записи, Terraform создаёт рядом с этим состоянием собственный объект блокировки S3, чтобы другой процесс записи не действовал на основе конфликтующего снимка.

terraform -chdir=operator-a state show aws_s3_bucket.reports
terraform -chdir=operator-b state show aws_s3_bucket.reports

Обе определяют coordinated-daily-reports. Прочитайте его реальный отчёт и оставьте финансовое эталонное хранилище без изменений:

aws s3 \
  cp s3://coordinated-daily-reports/report.txt -

Ожидайте Daily sales: 120 orders. Изучите предоставленное контролируемое изменение:

cat operator-a/pending-change.tf

Только для этого упражнения ресурс terraform_data приостанавливает своё создание на 30 секунд через local-exec. Эта пауза позволяет наблюдать блокировку реального процесса записи. Обычные обновления ресурсов тоже удерживают блокировку; искусственная задержка не является рекомендацией для развёртывания в рабочей среде. Это контролируемое изменение состояния присутствует в обеих конфигурациях, но ещё не применено.

Наблюдение за реальной конкуренцией и штатным освобождением блокировки

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

& запускает процесс оператора A в фоновом режиме; $! сохраняет идентификатор его процесса. Его вывод направляется в журнал, чтобы ошибку второго оператора было удобно читать. Ограниченный цикл ожидает фактическую блокировку S3, а не предполагает фиксированное время запуска. Условие if позволяет изучить ожидаемо неудачный план, а wait возвращает реальный статус завершения процесса записи. Это два независимых процесса Terraform, хотя вы запускаете их из одного Terminal.

terraform -chdir=operator-a apply -auto-approve > /tmp/operator-a.log 2>&1 &
WRITER_PID=$!
echo "$WRITER_PID"
for attempt in $(seq 1 60); do
  if aws s3api head-object \
    --bucket coordination-team-state \
    --key reports/shared.tfstate.tflock > /dev/null 2>&1; then
    break
  fi
  sleep 1
done
aws s3api get-object \
  --bucket coordination-team-state \
  --key reports/shared.tfstate.tflock \
  /tmp/current-lock.json
cat /tmp/current-lock.json
if terraform -chdir=operator-b plan -lock-timeout=0s; then
  echo 'Unexpected: the competing plan acquired the lock.'
  false
else
  PLAN_EXIT=$?
  echo "$PLAN_EXIT"
fi
wait "$WRITER_PID"
cat /tmp/operator-a.log

Конкурирующий план должен завершиться с кодом 1 и сообщением Error acquiring the state lock. Ошибка аутентификации или подключения не доказывает конкуренцию за блокировку. Сведения о блокировке принадлежат реальному процессу записи; загрузка файла с именем блокировки не подтверждала бы координацию процессов записи.

Оператор A должен успешно завершить контролируемое создание и штатно освободить блокировку. Не отключайте блокировки, не удаляйте блокировку активного процесса записи и не используйте force-unlock, чтобы позволить второму оператору продолжить работу. В AWS View хранилища отчётов остаются доступными всё время; блокировка координирует управление, а не доступ к чтению отчётов.

Продолжение из другой рабочей копии после освобождения блокировки

На этом шаге дайте оператору B штатно получить блокировку backend после завершения процесса записи. Теперь вторая рабочая копия должна прочитать обновлённое общее состояние, а не независимо создавать ещё одну копию ресурсов.

terraform -chdir=operator-b plan -lock-timeout=5s

Ожидайте No changes. Та же команда, которая блокировалась во время записи, теперь может штатно получить и освободить блокировку.

Изучите итоговое состояние из обоих каталогов:

terraform -chdir=operator-a state list
terraform -chdir=operator-b state list

Каждый список содержит aws_s3_bucket.reports и terraform_data.coordination. Это одна и та же среда и общая запись управления, а не два развёртывания.

aws s3 \
  cp s3://coordinated-daily-reports/report.txt -

Исходный текст остаётся доступным. Изучите историю версий состояния:

aws s3api \
  list-object-versions \
  --bucket coordination-team-state \
  --prefix reports/shared.tfstate

У фактического состояния есть история, а в текущем списке объектов не должно остаться активного .tflock. Исторические версии блокировки или маркеры удаления не являются активной блокировкой процесса записи.

terraform -chdir=operator-a plan

Здесь тоже ожидайте No changes. Фоновые проверки отличают реальную конкуренцию процессов Terraform от вручную созданной блокировки и проверяют исходные версии отчётов, штатное освобождение блокировки и последующий успешный доступ. Оставьте общее хранилище и backend их владельцам.

Резюме

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