Unleash на Ubuntu 24.04: пошаговая установка

MAATRIX

Функция ушла в прод, а через час выяснилось, что она течёт данными или кладёт базу под нагрузкой — и единственный выход это откатывать деплой, поднимая всех на уши посреди дня. Feature flags решают эту проблему в одно действие: код уже в проде, но выключатель снаружи кода, и вы гасите проблемную функцию за секунды, а не гоняете CI/CD заново. Ниже — установка Unleash, open-source сервера управления флагами, с нуля на чистом VPS с Ubuntu 24.04: Docker Compose, PostgreSQL, HTTPS и первый рабочий флаг.

Зачем свой Unleash, а не облачный SaaS

У Unleash есть облачная версия (Unleash Cloud), но self-hosted вариант даёт три вещи, которые важны именно с точки зрения безопасности и контроля:

• Данные о фичах остаются у вас. Список флагов и стратегий раскрытия — это фактически карта того, какие функции существуют в продукте и кому они видны. Отдавать это третьей стороне не всегда приемлемо, особенно для внутренних админок и финтех-логики.
• Флаг работает даже если внешний SaaS недоступен. SDK Unleash кэширует состояние флагов локально и продолжает отдавать последнее известное значение при потере связи с сервером — но чем ближе сервер флагов к вашей инфраструктуре, тем меньше точек отказа в критичной цепочке.
• Нет лимитов бесплатного тарифа. Open-source версия не ограничивает число флагов, окружений и запросов SDK — это единственное отличие от платных тарифов, которое реально чувствуется на среднем проекте.

Минус тоже честно нужно назвать: вы сами отвечаете за апдейты, бэкапы базы и доступность сервера. Для команды из одного-двух разработчиков это не проблема — Unleash достаточно лёгкий, чтобы жить на бюджетном VPS.

Что понадобится

• VPS на Ubuntu 24.04 LTS, от 1 vCPU / 2 ГБ RAM — этого хватает и для Unleash-сервера, и для PostgreSQL под ним при умеренной нагрузке.
• Docker и Docker Compose plugin.
• Домен (не обязателен для старта, но нужен для нормального HTTPS, если SDK будут стучаться в Unleash снаружи локальной сети).
• Root-доступ по SSH и открытые порты 22, 80, 443 (443 — если поднимаете HTTPS через reverse-proxy).

Если сервер уже настраивался под другие Docker-сервисы, часть шагов ниже можно пропустить — конфигурация ничем не отличается от обычного продакшен-стека на Compose, детали которого разобраны в статье про Docker Compose для продакшена на Ubuntu 24.04.

Готовим сервер: Docker и фаервол

Обновляем систему и ставим Docker по официальному репозиторию:

apt update && apt upgrade -y
apt install -y ca-certificates curl gnupg

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  tee /etc/apt/sources.list.d/docker.list > /dev/null

apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Проверяем, что всё встало:

docker --version
docker compose version

Настраиваем фаервол — Unleash не должен торчать наружу напрямую на своём порту 4242, доступ идёт только через reverse-proxy на 443. Если ufw ещё не настроен, шаги подробно разобраны в статье про фаервол UFW на Ubuntu 24.04:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Порт 4242 в ufw специально не открываем — он будет доступен только локально на сервере, между контейнерами.

Поднимаем Unleash и PostgreSQL через Docker Compose

Unleash-серверу нужна база — используем официальный образ unleashorg/unleash-server вместе с PostgreSQL в одном compose-файле. Создаём рабочую директорию и файл:

mkdir -p /opt/unleash && cd /opt/unleash
nano docker-compose.yml

Содержимое docker-compose.yml:

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: unleash
      POSTGRES_USER: unleash_user
      POSTGRES_PASSWORD: замените_на_свой_пароль
    volumes:
      - unleash-db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "unleash_user"]
      interval: 5s
      timeout: 5s
      retries: 5

  unleash:
    image: unleashorg/unleash-server:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:4242:4242"
    environment:
      DATABASE_URL: "postgres://unleash_user:замените_на_свой_пароль@postgres/unleash"
      DATABASE_SSL: "false"
      LOG_LEVEL: warn
    depends_on:
      postgres:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "node", "-e", "require('http').get('http://localhost:4242/health', r => process.exit(r.statusCode === 200 ? 0 : 1))"]
      interval: 5s
      timeout: 5s
      retries: 5

