Вторая часть материала посвящена практическому применению архитектуры Uncloud в реальной эксплуатации. Рассматриваются механизмы обновления сервисов, доставка Docker-образов без внешнего реестра, управление размещением workload, работа со stateful-приложениями, передача чувствительных данных и инструменты наблюдаемости. Также анализируются ограничения модели, определяющие её применимость для конкретных задач.
Процесс обновления сервисов в Uncloud базируется на двух механизмах: собственном health monitoring и стандартном Docker healthcheck. По умолчанию Uncloud наблюдает за новым контейнером в течение 5 секунд, проверяя его стабильность работы. Этот период можно настроить через директиву deploy.update_config.monitor, а значение 0s отключает мониторинг. Важно отметить, что monitor не является полноценной проверкой готовности приложения, он лишь фиксирует отсутствие постоянных перезапусков. Для глубокой проверки используется Docker healthcheck, который может тестировать HTTP-эндпоинты или другие зависимости. Если контейнер становится healthy до окончания периода мониторинга, развертывание продолжается; если же после мониторинга контейнер остаётся unhealthy, Uncloud останавливает новый экземпляр и сохраняет работу старого. При этом healthcheck не перезапускает упавшие контейнеры автоматически, а лишь исключает их из upstreams прокси-сервера Caddy.
Для доставки образов в self-hosted кластерах Uncloud использует проект Unregistry, который реализует Docker Registry HTTP API поверх локального хранилища containerd. Вместо развёртывания отдельного постоянно работающего реестра, система использует команду docker pussh (в Uncloud — uc image push), которая передаёт образ на целевую машину через SSH. Под капотом запускается временный контейнер Unregistry, через который пробрасывается порт для выполнения операции push. Механизм использует стандартный Docker Distribution: при передаче образа на сервер существующие слои (layers) не копируются повторно, что делает процесс эффективным, похожим на rsync для контейнерных образов. Если в Compose используется директива build, образ собирается локально, а затем необходимые данные передаются на узлы через Unregistry.
Управление размещением контейнеров осуществляется с помощью расширения x-machines, позволяющего ограничить набор машин для конкретного сервиса. Например, можно указать, что реплики веб-сервиса должны работать только на определённых узлах, а база данных — на конкретном сервере с привязанными томами. Однако Uncloud не реализует автоматический failover: если машина становится недоступна, контейнеры на ней не переносятся на другие узлы автоматически. Наличие нескольких реплик не гарантирует восстановление после отказа узла, так как вопрос репликации данных и отказоустойчивости для stateful-приложений (например, PostgreSQL или Redis) остаётся за пользователем. Uncloud не создаёт распределённые или реплицированные диски автоматически, поэтому для таких приложений требуется самостоятельная настройка механизмов резервного копирования и кластеризации.
Для работы с чувствительными данными, такими как пароли и API-токены, Uncloud предлагает механизм x-command. Он позволяет получать значение секрета непосредственно во время деплоя, выполняя внешнюю команду, результат которой подставляется вместо переменной. Сам Uncloud не хранит секреты и не является менеджером секретов; он лишь запускает команду (например, op read для 1Password или vault kv get для HashiCorp Vault) и передаёт полученный результат приложению. Поддерживается только подстановка значений в переменные окружения, монтирование секретов как файлов в контейнер пока не реализовано. Безопасность схемы зависит от среды выполнения: пользователь или CI-агент должен иметь права на получение секретов, а доступ к внешним менеджерам должен быть защищён и регулярно ротирован.
Наблюдаемость в Uncloud включает диагностику состояния узлов, самой платформы, кластерной сети и метрик. Команда uc machine ls выводит информацию о хостах, включая IP-адреса, версию Docker, версию uncloudd и параметры WireGuard. В JSON-формате это позволяет интегрировать данные в собственные скрипты. Для просмотра системных логов используется uc machine logs, которая собирает journald-логи сервисов инфраструктуры (uncloud, corrosion, docker) с удалённых узлов без ручного подключения по SSH. Также доступна команда uc machine rtt для измерения времени отклика между узлами кластера, что помогает оценить качество связи в peer-to-peer сети на базе WireGuard. Эти инструменты позволяют отслеживать состояние платформы и быстро выявлять проблемы инфраструктуры.
