GitOps With OpenShift Applier
GitOps With OpenShift Applier
GitOps in short is a set of practices to use Git pull requests to manage infrastructure and application configurations.
Join the DZone community and get the full member experience.Join For Free
GitOps in short is a set of practices to use Git pull requests to manage infrastructure and application configurations. In this paradigm, git repositories are the source of truth.
There are a lot of tools to implements a strategy GitOps strategy in an Openshift environment. We can talk about ArgoCD, FluxCD, Tekton, etc. In this article, I want to show how OpenShift Applier is a great allied in a GitOps strategy fo OpenShift.
The OpenShift-Applier is an Ansible role, that uses your local OpenShift command-line tools (oc) to process and apply templates into OpenShift.
As it is an Ansible process, we need a tool that can monitor the Git repository and, from a push, start the execution of OpenShift Applier. We can use a Jenkins CI or GitLab CI or Ansible to do it.
Let's start. The first step is to create an Ansible structure. You can use my demo as reference: openshift-applier-demo
The structure of the project is:
Notice the folder called templates. In this folder, I saved the templates to being applied on Openshift. I can create a project or edit or deploy new applications on existing projects. In my example, there are two templates: fis-test.yml that is a fuse application demo and projectrequest-template.yml that is a template for creating a new project on OpenShift. The magic is here; The Openshift Applier will use the content of these templates to process and apply resources on Openshift. We can have one or many templates in this folder.
After defining our templates, very probably, it is waiting for some parameters. All values of parameters are store in a file called "build" in the params folder. Notice that I used the same folder structure as the folder template.
After defining templates and params, we need to associate the templates files with the build files; for this, we use the file all.yml located in the folder inventory/group_vars.
Notice that in the file all.yml, there are objects defined, and each one makes reference to one template and his "build" file. In this way, the Openshift Applier applies the parameter values in the template and processes it and applies its values.
Last but not least, we have the file apply.yml at the root of the project. This file is an Ansible playbook that starts all processes. We can add new tasks to complete our strategy. In my example, you can notice that I include two tasks: one to access the project and another to execute a rollout in the deployment config fis-test.
To run the Openshift Applier, we need to run the commands below.
Notice that after running this command, a new folder created with the name "roles" in the project.
After running the playbook, notice a new project called fis-rest-demo was created and also an application was created exposing a web service http://<route>/rest/demo/person/1
After that, any change in the application template will apply in the OpenShift, for example:
NOTE: For work with secrets, we can use Ansible-vault to improve security.
To finish our GitOps process, we need to include an engine to observe the git repository to detect pushes on templates files and start the Openshift Applier. There are a lot of options, including the Ansible, Jenkins CI, Git Lab CI. Openshift Applier executes the heavy work, so, this other tool is only a trigger to start a process and perform small tasks like login on OpenShift, define variables, etc.
Below I show a groovy script to use on Jenkins CI. The job of Jenkins, in this case, it's just an adjunct, that set a webhook with GitHub, clone the repository, and execute the playbook.
Openshift applier is very practical, worth having in your toolbox. With Openshift-Applier and git, we can say that we have the basics of the GitOps concept. I recommend a test drive. It is free, It's easy.
Opinions expressed by DZone contributors are their own.