volumes:
  unleash-db:

Обратите внимание на 127.0.0.1:4242:4242 — порт пробрасывается только на локальный интерфейс сервера, а не на все интерфейсы. Так снаружи Unleash не достучаться напрямую, только через reverse-proxy, который добавим ниже.

Пароль базы в POSTGRES_PASSWORD и DATABASE_URL должен совпадать — сгенерируйте длинный случайный пароль, например openssl rand -base64 24, и подставьте в оба места.

Запускаем:

docker compose up -d
docker compose logs -f unleash

В логе должна появиться строка о том, что сервер слушает 4242-й порт и миграции базы прошли успешно. Первый старт занимает чуть дольше — Unleash накатывает схему в PostgreSQL.

Первый вход, смена пароля и создание проекта

Пока порт закрыт наружу, зайти в интерфейс можно через SSH-туннель:

ssh -L 4242:127.0.0.1:4242 root@<ip-сервера>

Открываем http://localhost:4242 в браузере. Стандартные учётные данные при первом запуске — логин admin, пароль unleash4all. Первым делом заходим в Admin → Users и меняем пароль администратора на свой — оставлять дефолтные креды даже за закрытым портом не стоит.

Дальше:

1. Projects → New project — создаём проект под свой продукт (по умолчанию есть Default, но отдельный проект удобнее, если сервисов несколько).
2. Environments — из коробки есть development и production, для каждого свой набор включённых стратегий.
3. Feature flags → New feature flag — создаём первый флаг, например new-checkout-flow, тип toggle, стратегия по умолчанию — выключен для всех.

Флаг создан, но пока ни на что не влияет — SDK в приложении ещё не подключён.

HTTPS и подключение SDK: закрываем доступ снаружи

Чтобы приложения могли обращаться к Unleash не только с самого сервера, нужен HTTPS через reverse-proxy — поднимать TLS прямо в Unleash смысла нет, проще отдать это Caddy. Установка с авто-SSL по домену подробно разобрана в статье про Caddy с авто-SSL на Ubuntu 24.04; здесь — минимальный Caddyfile:

flags.example.com {
    reverse_proxy 127.0.0.1:4242
}

После systemctl reload caddy Unleash доступен по https://flags.example.com, а порт 4242 по-прежнему закрыт для внешних подключений напрямую.

API-токены создаются в Admin → API access: отдельно CLIENT (для backend SDK, полный доступ на чтение флагов) и FRONTEND (для клиентского кода в браузере, урезанные права). Токен для backend-приложения на Node.js подключается так:

const { initialize } = require('unleash-client');

const unleash = initialize({
  url: 'https://flags.example.com/api/',
  appName: 'checkout-service',
  customHeaders: { Authorization: '<CLIENT_API_TOKEN>' },
});

unleash.on('ready', () => {
  if (unleash.isEnabled('new-checkout-flow')) {
    // включённая ветка
  }
});

Именно этот SDK-вызов и есть тот самый «выключатель без деплоя»: чтобы погасить функцию, ничего не пересобирается и не выкатывается — вы меняете состояние флага в веб-интерфейсе Unleash, и приложение подхватывает изменение в течение нескольких секунд (SDK опрашивает сервер по таймеру, по умолчанию раз в 15 секунд).

Стратегии раскрытия как инструмент снижения риска

В контексте безопасности флаги полезны не только как аварийный рубильник, но и как способ ограничить радиус поражения новой функции ещё до инцидента:

Комбинация стратегий (например, gradual rollout 10% + список сотрудников в UserIDs) даёт то же самое, что canary deploy на уровне инфраструктуры, но без отдельного окружения — прод один, а разная логика включается флагом для разных сегментов. Это удобно и с точки зрения безопасности: если в новой функции найдена уязвимость, вы не откатываете релиз всей команды разработки, а просто гасите один флаг.

Для планирования бэкапов не забывайте, что вся конфигурация флагов и история изменений живёт в PostgreSQL-контейнере — том unleash-db стоит бэкапить так же регулярно, как любую боевую базу, если решите вынести базу из контейнера на отдельный managed-инстанс.

Частые вопросы