ArgoCD
Argo CD is a service that allows you to continously deploy applications to NKE clusters by using a gitops workflow.
Details
For customers who need to continously deploy application code, Argo CD provides:
- declarative and version controlled application deployments
- automation and traceability via gitOps workflow
- support for Helm, kustomize and jsonnet application declarations
- a web UI for visualizing kubernetes resources
- webhook integration to fully automate deployments on git operations
- a command line interface application
- audit trails for application events and API calls
- parameter overrides of Helm/ksonnet declarations (simplifies development deployments)
- a grafana metrics dashboard
Availability
Argo CD is available as an optional service for NKE. It can be deployed using Cockpit and can connect with any number of configured NKE clusters.
Usage
Before starting to use Argo CD it is important to understand how a typical workflow should look in the end. Argo CD supports a continous deployment by utilizing a gitops workflow. For that to work it recommends to separate application code from application configuration (Helm charts, kustomize files, etc.). The separation should happen by using 2 different git repositories. Although it is technically possible to use 1 git repository, best practises advise strongly against doing so.
When using 2 separate git repositories, one possible production deployment workflow with Argo CD could look like:
- a developer creates a pull request/merge request to get some application code changes merged into the master branch
- after merging of the changes happened (and all tests passed), a tag will be created by the developer signaling that a new productive version of the application should be build
- a CI pipeline starts. It executes the following steps:
- it builds, tags and pushes a new application container image.
- it creates a commit in the configuration git repository, specifying the new image version to be used (for example by changing the content of the values.yaml in a Helm chart)
- it pushes the commit
- (optional) a git webhook signalises Argo CD to check for new commits in the configuration repository
- Argo CD deploys the new image version of the container
Argo CD is not connected to the application source code repository in any way. It only connects to the configuration git repository (read only permissions are sufficient).
If there are any problems with the deployed version, a rollback can be initiated by reverting the commit in the configuration git repository. ArgoCD will then deploy the previous version of the image.
For a further separation of access it is also possible to not directly commit to the configuration git repository within the pipeline. Instead a pull request/merge request will be created which needs to be approved before the new image version should be deployed. With this it is possible to give developers access to the code repository without granting permissions in the configuration repository.
Requirements
To be able to use Argo CD (for production deployments) with a gitops workflow you will need at least the following:
- the URL to your Argo CD installation (see Login)
- a kubernetes namespace where Argo CD can deploy to (see here)
- a git repository with the configuration of your application (called the
config repo). This can be:
- a kustomize application
- a Helm chart
- a directory of plain yaml manifests
- a jsonnet application
- a CI tool/service for:
- automatically building container images
- doing changes to the configuration repository (optional)
We at Nine are preferring Helm charts as we are using them in the company ourselves. An example Helm application configuration which deploys a guestbook application can be found in the argo project github namespace in the helm-guestbook directory.
Permissions
The current authorization concept permits all configured NKE users with one of the following roles with full access to all Argo CD applications and projects in their installation of Argo CD:
- admin
- user
Users with the role "view" are only permitted to see configured Argo CD applications and projects, but are not authorized to change them.
Login
Argo CD provides a web user interface as well as a cli application to interact with it.
Web UI
You can find the URL in Cockpit.
You can login with your Cockpit account credentials after clicking on Login via Nine in the web UI.
CLI
The CLI application can be downloaded on the help page in the Argo CD web interface (you will find a link to the help page in the navigation menu on the left side).
To login via the cli application, please follow these steps:
- execute
argocd login <Argo CD URL> --sso
locally in a terminal on your machine - argocd will open a browser page so that you can enter your Nine Cockpit credentials
- after a successful authentication you can use
argocd
locally on the cli as an authenticated user
Argo CD opens a local port (8085 by default) on your machine to be able to authenticate via single sign on. If that port is already in use by another application, please choose a different port by the using the --sso-port
argument.
Configuration resources in Argo CD
Argo CD introduces 2 kubernetes resources: Applications and Projects.
Applications: The Application CRD is the Kubernetes resource object representing a deployed application instance in an environment. It is defined by two key pieces of information:
- a source reference to the desired state in the configuration Git (repository, revision, path, environment)
- a destination reference to the target cluster and namespace.
It basically describes which configuration state should be deployed to which namespace in your cluster.
Projects: The AppProject CRD is the Kubernetes resource object representing a logical grouping of applications. It is defined by the following key pieces of information:
- a sourceRepos reference to the configuration repositories that applications within the project can pull manifests from
- a destinations reference to clusters and namespaces that applications within the project can deploy into
- a roles list of entities with definitions of their access to resources within the project