Skip to content

OpenShift recipes to manage cluster infrastructure workload and capabilities using GitOps principles with ArgoCD, helm, kustomize, Tekton and Ansible

License

Notifications You must be signed in to change notification settings

ocp-universe/ocp-recipes

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

OpenShift Recipes

Collection of OpenShift recipes to manage common/infrastructure workload

Using GitOps to manage a Kubernetes/OpenShift cluster with the cross-cutting capabilities like Pipeline, Secret Management or similar. For the realization of the GitOps principles basically ArgoCD is used. In the current state the OpenShift GitOps option is used, which integrates ArgoCD and Pipeline.

The idea of the solution to manage a Kubernetes/OpenShift cluster in the GitOps way has the following pillars

  • Init: which installs the minium tools to support GitOps, here ArgoCD using the Red Hat OpenShift GitOps

  • Cluster Config: The ArgoCD project and app which will manage the cluster and maintain the capabilities. Here is the list of wanted capabilities defined - the descriptive state of your cluster.

  • Cluster Capabilities: All the possible (cross-cutting) capabilities. Usually this is an own repository and not project specific.

Figure Overview solution visualize the relation between the repositories and configuration artifacts.

ocp recipes

To prepare your (new) cluster follow only the 2 steps:

  1. Configure the cluster-config.json in Cluster Config to select the desired state (and capabilities). Some capability examples are in Cluster Capabilities, any other repository is how ever possible.

  2. Apply the init as stated in the instruction in Init to install the foundation (ArgoCD and the bootstrap config).

Some capabilities use ArgoCD wave logic to define the order. Since ArgoCD 1.8 this results in some issues if wave and specific resources like Namespaces are used. See for details issue and docu.

Adjust the existing argocd-cm
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: openshift-gitops
  labels:
    app.kubernetes.io/name: argocd-cm
    app.kubernetes.io/part-of: argocd
data:
  resource.customizations: |
    argoproj.io/Application:
      health.lua: |
        hs = {}
        hs.status = "Progressing"
        hs.message = ""
        if obj.status ~= nil then
          if obj.status.health ~= nil then
            hs.status = obj.status.health.status
            if obj.status.health.message ~= nil then
              hs.message = obj.status.health.message
            end
          end
        end
        return hs
Or the ArgoCD instance
apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: openshift-gitops
spec:
  # ...
  resourceCustomizations: |
    argoproj.io/Application:
      health.lua: |
        hs = {}
        hs.status = "Progressing"
        hs.message = ""
        if obj.status ~= nil then
          if obj.status.health ~= nil then
            hs.status = obj.status.health.status
            if obj.status.health.message ~= nil then
              hs.message = obj.status.health.message
            end
          end
        end
        return hs
Or create a new with the argocd-cm annotation
$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-argocd-cm
  namespace: openshift-gitops
  labels:
    app.kubernetes.io/name: argocd-cm
    app.kubernetes.io/part-of: argocd
data:
  resource.customizations: |
    argoproj.io/Application:
      health.lua: |
        hs = {}
        hs.status = "Progressing"
        hs.message = ""
        if obj.status ~= nil then
          if obj.status.health ~= nil then
            hs.status = obj.status.health.status
            if obj.status.health.message ~= nil then
              hs.message = obj.status.health.message
            end
          end
        end
        return hs
EOF

GitOps approach also for maintaining Kubernetes Clusters. Reusability. Idempotent results.

N/A

This article is licensed under the Apache License, Version 2. Separate third-party code objects invoked within this code pattern are licensed by their respective providers pursuant to their own separate licenses. Contributions are subject to the Developer Certificate of Origin, Version 1.1 and the Apache License, Version 2.

See also Apache License FAQ .

About

OpenShift recipes to manage cluster infrastructure workload and capabilities using GitOps principles with ArgoCD, helm, kustomize, Tekton and Ansible

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published