Managing Red Hat Satellite | Content

Lifecycle Environments | Content Views | Activation Keys

In our previous post, we discussed how to attach Red Hat entitlements, set up initial repositories, sync our content and set up a daily sync plan. This will give you the basics you need for managing Red Hat Satellite Servers, however in most cases we want to expand upon the features that Satellite provides by utilizing lifecycle environments, content views, and activation keys. So, let us get started with Lifecycle Environments.

Lifecycle Environments

So what exactly is a lifecycle environment?

Application life cycles are divided into life cycle environments, which represent each stage of the application life cycle. Life cycle environments are linked to form an environment path. You can promote content along the environment path to the next life cycle environment when required. For example, if development ends on a particular version of an application, you can promote this version to the testing environment and start development on the next version.

Red Hat

We add a lifecycle to our environment by going to Content > Lifecycle Environments.

Creating the lifecycle environment

On a new Satellite server, you will only see Library in your Lifecycle path. By default, this is created, and all hosts registered to Satellite will have access to it. Smaller environments may be able to get away with keeping it this way, however, it is recommended to build out an environment based on your own development lifecycle. For example: DEV > QA > PROD. To get started, just click on Create Environment Path.

You will begin by adding your first environment in which you wish to promote content through. Generally, this is a TEST or DEV environment. You will send your new ERATTA, REPOS, and the like first into DEV, in which servers that are in this DEV lifecycle can then best tested with these patches, and software that is installed. Once everything checks out you know it is safe to promote to the next lifecycle, which could be QA, or end PROD in some environments. You are then assured you will not have adverse effects from a patch cycle in PROD as it was previously tested while in DEV and even QA.

Adding configuration details to the enviornment

Continuing on in our example, we fill in the details of our environment. Whatever makes sense for your organization. Once you are done, click on Save.

You will then see your first lifecycle, it currently holds 0 content views and content hosts. Those will be added later.

Finish your lifecycle path by repeating the previous steps, adding QA, and PROD.

Content Views

Content views are managed selections of content, which contain one or more repositories (yum, puppet, or containers) with optional filtering. These filters can be either inclusive or exclusive, and tailor a system view of content for life cycle management. They are used to customize content to be made available to client systems.

Red Hat

Our next step in managing Red Hat Satellite is with content views. One example of why you would use a content view is with patching different types of RHEL Servers. You may not want a file server to have access to packages that are required for a web server. You may need to have higher versions of PHP, Python or such on your web server, so you will have Red Hat Software Collections or third-party repositories to have specific versions of PHP on your web server. By adding those repositories to a specific content view, which is then attached to an activation key you can have these packages visible to just your web server, while your file server or database server would have their own role specific repositories.

To create a content view, just go to Content > Content Views > Create New View.

Naming the content view

Give it a name, I like prefixing things within Satellite with CV or AK (content view, or activation key). This way you notice what it is at a glance by the prefix. Fill in the remainder of the information, and then click on Save.

Adding yum content to your view

Next, you will need to attach yum content to your view. We only have RHEL 7 and Satellite Tools. As both are needed for a base RHEL server, we will add both to our content view. In a production environment you will likely have many other products, just choose the ones that are required for this view, which you plan to attach to specific servers. Once you have them selected, click on Add Repositories.

Once added you need to publish your content to the appropriate lifecycle environment. At the least, you will need to publish to library. Generally, though you will continue to your first lifecycle, in our case DEV. It is good practice to add a description as to what you are doing and why. Once you are ready, click on Save.

Initial content view publish

It will take time, especially the more repositories you have in the content view, for the initial publish into library. Just be patient.

Content view ready to promote

Once it is finished, you will see the initial environment, as well as how many packages, and errata are available in your content view. This is helpful when publishing future content view revisions, as this number will change with each itteration as your daily sync will download new packages and errata over time. To gain access to those new packages after this initial publish, you will need to republish your content view again, and move it through the lifecycle enviornment.

We finish by promoting our content view one more time, this time into DEV. With an initial publish, you will usually push it all the way into Prod, as if you don’t the production servers will not have any content to install.

Activation Keys

Activation keys define selected properties of content hosts. You can use activation keys during content host registration to improve the speed, simplicity and consistency of the process. Activation can specify:

– Associated subscriptions and subscription attach behavior.
– Available products and repositories.
– A life cycle environment and a content view.
– Host collection membership.

Red Hat

Activation Keys will make managing a Red Hat Satellite server more efficitent. To create an activation key, we go to Content > Activation Keys > Create Activation Key.

Naming conventions for Activation Keys

Name the key (I like prefixing, so AK-) based on the role of servers you will be registering with that AK. If they are simple RHEL servers, give them a name such as I have. However, you can customize them further by naming them Web Servers, Database Servers, etc. Just so it is clear what they will be registering so you can connect them to the appropriate server while registering. You also need to choose what environment that server will be placed in. In this example, I want RHEL 7 Servers that will be in the DEV lifecycle. I guess a better naming convention would have been AK-RHEL7-DEV-Servers. When you are finished, just click on Save.

Setting the release version of RHEL

By default, the release version let us blank. Which you can keep it as, or you can set the release version based on what products you have attached. In my case, as I used the main RHEL7 repository, I can set the servers for 7Server, which will allow my servers to upgrade to each z stream of 7 as it comes out. It will, however, hold them at 7 and not allow them to upgrade to 8. Which in reality it would be unable to do without the RHEL 8 repos attached to the content view/activation key combination.

Entitlements

Next, we need to attach our entitlements to this AK, this will hand out the required number for each server that uses this activation key. So, select the subscription tab, choose the Add sub tab, then choose the entitlements that are needed. Then choose Add Selected.

Finally we need to choose which repositories are enabled or disabled by default when a server is registered via the Activation Key. By deafult, Satellite Tools is disabled. Choose Satellite Tools, then Select Actions, here we can choose Override to Enabled. If you wish to disable a repository by default, you can set it to override to disable.

How to use your activation key

You will see the results below. And that about does it. We now have a lifecycle enviornment, a content view, and an activation key. We are ready to register our first server into our enviornment. This will be discussed in our next article. To use the activation key, you will see the synatax of it in the Details tab.

# subscription-manager register --org="ACME" --activationkey="AK-RHEL7-Servers"

What’s next?

Our next article will cover registering an already built or manually installed RHEL server into our Satellite environment. Later we will cover provisioning. I hope this article has helped in understanding further how to manage a Red Hat Satellite server.