Skip to Content
Next Hat / Блог

Представляем Nanocl 0.18

· leone

Nanoclвыпуск0.18

Nanocl 0.18 превращает Cargo в полноценную нагрузку с несколькими контейнерами. Именованные контейнеры приложения, упорядоченные init-контейнеры, устойчивые реплики, общая сеть и обновления с учётом здоровья теперь образуют единую модель выполнения. Повседневные операции выполняются над отдельными процессами, а стек прокси и DNS стал проще.

Видеоруководство

Разверните нагрузку с несколькими контейнерами в Nanocl 0.18, изучите новые команды для процессов и примените обновление с учётом здоровья.

Смотреть на YouTube .

Cargo теперь поддерживает несколько контейнеров

Containers заменяет прежнее поле Container. Каждый контейнер приложения имеет имя, а InitContainers выполняются в порядке объявления до запуска приложений. Replicas теперь — обычное целое число; для каждой реплики создаются одинаковые объявленные процессы.

Небольшой Statefile 0.18 для API и рабочего процесса, которым сначала нужна миграция схемы:

ApiVersion: v0.18
Namespace: global
 
Cargoes:
- Name: storefront
  Replicas: 2
  NetworkMode: storefront-net
  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

В каждой реплике migrate должен успешно завершиться перед запуском api и worker. Поскольку Cargo содержит два контейнера приложения и не использует сеть хоста, Nanocl создаёт для каждой реплики внутреннюю песочницу. Оба приложения присоединяются к её сетевому пространству имён, разделяют IP-адрес и взаимодействуют через localhost.

Поля сети, портов, имени хоста и DNS принадлежат Cargo и настраивают общую сетевую границу. Образ, команда, окружение, проверки здоровья, монтирования, capabilities и секреты контейнера остаются у каждого именованного контейнера. Cargo с одним контейнером работает напрямую без лишней песочницы.

См. полное руководство по Cargo с несколькими контейнерами.

Готовность — часть развёртывания

Одного запуска контейнера Docker теперь недостаточно для готовности. Обязательное приложение с проверкой здоровья должно стать healthy; без проверки достаточно работающего состояния. Общая песочница также должна работать, а контейнер с Essential: false не блокирует готовность Cargo.

Во время обновления Nanocl последовательно подготавливает новые реплики и до пяти минут ожидает готовности обязательных процессов. Если сеть и порты хоста позволяют, сохранённое поколение продолжает обслуживать запросы до готовности кандидата. Кандидат, отказавший до продвижения, удаляется, а сохранённое поколение восстанавливается.

Такое поведение не обещает отсутствия простоев. Для фиксированного порта хоста может потребоваться удаление старого процесса, прежде чем кандидат займёт порт; сеть хоста требует предварительной остановки старого поколения. Если нужна готовность на уровне приложения, задайте проверку здоровья Docker.

Полные границы готовности и отката описаны в разделе Проверки здоровья и последовательные обновления.

Работайте с нужным процессом

Реплицированный Cargo с несколькими контейнерами создаёт несколько процессов выполнения, поэтому exec и kill теперь выбирают конкретный процесс напрямую. Найдите точное имя процесса или полный Docker ID с nanocl ps, затем укажите его:

nanocl ps --namespace global --kind cargo
nanocl exec PROCESS -- sh
nanocl kill --signal SIGTERM PROCESS

nanocl exec поддерживает интерактивный ввод, TTY, отсоединённый режим, файлы и значения окружения, пользователя, рабочий каталог и привилегированный режим. В присоединённом режиме без TTY stdout и stderr остаются раздельными, а код завершения команды становится кодом завершения CLI. inspect, logs и stats также принимают идентификаторы процессов, где это предусмотрено.

Операции exec для Cargo и группового завершения удалены. См. руководство по операциям с процессами.

Минимальные сетевые возможности

Именованные локальные сети Docker теперь выбираются на уровне Cargo. Nanocl использует существующую сеть без изменений или создаёт отсутствующую локальную bridge-сеть с возможностью подключения, затем сохраняет её параметры для селекторов прокси и DNS. API для драйверов, подсетей, mesh-сетей и автоматической очистки не добавляется; сети Docker не принадлежат пространствам имён Nanocl.

