Containers

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

Когда Container — правильный владелец

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

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

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

Контейнеры, созданные не через Opfield

Docker-демон сообщает обо всех контейнерах на своей ноде, а не только о созданных через Opfield. Контейнер, запущенный командой docker run или другим инструментом без меток проекта Docker Compose, появляется в Docker > Containers как обычный автономный Container со стабильной идентичностью ресурса в Opfield. Отдельный шаг принятия под управление не нужен: пользователи с соответствующими областями прав могут смотреть его журналы, статистику и процессы, запускать, останавливать, перезапускать и принудительно завершать его, открывать консоль и файловый браузер, изменять и пересоздавать его.

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

Два других вида контейнеров обрабатываются иначе:

• Контейнеры Compose. Контейнер с меткой com.docker.compose.project принадлежит своему Compose Project и не показывается как автономный Container. Для его служб остаются доступны журналы, мониторинг, консоль и работа с файлами. Запуск, остановка, перезапуск, изменение, пересоздание, дублирование и удаление отдельных контейнеров Compose отклоняются — независимо от того, внешний это проект или управляемый Opfield.
• Внутренние контейнеры Opfield. Служебные контейнеры, которые Opfield запускает для себя, скрыты от пользовательских API жизненного цикла.

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

Перед началом

Вам нужны доступ к целевой ноде Docker и право создавать или изменять Container. Убедитесь, что образ доступен в разрешённом реестре, на ноде достаточно ресурсов, а запрошенная среда выполнения поддерживается. До выбора имени проверьте порты, Routes, привязки баз данных, управляемые тома и секреты: эти связи могут повлиять на последующее переименование, миграцию или удаление. Container можно привязать к управляемой базе данных; к внешней базе он подключается по параметрам, сохранённым в секретах Container. См. Управляемые и внешние базы данных: сравнение.

Новые привязки каталогов хоста (bind mounts) отклоняются. Для новых постоянных данных используйте локальные тома под управлением Opfield. Устаревшие привязки могут сохраняться при обычном обновлении, но после удаления их нельзя снова добавить через Opfield.

У ворклоада с устаревшими привязками каталогов хоста они сохраняются при изменениях без смены образа: правке переменных окружения, привязке базы данных или хранилища, переключении слота деплоя. Для таких изменений docker:containers:mounts не нужен. Новый образ получает тот же доступ к хосту, поэтому для его смены право нужно: у того, кто запускает изменение, а для автоматического деплоя из Git и вебхуков — у учётной записи, которая последней сохранила источник или вебхук, на момент деплоя. У вебхуков, сохранённых до 2.11, учётная запись не записана: на таких ворклоадах они отклоняются, пока их не пересохранит пользователь с этим правом.

Среда выполнения Default доступна на поддерживаемых нодах Docker. Защищённая среда выполнения gVisor требует подтверждённой работоспособной возможности и несовместима с GPU, devices, привязками каталогов хоста, миграцией и экспортом архива.

Создайте и обновите Container

1. Выберите ноду Docker и образ; для рабочей среды по возможности используйте неизменяемый дайджест.
2. Задайте command, entrypoint, переменные среды, зашифрованные секреты, labels, порты, политику перезапуска, ограничения ресурсов, проверки состояния и управляемые тома.
3. Проверьте итоговую конфигурацию и создайте Container.
4. Следите за Task создания, пока демон не сообщит состояние среды выполнения.
5. До направления трафика проверьте состояние, журналы и каждый Route или приватное подключение к базе данных.

Некоторые пространства имён labels зарезервированы, потому что Opfield и Docker Compose используют их, чтобы размещать, группировать или скрывать контейнеры: любые метки, начинающиеся с com.docker.compose., wiolett.gateway., net.wiolett.gateway. или com.wiolett.gateway., а также метка gateway.sandbox. Создание Container с такой меткой отклоняется в Console, REST API и MCP с сообщением Labels <names> are reserved for Gateway and Docker Compose. При пересоздании или изменении Container его метки передаются целиком: уже имеющиеся зарезервированные метки можно вернуть без изменений, а добавление или изменение такой метки завершается ошибкой 400 RESERVED_DOCKER_LABEL. Duplicate не переносит зарезервированные метки в копию и сохраняет только собственные записи Docker-демона о скопированной конфигурации, например происхождение группы GPU. Более старые Docker-демоны копируют все метки, поэтому на ноде с необновлённым демоном дублирование контейнера с зарезервированными метками отклоняется с 409 UNSUPPORTED_DAEMON, пока демон не обновлён. Импорт архива контейнера не отклоняет архив, а удаляет из него метки Compose и метки архива, развёртываний и миграций Opfield.

На ноде Docker, где драйвер журналов по умолчанию — json-file, Opfield ограничивает журналы каждого создаваемого или пересоздаваемого контейнера без собственных настроек журналирования тремя файлами по 50 МБ. Проекты Compose получают такой же лимит для каждой службы без собственного раздела logging, см. Поддерживаемая конфигурация Compose. Другие драйверы журналов не меняются, а если на ноде в /etc/docker/daemon.json заданы log-opts по умолчанию, они сохраняются. Когда скрипт установки ноды Docker сам ставит Docker, он записывает этот файл с той же ротацией 50 МБ × 3, поэтому ограничены и контейнеры, созданные в обход Opfield.

Чтобы найти контейнеры, журналы которых всё ещё растут без ограничений, создайте оповещение для контейнеров по метрике Log Size (MB). Она учитывает файл журнала контейнера и его ротированные копии на ноде; Docker-демон, который ещё не обновлён, сообщает ноль.

Используйте Recreate, если изменение конфигурации требует заменить процесс. Opfield сохраняет стабильную идентичность ресурса и заново создаёт требуемую среду выполнения. Используйте Duplicate, если нужен отдельный ресурс с независимыми правами доступа и историей жизненного цикла. Используйте Rename только после проверки зависимых Routes, привязок и интеграций. Имя, занятое источником Git, контейнер которого ещё ждёт первой сборки, нельзя получить созданием, дублированием, переименованием или импортом другого контейнера: запрос завершается ошибкой 409 NAME_IN_USE. Удаление контейнера удаляет и его источник Git, а переименование переносит источник на новое имя.

Duplicate копирует собственные секреты контейнера, но не его привязки к базам данных и хранилищам: переменные, которые они добавляют, в копию не попадают. Просмотр контейнера (inspect), вкладка Environment и экспорт архива никогда не раскрывают пароли привязок и ключи привязок хранилищ. Для смены образа контейнера нужны docker:containers:environment и docker:containers:secrets, потому что новая среда выполнения получает окружение и секреты контейнера, а для подключения контейнера к сетям нужно право на изменение этих сетей.

Проверяйте и эксплуатируйте

Страница сведений служит эксплуатационной записью. Сравните желаемое и наблюдаемое состояния, результат проверки, идентичность образа, последние Tasks и журналы. Обзор показывает профиль среды выполнения контейнера, например Secure · gVisor, а мониторинг — его ограничения памяти и PID рядом с фактическим потреблением. Stop для контейнера, в котором ничего не выполняется (созданного, завершённого или «мёртвого»), завершается сразу. Используйте Console и доступ к файлам только в рамках выданных областей и не превращайте интерактивную Console в обычный способ развёртывания.

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

Чтобы Container приватно обращался к одному порту другой рабочей нагрузки или чтобы другие рабочие нагрузки обращались к нему без публикации порта, используйте связи контейнеров в блоке Container Links на его вкладке Environment.

Обработка сбоев и очистка

Перед повторной попыткой устраните причину: ошибку загрузки образа, недоступные учётные данные реестра, конфликт портов, недопустимую точку монтирования, неподдерживаемую возможность среды выполнения или нехватку ресурсов ноды. Пока сборка из Git развёртывается в Container, изменения жизненного цикла, конфигурации и секретов возвращают BUILD_ROLLOUT_IN_PROGRESS до завершения развёртывания; см. Источники Git и Build Workers. История Task показывает этап остановки; повтор без изменения предварительного условия обычно завершается той же ошибкой. Ошибки, которые вы можете исправить, возвращаются как ошибки клиента со своим кодом, например 409 HOST_PORT_IN_USE с номером порта, 409 IMAGE_NOT_ON_NODE, 409 DISK_IMAGE_VOLUMES_UNSUPPORTED, если на ноде нет свободного loop-устройства для тома на образе диска, и 404 CONTAINER_NOT_FOUND. Пересоздание контейнера с Secure Runtime и GPU отклоняется с 409 SECURE_RUNTIME_GPU_UNSUPPORTED ещё до остановки контейнера.

Перед удалением проверьте Routes, привязки баз данных, разрешения, тома, настройки источника и экспортированные данные. Удаление Container снимает разрешения ресурса и удаляет его привязки к базам данных и хранилищам, поэтому новый Container с тем же именем не наследует ни доступ, ни учётные данные привязок. Container, который ждёт первой сборки своего источника Git, отдельно удалить нельзя (409 SOURCE_CONTAINER_NOT_BUILT); удалите вместо этого его источник Git. Удаление тома — отдельное разрушительное действие: сохраните или скопируйте постоянные данные до удаления любого из ресурсов.

Операторские детали: пересоздание и восстановление

Изменение образа, command, переменных среды, точек монтирования, среды выполнения, портов, ограничений или поведения перезапуска может потребовать пересоздания. При пересоздании Docker заменяет среду выполнения, а стабильная идентичность Container и поддерживаемые связи в Opfield сохраняются. Текущие сеансы процесса прерываются, поэтому запланируйте окно работ или используйте Deployment, если перерыв недопустим.

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

Если нода Docker отключилась во время операции, дождитесь нового инвентаря после подключения и только затем повторяйте действие. Хост мог завершить операцию, но не успеть подтвердить её. Если Container отсутствует, а его желаемое состояние сохранено, используйте поддерживаемое согласование или Recreate. Удаление и повторное создание записи Opfield меняет владение и права и не должно быть первым способом восстановления.

Console и доступ к файлам предназначены для инспекции и работы с инцидентами, а не для замены воспроизводимой конфигурации. Изменения только внутри работающего Container могут исчезнуть при следующем пересоздании; перенесите их в образ, управляемую конфигурацию или постоянный том.