- SAP Managed Tags:
The goal for this blog post is to show how we can implement DevOps engineering practices like Configuration as Code, Continuous Integration or Continuous Delivery into cloud-native integrations with SAP S/4HANA using microservices running in enterprise Kubernetes platforms like OpenShift.
We are going to use 2 different microservices for this purpose:
The code for the sample backend microservice can be found here, and the code for the frontend microservice can be found here. Using these we will cover the following use cases:
Detailed instructions on how to configure and test this on your own can be found in the following repository. This post will cover the key aspects of the process so the reader can gain a high-level understanding of the moving pieces.
As previously mentioned, there are two different tools we are going to use: Argo CD and Tekton. Both are supported in OpenShift 4.7 as Technology Preview and planned to be General Available supported in OpenShift 4.8 coming out during Q2 2021. Both can be automatically deployed as Operators in OpenShift, which means the installation and operation of the tooling are automatically done by the platform.
Since Argo CD will give you the option to sync your configuration with multiple OpenShift clusters, once deployed, we can start defining the strategy to build and deploy the microservices on the different environments in our cluster or multiple clusters.
To do so, we need first to create an Application in Argo CD. We can do this by creating the corresponding k8s object (kind: Application) using the command line or the Argo CD web interface. Out from the application name, we need to specify the cluster(s) where we want to deploy our configuration and the git source we are going to use for this. As an example, this is how the objects required to build and deploy the backend microservice in DEV looks like on this example:
If we want to review more details about the objects that have been created in OpenShift and any pending synchronization between the source repository and the objects in Openshift, we can select any of the applications which will give us more detailed information.
The Argo CD Applications will contain not only all the objects required to build and deploy each microservice on each environment, but also the pipelines specifications using Tekton objects that will define how each microservice is built and tested from source, and deployed in OpenShift.
All this configuration is stored as code in Git, as we can see in this example of how the Pipeline for our DEV environment would look like. Tekton brings simplicity and uniformity when running pipelines in multiple environments by providing a high reusable, declarative and component-based cloud-native build system.
Once Argo CD has synced the Tekton objects we have created in Git to define our Pipelines, we will be able to see these in OpenShift. As an example, the following pipeline will build and test the frontend microservice; it will create a container image from the source artefacts, push the container image to the OpenShift container registry and deploy the new container image in the corresponding namespace. This will be done on every single commit to the corresponding branch in GitHub for the repository containing the source of our application.
Going forward, application developers and platform operators can easily make changes on the repository containing the Kubernetes objects that define how the application is built and deployed. In addition, these changes will automatically synchronize with any OpenShift cluster we have defined in Argo CD for each application.
Conclusion
Using DevOps engineering practices like Configuration as Code or CI/CD will not only simplify and increase the reliability of your cloud-native applications but will also increase the understanding between your developers and operations teams around your application lifecycle, dependencies and moving parts.
Argo CD and Tekton are very powerful tools to implement GitOps and CI/CD in your organization and combining with OpenShift will level up your developers and operations teams to new ways of managing your infrastructure and applications in your organization.
We are going to use 2 different microservices for this purpose:
- A backend microservice that integrates with SAP S/4HANA via SAP JCo and OData using Camel routes and exposing REST APIs.
- A frontend microservice that uses the REST APIs from the backend microservice to present and manage data from SAP HANA.
The code for the sample backend microservice can be found here, and the code for the frontend microservice can be found here. Using these we will cover the following use cases:
- Automatically manage all the Kubernetes objects in multiple environments (DEV, QA, PROD…) from Configuration as Code stored in a git repository. To do so we are going to use Argo CD, a declarative, GitOps continuous delivery tool for Kubernetes.
- Automatically build, test and deploy the backend and frontend microservices on every new change committed to the repository containing the source code of the mentioned microservices. To do so we are going to use Tekton, a powerful and flexible open-source framework for creating CI/CD systems.
Detailed instructions on how to configure and test this on your own can be found in the following repository. This post will cover the key aspects of the process so the reader can gain a high-level understanding of the moving pieces.
As previously mentioned, there are two different tools we are going to use: Argo CD and Tekton. Both are supported in OpenShift 4.7 as Technology Preview and planned to be General Available supported in OpenShift 4.8 coming out during Q2 2021. Both can be automatically deployed as Operators in OpenShift, which means the installation and operation of the tooling are automatically done by the platform.
Since Argo CD will give you the option to sync your configuration with multiple OpenShift clusters, once deployed, we can start defining the strategy to build and deploy the microservices on the different environments in our cluster or multiple clusters.
To do so, we need first to create an Application in Argo CD. We can do this by creating the corresponding k8s object (kind: Application) using the command line or the Argo CD web interface. Out from the application name, we need to specify the cluster(s) where we want to deploy our configuration and the git source we are going to use for this. As an example, this is how the objects required to build and deploy the backend microservice in DEV looks like on this example:
If we want to review more details about the objects that have been created in OpenShift and any pending synchronization between the source repository and the objects in Openshift, we can select any of the applications which will give us more detailed information.
The Argo CD Applications will contain not only all the objects required to build and deploy each microservice on each environment, but also the pipelines specifications using Tekton objects that will define how each microservice is built and tested from source, and deployed in OpenShift.
All this configuration is stored as code in Git, as we can see in this example of how the Pipeline for our DEV environment would look like. Tekton brings simplicity and uniformity when running pipelines in multiple environments by providing a high reusable, declarative and component-based cloud-native build system.
Once Argo CD has synced the Tekton objects we have created in Git to define our Pipelines, we will be able to see these in OpenShift. As an example, the following pipeline will build and test the frontend microservice; it will create a container image from the source artefacts, push the container image to the OpenShift container registry and deploy the new container image in the corresponding namespace. This will be done on every single commit to the corresponding branch in GitHub for the repository containing the source of our application.
Going forward, application developers and platform operators can easily make changes on the repository containing the Kubernetes objects that define how the application is built and deployed. In addition, these changes will automatically synchronize with any OpenShift cluster we have defined in Argo CD for each application.
Conclusion
Using DevOps engineering practices like Configuration as Code or CI/CD will not only simplify and increase the reliability of your cloud-native applications but will also increase the understanding between your developers and operations teams around your application lifecycle, dependencies and moving parts.
Argo CD and Tekton are very powerful tools to implement GitOps and CI/CD in your organization and combining with OpenShift will level up your developers and operations teams to new ways of managing your infrastructure and applications in your organization.
