CloudOps for Kubernetes Extensions Framework
Introduction
The Extensions framework empowers users to add custom jobs into Jenkins without directly modifying the CloudOps for Kubernetes Git source code repository. With this framework, you can define custom Jenkins jobs in external Git repositories and import it into Jenkins.
Note: The Jenkins jobs in the CloudOps for Kubernetes repository that implement the CloudOps for Kubernetes Extensions framework are supported by Elastic Path. However, any jobs imported into Jenkins from an Extensions repository are not supported by Elastic Path. If and when you choose to use jobs provided in any Extensions repository, then your organization is responsible to support, verify and troubleshoot those jobs without assistance from Elastic Path for as long as you continue to use them.
What is an Extensions repository?
An Extensions repository is a separate Git repository that contains files to implement custom Jenkins jobs, and the files used to import those jobs into Jenkins. The Extensions framework stores the information necessary to load the new jobs into Jenkins so that they can be reloaded or refreshed in the future. The Jenkins jobs in an Extensions repository follow a specific format to properly operate within the Extensions framework. For information on the Extensions repository layout, see here.
Why would you want to use an Extensions repository instead of other ways of customizing CloudOps for Kubernetes?
It is very common to add new Jenkins jobs or override Jenkins jobs provided in CloudOps for Kubernetes. Use an Extensions repository for custom Jenkins jobs to meet your custom requirements without directly modifying the CloudOps for Kubernetes Git repository. The Extensions framework has several benefits, such as:
- It avoids the need to modify the CloudOps for Kubernetes cloud-ops-kubernetes Git repository, which can simplify the work required to apply future CloudOps for Kubernetes upgrades and patches.
- It allows you to implement and configure your Jenkins jobs as code, ensuring that they are saved and changes are tracked in a Git repository that you control completely.
- It ensures that your Jenkins jobs will not be lost or disappear from the CloudOps for Kubernetes Jenkins instance when the Jenkins helm chart gets updated.
If you create custom Jenkins jobs through the Jenkins user interface, and not through an Extensions repository, they would not be tracked in a persistent state. If your jobs are not tracked in a persistent state, then the jobs will have to be created each time that Jenkins is restarted, or the bootstrap Jenkins job is ran. This can become a tedious problem for an operations team, especially if a custom job is scheduled to be ran, but the job has been deleted or overwritten because Jenkins has restarted. With an imported Extensions repository, the state of Jenkins does not impact the jobs that are displayed from the Jenkins repository. The state of the imported Extensions repository is tracked outside of Jenkins in a persistent resource within the Kubernetes cluster.
Use Cases
The following sections describe some of the use cases for the Extensions framework: Some of the use cases can include:
Storing custom configuration of a CloudOps for Kubernetes job
Using some of the built in groovy libraries in CloudOps for Kubernetes, it is possible to create a new Jenkins job using the Extensions framework that can wrap around the functionality of an existing CloudOps for Kubernetes Jenkins job.
For example, if you want to use a static list of IP addresses for the ingresses that are created by the deploy-or-delete-commerce-stack Jenkins job, you can create an Extensions repository that contains a Jenkins job that will remotely trigger the deploy-or-delete-commerce-stack Jenkins job with hard-coded allow list ranges for the different Self Managed Commerce services. You can even create three different Jenkins jobs in your Extensions repository for three different Self Managed Commerce environments that you want to deploy. Each Self Managed Commerce environment has its own dedicated Jenkins job with their unique allow list ranges that will be persistently tracked in Git through your Extensions repository.
With this method, it is not necessary to save your allow list values in the deploy-or-delete-commerce-stack Jenkins job. This would prevent the loss of your changes in Jenkins, if Jenkins restart, or the bootstrap Jenkins job ran, and the saved values in the job configuration were overwritten with CloudOps for Kubernetes values.
Overriding existing CloudOps for Kubernetes jobs
If a provided Jenkins job does not cover your required use case, then you can copy and modify it as needed. For example, if your organization’s Self Managed Commerce project requires additional testing that is not covered in the jobs provided by CloudOps for Kubernetes, you can copy the files that implement the provided testing jobs into your Extensions repository and then make the changes necessary to meet your custom requirements.
You can name the job differently if you want to keep the functionality of the CloudOps for Kubernetes job separate. You can also keep the same name as the job if you do not want the job to be available. Overwriting the CloudOps for Kubernetes Jenkins jobs is particularly useful if you are using a Continuous Integration (CI) pipeline that is provided by CloudOps for Kubernetes, but ensure to add functionality that is not currently covered.
Writing new CI pipelines
This use case is applicable when you want to take a series of actions that are not currently covered by the CI pipelines provided in CloudOps for Kubernetes. You may notify your organization through an email if a CI pipeline has failed. The CI pipelines in CloudOps for Kubernetes do not currently implement this action, but you can write new Jenkins jobs that could include this functionality as well as new CI pipelines that make use of the new Jenkins jobs in your Extensions repository.
Deploying custom infrastructure
With the framework, you can write new Jenkins jobs that create new infrastructure that is not created by CloudOps for Kubernetes infrastructure.
For example, your organization might find the functionality of a different artifact repository to be necessary for their Self Managed Commerce operations. A new Jenkins job in your Extensions repository could create that infrastructure in a number of different ways. You could create that infrastructure through a shell script, by writing custom Terraform code, make use of a CloudFormation template, etc.