이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 6. Managing application lifecycles
This chapter outlines the application lifecycle in Satellite and how to create and remove application lifecycles for Satellite and Capsule.
6.1. Introduction to application lifecycle
The application lifecycle is a concept central to Satellite’s content management functions. The application lifecycle defines how a particular system and its software look at a particular stage. For example, an application lifecycle might be simple; you might only have a development stage and production stage. In this case the application lifecycle might look like this:
- Development
- Production
However, a more complex application lifecycle might have further stages, such as a phase for testing or a beta release. This adds extra stages to the application lifecycle:
- Development
- Testing
- Beta Release
- Production
Satellite provides methods to customize each application lifecycle stage so that it suits your specifications.
Each stage in the application lifecycle is called an environment in Satellite. Each environment uses a specific collection of content. Satellite defines these content collections as a content view. Each content view acts as a filter where you can define what repositories, and packages to include in a particular environment. This provides a method for you to define specific sets of content to designate to each environment.
For example, an email server might only require a simple application lifecycle where you have a production-level server for real-world use and a test server for trying out the latest mail server packages. When the test server passes the initial phase, you can set the production-level server to use the new packages.
Another example is a development lifecycle for a software product. To develop a new piece of software in a development environment, test it in a quality assurance environment, pre-release as a beta, then release the software as a production-level application.
Figure 6.1. Satellite application lifecycle
6.2. Content promotion across the application lifecycle
In the application lifecycle chain, when content moves from one environment to the next, this is called promotion.
Example: Content promotion across Satellite lifecycle environments
Each environment contains a set of systems registered to Red Hat Satellite. These systems only have access to repositories relevant to their environment. When you promote packages from one environment to the next, the target environment’s repositories receive new package versions. As a result, each system in the target environment can update to the new package versions.
Development | Testing | Production |
---|---|---|
example_software-1.1-0.noarch.rpm | example_software-1.0-0.noarch.rpm | example_software-1.0-0.noarch.rpm |
After completing development on the patch, you promote the package to the Testing environment so the Quality Engineering team can review the patch. The application lifecycle then contains the following package versions in each environment:
Development | Testing | Production |
---|---|---|
example_software-1.1-0.noarch.rpm | example_software-1.1-0.noarch.rpm | example_software-1.0-0.noarch.rpm |
While the Quality Engineering team reviews the patch, the Development team starts work on example_software 2.0. This results in the following application lifecycle:
Development | Testing | Production |
---|---|---|
example_software-2.0-0.noarch.rpm | example_software-1.1-0.noarch.rpm | example_software-1.0-0.noarch.rpm |
The Quality Engineering team completes their review of the patch. Now example_software 1.1 is ready to release. You promote 1.1 to the Production environment:
Development | Testing | Production |
---|---|---|
example_software-2.0-0.noarch.rpm | example_software-1.1-0.noarch.rpm | example_software-1.1-0.noarch.rpm |
The Development team completes their work on example_software 2.0 and promotes it to the Testing environment:
Development | Testing | Production |
---|---|---|
example_software-2.0-0.noarch.rpm | example_software-2.0-0.noarch.rpm | example_software-1.1-0.noarch.rpm |
Finally, the Quality Engineering team reviews the package. After a successful review, promote the package to the Production environment:
Development | Testing | Production |
---|---|---|
example_software-2.0-0.noarch.rpm | example_software-2.0-0.noarch.rpm | example_software-2.0-0.noarch.rpm |
For more information, see Section 7.7, “Promoting a content view”.
6.3. Best practices for lifecycle environments
- Use multiple lifecycle environment paths to implement multiple sequential stages of content consumption. Each stage contains a defined set of content, for example in the Production lifecycle environment.
- Automate the creation of lifecycle environments by using a Hammer script or an Ansible playbook.
Default use case: Fixed stages in each lifecycle environment paths, for example Development, Test, and Production.
- Promote content views to lifecycle environments, for example, from Test to Production. All content hosts consuming this content view or composite content view are able to install packages from the Production lifecycle environment. Note that these packages are not installed or updated automatically.
- If you encounter errors during patching content hosts, attach the host to a previous version of the content view. This only affects the availability of packages but does not downgrade installed packages.
Alternative use case: Using stages in lifecycle environments for fixed content, for example, quarterly updates, and only publishing new minor versions with incremental updates from errata.
-
When patching content hosts, change the lifecycle environment from
2023-Q4
to2024-Q1
using the Satellite web UI, Satellite API, Hammer CLI, or an activation key. - Advantage: You can directly see which software packages a hosts receives by looking at its lifecycle environment.
- Disadvantage: Promoting content is less dynamic without clearly defined stages such as Development, Test, and Production.
-
When patching content hosts, change the lifecycle environment from
- Use multiple lifecycle environment paths to define multiple stages for different environments, for example to decouple web server and database hosts.
- Capsule Servers use lifecycle environments to synchronize content. They synchronize content more efficiently if you split content into multiple lifecycle environment paths. If a specific Capsule Server only serves content for one operating system in a single lifecycle environment path, it only synchronizes required content.
6.4. Creating a lifecycle environment path
To create an application lifecycle for developing and releasing software, use the Library environment as the initial environment to create environment paths. Then optionally add additional environments to the environment paths.
Procedure
- In the Satellite web UI, navigate to Content > Lifecycle > Lifecycle Environments.
- Click New Environment Path to start a new application lifecycle.
- In the Name field, enter a name for your environment.
- In the Description field, enter a description for your environment.
- Click Save.
- Optional: To add an environment to the environment path, click Add New Environment, complete the Name and Description fields, and select the prior environment from the Prior Environment list.
CLI procedure
To create an environment path, enter the
hammer lifecycle-environment create
command and specify the Library environment with the--prior
option:# hammer lifecycle-environment create \ --name "Environment Path Name" \ --description "Environment Path Description" \ --prior "Library" \ --organization "My_Organization"
Optional: To add an environment to the environment path, enter the
hammer lifecycle-environment create
command and specify the parent environment with the--prior
option:# hammer lifecycle-environment create \ --name "Environment Name" \ --description "Environment Description" \ --prior "Prior Environment Name" \ --organization "My_Organization"
To view the chain of the lifecycle environment, enter the following command:
# hammer lifecycle-environment paths --organization "My_Organization"
6.5. Adding lifecycle environments to Capsule Servers
If your Capsule Server has the content functionality enabled, you must add an environment so that Capsule can synchronize content from Satellite Server and provide content to host systems.
Do not assign the Library lifecycle environment to your Capsule Server because it triggers an automated Capsule sync every time the CDN updates a repository. This might consume multiple system resources on Capsules, network bandwidth between Satellite and Capsules, and available disk space on Capsules.
You can use Hammer CLI on Satellite Server or the Satellite web UI.
Procedure
- In the Satellite web UI, navigate to Infrastructure > Capsules, and select the Capsule that you want to add a lifecycle to.
- Click Edit and click the Lifecycle Environments tab.
- From the left menu, select the lifecycle environments that you want to add to Capsule and click Submit.
- To synchronize the content on the Capsule, click the Overview tab and click Synchronize.
Select either Optimized Sync or Complete Sync.
For definitions of each synchronization type, see Recovering a Repository.
CLI procedure
To display a list of all Capsule Servers, on Satellite Server, enter the following command:
# hammer capsule list
Note the Capsule ID of the Capsule to which you want to add a lifecycle.
Using the ID, verify the details of your Capsule:
# hammer capsule info \ --id My_capsule_ID
To view the lifecycle environments available for your Capsule Server, enter the following command and note the ID and the organization name:
# hammer capsule content available-lifecycle-environments \ --id My_capsule_ID
Add the lifecycle environment to your Capsule Server:
# hammer capsule content add-lifecycle-environment \ --id My_capsule_ID \ --lifecycle-environment-id My_Lifecycle_Environment_ID --organization "My_Organization"
Repeat for each lifecycle environment you want to add to Capsule Server.
Synchronize the content from Satellite to Capsule.
To synchronize all content from your Satellite Server environment to Capsule Server, enter the following command:
# hammer capsule content synchronize \ --id My_capsule_ID
To synchronize a specific lifecycle environment from your Satellite Server to Capsule Server, enter the following command:
# hammer capsule content synchronize \ --id My_capsule_ID --lifecycle-environment-id My_Lifecycle_Environment_ID
To synchronize all content from your Satellite Server to your Capsule Server without checking metadata:
# hammer capsule content synchronize \ --id My_capsule_ID \ --skip-metadata-check true
This equals selecting Complete Sync in the Satellite web UI.
6.6. Removing lifecycle environments from Satellite Server
Use this procedure to remove a lifecycle environment.
Procedure
- In the Satellite web UI, navigate to Content > Lifecycle Environments.
- Click the name of the lifecycle environment that you want to remove, and then click Remove Environment.
- Click Remove to remove the environment.
CLI procedure
List the lifecycle environments for your organization and note the name of the lifecycle environment you want to remove:
# hammer lifecycle-environment list \ --organization "My_Organization"
Use the
hammer lifecycle-environment delete
command to remove an environment:# hammer lifecycle-environment delete \ --name "My_Environment" \ --organization "My_Organization"
6.7. Removing lifecycle environments from Capsule Server
When lifecycle environments are no longer relevant to the host system or environments are added incorrectly to Capsule Server, you can remove the lifecycle environments from Capsule Server.
You can use both the Satellite web UI and the Hammer CLI to remove lifecycle environments from Capsule.
Procedure
- In the Satellite web UI, navigate to Infrastructure > Capsules, and select the Capsule that you want to remove a lifecycle from.
- Click Edit and click the Lifecycle Environments tab.
- From the right menu, select the lifecycle environments that you want to remove from Capsule, and then click Submit.
- To synchronize Capsule’s content, click the Overview tab, and then click Synchronize.
- Select either Optimized Sync or Complete Sync.
CLI procedure
Select Capsule Server that you want from the list and take note of its id:
# hammer capsule list
To verify Capsule Server’s details, enter the following command:
# hammer capsule info \ --id My_Capsule_ID
Verify the list of lifecycle environments currently attached to Capsule Server and take note of the Environment ID:
# hammer capsule content lifecycle-environments \ --id My_Capsule_ID
Remove the lifecycle environment from Capsule Server:
# hammer capsule content remove-lifecycle-environment \ --id My_Capsule_ID \ --lifecycle-environment-id My_Lifecycle_Environment_ID
Repeat this step for every lifecycle environment that you want to remove from Capsule Server.
Synchronize the content from Satellite Server’s environment to Capsule Server:
# hammer capsule content synchronize \ --id My_Capsule_ID