ArgoCD

ArgoCD is a tool that compares the status of objects in a Kubernetes cluster and a git source, and depending on settings either automatically fixes the cluster state to match git or alerts about a difference.

There are multiple plugins available for ArgoCD, but for Tike Container Platform the Red Hat flavored OpenShift GitOps can be requested from the container administration.

Basic principles

In order to operate, ArgoCD needs the following:

• An Application or ApplicationSet resource
  • If the resource points to git and the repository is private, a Secret with the label argocd.argoproj.io/secret-type=repository
    • For Gitlab, an account for this can be created from Settings -> Repository -> Deploy tokens. Only read_repository is required.

In addition, ArgoCD will need to have permission to manage objects in another namespace. In OpenShift, the managed namespace will need a label such as 

and for vanilla ArgoCD, this is usually done by creating a ServiceAccount, Role and RoleBinding.

Example Application

Below is an example application that utilizes kustomize (a "templating" tool) to create all resources defined in path/to/folder.

Repository Secret

The repository when using a http-based authentication looks like

Templating with ArgoCD

Even though ArgoCD can check individual files from a git source, using a templating language such as kustomize or Helm is easier. Both require their own binaries, but of the two kustomize is simpler since Helm utilizes jinja2-templates that allow for inputting conditionals to the generated yaml.

Remember that Secrets are only base64 encoded, so putting them in git is not recommended. Instead, use SealedSecrets.

Kustomize

When using kustomize with ArgoCD the recommended pattern is to have the default parts of your application in base, with environment specific details in overlays/environment. You can make sure all changes are automatically applied by pointing an ArgoCD Application to the folder where it resides by adding the Application definition to kustomize in git.

Here we are inheriting all files added to ../../base and adding in the yaml-file called create-test.application.yaml.

Also note the naming convention of resource-name.resource-type.yaml

For a regular Deployment in OpenShift, the kustomization.yaml will probably include the yaml files for

• BuildConfig
• Deployment
• ImageStream
• Service
  • Also Route or Ingress if it is accessible from the Internet
• (PersistentVolumeClaim)
• SealedSecrets and ConfigMaps if those are required

The benefit in using kustomize is being able to have all environments to start from the same "defaults", and then adding/patching/removing definitions for environment specific configurations. This reduces the amount of repetition in yaml files.

An unfinished kustomize workshop can be found here: https://version.helsinki.fi/tike-kontit/openshift-esimerkit/kustomize-esimerkit

Helm

ArgoCD can also manage the installation of Helm-charts

Below is a snippet of an application that installs the Helm chart for Dependency Track. Note that Helm chart options are usually saved in a file called values.yaml, which can be overwritten by placing the key-value pair under valuesObject.

Since environments could have overlapping and differing values for the Helm-chart, the recommended way is to add the Application that installs the Helm-chart to base/kustomization.yaml and then patching the application for environment specific values. This also includes patching the targetRevision per environment.