Vxero Neo

Что такое Vxero Neo?

Vxero Neo (Neo) — SSH-native инструмент командной строки для развертывания Docker-приложений на VPS. Он подключается к серверу по SSH, настраивает Docker и Caddy, развертывает приложения с HTTPS через auto-SSL — без установки агента или отдельного control plane.

Neo также управляет жизненным циклом приложений от локальной разработки через staging до production. Он читает локальную конфигурацию проекта (включая docker-compose.yml, .env и .neo.yml), собирает и передает образы по SSH, выполняет health checks и переключает трафик без downtime.

Ключевые возможности

• Развертывание только по SSH (без агента, без дашборда): Neo запускается на локальной машине и подключается к VPS по SSH; кроме Docker/Caddy для runtime, не требует дополнительного серверного ПО.
• Автоматическая инициализация сервера (Docker + Caddy): При развертывании Neo настраивает Docker и Caddy на целевом сервере, чтобы контейнеры могли работать и принимать HTTPS-трафик.
• От compose/config до live switch: Neo читает локальную конфигурацию, собирает образ, передает по SSH, затем переключает трафик после health checks; старые контейнеры продолжают работать до переключения.
• Мгновенный HTTPS-домен и альтернативные опции сертификатов: Neo может настроить HTTPS с sslip.io (без DNS) через --temp. Для реальных доменов — Let’s Encrypt via Caddy (после настройки DNS), или свои cert с --cert и --key.
• Генерация конфигурации и управление окружением: neo config generate сканирует docker-compose.yml и авто-генерирует .neo.yml, определяя app service, sidecars, workers, env vars и volumes. Neo также синхронизирует env/state через neo env и neo sync.
• Blue-green zero-downtime развертывания: Запускает новые контейнеры, ждет health checks, затем переключает трафик, оставляя предыдущую версию доступной до cutover.
• Workers, sidecars и persistent volumes: Определяйте background workers и sidecars в .neo.yml для развертывания вместе с основной app с общими volumes и env vars. Объявляйте volumes в .neo.yml для сохранения данных при redeploy.
• Multi-server и per-environment настройки: Используйте флаги вроде --to staging для развертывания в staging или production; каждое окружение может иметь свой домен, env vars и SSL-конфигурацию.

Как использовать Vxero Neo

1. Подготовьте проект: Убедитесь, что приложение описано в docker-compose.yml (и опциональном .env).
2. Сгенерируйте конфиг развертывания Neo: В директории проекта выполните neo config generate. Neo сканирует docker-compose.yml и создаст .neo.yml с обнаруженными сервисами: app, workers/sidecars (если определены), env vars и volumes.
3. Локальная разработка (опционально, но поддерживается): Используйте neo dev для обертки docker-compose с загрузкой окружения из .neo.yml.
4. Развертывание по SSH: Выполните neo deploy нацеливаясь на VPS. Neo соберет образ из Dockerfile (и compose-конфига), передаст по SSH, выполнит health checks и переключит трафик.
5. Включите HTTPS: Используйте neo domain --temp для мгновенной HTTPS-ссылки на sslip.io, или реальный домен с Let's Encrypt auto-SSL после настройки DNS, или укажите --cert/--key для своего сертификата.

Сценарии использования

• Развертывание Docker-приложений на single-VM: Развертывайте одно контейнеризованное приложение на VPS (например, web-сервис), где нужна SSH-автоматизация вместо cluster orchestrator.
• Staging → production с общей конфигурацией: Используйте одну конфигурацию для окружений (через генерацию .neo.yml и загрузку env), развертывая в staging, затем продвигая в production с разными доменами/SSL.
• Приложения с sidecars и background workers: Развертывайте основное app вместе с worker- и sidecar-контейнерами из .neo.yml, включая общие env vars и volumes.
• Проекты с быстрым HTTPS без DNS-изменений: Используйте neo domain --temp для немедленной HTTPS-ссылки на sslip.io для тестов, затем перейдите на реальный домен.
• Zero-downtime релизы для малых команд: Выполняйте blue-green обновления с health checks, чтобы старая версия оставалась доступной до готовности новых контейнеров.

FAQ

• Neo устанавливает агент на мой сервер? Нет. Neo запускается на вашей локальной машине и подключается к VPS по SSH. На сервере настраиваются только Docker и Caddy для runtime вашего приложения.

• Я уже использую docker-compose. Как перейти на Neo? Выполните neo config generate в директории проекта. Neo просканирует docker-compose.yml и автоматически сгенерирует .neo.yml, после чего можно использовать neo deploy для деплоя приложения.

• Какие облачные провайдеры поддерживаются? Neo может деплоить на любой VPS с SSH-доступом, например DigitalOcean, Hetzner, Linode, Vultr, AWS EC2, GCP и Azure. Neo деплоит на одну VM (это не оркестратор многоузловых кластеров вроде Kubernetes или Docker Swarm).

• Как работает HTTPS? Neo поддерживает neo domain --temp для мгновенного HTTPS через sslip.io, neo domain app example.com для Let’s Encrypt auto-SSL после настройки DNS, и --cert/--key для собственной сертификата.

• Может ли Neo запускать background workers и базы данных? Workers объявляются в .neo.yml и деплоятся как отдельные контейнеры с тем же image, env vars и volumes. Для баз данных Neo может запускать их как Docker sidecars/services для небольших проектов; для продакшена с реальными пользователями рекомендует managed databases.

Альтернативы

• Ручные скрипты деплоя Docker + Caddy: Если вы предпочитаете полный контроль и у вас уже есть собственная автоматизация деплоя, можно строить и передавать images, запускать контейнеры и управлять Caddy/SSL самостоятельно. Это обычно требует больше усилий на настройку, чем однокомандный workflow Neo.
• Docker Swarm или Kubernetes: Это оркестраторы кластеров для многоузловых деплоев. Они отличаются от Neo тем, что нацелены на оркестрацию по кластерам, а не на одиночный VPS с SSH-доступом.
• Другие VPS-ориентированные CI/CD пайплайны: Можно использовать универсальные CI/CD инструменты для SSH на сервер, сборки images и перезапуска контейнеров. По сравнению с Neo вам придётся самостоятельно заниматься генерацией конфигов, логикой zero-downtime свитчинга и интеграцией HTTPS.
• Managed container платформы: Платформы, управляющие роутингом и TLS, упрощают инфраструктурные шаги. Обычно они жертвуют SSH-first моделью деплоя «без агента/control plane», описанной для Neo.