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.
About the author
Browse by channel
Automation
The latest on IT automation that spans tech, teams, and environments
Artificial intelligence
Explore the platforms and partners building a faster path for AI
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
Explore how we reduce risks across environments and technologies
Edge computing
Updates on the solutions that simplify infrastructure at the edge
Infrastructure
Stay up to date on the world’s leading enterprise Linux platform
Applications
The latest on our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Developer resources
- Customer support
- Red Hat value calculator
- Red Hat Ecosystem Catalog
- Find a partner
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit