linuxlab.io
Учебники▾
  • Линукс и сети
    Файловая система, процессы, TCP/IP, BGP и OSPF
    →
  • Terraform и IaC
    HCL, state, plan/apply на sandbox LocalStack
    →
  • Git и GitHub
    Объектная модель, plumbing, ветвление, GitHub Actions
    →
Все учебники →
ЦеныО платформеВойтиСоздать аккаунт
/
Intro
Lessons
Footer
linuxlab-УчебникиЦеныО платформеКонфиденциальность и куки
Copyright © 2026 LinuxLab. Все права защищены.
linuxlab.io
Учебники▾
  • Линукс и сети
    Файловая система, процессы, TCP/IP, BGP и OSPF
    →
  • Terraform и IaC
    HCL, state, plan/apply на sandbox LocalStack
    →
  • Git и GitHub
    Объектная модель, plumbing, ветвление, GitHub Actions
    →
Все учебники →
ЦеныО платформеВойтиСоздать аккаунт
/
  • Введение
  • Уроки
  • How it works
  • База знаний
  • Шпаргалка
  • Capstone
  • Собеседование
home/terraform/how/tf-remote-backend-lock

how/state

Remote backend и lock: как двое инженеров работают с одним state

S3 хранит state, DynamoDB держит lock. Что происходит, когда двое запускают apply одновременно, и почему «команда из одного» - единственный сценарий, где можно без этого жить.

Локальный terraform.tfstate рядом с main.tf отлично работает, пока ты один. Как только в команде появляется второй человек - обязателен remote backend. Без него вы либо коммитите state в git и редактируете его в merge-конфликтах (катастрофа), либо теряете изменения один другого (тихая катастрофа).

Стандарт де-факто в AWS - S3 + DynamoDB:

  • S3 хранит сам файл state, плюс шифрование и версионирование.
  • DynamoDB держит lock - крошечная таблица, в которой Terraform пишет «я сейчас работаю».

Жми ▶ - пройдём по сценарию, когда двое одновременно делают apply.

step 1/5·00 · двое инженеров, один state
АлисаIDLEidleБобIDLEidleREMOTE BACKENDS3 · terraform.tfstateserial: 10SSE-KMS encryptedversioning enabledDynamoDB · lock table(no lock)двое инженеров · один state · никто пока ничего не делает

§ шаги

  1. Алиса и Боб работают с одной инфраструктурой. Они запускают terraform apply со своих ноутбуков, но state хранится не у них, а в S3-бакете команды.

    В DynamoDB пока пусто - никто не работает. State в S3 имеет serial: 10 (то есть на нём уже сделано 10 успешных apply кем-то из команды).

итого

Что важно запомнить:

  • Lock - это не транзакция БД, это просто запись в DynamoDB: PutItem с условием «ключ не существует». Кто успел первым - взял lock; второй получает ConditionalCheckFailed и видит «Lock held by …».
  • На lock есть TTL в Terraform Cloud / Atlantis, но в чистом DynamoDB - нет. Если terraform apply упал по сети, lock остаётся висеть, пока кто-нибудь не сделает terraform force-unlock <LockID>. Это нормальная процедура, не повод паниковать.
  • Каждый apply увеличивает serial в state. Backend перед записью проверяет, что serial вырос - это защита от одновременных перезаписей (даже без lock).
  • GCS имеет встроенный lock (без отдельной таблицы). Terraform Cloud - тоже. Azure Storage - тоже. Только S3 требует DynamoDB сбоку.
  • Не путать lock с state encryption. Lock защищает от concurrent-write; шифрование - от чтения посторонними. Нужны оба.

Дальше: tf-state-mv-rm-import про то, как руками двигать ресурсы внутри state-файла.

§ копнуть в базу знаний

  • tf-remote-backend-s3Remote backend на S3 с DynamoDB
  • tf-stateЧто такое state и почему он source of truth
  • tf-state-anatomyАнатомия state-файла
  • tf-init-backendsterraform init и backend
  • tf-large-scale-stateБольшой state: разбиение и оптимизация

§ попробовать руками

  • ›tf-intermediate-06-remote-backend- Настройка S3 + DynamoDB backend
  • ›tf-intermediate-12-multi-env-layout- Multi-env layout: один backend на окружение
Footer
linuxlab-
Copyright © 2026 LinuxLab. Все права защищены.
Учебники
Цены
О платформе
Конфиденциальность и куки