* Generate swagger files * Add basic Swagger definitions * Add reposerver swagger file * Consolidate swagger files * Move swagger files to swagger-ui directory instead * Put swagger files in swagger-ui * Fix order of operations * Move back to swagger directory * Serve API server swagger files raw for now * Serve reposerver swagger files from API server * Move back to subdirectories, thanks @alexmt * Fix comment on application Rollback * Update two more comments * Fix comment in session.proto * Update generated code * Update generated swagger docs * Fix comment for delete actions in cluster and repository swagger * Set expected collisions and invoke mixins * Update generated code * Create swagger mixins from codegen * Move swagger.json location, thanks @jazminGonzalez-Rivero * Add ref cleanup for swagger combined * Make fewer temp files when generating swagger * Delete intermediate swagger files * Serve new file at /swagger.json * Set up UI server * Update package lock * Commit generated swagger.json files * Add install commands for swagger * Use ReDoc server instead of Swagger UI server * Update lockfile * Make URL paths more consistent * Update package lock * Separate out handlers for Swagger UI, JSON * Rm unnecessary CORS headers ...since we're serving from the app server * Simplify serving * Further simplify serving code * Update package lock * Factor out swagger serving into util * Add test for Swagger server * Use ServeSwaggerUI method to run tests * Update package lock * Don't generate swagger for reposerver * Reset to master Gopkg.lock and server/server.go * Merge in prev change to server/server.go * Redo changes to Gopkg.lock * Fix number of conflicts * Update generated swagger.json for server * Fix issue with project feature error |
||
|---|---|---|
| .argo-ci | ||
| cmd | ||
| common | ||
| controller | ||
| docs | ||
| errors | ||
| examples/guestbook | ||
| hack | ||
| install | ||
| pkg | ||
| reposerver | ||
| server | ||
| test | ||
| util | ||
| workflows | ||
| .dockerignore | ||
| .gitignore | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| Dockerfile-argocd | ||
| Dockerfile-ci-builder | ||
| gometalinter.json | ||
| Gopkg.lock | ||
| Gopkg.toml | ||
| LICENSE | ||
| Makefile | ||
| OWNERS | ||
| Procfile | ||
| README.md | ||
| VERSION | ||
| version.go | ||
Argo CD - GitOps Continuous Delivery for Kubernetes
What is Argo CD?
Argo CD is a declarative, continuous delivery service based on ksonnet for Kubernetes.
Why Argo CD?
Application definitions, configurations, and environments should be declarative and version controlled. Application deployment and lifecycle management should be automated, auditable, and easy to understand.
Getting Started
Follow our getting started guide.
How it works
Argo CD uses git repositories as the source of truth for defining the desired application state as well as the target deployment environments. Kubernetes manifests are specified as ksonnet applications. Argo CD automates the deployment of the desired application states in the specified target environments.
Application deployments can track updates to branches, tags, or pinned to a specific version of manifests at a git commit. See tracking strategies for additional details about the different tracking strategies available.
Argo CD is implemented as a kubernetes controller which continuously monitors running applications and compares the current, live state against the desired target state (as specified in the git repo). A deployed application whose live state deviates from the target state is considered out-of-sync. Argo CD reports & visualizes the differences as well as providing facilities to automatically or manually sync the live state back to the desired target state. Any modifications made to the desired target state in the git repo can be automatically applied and reflected in the specified target environments.
For additional details, see architecture overview.
Features
- Automated deployment of applications to specified target environments
- Continuous monitoring of deployed applications
- Automated or manual syncing of applications to its target state
- Web and CLI based visualization of applications and differences between live vs. target state
- Rollback/Roll-anywhere to any application state committed in the git repository
- SSO Integration (OIDC, LDAP, SAML 2.0, GitLab, Microsoft, LinkedIn)
- Webhook Integration (GitHub, BitBucket, GitLab)
What is ksonnet?
- Jsonnet, the basis for ksonnet, is a domain specific configuration language, which provides extreme flexibility for composing and manipulating JSON/YAML specifications.
- Ksonnet goes one step further by applying Jsonnet principles to Kubernetes manifests. It provides an opinionated file & directory structure to organize applications into reusable components, parameters, and environments. Environments can be hierarchical, which promotes both re-use and granular customization of application and environment specifications.
Why ksonnet?
Application configuration management is a hard problem and grows rapidly in complexity as you deploy more applications, against more and more environments. Current templating systems, such as Jinja, and Golang templating, are unnatural ways to maintain kubernetes manifests, and are not well suited to capture subtle configuration differences between environments. Its ability to compose and re-use application and environment configurations is also very limited.
Imagine we have a single guestbook application deployed in following environments:
| Environment | K8s Version | Application Image | DB Connection String | Environment Vars | Sidecars |
|---|---|---|---|---|---|
| minikube | 1.10.0 | jesse/guestbook:latest | sql://locahost/db | DEBUG=true | |
| dev | 1.9.0 | app/guestbook:latest | sql://dev-test/db | DEBUG=true | |
| staging | 1.8.0 | app/guestbook:e3c0263 | sql://staging/db | istio,dnsmasq | |
| us-west-1 | 1.8.0 | app/guestbook:abc1234 | sql://prod/db | FOO_FEATURE=true | istio,dnsmasq |
| us-west-2 | 1.8.0 | app/guestbook:abc1234 | sql://prod/db | istio,dnsmasq | |
| us-east-1 | 1.9.0 | app/guestbook:abc1234 | sql://prod/db | BAR_FEATURE=true | istio,dnsmasq |
Ksonnet:
- Enables composition and re-use of common YAML specifications
- Allows overrides, additions, and subtractions of YAML sub-components specific to each environment
- Guarantees proper generation of K8s manifests suitable for the corresponding Kubernetes API version
- Provides kubernetes-specific jsonnet libraries to enable concise definition of kubernetes manifests
Development Status
- Argo CD is in early development
Roadmap
- PreSync, PostSync, OutOfSync hooks
- Customized application actions as Argo workflows
- Blue/Green & canary upgrades
