| **mocks-test** | WireMock, Mailpit | `sova-mocks` | internal only | по pod |
---
## sova-root — «корневое» GitOps-приложение
**Назначение:** паттерн *app-of-apps*. Один `Application` следит за каталогом `sova-deploy/argocd/apps/` и создаёт/обновляет остальные Application-манифесты (`backend-test`, `data-test`, …).
**Почему «нельзя войти»:**
- Это **мета-приложение**. Оно не разворачивает Deployment, Service или Ingress.
- В дереве ресурсов — только объекты типа `Application` в namespace `argocd`.
- Нет веб-интерфейса, логина пользователя или pod'а для exec.
**Как пользоваться:** смотрите дочерние приложения (`backend-test`, `docs-test`, …). `sova-root` нужен для автоматического подхвата новых Application при push в `sova-deploy`.
```mermaid
flowchart TB
root["sova-root Application"]
apps["argocd/apps/*.yaml"]
be["backend-test"]
data["data-test"]
docs["docs-test"]
root --> apps
apps --> be & data & docs
```
---
## data-test — инфраструктура данных
**Назначение:** Helm-чарт `sova-deploy/data/test` — PostgreSQL (backend + cabinet БД), MySQL Bitrix, Redis для test-контура.
**Почему «нельзя войти»:**
- Это **слой данных**, не пользовательское приложение.
- Нет Ingress и публичного hostname.
- «Войти» в ArgoCD UI можно только в смысле открыть карточку приложения — там StatefulSet/Deployment БД, а не сайт.
# Инициализация schema/seed — отдельный Job db-init (чарт data/db-init), не через браузер
kubectl get jobs -n sova-data-test
```
**Terminal:** технически можно `exec` в pod PostgreSQL/MySQL, но это для DBA/отладки, не «логин в приложение».
**Sync degraded:** если в чарте `data/test` был лишний шаблон `db-init` с несуществующими values (`postgres.*` вместо `postgresql.*`), Application падал в ошибку. Инициализация БД выполняется **отдельным** чартом `data/db-init` через `deploy-test-stack.sh`.
Скрипт создаёт аннотированный тег в локальном зеркале репозитория и пушит в Gitea. Workflow парсит суффикс `-test` и обновляет соответствующий `values-test.yaml`.
| MySQL | `sova_bitrix_test` | Views/синк Bitrix |
| Redis | — | Кэш, messenger |
MySQL поднят через простой manifest `mysql:8.0` (Bitnami chart давал ImagePullBackOff). Auth plugin: `mysql_native_password` для совместимости с клиентом в init Job.
- Репозитории в Gitea: `sova/backend`, `sova/adminpanel`, `sova/sova-deploy`, `sova/sova-mocks`.
#### Backend: stateless console в ArgoCD
Помимо Deployment (nginx + php-fpm), chart `apps/backend` создаёт **CronJob-ы с контейнером `console`** — Symfony-команды по расписанию. В ArgoCD они видны в дереве приложения `backend-test` как отдельные ресурсы с label `app.kubernetes.io/component: console`:
Конфигурация — список `cronjobs` в `values.yaml`. Для test-контура Job миграций (`backend-migrate`) **отключён** (`migrate.enabled: false`), т.к. схема накатывается через `db-init`, а не `doctrine:migrations:migrate`. На stage/prod можно включить PreSync-migrate.
Deployment использует initContainer `warmup-cache` и `emptyDir` для `/app/var/cache` и `/app/var/log` — иначе Symfony не может писать кэш в prod (HTTP 500).
### Platform layer
| Компонент | Namespace | Ingress |
|-----------|-----------|---------|
| ingress-nginx | `ingress` | LoadBalancer на IP VM |
| Loki + Promtail | `monitoring` | только внутри кластера (логи в Grafana) |
**Метрики vs логи:** Prometheus собирает **метрики** (CPU, память, kube-state). **Логи подов** — через **Loki + Promtail** (Explore → Loki в Grafana). Без Loki в Grafana «логов нет» — это ожидаемо до `./scripts/deploy-monitoring-logs.sh`.
```bash
# После deploy-platform или отдельно:
./scripts/deploy-monitoring-logs.sh
# В Grafana Explore:
# datasource: Loki
# query: {namespace="sova-test", app="backend"}
```
**Важно для ArgoCD:** UI работает по HTTP только при:
-`server.insecure=true` в `argocd-cmd-params-cm` (ключ `server.insecure`, не вложенный YAML);
-`url: http://argocd.sova.local` в `argocd-cm`;
- ingress без принудительного HTTPS.
**Терминал в pod (exec):** по умолчанию в Argo CD выключен. В test-контуре включён через `sova-deploy/platform/argocd/values-test.yaml` (`exec.enabled: true` + RBAC). В UI: Application → backend-test → Pod → **⋮** → **Terminal** → контейнер **`php-fpm`**.
Цепочка по тегу `backend-v1.0.1-test` / `adminpanel-v1.0.1-test`:
1.**test** — composer / npm, lint, build
2.**build-and-push** — Docker-образ в Gitea Container Registry
3.**deploy-gitops** — commit в `sova/sova-deploy` (repository, tag, pullPolicy)
### Registry и секреты CI
| Секрет | Назначение |
|--------|------------|
| `REGISTRY_USER` / `REGISTRY_PASSWORD` | Push образов (`gitea_admin` — у`sova-ci` нет прав на packages) |
| `DEPLOY_TOKEN` | HTTPS push в `sova-deploy` |
| `HOST_IP` | IP VM для `/etc/hosts` (имена с префиксом `GITEA_` Gitea не принимает) |
Push из runner идёт на **внутренний URL**`gitea-http.gitea.svc.cluster.local:3000` (DinD не резолвит `git.sova.local`). В`values-test.yaml` для pull на ноде k3s используется **`git.sova.local/sova/backend`** — после `./scripts/configure-k3s-registry.sh`.
```bash
./scripts/bootstrap-gitea-ci-secrets.sh # секреты в Gitea Actions
Terraform-модуль `sova-platform/terraform/modules/k3s-single-node` можно использовать и для удалённого сервера: задать `server_ip`, `ssh_user`, `ssh_private_key_path` в `terraform.tfvars`.
### 3. DNS вместо /etc/hosts
Замените `*.sova.local` на реальный домен, например:
-`sova-adminpanel/public/env.js` (или ConfigMap) — `API_BASE_URL`
### 4. TLS (рекомендуется на сервере)
1. cert-manager уже ставится через `deploy-platform.sh`.
2. Создайте ClusterIssuer Let's Encrypt (HTTP-01 или DNS-01).
3. В Ingress добавьте `tls:` секции и annotation `cert-manager.io/cluster-issuer`.
4. Для ArgoCD при TLS на ingress: оставьте `server.insecure=true`**или** настройте TLS passthrough — см. [документацию ArgoCD](https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/).
### 5. Образы: с локального import на registry
**Сейчас (Multipass):** образы собираются на Mac, импортируются через `multipass transfer` + `k3s ctr images import`, `image.pullPolicy: Never`.
**На сервере:**
```bash
# Вариант A: registry в Gitea
# После bootstrap-gitea — включить Container Registry в Gitea,
В`k3s-test/` собран **полноценный test-контур**: приложения, изолированные БД (schema → seed), моки внешних сервисов, GitOps и заготовка CI. Локально он крутится на Multipass + k3s и имитирует production-подобный стек без изменений монорепо.
Перенос на удалённый сервер — это в основном замена **домена**, **TLS**, **registry образов** и **управления секретами**; скрипты и Helm charts из `k3s-test/` переиспользуются с минимальными правками `values-test.yaml`.
Дальнейшие шаги для production-ready test-сервера:
1. DNS + TLS
2. Gitea Container Registry (для `docker push` в CI)
3. SealedSecrets
4. Backup БД
5. Отдельный stage-контур с `values-stage.yaml`
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
sova-bootstrap