Skip to main content

Установка FlipFlag в Kubernetes

Этот вариант рассчитан на ИТ-команду заказчика: Kubernetes 1.26+, Helm 3, корпоративный PostgreSQL, ingress controller и сертификаты уже подготовлены. Chart находится в helm/flipflag внутри полного self-host комплекта. Он устанавливает API и UI; кластер PostgreSQL не устанавливается.

1. Подготовьте образы и PostgreSQL​

Доставьте API/UI образы из images/flipflag-images.tar во внутренний registry. Например, для AMD64 на машине с Docker:

docker load -i images/flipflag-images.tar
docker tag flipflag/api:0.3.0-onprem-amd64 registry.example.com/flipflag/api:0.3.0-onprem-amd64
docker tag flipflag/web:0.3.0-onprem-amd64 registry.example.com/flipflag/web:0.3.0-onprem-amd64
docker push registry.example.com/flipflag/api:0.3.0-onprem-amd64
docker push registry.example.com/flipflag/web:0.3.0-onprem-amd64

Для ARM64 исходные теги — 0.3.0-onprem; не запускайте образ другой архитектуры. Для смешанного кластера подготовьте multi-platform image index либо node placement. Не используйте облачный образ API для коммерческой on-prem установки.

DBA создаёт две отдельные базы, control и tenant, и LOGIN-роль без SUPERUSER/CREATEDB/CREATEROLE с правами на миграции. Установите uuid-ossp в обеих базах. DSN должны использовать sslmode=verify-full, фиксированный адрес tenant без %s, percent-encoded пароль и при необходимости частный CA.

2. Создайте Secrets​

Файлы в /secure/ подготовьте средствами корпоративного менеджера секретов: каждый содержит только соответствующее значение. JWT-секрет должен быть случайным и одинаковым для всех реплик API. Не коммитьте файлы, значения или полученный Secret YAML.

kubectl create namespace flipflag
kubectl -n flipflag create secret generic flipflag-secrets \
  --from-file=CONTROL_PLANE_DSN=/secure/control-dsn \
  --from-file=TENANT_DSN_TEMPLATE=/secure/tenant-dsn \
  --from-file=JWT_SECRET=/secure/jwt-secret

Если PostgreSQL использует частный CA:

kubectl -n flipflag create secret generic flipflag-postgres-ca \
  --from-file=ca.crt=/secure/postgres-ca.crt

Тогда добавьте sslrootcert=/etc/flipflag-ca/ca.crt в обе DSN и укажите caSecret в values. Для приватного registry создайте корпоративный imagePullSecret и укажите его имя в imagePullSecrets.

3. Подготовьте лицензию​

Один раз создайте ID установки и сохраните его в конфигурации:

openssl rand -hex 16

Все реплики используют один и тот же ID. Для офлайн-режима передайте его поставщику и получите подписанный файл:

kubectl -n flipflag create secret generic flipflag-license \
  --from-file=license.json=/secure/company.license

Для онлайн-режима вместо файла создайте Secret с ключом активации:

kubectl -n flipflag create secret generic flipflag-license \
  --from-file=activation-key=/secure/activation.key

Это альтернативные варианты. В values задаётся соответственно offline или online. Онлайн-режиму нужен исходящий HTTPS к https://flipflag.ru/selfhost/licensing. Новый pod получает допуск при старте: если сервер лицензий недоступен и у pod нет сохранённого допуска, его бизнес API отвечает 402. Readiness сама по себе этого не обнаруживает. Для полностью изолированной инфраструктуры выбирайте офлайн-файл.

4. Установите chart​

Пример /secure/flipflag-values.yaml для AMD64 и офлайн-лицензии:

existingSecret: flipflag-secrets
publicOrigin: https://flags.example.com
licensing:
  instanceId: REPLACE_WITH_THE_ID_GENERATED_ABOVE
  mode: offline
  existingSecret: flipflag-license
