The goal is that you will build and deploy the modernized customer application to OpenShift using OpenShift Pipelines and GitOps.
-
Use the Tekton Pipeline to build and deploy the new, modernized application using Red Hat JBoss Web Server instead of Apache Tomcat as the runtime.
-
Set up the configuration for the customers service to connect to the Oracle database VM which is now running on OpenShift Container Platform
-
Test the customers service
-
Update the configuration for the gateway service to now point to the modernized customers service.
-
Demonstrate that your frontend service still works as before.
Helm is a package and install manager that standardizes and simplifies packaging and deployment of containerized applications with Kubernetes, anywhere in the hybrid cloud. Helm lets developers package their applications so that they can be easily shared and deployed by anyone in their organization and beyond.
Helm can also be used to automate day-1 tasks like installation and basic configuration management for setting up the applications, and some day-2 operations like performing some simple upgrades and rollbacks.
The customers application in the OpenShift cluster has currently a connection failure because the application still tries to connect to the Oracle database running on RHV. To fix the issue, you need to update the JDBC configuration that points to the migrated Oracle database on OpenShift virtualization.
|
Important
|
To save your time to go through the hands-on labs today, our SRE team has already migrated the VM running Oracle database to the OpenShift virtualization in the retail-userXX project. |
The JDBC configuration is currently managed by the helm chart to automate day 1 & 2 operations for the modernized Globex retail system. Let’s go back to the VS Code server and open the persistence.properties file in customer-tomcat-gitops/helm/secret directory.
Update the jdbc.url value to the Oracle virtual machine’s name (oracle-database) on OpenShift. It should look like this:
jdbc.url=jdbc:oracle:thin:@oracle-database:1521/xepdb1|
Note
|
Where is the |
Switch to the Source Control menu in VSCode. Click on + button to add the changes (persistence.properties).
Type Update jdbc.url in the comment. Then, commit it(e.g. Command + Enter on macOS) and click on Sync Changes.
Access your Gitea repository (e.g. https://gitea.apps.cluster-l6kxh.sandbox541.opentlc.com) in the shared environment detail page with the following credentials:
-
Gitea admin username:
userXX -
Gitea admin password:
openshift
Once you logged in to the Gitea admin console, you will see the latest commit (e.g. 08fb9fb6f4 Update jdbc.url).
OpenShift Pipelines provides a kubernetes-native CI/CD framework based on Tekton to design and run your pipelines, and is designed to run each step of the CI/CD pipeline in its own container, allowing each step to scale independently to meet the demands of the pipeline.
By extending Kubernetes/OpenShift with Custom Resource Definitions (CRDs), OpenShift Pipelines makes CI/CD concepts such as pipeline, task, and step natively in terms of increasing the scalability, security, ease of deployment capabilities of Kubernetes.
Each of these tasks can be described as follows:
-
Clone Repository downloads the source code from the target Git repository.
-
Build from Source builds the application artifact from source code. This task has been tweaked to allow selecting the target subdirectory from the repository in which the target application source is available, allowing to have several application/components available in a single repository. This way of versioning different services/components is highly discouraged, as the optimal approach would be to have a dedicated repository for each component since their lifecycle should be independent. Nevertheless, this choice was made to gather all demo materials on a single repository for simplicity purposes.
-
Build Image uses the Dockerfile packaged on the root directory of an application to build an image and push it to the target registry. The image will be tagged with the short commit hash of the source it contains.
-
Update Manifest uses the short commit hash tag to update the application manifest in Git and point to the newly built image. Application deployment is then delegated to ArgoCD, which is continuously polling the configuration repository for changes and creates/updates all OpenShift objects accordingly.
The pipeline accepts the following parameters:
-
git-url: URL of the target Git repository.
-
git-branch: target branch to work with. (default: main)
-
app-subdir: Subdirectory from the repository in which the application source code is stored.
-
target-namespace: Namespace/project in which to deploy the application.
-
target-registry: Registry to push the built image to. (default: image-registry.openshift-image-registry.svc:5000)
In the future we will have a trigger and event listener on the pipeline. But for now you have to kick off the pipeline run manually.
First, open a new browser to access the OpenShift web console that is provided from the shared environment detail page.
Login using your credentials:
Username: userXX
Password: openshift
Then, switch project to cicd-userXX in Developer perspective.
Click on Pipelines on the left menu. You will see pre-defined customers-deployment-pipeline pipeline. Click on the pipeline.
Click on Start in Actions dropbox to run the pipeline.
A PipelineRun is how you can start a pipeline and tie it to the Git and image resources that should be used for this specific invocation.
This dialog box is where you bind the final target values for the source repo of the build-artifact step, and the target namespace to deploy in the update-manifest-and-push step. Input the parameter and select resources as below then Click on Start:
-
git-url:
https://YOUR_GITEA_URL -
git-branch:
main -
app-subdir:
customers-tomcat-gitops -
target-namespace:
retail-userXX -
target-registry:
image-registry.openshift-image-registry.svc:5000 -
ws:
customers-pvcin PersistentVolumeClaim
As soon as you started the customers-deployment-pipeline pipeline, a pipelinerun is instantiated and pods are created to execute the tasks that are defined in the pipeline. After a few minutes, the pipeline should finish successfully. You can hover over the steps to get a quick snapshot of the step’s progress, or click on the steps to see detailed logs of the steps.
Globex retail system has deployed multiple microservices to the OpenShift cluster as well as each microservices has complex relations with the other microservices and databases. This architecture might not be understandable quickly and easily for developers and SREs. Luckily, OpenShift developer console provides a decent topology view with adding labels and annotations. It makes the topology view more clear and explicit relations among deployed applications in the same namespace.
Add following labels and annotations to show which languages, frameworks, and runtimes are used for each application by running the following oc commands in terminal on the VS Code server where you logged in to the OpenShift cluster.
Run the following command in the VS Code server terminal. Be sure to replace userXX with your username.
oc project retail-userXX && \
oc label deployment/inventory app.kubernetes.io/part-of=inventory app.openshift.io/runtime=quarkus --overwrite && \
oc label deployment/postgresql-inventory app.kubernetes.io/part-of=inventory app.openshift.io/runtime=postgresql --overwrite && \
oc annotate deployment/inventory app.openshift.io/connects-to=postgresql-inventory --overwrite && \
oc label deployment/orders app.kubernetes.io/part-of=orders app.openshift.io/runtime=spring --overwrite && \
oc label deployment/postgresql-orders app.kubernetes.io/part-of=orders app.openshift.io/runtime=postgresql --overwrite && \
oc annotate deployment/orders app.openshift.io/connects-to=postgresql-orders --overwrite && \
oc label deployment/customers app.kubernetes.io/part-of=customers app.openshift.io/runtime=tomcat --overwrite && \
oc label deployment/ordersfrontend app.kubernetes.io/part-of=ordersfrontend app.openshift.io/runtime=nodejs --overwrite && \
oc annotate deployment/ordersfrontend app.openshift.io/connects-to=gateway --overwrite && \
oc label deployment/gateway app.kubernetes.io/part-of=gateway app.openshift.io/runtime=spring --overwrite && \
oc annotate deployment/gateway app.openshift.io/connects-to=inventory,orders,customers --overwrite|
Note
|
You might have no connection between |
Go back to the Topology View of retail-userXX project in Developer perspective, the applications deployment should look like:
Now we need to update the gateway application’s configuration to connect to the customers based on Kubernetes service name rather than the IP address.
GitOps in short is a set of practices to use Git pull requests to manage infrastructure and application configurations. Git repository in GitOps is considered the only source of truth and contains the entire state of the system so that the trail of changes to the system state are visible and auditable.
Traceability of changes in GitOps is no novelty in itself as this approach is almost universally employed for the application source code. However GitOps advocates applying the same principles (reviews, pull requests, tagging, etc) to infrastructure and application configuration so that teams can benefit from the same assurance as they do for the application source code.
Although there is no precise definition or agreed upon set of rules, the following principles are an approximation of what constitutes a GitOps practice:
-
Declarative description of the system is stored in Git (configs, monitoring, etc) *Changes to the state are made via pull requests *Git push reconciled with the state of the running system with the state in the Git repository
Go back to the VS Code server and open the application.yaml file in gatway/helm/config directory. Replace customers' URL with the following URL.
|
Note
|
You must update the application.yaml file in the |
http://customers:8080/customers-tomcat-0.0.1-SNAPSHOT/customers
Switch to the Source Control menu in VSCode. Click on + button to add the changes (application.yaml).
Type Update customers url in the comment. Then, commit it(e.g. Command + Enter on macOS) and click on Sync Changes.
Access the ArgoCD admin console by clicking on Open URL over the argocd-server pod.
Then you will see the ArgoCD login page.
Click on LOG VIA OPENSHIFT button.
Then, enter your OpenShift login credentials.
-
Username:
userXX -
Password:
openshift
you will see all applications such as frontend, gateway, inventory, orders, and customers. Click on gateway application.
When the code change (e.g. application.yaml) completes in Gitea server, ArgoCD starts syncing the gateway application. It usually takes less than 3 minutes to complete the sync. You can also click on REFRESH manually to sync the change instantly.
Go to the OpenShift admin console to confirm if the gateway-config is updated based on the code change.
Let’s go back to the Customers in the GLOBEX web page. You can find the frontend URL by running the following oc command in terminal on the VS Code server.
oc get route ordersfrontendThe output should look like:
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
ordersfrontend ordersfrontend-retail-user1.apps.cluster-mkddz.sandbox1883.opentlc.com ordersfrontend web edge/Redirect NoneOpen a new web browser to paste the above URL. Then, you can see the same customers data as you had in the VM.
|
Note
|
You might see |
⬅️ 5. Rehost