Automatically subscribe to Red Hat Enterprise Linux (RHEL) VMs with OpenShift Pipelines
Do you want your Red Hat Enterprise Linux (RHEL) VMs running on OpenShift Virtualization to be automatically subscribed to the most recent updates? This post will teach you how to use OpenShift Pipelines to accomplish that.
A cloud-native CI/CD system called OpenShift Pipelines enables users to quickly construct bespoke pipelines using pre-built building components. These constituent parts are also known as tasks. See Understanding OpenShift Pipelines for additional details on OpenShift pipelines.
New jobs for OpenShift Pipelines are released in a TechPreview as part of OpenShift Virtualization in OpenShift 4.11. These tasks are intended to assist with building and personalizing VMs and VM templates.
The boot sources of numerous operating systems, including RHEL 8 and RHEL 9, are automatically supplied with OpenShift Virtualization 4.10 installed. The earlier article, Subscribing RHEL VMs in OpenShift Virtualization, demonstrated how manually preparing VM templates can produce VMs that automatically subscribe for scheduled updates. However, keep in mind that you must perform this each time Red Hat delivers an update to the preconfigured templates. This post will demonstrate how to use a straightforward pipeline created using the new tasks to automate the subscription of RHEL VMs.
The installation of OpenShift Pipelines, OpenShiftVirtualization 4.11, and the activation of the ‘deployTektonTaskResources’ feature gate in the newly generated ‘HyperConverged’ custom resource are prerequisites for this article. A new pipeline with the name rhel-inject-subscription will show up in the pipelines view of the OpenShift UI once you apply the pipeline definition attached to this article to your cluster.
To start the pipeline, click “Start” after selecting the menu option from the menu button to the right of the pipeline. Enter your activation key and organization in the next screen, then click “Start” once more. The Red Hat Customer Portal is where you may get your subscription credentials, as was mentioned in the previous post. If you don’t already have them, ask your organization administrator to provide you with the necessary rights.
The PipelineRun view will open once the pipeline has been started, allowing you to monitor the progress of the pipeline’s execution.
According to the previously supplied settings, the pipeline will generate a new VM template and automatically inject the activation key and organization into it. The name and namespace of the newly constructed template will be displayed in the PipelineRun results. The pipeline can be run numerous times to update the credentials-injected template because, by default, templates with the same name will be rewritten.
The tasks copy-template and modify-vm-template are used to generate the new template. The former lets you duplicate already-existing templates, while the latter lets you change the template’s parameters. It is possible, among other things, to change the disks and volumes associated to virtual machines made using templates. The cloud-init configuration of the VM’s cloud-init configuration is updated using this capability.
The definition of the pipeline we just talked about is as follows:
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: rhel-inject-subscription
spec:
params:
- name: activationKey
description: Activation key that is injected into the VM template's cloud-init configuration
type: string
- name: organization
description: Organization that is injected into the VM template's cloud-init configuration
type: string
- name: sourceTemplateName
description: Name of the Template which is used to create the subscribed Template.
type: string
default: rhel9-server-small
- name: sourceTemplateNamespace
description: Namespace of the Template which is used to create the subscribed Template.
type: string
default: openshift
- name: subscribedTemplateName
description: Name of the subscribed RHEL Template which is created.
type: string
default: rhel9-server-small-subscribed
- name: subscribedTemplateDisplayName
description: Display name of the subscribed RHEL Template which is created.
type: string
default: Subscribed Red Hat Enterprise Linux 9.0 VM
- name: allowReplaceSubscribedTemplate
description: Allow to replace an already existing subscribed Template.
type: string
default: "true"
tasks:
- name: copy-template
params:
- name: sourceTemplateName
value: $(params.sourceTemplateName)
- name: sourceTemplateNamespace
value: $(params.sourceTemplateNamespace)
- name: targetTemplateName
value: $(params.subscribedTemplateName)
- name: allowReplace
value: $(params.allowReplaceSubscribedTemplate)
timeout: 10m
taskRef:
kind: ClusterTask
name: copy-template
- name: modify-vm-template
params:
- name: templateName
value: $(tasks.copy-template.results.name)
- name: templateAnnotations
value:
- "openshift.io/display-name: $(params.subscribedTemplateDisplayName)"
- "template.kubevirt.io/provider: my friendly cluster-admin"
- "template.kubevirt.io/provider-support-level: Full"
- "template.kubevirt.io/provider-url: https://www.my.corp"
- name: volumes
value:
- |
{
"cloudInitNoCloud": {
"userData": "#cloud-config\nuser: cloud-user\npassword: ${CLOUD_USER_PASSWORD}\nchpasswd: { expire: False }\nrh_subscription:\n activation-key: $(params.activationKey)\n org: $(params.organization)"
},
"name": "cloudinitdisk"
}
runAfter:
- copy-template
timeout: 10m
taskRef:
kind: ClusterTask
name: modify-vm-template
results:
- name: subscribedTemplateName
description: Name of the created subscribed Template
value: $(tasks.copy-template.results.name)
- name: subscribedTemplateNamespace
description: Namespace of the created subscribed Template
value: $(tasks.copy-template.results.namespace)
It’s now time to use our template to build a new, subscribed VM. Simply switch to the VirtualMachines pane, select “Create new VirtualMachine,” and our freshly constructed template with the subscription information included appears. Similar to the last post, this makes it very simple to create a new VM that is already subscribed, but be aware that any cluster user that has access to the template will see the subscription credentials.
Similar to the last post, this makes it very simple to create a new VM that is already subscribed, but be aware that any cluster user that has access to the template will see the subscription credentials.
When a change in one of the predefined templates needs to be propagated to the credentials-injected template, the pipeline still needs to be manually initiated, for the sake of simplicity in this piece (s). However, the suggested pipeline only changes the template; it leaves the default boot sources alone. In this method, Red Hat Enterprise Linux minor updates and other automated updates to the boot sources are automatically implemented without the need to restart the pipeline.
This pipeline only modifies one template per run, but with the flexibility of OpenShift Pipelines, it is possible to automate this even further and to create a pipeline that automatically creates subscribed templates for every RHEL version and flavor available. For an example of how that can be done see here.
