Передача проекта и безопасное завершение лаборатории

Завершим «Контур» передачей проекта другому человеку. Он должен понять, какие объекты входят в управление, какие файлы переносимы и где лежит настоящее состояние. Для этой цели недостаточно архива с HCL: без контекста человек может начать новую рабочую копию рядом с уже существующими ресурсами или применить план к неверной Docker-среде. В уроке подготовим регламент, не выполняя выпуск или удаление.

Текущий проект содержит два сайта home и docs, общую сеть и образ, дочерний модуль контейнера и отдельный пример adoption. Окружения dev и preview предполагают разные рабочие копии, префиксы и порты. У каждого корня собственное состояние. Первая запись передачи должна объяснять эту карту владения. Имена в Docker помогают ориентироваться, но не заменяют ссылку на конкретный корень и state.

Три комплекта данных

Первый комплект — исходники: .tf, шаблон страницы, документация, пример входных значений и будущий настоящий lockfile после независимой установки. Они описывают намерение и требования. Второй комплект — рабочее состояние и его ограниченные резервные копии. Они связывают намерение с реальными объектами. Третий — операционные сведения: фактический endpoint, ответственный, назначение окружения и последний согласованный план. Хранить всё вместе в публичном архиве неправильно.

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

Команды для отдельной самостоятельной работы читателя; при написании не выполнялись:

terraform plan -destroy -out=destroy.tfplan
terraform show destroy.tfplan

В HANDOVER.md зафиксирован порядок ответственности. Перед изменением выбирают рабочий корень и подтверждают Docker endpoint. Затем согласуют входы, читают разницу и отдельно рассматривают удаление или замену. Это не формальная церемония: порт 8088 и имя kontur-home могут принадлежать действующей странице, которой уже пользуется коллега. Читатель плана должен знать назначение затронутого ресурса, иначе технически правильное действие останется организационно неверным.

Восстановление связи с реальностью

Если потерян state, но контейнеры существуют, запуск нового применения не является автоматическим восстановлением прежнего управления. Возможны конфликты имён и появление ненужных объектов. Сначала ищут согласованную резервную копию и выясняют, что изменилось после её создания. При отсутствии подходящей копии может потребоваться принятие ресурсов через импорт с подробным описанием. Эта операция уже разобрана в девятом уроке и не должна выполняться вслепую.

Если state сохранился, но контейнер исчез, ситуация иная. Обычный план может предложить восстановление объявленного ресурса. Но сначала нужно выяснить причину исчезновения: случайная очистка, осознанное завершение окружения или неправильный endpoint. Восстановить временный стенд после согласованного завершения было бы ошибкой. Наличие ресурса в исходниках выражает прежнее намерение; если оно больше не актуально, конфигурация требует изменения.

Резервирование состояния также не резервирует содержимое приложения. В нашем Nginx содержимое строится из HTML-шаблона и потому воспроизводится из исходников. Если добавить загрузки пользователей, эту модель надо расширить внешним хранилищем и процедурой резервирования данных. Не обещайте, что terraform state pull сохранит файлы внутри контейнера. Он решает другую задачу — получение записи управления ресурсами.

Завершение лаборатории

Для удаления предназначен план разрушения выбранного корня. Читатель сначала получает и рассматривает его, проверяя имена и адреса. Затем отдельно решает применять ли его к своей лаборатории. Сохранённый destroy-план тоже является рабочим артефактом, который нельзя переносить как универсальную команду другому владельцу. Параметры и состояние должны соответствовать именно тем объектам, жизнь которых заканчивается.

Наш keep_locally = true оставляет образ на локальном хосте после прекращения управления ресурсом образа. Поэтому завершение основного корня не означает полного исчезновения всех скачанных байтов. Это может быть полезно для других лабораторий. Если цель состоит в освобождении диска, отдельно рассматривают реальные владельцы образов и контейнеров, а не запускают общую очистку Docker без понимания зависимостей. Регламент проекта ограничивается ресурсами «Контура».

Папка adoption имеет отдельный state. Разрушение основного корня не должно автоматически удалять принятый в неё контейнер. Это ясная граница ответственности, но также обязанность передающего: назвать оба корня. Если новая команда не знает о втором, ресурс может остаться без дальнейшего сопровождения. Передача проекта включает список самостоятельных областей управления и объяснение, какие из них надо сохранить, изменить или завершить.

Переход от лаборатории к инфраструктуре

Что потребуется для настоящего сервиса? Устойчивый вход вместо набора учебных loopback-портов, защищённое хранение командного состояния, наблюдение за приложением, стратегия обновления и восстановления, проверенные зависимости и подходящая модель данных. Эти решения не появляются автоматически после выделения модуля. Наш курс создаёт основу для их обсуждения: декларативное намерение, зависимости, идентичность адресов, планы, импорт и drift.

Перенос к облачному провайдеру также не сводится к замене слова docker в одном файле. Изменятся схемы ресурсов, права, сеть, способы хранения и стоимость. Привычка читать план и отделять состояние полезна в обеих средах, но конкретные конфигурационные блоки не универсальны. Сначала проектируют новую границу управления и её эксплуатационный контракт. Локальная лаборатория не создаёт облачных ресурсов и не требует платной подписки.

В результате другому человеку передаётся понятное описание проекта вместе с исходниками и честным перечнем непроверенного. Он может проследить, откуда взялся каждый ресурс и что означает его изменение. Для самостоятельного продолжения выберите один новый результат: например, устойчивый HTTP-вход или отдельное хранение состояния команды. Сохраняйте причинную связь между задачей и новым механизмом, вместо превращения «Контура» в коллекцию случайных инфраструктурных флагов.

Что оставить следующему автору

Хорошая передача содержит не только текущую конфигурацию, но и причину выбранных ограничений. Loopback-порты объясняются локальной лабораторией, одна сеть — общим транспортом сайтов, keep_locally — возможным повторным использованием образа. Если следующий автор знает эти причины, он сможет изменить решение вместе с задачей. Если видит только набор флагов, рискует сохранить устаревшую настройку случайно.

Последняя полезная запись относится к неопределённости: команды не выполнялись, фактический daemon не проверялся, зависимости не устанавливались, поведение обновления не измерялось. Это не отменяет ценность объяснения, но задаёт границу приёмки. Перед эксплуатацией новый владелец должен отдельно подтвердить профиль среды и наблюдаемые результаты. Учебный текст предоставляет последовательную модель, исходники и ожидаемые эффекты; готовность настоящей системы устанавливается самостоятельной проверкой в её окружении.

Оглавление серии, общая подборка и полный архив исходников. Для этого урока выберите lesson-12.

Первичные источники: Версии Terraform, Учебник Terraform и Docker, Схема Docker container 3.6.2, Схема Docker image 3.6.2, Адреса и moved, Локальный backend, Import, Refresh-only plan.

Редакционный статус: локальный черновик. Учебные команды, приложение и проверки не запускались; описанные результаты ожидаемые. Профиль версий закреплён, разрешённый lockfile не создавался.