Elido на k3s: що розгортає Helm-чарт, а що ні

Elido постачає Helm-чарт, що розгортає весь стек на одному кластері Kubernetes, і ця стаття проходить його на одному вузлі k3s. Перед командами - частина, яка вирішує, чи варто читати далі: Elido не є відкритим кодом, а самохостинг - не продукт, який ми продаємо. У репозиторії немає файлу ліцензії, тож ніхто поза компанією не має ліцензії запускати чи змінювати його. Чарт - це інструмент розгортання, який ми тримаємо в репозиторії, а команди нижче взято з нього та з ранбука поруч (дата звернення 2026-10-25). Користуйтеся цим посібником, якщо ви працюєте над Elido, якщо маєте з нами письмову домовленість або хочете побачити, що саме передбачає запуск платформи.

Якщо ви ще вибираєте між проєктами, які можна справді завантажити, почніть із порівняння самохостингових скорочувачів. Воно охоплює YOURLS, Shlink, Kutt і Dub і не повторює жодного з кроків тут.

Чим є чарт і чим не є

Чарт лежить у deploy/helm/elido. Його метадані вказують на репозиторій GitHub під організацією elidoapp; неавторизований запит на цю адресу 2026-10-25 повернув 404, тож не розраховуйте клонувати його з інтернету. Файл значень тягне образи з ghcr.io/elidoapp, а коментар у ньому називає реєстр публічним. Анонімне завантаження я підтвердити не зміг, тож вважайте це неперевіреним.

Чарт також молодий. Його версія 0.1.0, а власний опис називає ціль «одно-регіональний кластер k3s на потужній ВМ». Бракує кількох речей, які люди вважають такими, що йдуть із чартом Kubernetes, а раніша версія цієї статті помилково описувала деякі з них:

• Немає високої доступності. Кожен stateful set працює в одній репліці.
• Немає завдань резервного копіювання. Ранбук так і каже й радить використати Velero, k8up або знімки провайдера.
• Немає об'єктів моніторингу, дашбордів чи автомасштабувальників.
• Немає мультирегіонального edge. Пресет згортає редиректи в один парк.

Якщо їх вимагає регулятор або ваша власна політика, закладіть роботу, щоб додати їх самостійно.

Що розгортає пресет самохостингу

values-selfhost.yaml урізає все, щоб воно вміщалося на хості з 4 ядрами та 8 ГБ. Він запускає по одній репліці кожного прикладного навантаження: api-core, analytics-api, click-ingester, url-scanner, notification, bio-renderer, billing, дашборд (web), маркетинговий сайт і один парк edge, що відповідає за всі хости. Сервіс ідентичності обробляє реєстрацію й сесії.

За ними стоять шість stateful set із постійними томами: Postgres (20Gi у пресеті), Redis (2Gi), колонкове сховище для подій кліків (30Gi), шина подій (10Gi), об'єктне сховище (20Gi) та пошуковий індекс (5Gi). Redis тут - один екземпляр з append-only персистентністю, а не кластер. Кілька сервісів, що раніше були окремими, зокрема керування доменами, доставка вебхуків та індексація пошуку, тепер працюють усередині api-core, тому список навантажень коротший, ніж підказує старіша документація.

Передумови

Ранбук вимагає Kubernetes 1.27 чи новішого, Helm 3.13 чи новішого та kubectl, спрямований на кластер. Також потрібні DNS-записи для хостнеймів дашборда, API, редиректу та bio, SMTP-релей, доступний із кластера, і ingress-контролер класу caddy.

k3s постачається з Traefik, який конкуруватиме за порти 80 і 443 з контролером, який ви збираєтеся встановити. Вимкніть його під час встановлення k3s:

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable traefik" sh -
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $UID ~/.kube/config
kubectl get nodes   # should show Ready

Встановлення крок за кроком

Створіть простір імен і згенеруйте секрети. Скрипт генерує випадкові значення для пароля бази даних, ключів cookie та шифру сервісу ідентичності, ключа обфускації слагів і pepper для API-ключів, а для SMTP і LiqPay створює плейсхолдери. Він пропускає секрети, що вже існують, якщо ви не передасте --rotate.

kubectl create namespace elido
./deploy/helm/elido/scripts/bootstrap-secrets.sh elido

Наприкінці скрипт виводить пароль Postgres. Збережіть його. Потім замініть плейсхолдер SMTP до того, як хтось зареєструється; той самий шаблон працює для elido-liqpay, якщо ви приймаєте платежі:

kubectl -n elido create secret generic elido-smtp \
  --from-literal=host=smtp.example.com \
  --from-literal=port=587 \
  [email protected] \
  --from-literal=pass=YOUR_SMTP_KEY \
  --from-literal=kratos_uri='smtps://postmaster%40your-domain.com:[email protected]:465/?disable_starttls=false' \
  --dry-run=client -o yaml | kubectl apply -f -

Встановіть ingress-контролер із увімкненим TLS на вимогу:

helm repo add caddy https://caddyserver.github.io/charts
helm -n caddy-system upgrade --install caddy caddy/caddy-ingress-controller \
  --create-namespace --set controller.config.onDemandTLS=true

Тепер встановіть сам Elido. Закріпіть image.tag за обраним вами релізом. Приклад ранбука використовує latest, через що оновлення та відкати важко осмислити.

helm -n elido upgrade --install elido ./deploy/helm/elido \
  -f ./deploy/helm/elido/values-selfhost.yaml \
  --set image.tag=YOUR_TAG \
  --set ingress.hosts.dashboard=app.your-domain.com \
  --set ingress.hosts.api=api.your-domain.com \
  --set ingress.hosts.bio=bio.your-domain.com \
  --set 'ingress.hosts.redirect={r.your-domain.com}' \
  --set ingress.hosts.marketing=your-domain.com \
  --set auth.kratos.publicHost=app.your-domain.com
kubectl -n elido get pods -w

Міграції виконуються як init-контейнери для сервісів, яким вони потрібні, і як pre-install завдання для сервісу ідентичності. Якщо міграція не вдається, нові поди ніколи не приймають трафік.

Перший користувач і власні домени

Відкрийте https://app.your-domain.com/signup і зареєструйтеся. Сервіс ідентичності створює акаунт, а api-core зберігає рядок користувача. Ніщо поки не робить цього користувача власником, тож створіть робочий простір і членство вручну, що саме й радять нотатки встановлення самого чарту:

kubectl -n elido exec -it sts/postgres -- psql -U elido -d elido <<'SQL'
INSERT INTO workspaces (slug, name, plan_tier)
VALUES ('default', 'Default', 'business') RETURNING id;
INSERT INTO workspace_members (workspace_id, user_id, role)
SELECT 1, id, 'owner' FROM users WHERE email = '[email protected]';
SQL

Власні домени використовують TLS на вимогу. Клієнт додає links.brand.com у дашборді, потім спрямовує CNAME на хост, який ви задали в EDGE_CNAME_TARGET (змінна api-core, що за замовчуванням дорівнює власному edge-хостнейму Elido, тож змініть її). При першому HTTPS-запиті ingress-контролер викликає GET /v1/caddy/ask в api-core. Відповідь 200 випускає сертифікат; 403 означає, що домен не верифіковано. Налагоджуйте за допомогою kubectl -n elido logs deploy/api-core | grep caddy/ask.

Резервні копії, оновлення та відкат

Резервні копії - ваша справа. Рекомендація ранбука - щоденні знімки тому Postgres (data-postgres-0) і щотижневі для колонкового сховища (data-clickhouse-0), оскільки дані кліків можна відтворити з шини подій у межах її вікна зберігання. Том шини подій не потребує резервного копіювання. Щоб використати керований Postgres, задайте postgres.enabled=false і спрямуйте url секрету elido-postgres на нього. Виконайте відновлення в тимчасовий простір імен, перш ніж на щось із цього покладатися.

Оновлення - одна команда з новим тегом:

helm -n elido upgrade elido ./deploy/helm/elido \
  -f ./deploy/helm/elido/values-selfhost.yaml --set image.tag=NEW_TAG

Поступові оновлення використовують maxSurge: 1 і maxUnavailable: 0, а helm -n elido rollback elido <revision> повертає Deployment назад, не чіпаючи томів чи секретів. З однією реплікою на сервіс очікуйте коротких збоїв у навантажень, що не є stateless.

Відомі підводні камені

Якщо причина, чому ви тут, - DPO, хостинговий варіант може вже бути достатнім: його основні дані в ЄС, а посібник із резидентності в ЄС перелічує, що обробляється поза ним. Про затримки при запуску власних редиректів дивіться статтю про edge POP.

Читайте також у блозі

• Порівняння самохостингових скорочувачів URL
• Альтернативи Bitly і різниця у функціях
• Як втримати p95 редиректів нижче 15 мс
• Розташування даних в ЄС для маркетингових інструментів
• Edge POP проти маршрутизації лише через DNS