Design and Implementation of an ArgoCD‑Based Continuous Delivery System at Liulishuo

Background : The original in‑house CD system (AppOS) suffered from poor maintainability, limited extensibility, and low usability, prompting the team to evaluate open‑source alternatives and ultimately adopt ArgoCD.

Why ArgoCD? It offers a visual UI, GitOps‑driven configuration stored in GitLab, and a clear open‑source architecture that simplifies maintenance.

Official quote: “Application definitions, configurations, and environments should be declarative and version controlled. Application deployment and lifecycle management should be automated, auditable, and easy to understand.”

Liulishuo Architecture :

ArgoCD components: api‑server, repo‑server, application‑controller, notification‑controller, dex‑server.

Liulishuo components: apps repo (desired state), code repo, cd‑webhook, operator (Jsonnet templating CLI), cd‑applier, notification‑wechat.

Design Concepts (standardized terminology): team, app, component, env, cluster, k8s.

Deployment Flow – Case 1: New App

Create an app directory in the apps repo using the operator create command: Usage: operator create --ns <namespace> --team <team> --app <app> --component <component> --env <env> --clusters <cluster0,cluster1,...> --kinds <kind1,kind2,...> [flags]

Each app follows the hierarchy <app>/<component>/<env>/<cluster> with a config.libsonnet template at each level.

Modify the generated Jsonnet (e.g., image, command) and build it into a Kubernetes manifest: (import'../config.libsonnet') + { data+: { deployment+: { default+: { spec+: { replicas:1, template+: { spec+: { containers+: { image:'nginx:1.19.6', }, }, }, }, }, }, }, }

Run operator build <path> to produce the final YAML.

Commit the changes to GitLab; ArgoCD automatically syncs and creates the application via the cd‑applier service.

Monitor deployment status in the ArgoCD UI, which shows health, sync state, and out‑of‑sync alerts.

Case 2: Updating an Existing Service

Code commit triggers CI.

CI triggers cd‑webhook to update the image in the apps repo.

Example JSON payload for image change: { "refer": "https://xxxx", "author": "[email protected]", "message": "xxx", "team": "cloud-infra", "app": "example", "items": [{ "component": "demo", "env": "dev", "cluster": "all", "kind": "deployment", "version": "default", "image": "nginx:1.19.6" }], "jsonnetItems": [{ "component": "demo", "env": "dev", "cluster": "all", "path": ".data.deployment.default.spec.template.spec.containers.image", "image": "nginx:1.19.6" }] }

ArgoCD detects the change, syncs automatically, and notifies via the message center.

Advantages :

Declarative, version‑controlled application definitions (GitOps).

Integration of GitLab + Jsonnet for flexible templating.

Implemented as a Kubernetes controller that continuously reconciles desired state with actual state, marking out‑of‑sync resources and providing visual diff and auto‑sync capabilities.

Conclusion : By standardizing on <app>-<component> naming, labels, and a unified monitoring model, Liulishuo achieved a streamlined, observable, and stable CI/CD pipeline on Kubernetes.

Outlook : Future work includes adding gray‑release capabilities using ingress controllers and service meshes to enable automated progressive rollouts without manual intervention.

References :

https://argo-cd.readthedocs.io/en/stable/

https://argoproj.github.io/argo-rollouts/