Argo CD: Infrastructure automation with OpenShift GitOps
Objective
This post shows a practical way to learn OpenShift GitOps.
For sysadmins and platform engineers, GitOps can feel abstract. This guide walks you through managing clusters and applications step by step, using Git as the single source of truth.
Requirements
We are using the following items for this laboratory :
- 2 Openshift clusters with minimal configuration.
- Git Repo: This lab is using Github repo.
Gitops concepts
Before diving into configuration, let’s recall the main principles of GitOps:
- Git is the source of truth → all configs stored in version control
- Declarative → you describe the desired state, not commands
- Automation → ArgoCD makes sure the cluster matches Git
- Benefits → auditability, consistency, easy rollback, collaboration
Git repo setup
First of all, create a git repo, clone it, and add apps/, clusters/, components/, then commit and push.
git clone https://$CONFIGURED_REPOSITORY
mkdir -p {apps,clusters,components}
mkdir -p clusters/hub
touch {apps,clusters,components}/README.md
git add -A
git commit -am "gitops directory structure"
git pushDirectory tree of the GIT repo:
├── apps
├── clusters
├── components- apps: Applications of your automation.
- clusters: The configuration of your ArgoCD cluster
- components: The components would be distributed over the managed clusters.
Openshift Gitops setup
Access the Openshift Console > Operators> OperatorHub>find for Openshift Gitops.
Install the Operator
Confirm the installation and wait for the pods to run and be up:
The ArgoCD instance will run fine if everything is okay :
Go to the console and validate the installation:
ArgoCD console :
There are two ways to access the console :
- The cluster-admins group has permission to access via OpenShift Authentication.
- local admin
To get the ArgoCD local Admin :
oc get secret argocd-cluster -n openshift-gitops \
-o jsonpath='{.data.admin\.password}' | base64 -dThe accessed console view :
Setting up the Git repository in ArgoCD
Configure the personal token in Github.
Get Fabio Reis’s stories in your inbox
Join Medium for free to get updates from this writer.
Go to: https://github.com/settings/tokens
Create a classic token with the following permissions:
The “no expiration” option is only for laboratory purposes, never production.
Apply the following secret in the hub cluster:
apiVersion: v1
kind: Secret
metadata:
name: openshift-gitops-repo
namespace: openshift-gitops
labels:
argocd.argoproj.io/secret-type: repository
stringData:
url: https://my-repo-server/openshift-gitops
password: $GENERATED TOKEN
username: not-usedThe repository will appear in the repositories list because Argo CD recognizes repositories labeled with argocd.argoproj.io/secret-type: repository.
Creating the first Application
We will only create a simple example at this moment. The intention is to demonstrate how it works and then scale the solution until we arrive at a GitOps pattern.
Let’s get back to our repository and create the directory example:
mkdir -p example/monitoring/base
mkdir -p example/monitoring/overlays/{dev,hml,prd}
git add -A
git commit -am "first gitops app example"
git push We are creating a similar components directory structure to simulate it.
example
└── monitoring -> Component that would be deployed
├── base -> The template for the solution
└── overlays -> The customization for each cluster environment.
├── dev
├── hml
└── prdWe will use the OpenShift monitoring stack setup as an example.
Configure the base directory:
vi example/monitoring/base/cm-monitoring.yaml
...
---
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-monitoring-config
namespace: openshift-monitoring
data: {}kustomization file of base directory :
vi example/monitoring/base/kustomization.yaml
...
---
kind: Kustomization
apiVersion: kustomize.config.k8s.io/v1beta1
resources:
- cm-monitoring.yamlLet’s create the dev example for our OpenShift Cluster dev
vi example/monitoring/overlay/kustomization.yaml
...
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
patches:
- target:
kind: ConfigMap
name: cluster-monitoring-config
patch: |-
- op: replace
path: /data/config.yaml
value: |-
enableUserWorkload: true
alertmanagerMain:
volumeClaimTemplate:
metadata:
name: pvc-alertmanager
spec:
storageClassName: $STORAGECLASS
resources:
requests:
storage: 10Gi
prometheusK8s:
volumeClaimTemplate:
metadata:
name: pvc-prometheus
spec:
storageClassName: $STORAGECLASS
resources:
requests:
storage: 10GiRemember to update the $STORAGECLASS for your setup.
Add, commit, and push the objects:
git add -A
git commit -am "adding the component example"
git pushConfiguring ArgoCD for the first example
Now go back to the Applications page and add a new App:
You must pass the values :
Source
- Repository URL: The repo that you’re creating.
- Path: The path of the example directory. examples/monitoring/overlays/dev
Destination
- Cluster URL: Maintain the https://kubernetes.default.svc because you’re configuring the local operator as an example.
Click on the create button, and you will see the following screen :
If you’re going into the details of the job, you will see the repo creating the config map cluster-monitoring-config:
The job has created the config map as expected :
And this setup created the PVCs for the openshift-monitoring :
Next Challenges
We finished this part of the installation. The next challenges for the future are:
- Managing Clusters
- Configuring Applications (Application Sets and Apps-of-Apps)
- Fully automated Gitops
