Два репозиторії

Платформа пишеться в одному репозиторії, а встановлюється з іншого.

Поки цієї сторінки не було, другий репозиторій не був названий тут ніде — ні в README, ні в документі, ні в коментарі. Тому кожна інфраструктурна сторінка тут була водночас чесною і хибною: вона описувала рівно те, що видно звідси, а інсталяція звідси не видна. Читач, який сумлінно відкрив GitOps або Кластер і ноди, почне будувати те, що вже кілька тижнів стоїть і обслуговує трафік.

Другий репозиторій — Agentfy/gitops.

	цей репозиторій (Agentfy/agentfy)	Agentfy/gitops
Код продукту	api, app, admin, worker і ці документи	—
Об'єкти Kubernetes	два шаблони, які слайс runtime/worker застосовує сам, під час роботи, по одному разу на сесію (k8s/runtime/)	усе довгоживуче: Application-об'єкти Argo CD і Helm-чарти, які вони доставляють
Terraform	terraform/ — самостійний шлях підняти кластер з нуля, на Hetzner або на AWS. Див. застереження нижче.	terraform/ + ansible/ — те, з чого реально підняті сервери, що працюють зараз
Секрети	немає. api читає конфігурацію з оточення, яке йому дали	Vault і об'єкти External Secrets, що перетворюють шлях у Vault на звичайний Kubernetes Secret
Деплой	—	коміт. У кожного Application стоїть automated: {prune: true, selfHeal: true}

Правило, яке не дає їм брехати одне одному: посилатися, а не копіювати. Маніфест, вставлений у цей репозиторій, за місяць розійдеться з оригіналом — і саме цю хворобу сторінка лікує. Називайте файл; файл і є істина.

Що Argo CD розгортає сьогодні

Прочитано за маніфестами в Agentfy/gitops, файл за файлом, — не з чиїхось слів.

Що	Де оголошено	Що в цьому файлі насправді стоїть
Корінь	bootstrap/root-app.yaml	один Application з іменем root, що дивиться в gitops-apps/control на main. Застосовується руками, один раз; усе нижченаведене досягається з нього
Сам Argo CD	gitops-apps/control/argocd.yaml	helm-чарт argo-cd 10.3.2, керує сам собою, server.insecure: true (TLS завершується на Traefik)
Vault	gitops-apps/control/vault.yaml	helm-чарт vault 0.34.0, standalone, dataStorage 5Gi, ingress traefik на vault.agentfy.ai з cert-manager.io/cluster-issuer: letsencrypt-prod, ui.enabled: true
Rancher	gitops-apps/control/rancher.yaml	чарт rancher 2.15.0 на rancher.agentfy.ai
cert-manager	gitops-apps/control/cert-manager.yaml і по одному на контур у gitops-apps/{dev,prod}/	v1.21.1, CRD увімкнено
External Secrets Operator	gitops-apps/dev/external-secrets.yaml і gitops-apps/prod/external-secrets.yaml	чарт external-secrets 2.9.0, в обох контурах, ServiceAccount external-secrets
Стор Vault	gitops-apps/{dev,prod}/manifests/external-secret*/clustersecretstore.yaml	ClusterSecretStore з іменем vault: сервер https://vault.agentfy.ai, KV v2 за шляхом secret, автентифікація kubernetes, mountPath kubernetes-dev / kubernetes-prod, роль eso
Живий споживач, у проді	gitops-apps/prod/manifests/external-secrets/externalsecret-external-dns.yaml	тягне prod/external-dns у секрет кластера external-dns-aws, refreshInterval: 1h
ExternalDNS	gitops-apps/{dev,prod}/external-dns.yaml	чарт 1.21.1, Route53, domainFilters: [agentfy.ai], policy: sync, свій txtOwnerId на контур
Reloader	gitops-apps/dev/reloader.yaml	stakater reloader 2.2.14
Продукт	agentfy-apps/dev/agentfy-{api,app,admin,redis}.yaml → helm/agentfy-{api,app,admin,redis}/	чотири чарти в namespace agentfy на dev-кластері, порядок за sync-wave: redis (0), api (1), app і admin (2)

Двом пунктам потрібен окремий рядок, бо якась сторінка в цьому репозиторії досі стверджує протилежне:

• api розгорнуто, і розгортає його Argo CD. helm/agentfy-api/ несе Deployment, Service, Ingress, HPA, ConfigMap, RBAC runtime-controller / runtime-worker і ExternalSecret, який наповнює оточення api з Vault (values.dev.yaml → secrets.vaultKey: dev/agentfy-api).
• Міграції Prisma виконуються, але як initContainer у Deployment api (helm/agentfy-api/templates/deployment.yaml, runMigrations), а не як PreSync-хук Argo, який планувався в цих документах.

Де межа проходить насправді

Чиста половина проста: Argo CD і все, що Argo CD розгортає, живуть в Agentfy/gitops. Ніщо в цьому репозиторії не деплоїть довгоживуче навантаження, і не повинно починати.

Друга половина акуратнішою не стає, і записана тут, а не згладжена:

• Сервери під робочою інсталяцією теж підняті з Agentfy/gitops — terraform/mgmt.tf, terraform/db.tf, terraform/loadbalancer.tf для мережі Hetzner, management-ноди, двох нод PostgreSQL і балансувальників; ansible/k3s.yml для односерверного k3s — control-кластера на management-ноді. Кластери dev і prod провіжаняться через Rancher — тому loadbalancer.tf пише, що мітку lb-target проставляє Rancher, і тому кожен робочий Application дивиться на https://10.0.1.3:6443 (dev) або https://10.0.1.9:6443 (prod), а не на control-кластер.
• terraform/ цього репозиторію — тому другий шлях, а не той, що відпрацював. Він піднімає кластер через kube-hetzner (або EKS з боку AWS), у трьох пулах нод, з CloudNativePG і Redis усередині кластера. У живої інсталяції немає жодної з цих рис: Postgres стоїть на своїх VM у Hetzner, налаштованих ansible/roles/postgres, а Redis — звичайний Deployment з helm/agentfy-redis.

Чи має terraform/ цього репозиторію замінити той шлях, обслуговувати другу інсталяцію або бути списаним — ніде не записано так, щоб це можна було перевірити, тому сторінка цього не вирішує. Див. terraform/README.md, де тепер стоїть те саме застереження.

Що лишається тут і чому це не дубль

У k8s/runtime/ лежать два шаблони, і жоден з них не належить Argo CD:

• namespace-rbac.template.yaml — ServiceAccount, Role і RoleBinding для одного runtime-namespace.
• worker-egress.template.yaml — default-deny egress над подами воркера.

Їх застосовують імперативно, під час роботи: слайс runtime/worker і .superset/k3d.sh на ноутбуці, підставляючи __NAMESPACE__ і плейсхолдери control-каналу в момент застосування. Argo CD не повинен ними володіти: він бачив би об'єкти кожної сесії як дрейф і прунив би їх посеред задачі.

Одна чесна нерівність: helm/agentfy-api/templates/runtime-rbac.yaml в Agentfy/gitops — другий вираз того самого RBAC, написаний як Helm-шаблон, а не як файл із плейсхолдерами. Вони не породжуються одне з одного і можуть розійтися. Це реальна ціна, і вона названа тут, а не виявлена потім.

Що перевірити не вдалося

Записано як прогалини, бо вигадати підтвердження гірше, ніж визнати, що його немає:

• Де збираються образи застосунків. helm/*/values.dev.yaml фіксує ghcr.io/agentfy/agentfy-{api,app,admin} на конкретних тегах, отже образи існують, — але в жодному з репозиторіїв немає workflow, який би їх збирав чи пушив. Три workflow GitHub Actions в Agentfy/gitops — це ansible-lint і два ручні запуски Ansible.
• У app у цьому репозиторії немає Dockerfile — у api, admin і worker є, — а helm/agentfy-app/values.dev.yaml фіксує образ agentfy-app. Звідки цей образ береться, не записано в жодному з репозиторіїв.
• У контурі prod немає продукту. gitops-apps/control/ оголошує agentfy-dev-services і не оголошує prod-аналога, а в agentfy-apps/ є лише тека dev/. Прод несе платформу (ESO, cert-manager, ExternalDNS, reloader) і, судячи з маніфестів, жоден з чотирьох застосунків.
• Нічого не перевірялося проти живого кластера. Кожне твердження на цій сторінці взяте з файлу в Agentfy/gitops на main. Маніфест — це те, до чого Argo CD велено зводити кластер; що він звівся — окреме твердження, і ця сторінка його не робить.

Див. також

• GitOps (ArgoCD) — задум і те, які його частини інсталяція взяла.
• Кластер і ноди · Ресурси · Хмарна стратегія — план, з позначками про сьогоднішній стан.