So far in this module, we have been covering the principles that govern CI/CD. In this video, we will begin putting these principles into practice by understanding how to building a CI/CD pipeline. We have covered several options for implementing a CI/CD pipeline, for this course we will look at using Tekton to implement a CI/CD pipeline. Tekton is an Open Source project. It provides a flexible framework for defining and executing CI/CD pipelines. Tekton is built off the Kubernetes API, And tekton can be executed in a Kubernetes cluster. Using tekton will allow skills needed to define and run workloads in a Kubernetes cluster to be reused in the defining and running of CI/CD pipelines, and vice-versa. Tekton also allows for increased centralization in source of truth, but allowing for the running and building of workloads to be co-located. Let’s take a look at some of the central concepts in Tekton There are seven central resources that make up most Tekton pipelines There are: Event Listeners, which as the name suggest, listen for events to trigger a pipeline Trigger Bindings which interpret event messages Trigger Templates, used for creating resources Pipeline Run, which instantiates a pipeline Pipeline which define task to be executed Tasks which perform the work of a pipeline And Service Account which gives identity and access for the pipeline Let’s take a closer look at each of these types of resources. An Tekton Event Listener setups an HTTP endpoint for receiving JSON messages. An Event Listener receiving a message is what will typically kick off a tekton pipeline and examples of such events would be A git push event, where a git repo sends a message to an event listener when a developer checks in some changes A pipeline completing, which might kick off a subsequent pipeline. We will discuss typical CI/CD workflows in more detail later in the video. When an event listener receivers a message, it needs to know how to interpret it. That is the job of a Trigger Binding. A trigger Binding will read the JSON message and pass the defined parameters to Tekton resources in the pipeline. Tekton pipelines often depend upon resources for completing their work; volumes to use as workspaces as artifacts are built and reports produced, secrets for connecting to services, a pipeline run for defining how the pipeline should be executed, among other resources. Trigger Templates can be used to define how the resources should be created in preparation for a pipeline rune The Pipeline Run resource is for instantiating a specific pipeline instance. A pipeline run defines the specific pipeline to be executed, and passes in parameters to that pipeline that define how it should be run. If you are a developer, a pipeline is analogous to a class, and a pipeline run is a specific instance of that class. A pipeline is defined as a group of tasks to be executed towards accomplishing specific goal. An example of pipeline could be a pipeline that has task that, clone, builds, tests, and packages an application. In computer science terms, a pipeline would be roughly analogous to a package or module. A task is a set of steps that accomplish a specific task within a pipeline. A task is where the actual work of a tekton pipeline takes place. In computer science terms a task is roughly equivalent to a class, all the steps within a task should be highly cohesive. In the example task, all the steps within the task relate to cloning a git repository. Steps that build the source code in the cloned repository should be located in a separate task so as to increase reusability. Tekton needs an identity to create and access resources, execute pipelines and tasks, and clean up after it is done. For this, a standard Kubernetes Service Account is needed. As mentioned, tekton is built on top of, and runs in Kubernetes. Like other resource running within a Kubernetes cluster, they will be defined in YAML using Kubernetes API. The above is an example of defining a tekton task. This tekton task is building a java artifact which can be seen under the steps. Tekton tasks, reference container images in their steps. Which, gives tekton a great deal of flexibility when using it to create CI/CD pipelines, as anything that can run in a docker container can be part of a tekton pipeline. At a high level a CI/CD pipeline would actually be a collection of smaller pipelines, each completing a specific task, but working together. Starting with a git push this would cause the repository to send a message to the build image pipeline event listener. The Build Image pipeline would, complete tasks associated with building a new docker image; clone the git repo, building the code, running tests, on successful completion it would send a message to the deploy to stage pipeline. The deploy to stage would pull down the newly created docker image, update the stage environment, and deploy the image. Likely at this point, this would start of automated tests that can only be done on a deployed application. On the successful completion of the deploy stage pipeline, the deploy stage pipeline would send a message to a deploy that will deploy the docker image to the production environment IBM Cloud has an integrated DevOps platform which can be used for configuring and running pipelines and integrating with other DevOps services, like security scanning, analytics, and workplace messaging like slack. In the next video, we will see a demo of using the DevOps feature on IBM Cloud to run and manage a tekton pipeline. You should now be familiar with: Benefits of container orchestrators, Overview of Kubernetes, Additional features OpenShift builds on top of Kubernetes
