5 stages of provisioning DevOps using Helm on OpenShift, from zero to hero
Here in this blog, we are going to learn about the 5 stages of provisioning DevOps using Helm on OpenShift, from zero to hero. Let’s look at how to set up a complete DevOps environment using Cloud Native Pipeline, best practices, and the Helm package manager for Kubernetes. The plan is to follow just 5 easy steps to set up our DevOps environment with Helm commands. After that, we’ll demonstrate how to implement this solution with a working application using a successful git branching paradigm, also known as git-flow.
This remedy will provide:
- Four namespaces: development, staging, and production (app environments), each with one to find (infra tools).
- Each git commit uses OpenShift Pipelines (Tekton) to produce the app image.
- Delivering the application in an OpenShift cluster using OpenShift GitOps (ArgoCD)
- Gitea git server (gitea/DevOps as user/password)
- Sonatype Nexus (login: admin; password: admin123)
- SonarQube (login: admin; password: admin)
- You must modify this solution to fit your needs because it isn’t suitable for all use circumstances. The essay does not cover topics like tag or versioning strategy, adding programs with separate workspaces, hiding secrets, etc.
Prerequisites:
- Admin for user clusters with OpenShift Platform 4.10+
- Pipelines for OpenShift by Tekton
- Gitops OpenShift [ArgoCD]
- Helm client OpenShift client Git client
Steps
We then outline the procedure for setting up the Helm environment for DevOps.
1. Installation of OpenShift GITOPs
Starting now, OpenShift GitOps ArgoCD will be installed in the cicd namespace. Use the scripts below to add the redhat-cop helm charts repository.
# add the redhat-cop repository helm repo add redhat-cop https://redhat-cop.github.io/helm-charts # having added redhat-cop helm repository helm upgrade --install argocd redhat-cop/gitops-operator --set namespaces[0]=cicd --create-namespace --namespace cicd
Verify that OpenShift GitOps Operator was installed properly.
2. INSTALLING SONARQUBE
Install SonarQube by running the command below.
helm upgrade --install sonar redhat-cop/sonarqube -n cicd
Verify that SonarQube is traversing the Ready column, where the value ought to be 1/1.
Sonarqube’s password should be changed from admin/admin to admin/admin123.
Sonar should be adjusted for unauthenticated access. As seen in the figure below, uncheck the box under Administration / Security / Force user authentication.
3. INSTALLING NEXUS
For the Nexus Sonatype to be installed, run the command below.
helm upgrade --install nexus redhat-cop/sonatype-nexus -n cicd
Access the application or the Ready column to see if Nexus is functioning properly. Administrator/admin123 is the default user and password.
4. INSTALLING GITEA
To install a gitea server in this phase, we must first define the “cluster” variable with the domain portion of our cluster. In the following phase, this variable will be utilized to build the Gitea server route.
As an illustration, the “cluster” variable in my cluster was defined as follows: https://console-openshift-console.apps.cluster-mqh7n.mqh7n.sandbox2145.opentlc.com. Considering how crucial this is, change your cluster variable.
Run the command to install the Gitea server once more.
cluster=apps.cluster-mqh7n.mqh7n.sandbox2145.opentlc.com helm upgrade --install --repo=https://redhat-cop.github.io/helm-charts gitea gitea --set db.password=openshift --set hostname=gitea-cicd.$cluster -n cicd
Check to see if Gitea is running after a short delay.
5. INSTALLATION OF OPEN-SHIFT PIPELINE AND OTHER STEPS
To install the OpenShift Pipeline – Tekton, do the following commands.
oc project cicd git clone https://github.com/ricardoaraujo75/devops-ocp-helm.git oc apply -f devops-ocp-helm/templates/operator-pipeline/openshift-pipelines-sub.yaml
Wait for the installation of the OpenShift Pipeline Operator to be completed under Operators / Installed Operators.
The moment has come for all of our DevOps strategies, including building namespaces, pipelines, tasks, triggers, and PVC as well as populating gitea repositories, webhooks, and Argocd apps. The last instructions implement the policy, enabling the pipeline to control the namespaces for resource creation.
helm --set pipeline.gitea.host=gitea-cicd.$cluster --set cluster=$cluster template -f devops-ocp-helm/values.yaml devops-ocp-helm | oc apply -f- oc policy add-role-to-user edit system:serviceaccount:cicd:pipeline -n dev oc policy add-role-to-user edit system:serviceaccount:cicd:pipeline -n sta oc policy add-role-to-user edit system:serviceaccount:cicd:pipeline -n prod
Verify the accurate creation of the Operator Pipeline, namespaces, pipeline object, tasks, triggers, PVC, webhooks, and Argocd app.
Ready!
Congratulations! By following the five steps above and utilizing the helm commands, you have successfully generated a complete DevOps environment for Cloud Native Pipeline on OpenShift. The proposal should now resemble the following image.
Let’s run the pipeline right now to make sure everything is working properly.
Let’s discuss the role of the CI and CD before we begin. The CI/CD article has more details.
Continuous Integration – CI
The following activities are carried out in the Pipeline on each push to the DevOps-ocp-app git repository on the Gitea server:
- The pipeline is started by the webhook set in Gitea;
- The build is carried out when the code has been copied from the Gitea server;
- It is possible to run unit tests while SonarQube analyses the code in parallel for anti-patterns and dependencies. a report is produced;
- The program is released to the Sonatype Nexus artifact repository packed as a WAR;
- Depending on the branch, a container image is produced in the DEV or STA environment, published to the internal OpenShift registry, and tagged with app-eap: latest;
- The image digest produced by the pipeline is used to update the Kubernetes manifests in the Git configuration repository;
- To incorporate the image summary update into the PROD environment, a pull request is issued in the configuration repository. This action is only taken for the STA environment.
Continuous Delivered – CD
When deploying the application to DEV, STA, and PROD environments, Argo CD employs Customize to override environment-specific settings while continuously monitoring settings maintained in the Git repository.
Pipeline execution
The goal is to build a pipeline that will deploy the application to development and staging environments, with manual approval required for production. This pipeline will be made available via a pull request in the GitOps configuration repository.
It includes the essential steps of a continuous integration process for the software.
Construction Pipeline Staging and development environments are both served by a single pipeline. Since we are utilizing git-flow, the branch that initiates the process—for example, the branch develop for development and release for staging—controls which environment will be used for execution. In order to advance, the Promotion of Pull Requests is not done.
The following command copies the app repository from the gitea server, creates a new branch called to develop, and pushes it to the origin, kicking off the pipeline for the development environment according to the defined webhook.
git clone https://gitea-cicd.$cluster/gitea/devops-ocp-app.git cd devops-ocp-app git checkout -b develop # User and password gitea/devops git push -u origin develop
Pipeline Staging All tasks, including the promotion of the Pull Request to move the picture to the production environment, are completed for this environment.
git checkout -b release git push -u origin release
Production Go to Gitea, open the configuration repository (devops-ocp-app-config), select the pull request tab, and approve the pull request produced by the staging pipeline to advance the application to the production environment. In this manner, ArgoCD will deploy in the production environment when carrying out the merge.
An application running on the cluster.
Applications in the ArgoCD
Conclusion
With Cloud Native Pipeline and GitOps, this solution enables you to have a quick and easy DevOps environment. Since there are no techniques involved, it was essential to use examples, write scripts, run tests, and other related tasks. However, once developed, you have a model that is both repeatable and useful. That is how automation works.
Contact me at any time with questions, concerns, or suggestions.