# Укажите только при наличии частного CA:
# caSecret: flipflag-postgres-ca
# imagePullSecrets:
#   - name: corporate-registry
api:
  image:
    repository: registry.example.com/flipflag/api
    tag: 0.3.0-onprem-amd64
  replicas: 2
web:
  image:
    repository: registry.example.com/flipflag/web
    tag: 0.3.0-onprem-amd64
  replicas: 2
ingress:
  enabled: true
  className: nginx
  host: flags.example.com
  tls:
    - secretName: flipflag-tls
      hosts: [flags.example.com]

Подготовьте TLS Secret flipflag-tls и DNS; используйте свой ingress class. Для онлайн-режима замените licensing.mode на online и создайте соответствующий Secret из предыдущего шага. Также обязательно задайте постоянный volume для кеша подписанного допуска:

licensing:
  mode: online
  persistence:
    existingClaim: flipflag-license-state

PVC создаёт администратор кластера. Для двух и более реплик требуется RWX-хранилище с поддержкой POSIX file locks; UID/GID 10001 должны иметь право записи. Для одной реплики допустим RWO, но rolling update и перенос между узлами требуют отдельной проверки подключения volume. Chart отклонит online-конфигурацию без PVC. Включите volume в backup; удаление PVC удаляет кеш и заставляет снова обратиться к issuer. При недоступном issuer новый Pod использует сохранённый действующий lease до его истечения; бессрочной работы без продления нет.

Настройте CPU/RAM, affinity, nodeSelector и tolerations по требованиям кластера. Две реплики сами по себе не обеспечивают распределение по разным узлам.

helm lint helm/flipflag --values /secure/flipflag-values.yaml
helm upgrade --install corp helm/flipflag -n flipflag \
  --values /secure/flipflag-values.yaml --wait --timeout 10m
kubectl -n flipflag get pods

Pre-install/pre-upgrade Job выполняет миграции. Ошибка миграции останавливает установку; API pods самостоятельно схему не меняют. Для несовместимой миграции старой схемы заранее остановите трафик и старые API pods.

5. Создайте администратора и проверьте API​

Однократное создание администратора; пароль из файла передаётся через stdin:

API_POD=$(kubectl -n flipflag get pods \
  -l app.kubernetes.io/instance=corp,app.kubernetes.io/component=api \
  -o jsonpath='{.items[0].metadata.name}')
kubectl -n flipflag exec -i "$API_POD" -- env \
  BOOTSTRAP_EMAIL=admin@example.com BOOTSTRAP_ORG_NAME='Example Corp' \
  BOOTSTRAP_NAME=Administrator ./flipflag-api bootstrap < /secure/admin-password
curl -fsS https://flags.example.com/v1/license/status

Войдите в UI, создайте тестовый проект/флаг и проверьте SDK evaluate через ingress. Health checks не заменяют проверку tenant БД и лицензии. Одна реплика API может занимать до 10 control + 2 tenant соединений; учитывайте миграции и операции DBA.

Продление, ротация и эксплуатация​

Офлайн-файл заменяется в Secret с тем же именем и ID:

kubectl -n flipflag create secret generic flipflag-license \
  --from-file=license.json=/secure/renewed.license --dry-run=client -o yaml \
  | kubectl apply -f -

Файл смонтирован целиком и перечитывается приложением после обновления volume Kubernetes; доставка изменения не мгновенна. Проверьте /v1/license/status у каждой реплики. Для онлайн-режима обычная оплата не требует нового ключа; при его замене обновите Secret activation-key и выполните контролируемый rollout API. После ротации DSN/JWT также требуется rollout; смена JWT завершает старые сессии.

Используйте корпоративный backup/PITR PostgreSQL. Сохраняйте обе базы, Secrets и ID установки согласованно; Helm rollback не откатывает схему БД. Настройте мониторинг, проверку восстановления и NetworkPolicy: ingress → web:8080, web → api:8080, API/migration → PostgreSQL, DNS и необходимый egress для онлайн-лицензии. SDK в закрытой сети доставляются через внутренние npm/Maven/Swift репозитории.

Окончание лицензии и безопасные defaults приложения описаны в руководстве Compose.