Cargo с несколькими контейнерами

Cargo описывает одну нагрузку. В Nanocl 0.18 каждый Cargo объявляет один или несколько именованных Containers приложения, необязательные упорядоченные InitContainers и сохраняемое число Replicas.

ApiVersion: v0.18
Namespace: global
 
Cargoes:
- Name: storefront
  Replicas: 2
  NetworkMode: storefront-net
  Secrets:
  - shared-env
  InitContainers:
  - Name: migrate
    Image: ghcr.io/example/storefront-migrate:1.0.0
  Containers:
  - Name: api
    Image: ghcr.io/example/storefront-api:1.0.0
    Healthcheck:
      Test: ["CMD-SHELL", "wget -qO- http://127.0.0.1:8080/health || exit 1"]
      Interval: 5000000000
      Timeout: 3000000000
      Retries: 3
  - Name: worker
    Image: ghcr.io/example/storefront-worker:1.0.0
    Essential: false
    Secrets:
    - worker-env

Имена контейнеров должны быть уникальными в обоих списках. _sandbox зарезервировано Nanocl. Cargo должен иметь хотя бы один контейнер приложения и хотя бы одно обязательное приложение. Приложения обязательны, если не задано Essential: false; init-контейнеры всегда обязательны.

Реплики и песочница

Каждая реплика имеет свои процессы приложений и отдельные запуски init-контейнеров. Для двух и более приложений в сети, отличной от сети хоста, Nanocl создаёт внутренний процесс песочницы реплики. Приложения присоединяются к её сетевому пространству имён, разделяют IP-адрес и взаимодействуют через localhost.

Cargo с одним приложением запускает его напрямую, даже при наличии init-контейнеров. С NetworkMode: host приложения также запускаются напрямую. Песочница — деталь реализации: не объявляйте её в Statefile и не выбирайте как контейнер приложения.

Init-контейнеры каждой реплики выполняются последовательно в порядке объявления. Nanocl запускает приложения только после завершения всех init-контейнеров с кодом 0. Ненулевой код блокирует переход реплики к приложениям.

Общие настройки и настройки контейнеров

NetworkMode, PortBindings, Hostname и Dns Cargo настраивают владельца сети реплики. Secrets Cargo наследуются всеми init-контейнерами и приложениями. Placement и ResourceRequirement также принадлежат Cargo.

Каждый именованный контейнер сохраняет свою конфигурацию Docker: образ, команду, окружение, проверку здоровья, capabilities, устройства, binds, mounts и секреты контейнера. Файловые системы и пространства имён IPC, PID, UTS, пользователя и cgroup автоматически не разделяются. Для общих постоянных данных настройте одинаковый том Docker или bind mount у нужных контейнеров.

Nanocl резервирует поля владения сетью и жизненного цикла. Поля контейнера HostConfig.PortBindings, PublishAllPorts, AutoRemove, NetworkingConfig и NetworkDisabled отклоняются. HostConfig.NetworkMode контейнера можно опустить или задать как host либо none; прямые ссылки container:... в настройках сети, IPC, PID, UTS, пользователя и cgroup отклоняются.

Идентификация процессов и отказы

Ключ Cargo остаётся namespace.name, а каждый процесс имеет конкретное имя с порядковым номером реплики и логическим именем контейнера. Перед командами для процессов получите реальное имя или полный Docker ID через nanocl ps. См. Операции с процессами.

Процессы приложений по умолчанию используют политику перезапуска Docker always. Если обязательное приложение или необходимая песочница не готовы, Nanocl сообщает unhealthy для Cargo. Необязательное приложение по-прежнему управляется, но его здоровье не блокирует готовность Cargo.