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 , 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 , 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 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 to 2024-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 . 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: 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: To view the chain of the lifecycle environment, enter the following command: 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: Note the Capsule ID of the Capsule to which you want to add a lifecycle. Using the ID, verify the details of your Capsule: To view the lifecycle environments available for your Capsule Server, enter the following command and note the ID and the organization name: Add the lifecycle environment to your Capsule Server: 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: To synchronize a specific lifecycle environment from your Satellite Server to Capsule Server, enter the following command: To synchronize all content from your Satellite Server to your Capsule Server without checking metadata: 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: Use the hammer lifecycle-environment delete command to remove an environment: 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 : To verify Capsule Server's details, enter the following command: Verify the list of lifecycle environments currently attached to Capsule Server and take note of the Environment ID : Remove the lifecycle environment from Capsule Server: 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:

Commands:
hammer lifecycle-environment create --name " Environment Path Name " --description " Environment Path Description " --prior "Library" --organization " My_Organization "
hammer lifecycle-environment create --name " Environment Name " --description " Environment Description " --prior " Prior Environment Name " --organization " My_Organization "
hammer lifecycle-environment paths --organization " My_Organization "
hammer capsule list
hammer capsule info --id My_capsule_ID
hammer capsule content available-lifecycle-environments --id My_capsule_ID
hammer capsule content add-lifecycle-environment --id My_capsule_ID --lifecycle-environment-id My_Lifecycle_Environment_ID --organization " My_Organization "
hammer capsule content synchronize --id My_capsule_ID
hammer capsule content synchronize --id My_capsule_ID --lifecycle-environment-id My_Lifecycle_Environment_ID
hammer capsule content synchronize --id My_capsule_ID --skip-metadata-check true
hammer lifecycle-environment list --organization " My_Organization "
hammer lifecycle-environment delete --name " My_Environment " --organization " My_Organization "
hammer capsule list
hammer capsule info --id My_Capsule_ID
hammer capsule content lifecycle-environments --id My_Capsule_ID
hammer capsule content remove-lifecycle-environment --id My_Capsule_ID --lifecycle-environment-id My_Lifecycle_Environment_ID
hammer capsule content synchronize --id My_Capsule_ID