Обзор Docker

Opfield назначает рабочей нагрузке Docker долговременную идентичность продукта, а не сводит всё приложение к запущенному Container. Эта идентичность хранит конфигурацию, права доступа, историю жизненного цикла, связи и желаемое состояние, которое Opfield может восстановить после сбоя.

Выбирайте самый высокий уровень управления, соответствующий приложению:

Container: одна среда выполнения с прямым управлением, отдельной конфигурацией и жизненным циклом.
Deployment: стабильная идентичность приложения и два слота среды выполнения для сине-зелёных релизов с проверкой состояния и возможностью отката.
Compose Project: обнаруженное внешнее приложение или одновузловое приложение под управлением Opfield с проверенной конфигурацией, неизменяемыми ревизиями, операциями жизненного цикла, журналами, Routes и привязками баз данных.
Источник Git: входные данные доставки для Container, Deployment и Pages, а не отдельная сущность приложения.

Workload Availability (HA) доступна на Business и Enterprise для подходящих Containers, Deployments и целых Compose Projects без монтирований. Она добавляет фиксированное число реплик или один обслуживающий экземпляр с переключением при отказе между независимыми Docker-узлами, сохраняя идентичность ресурса.

Выбор модели эксплуатации

Выбор зависит прежде всего от владения и восстановления, а не от количества полей в форме.

Потребность	Рекомендуемая модель	Основной компромисс
Один сервис с простым жизненным циклом	Container	Прямое и гибкое управление, но релизом и откатом управляет оператор
Релизы с проверкой состояния и сохранённым кандидатом для отката	Deployment	Более безопасный релиз за счёт двух управляемых слотов среды выполнения
Несколько сервисов, которые должны меняться как одно приложение	Compose Project	Одна ревизия и одна граница операции, один узел на экземпляр; необязательная Availability всего проекта на Business/Enterprise
Воспроизводимые артефакты из системы контроля версий	Источник Git и владеющий ресурс	Добавляет происхождение сборки; безопасность развёртывания всё равно обеспечивает Container, Deployment, Compose Project или Pages

Выбирайте владельца самого высокого уровня, который отражает обычный выпуск приложения и его восстановление при инциденте. Не представляйте многосервисное приложение набором несвязанных Containers только ради отказа от Compose Project. Не выбирайте Deployment, если приложение использует общее изменяемое состояние, которое нельзя безопасно разделить между слотами релиза.

Руководитель платформы должен назначить ответственных за ресурс приложения, его данные, публичные Routes, доступ к реестру и решение об откате. Opfield записывает и применяет эти границы, но не может определить, обратима ли миграция данных на уровне приложения.

Границы владения

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

Некоторые объекты Docker принадлежат ресурсу более высокого уровня. Слотами Deployment управляют через Deployment, а Containers с метками Compose объединяются в контексте обнаруженного проекта. Не изменяйте такие дочерние объекты через автономный жизненный цикл: прямые действия могут создать расхождение между фактическим состоянием демона и конфигурацией в Opfield.

Контейнеры, созданные не через Opfield, тоже видны и доступны для операций. Автономный контейнер, запущенный командой docker run, можно перезапускать и просматривать по правам уровня ресурса без принятия под управление, а внешний проект Compose остаётся доступным только для чтения до принятия. См. Контейнеры, созданные не через Opfield и Примите внешний проект во владение.

Внутренние ресурсы Opfield могут включать метки, имена в среде выполнения, сети, тома, учётные данные, артефакты сборки и записи Tasks. Считайте их деталями реализации, если Opfield не предоставляет для них явного действия. Удаление или переименование таких объектов через инструменты Docker может нарушить согласование состояния, маршрутизацию или последующий откат.

Как выполняются операции жизненного цикла

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

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

Рабочие нагрузки обращаются к базам данных одним из двух способов. Управляемую базу данных можно привязать к Container, Deployment или службе Compose, и Opfield передаст параметры подключения для отдельной идентичности движка. К внешней базе нагрузка подключается по параметрам, которые вы храните в её секретах. См. Управляемые и внешние базы данных: сравнение.

Безопасная последовательность эксплуатации

Убедитесь, что выбранная нода Docker подключена и сообщает требуемую возможность среды выполнения.
Перед изменением конфигурации проверьте владельца ресурса и связанные с ним ресурсы.
Выполните одно намеренное изменение жизненного цикла и проследите его Task до завершения.
Проверьте состояние, журналы приложения и ожидаемый Route или приватное подключение.
Сохраняйте заведомо исправный образ или предыдущий слот Deployment до окончания окна восстановления.

Если операция завершилась ошибкой, откройте её Task и по сообщению определите неисправный уровень: образ, конфигурацию, хранилище, порт, права или соединение с нодой. Исправьте указанное предварительное условие и повторите действие из Opfield. Не удаляйте принадлежащие Opfield объекты Docker как универсальный способ восстановления.

Критерии успеха

Рабочая нагрузка готова, когда желаемое и наблюдаемое состояния совпадают, владеющая операция завершена, состояние и журналы приемлемы, а реальный путь доступа работает. Для публичного приложения это Route, для приватного — Secure Link или зависимость от базы данных. Работающий процесс без проверенного доступа не считается успешным развёртыванием.

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