Today’s blog post is about the awesome IBM Garage
Cloud Native Toolkit to support continuous integration and continuous delivery (CICD).
I want to provide a basic overview from my perspective, which I structured in following sections:
- Basic Overview
- Try it out
- Open-Source Tools/Technologies
- What are the major tasks inside a OOTB Tekton pipeline?
I love to see how tools can support different kinds of software development processes fully or partly, especially in today’s agile world. With my background of using Rational Tools for a long time, I always like to see, how is it possible to make life easier for the different roles in the Software Development Lifecycle. Continuous integration and continuous delivery are two big important parts of an effective implementation of a Software Development Lifecycle in a company to speed up the development and innovation. So, the IBM Garage
Cloud Native Toolkit exactly does address these two critical important topics. The toolkit does address it with a concrete initial configuration.
The Cloud Native Toolkit utilizes the Tekton Operator to create an awesome starting point with a preconfiguration for continuous integration and continuous delivery in your Red Hat OpenShift cluster using Open-Source tools.
Try it out¶
I wanted to try out the Cloud Native Toolkit with an own simple project and I used one of my very basic Node.js server implementations in my private GitHub repository. My objective was only to try out the basic
Out-Of-The-Box configuration. I followed the given guides in the getting started documentation of the Cloud Native Toolkit for setup the toolkit and then I used it.
The documentation worked fine for me for the entire setup and the usage for my example application.
The Cloud Native Toolkit highlights in an impressive way, how Open-Source technologies/tools can be used together to support continuous integration and continuous delivery for containerized applications in Red Hat OpenShift. So, I want to give you a basic overview of the used Open-Source tools/technologies in the
Out-Of-The-Box default configuration for a Tekton pipeline, provided by the Cloud Native Toolkit.
These are the used Open-Source tools/technologies in the pipeline with a very short explanation what they do address in context of the Cloud Native Toolkit:
|Open-Source Technology/Tool||Addresses following topic|
|Tekton||Continuous integration is realized with Tekton. The following image shows some of the predefined tasks in the Tekton pipeline and how pipeline appear in Red Hat OpenShift.|
|Tekton Operator||The IBM Garage team is using the Tekton Operator provided by Red Hat to setup the Cloud Native Toolkit inside Red Hat OpenShift.|
|ArgoCD||Continuous delivery is implemented with ArgoCD, related to GitOps.|
|SonarQube||White box testing/scanning is realized with SonarQube. Thats related to the implementation of the scanning for the well known top 10 security risks identified by the OWASP project, which is well known in the application security area. |
|Artifactory||Saving binary assets like tgz files containing the Helm chart configurations within Artifactory. |
|Helm charts||Defining the deployment of the containerized applications with Helm charts. “Helm is the best way to find, share, and use software built for Kubernetes.”|
|Mocha and supertest||In the Tekton Task Test, I used for my unit tests of my Node.js server Mocha in combination with Supertest. |
What are the major tasks inside a OOTB Tekton pipeline?¶
The IBM Garage team did a lot of bash programming and yaml preconfigration for the Tekton tasks and steps to reflect for example different quality gates you can customize to stop the execution of your pipeline. For sure it also includes a lot of experience of a huge number of different customers projects.
The image contains a brief inside of a task implementation.
In the image you see a screen shot of the default configuration for a pipeline.
Here is a short and very simplified overview of the preconfigured Tekton pipeline tasks, which are defined for the
Out-Of-The-Box configuration I used.
|Test||Executing unit tests and security scanning for the application.|
|Build||Building a container image based on the Dockerfile|
|Deploy||Deploying the application using a |
|Tag-release||Doing an automated tagging of your deployed releases in your GitHub project.|
|Img-release||Tag the container image in your container registry.|
|Img-scan||Security scan of the container using container registry capabilities.|
|Helm-release||Helm chart for this deployment will be saved in a repository.|
|Gitops||Using the Helm chart to deploy container into other projects with ArgoCD. |
These projects can reflect for example deferent environments like
The IBM Cloud Garage team invested for us time and shares their experience with us, to provide us a great professional starting point with preconfigurations and guided setups containing different Open-Source tools/projects to get started with a setup and using continuous integration and continuous delivery in a professional way. The Cloud Native Toolkit also provides various templates for different technologies.
Ok, we have to dig in a lot of different areas on tooling and methods, but setting up continuous integration and continuous delivery isn’t easy and that’s only the tooling and not the topic: “How to integrate this in your development life cycle process?” To understand Cloud Native Toolkit in a broader context, it makes sense to take a look into the IBM Garage Method to get more insides, what are their best practices.
Surely that’s not a one size fits all solution and must be configured to your needs. But the Cloud Native Toolkit can reduce your effort with the implementation of the tooling for continuous integration and continuous delivery, if it’s not already in place.
I hope this was useful for you and let’s see what’s next?
#cicd, #gitops, #argocd, #sonarqube, #tekton, #OpenShift, #cloudnativetookit, #helmchart, #Artifactory, #IBMGarage