69 lines
3.4 KiB
Markdown
69 lines
3.4 KiB
Markdown
# ADR 0002: Use the team's existing ArgoCD instance for deployment (GitOps)
|
|
|
|
## Status
|
|
|
|
**Accepted — still the target, not yet implemented.** Not superseded by the
|
|
current production setup.
|
|
|
|
Since 2026-08-10 the project has a *different*, interim deployment: a single
|
|
EC2 box running `infra/docker/docker-compose.prod.yml` behind Caddy, deployed
|
|
by `.github/workflows/deploy.yml` over SSH. That was built to get a working
|
|
demo online, not to replace this decision. Migrating to the team's Kubernetes
|
|
+ ArgoCD remains planned work, and the expensive prerequisite — containerising
|
|
both apps — is already done, so the Dockerfiles and compose services port over.
|
|
|
|
Two things must still happen and neither has been started:
|
|
|
|
1. **Repository move to the team's self-hosted Gitea** (company domain), which
|
|
is where the GitOps repo is meant to live. The project stays on private
|
|
GitHub until that move is deliberately made. Note the hard boundary already
|
|
in force: the team's existing `git.vinmec.tech/ai-team/gitops` repository is
|
|
**reference-only** — never push this project into it.
|
|
2. **Filling in the scaffolds this ADR assumes exist.** `infra/helm/medical-chatbot/templates/`
|
|
and `infra/k8s/**` are empty (`.gitkeep` only), the chart is version `0.0.0`,
|
|
and every `infra/argocd/applications/*/app.yaml` still carries unresolved
|
|
TODOs for project, repo URL and destination cluster.
|
|
|
|
## Context
|
|
|
|
Phase 6 of the build roadmap needs a way to actually deploy the Helm chart to
|
|
Kubernetes across dev/staging/prod. The original scaffold (`infra/ci/github-actions/deploy-cd.yml`)
|
|
assumed a push-based CI deploy step (CI runs `helm upgrade`/`kubectl apply`
|
|
directly against the cluster). The team already runs an ArgoCD instance used
|
|
by other projects.
|
|
|
|
## Decision
|
|
|
|
Deploy via **GitOps through the team's existing ArgoCD instance** instead of
|
|
building a custom push-based CD pipeline. ArgoCD Applications
|
|
(`infra/argocd/applications/{dev,staging,prod}/app.yaml`) point at
|
|
`infra/helm/medical-chatbot` in this repo; ArgoCD watches the repo and
|
|
reconciles the cluster to match.
|
|
|
|
## Rationale
|
|
|
|
- Reuses infrastructure the team already operates and trusts, instead of
|
|
standing up a parallel deploy mechanism.
|
|
- GitOps gives an auditable history of every deploy (it's just git commits
|
|
changing values files/image tags) and a built-in rollback path (revert the
|
|
commit).
|
|
- Removes the need for CI to hold cluster credentials — CI's job shrinks to
|
|
"build, test, push image, bump tag," which is a smaller security surface
|
|
than "CI can directly mutate the production cluster."
|
|
- Prod uses a non-automated `syncPolicy` (manual approval in ArgoCD) while
|
|
dev/staging auto-sync, matching normal caution around production changes.
|
|
|
|
## Consequences
|
|
|
|
- CI workflows (`infra/ci/github-actions/*.yml`) build/test/push images and
|
|
bump the relevant `values-<env>.yaml` image tag + push that commit; they do
|
|
**not** call `kubectl`/`helm` against any cluster directly.
|
|
- Actual deploy execution and health/sync status live in the team's ArgoCD
|
|
UI/CLI, outside this repo — runbooks in `docs/runbooks/` should document how
|
|
to check sync status and roll back once the team's ArgoCD instance details
|
|
(cluster/server, project, repo URL) are confirmed (see TODOs in
|
|
`infra/argocd/README.md`).
|
|
- If the team's ArgoCD instance becomes unavailable or this project needs to
|
|
fully own its own deploy tooling later, the push-based `deploy-cd.yml`
|
|
approach remains a documented fallback.
|