Встроенные режимы Docker default, bridge, host и none остаются доступными; пользовательские режимы container:... зарезервированы. $$INTERNAL_GATEWAY подставляет шлюз выбранной пользовательской сети либо шлюз nanoclbr0 для встроенных режимов.

Подробнее — в разделе Сеть Cargo.

Меньше отдельных компонентов

ncproxy теперь включает Nginx, а ncdns — dnsmasq. Отдельно управляемые сервисы nproxy и ndns, требующие координации через docker exec, больше не нужны. Оба контроллера согласуют сохранённые правила после запуска и переподключения потока событий. Изменения прокси проверяются и перезагружаются транзакционно; правила DNS хранятся отдельными фрагментами, чтобы изменение одного ресурса не удаляло другой.

Остальная односерверная архитектура остаётся привычной: nanocld управляет нагрузками и API, nstore хранит состояние управления, nmetrics собирает метрики хоста, а ncvpnkit интегрирует сеть Docker Desktop. Nanocl 0.18 не заявляет автоматическое планирование на нескольких узлах, автомасштабирование, высокую доступность всего кластера или service mesh.

Надёжность выполнения

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

Выпуски компонентов

  • nanocl 0.18.0 — новая модель Statefile и CLI, exec и kill для отдельных процессов, канонические ключи ресурсов, полные пути образов VM и повторно применимые резервные копии без привязок секретов, добавленных демоном.
  • nanocld 0.18.0 — компиляция и жизненный цикл нескольких контейнеров, устойчивые реплики, обновления с учётом готовности, обнаружение именованных сетей, init-контейнеры VM и сертификаты TLS базы данных в PEM.
  • ncproxy 0.15.0 — встроенный Nginx, разрешение целей в именованных сетях, переключение маршрутов с учётом готовности, согласование при запуске и транзакционные перезагрузки.
  • ncdns 0.10.0 — встроенный dnsmasq, селекторы именованных сетей, независимые фрагменты правил, проверка, откат и согласование после перезапуска.
  • ncvpnkit 0.8.0 — совместимость с API клиента и контроллера Nanocl 0.18.

Прежние отдельные выпуски nproxy (1.28.0-n0.15.0) и ndns (2.91.0-n0.10.0) заменены компонентами, встроенными в ncproxy и ncdns.

VM получают необязательный InitContainer, подготавливающий образ по полному локальному пути перед запуском QEMU вместо удалённого процесса nanocl vm image. Секреты TLS сохраняются как содержимое PEM вместо путей на узле; старые читаемые пути секрета сертификата БД преобразуются при первом запуске обновлённого демона.

Несовместимые изменения и миграция

Nanocl ещё не достиг v1; переход с 0.17 на 0.18 содержит несовместимые изменения и может требовать простоя. Перед заменой установки выполните:

nanocl backup -o ./nanocl-0.17-backup

Экспорт содержит Statefile для пространств имён, задания, секреты и ресурсы. Файлы по-прежнему описывают схему 0.17. Проверьте и перепишите их перед повторным применением:

  • Container заменяется именованными Containers; при необходимости добавьте упорядоченные InitContainers.
  • Старый объект репликации заменяется целым числом Replicas.
  • Сеть, порты хоста, имя хоста и DNS перемещаются на уровень Cargo.
  • Канонические ключи и цели прокси используют порядок {namespace}.{name}.
  • Disk.Image VM и управляемые демоном образы VM заменяются полным локальным путём Image, при необходимости подготовленным InitContainer.
  • Команды cargo exec, завершение всего Cargo и vm image удалены.

Обеспечьте доступность старых файлов сертификата БД для чтения при первом запуске демона 0.18, чтобы перенести их содержимое. Резервная копия 0.17 не является автоматически совместимой и не гарантирует восстановление без простоя.

Перед обновлением следуйте руководству миграции с 0.17 на 0.18.

Что дальше

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

Последнее обновление