Is it too late to integrate GitOps?

Author: Ryan Cook (rcook@redhat.com)

Is it too late to integrate GitOps?
By: Ryan Cook

The idiom “missed the boat” can be used to describe the loss of an opportunity or a chance to do something. With OpenShift, the excitement to use this new and cool product immediately may create your own “missed the boat” moment in regards to managing and maintaining deployments, routes, and other OpenShift objects but what if the opportunity isn’t completely gone?

Continuing with our series on GitOps, the following article will walk through the process of migrating an application and its resources that were created manually to a process in which a GitOps tool manages the assets. To help us understand the process we will manually deploy a httpd application. Using the steps below we will create a namespace, deployment, and service and expose the service which will create a route.

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml

oc expose svc/httpd -n simple-app

We start with our sample application managed manually, then bring it under GitOps control in a way which ensures the application remains available.

• Define a repository for the code
• Export our current objects and load into git
• Select and deploy a GitOps tool
• Add the repository to our GitOps tool
• Define the application in our GitOps tool
• Perform a dry run of the object using the GitOps tool
• Perform sync of the objects using the GitOps tool
• Enable pruning and auto-syncing of the objects

As we have stated in the previous GitOps articles, when using GitOps the git repository is the source of truth for all of your objects within your Kubernetes cluster(s). We will assume that a git repository service is currently being used within your organization. This git repository can be public or private but the repository must be accessible by the Kubernetes clusters. The repository can be the same one as where the application code exists or a separate repository can be used specifically for deployments. It is suggested that the repository has strict permissions as secrets, routes, and other objects need to be stored.

For this exercise a new public repository can be created on GitHub. The repository can be named whatever you like but for this example we will use the name blogpost for our repository.

If the YAML files for the objects have not previously been stored in git or locally then oc or kubectl binary can help us out. Below we will request the YAML for our namespace, deployment, service, and route. Clone the newly created repository and cd into the directory.

oc get namespace simple-app -o yaml --export > namespace.yaml

oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml

oc get service httpd -o yaml -n simple-app --export > service.yaml

oc get route httpd -o yaml -n simple-app --export > route.yaml

Make the following modification to the deployment.yaml to remove a field in which Argo CD cannot sync properly.

sed -i '/\sgeneration: .*/d' deployment.yaml

We also must modify the route. We will first set a multiline variable and then we will replace ingress: null with the contents of the variable.

export ROUTE="  ingress:\\

    - conditions:\\

        - status: 'True'\\

          type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yaml
 

Once we have these files it is time to save them into the git repository. From this point forward, the repository should be the source of truth for anything and manual changes to any of the objects should be prohibited.

git commit -am ‘initial commit of objects’

git push origin master

We will assume that ArgoCD has already been deployed based on this blog post. So we will add the newly created repository to Argo CD that contains the simple-app code. Ensure that the repository below matches the one that was created in previous steps.

argocd repo add https://github.com/cooktheryan/blogpost

Next, create the app. The app defines the values for the GitOps tool to know the repository and path to use, the OpenShift cluster to manage the objects, the specific branch of the repository, and whether to sync assets automatically or not.

argocd app create --project default \

--name simple-app --repo https://github.com/cooktheryan/blogpost.git \

--path . --dest-server https://kubernetes.default.svc \

--dest-namespace simple-app --revision master --sync-policy none

Once the application has been defined in Argo CD the tool will begin to verify the current objects deployed objects versus those defined in the repository. We have the sync policy currently disabled and pruning is not enabled so no items should be changed at this point. One thing that you will notice is that the application within Argo CD UI will be stated as “Out of Sync” this is due to a missing label that ArgoCD supplies. This label will not cause any assets to be redeployed when we run the sync.

Now let’s run a dry run to ensure no errors exist within our files.

argocd app sync simple-app --dry-run

If no errors show up during the dry run we can move forward with the sync.

argocd app sync simple-app

When running the command argocd get on our simple-app application we should see that the application is “Healthy” and “Synced”. This means that all of the resources in our git repository now match those that are deployed.

argocd app get simple-app

Name:               simple-app

Project:            default

Server:             https://kubernetes.default.svc

Namespace:          simple-app

URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app

Repo:               https://github.com/cooktheryan/blogpost.git

Target:             master

Path:               .

Sync Policy:        <none>

Sync Status:        Synced to master (60e1678)

Health Status:      Healthy

...

At this point we can enable “auto-sync” and “pruning” to ensure that nothing in manually created and that any time an object is updated and pushed to the repository it will be deployed.

argocd app set simple-app --sync-policy automated --auto-prune

Now you have successfully migrated an application that did not initially use GitOps to a GitOps managed application.