Managing application lifecycles
Lifecycle environments in orcharhino separate content into ordered stages from development to production and link content views, hosts, and orcharhino Proxy Server synchronization. You can create environment paths to stage applications and promote content views to deliver new versions to hosts.
Introduction to application lifecycle
The application lifecycle organizes how hosts and software appear at each stage of delivery. In orcharhino, each stage is a lifecycle environment backed by a content view that selects repositories and packages for hosts registered to that stage.
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
orcharhino 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 orcharhino. Each environment uses a specific collection of content. orcharhino 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.
Content promotion across the application lifecycle
In the application lifecycle chain, moving content from one environment to the next is called promotion. Promotion updates repositories of the target environment so hosts registered to that environment can use the new versions.
Each environment contains a set of systems registered to orcharhino. 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.
This example uses a .rpm package, but you can promote any type of content across the application lifecycle.
| 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 |
Best practices for lifecycle environments
Design lifecycle environment paths, plan promotions, and configure orcharhino Proxy Server content synchronization for predictable staging from development to production.
-
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 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 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 hosts, change the lifecycle environment from
2023-Q4to2024-Q1using the orcharhino management UI, orcharhino 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.
-
orcharhino Proxy Servers use lifecycle environments to synchronize content. They synchronize content more efficiently if you split content into multiple lifecycle environment paths. If a specific orcharhino Proxy Server only serves content for one operating system in a single lifecycle environment path, it only synchronizes required content.
Creating a lifecycle environment path by using orcharhino management UI
Create a lifecycle environment path starting from the Library environment to stage content from development through release. Optionally chain additional environments for testing, beta, or production stages.
-
In the orcharhino management 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.
Creating a lifecycle environment path by using Hammer CLI
Create a lifecycle environment path starting from the Library environment to stage content from development through release. Optionally chain additional environments for testing, beta, or production stages.
-
Create a lifecycle environment path by tying your first environment to Library:
$ hammer lifecycle-environment create \ --name "My First Lifecycle Environment" \ --description "Environment Path Description" \ --prior "Library" \ --organization "My_Organization" -
Optional: Add another environment to the environment path by tying it to the prior environment:
$ hammer lifecycle-environment create \ --name "My Second Lifecycle Environment" \ --description "Environment Description" \ --prior "My First Lifecycle Environment" \ --organization "My_Organization" -
View the chain of the lifecycle environment path:
$ hammer lifecycle-environment paths --organization "My_Organization"
Adding lifecycle environments to orcharhino Proxy Servers by using orcharhino management UI
To distribute content through content-enabled orcharhino Proxy Server, add lifecycle environments to your orcharhino Proxy Server. orcharhino Proxy Server synchronizes the right repositories from orcharhino Server and provides that content to hosts.
Do not assign the Library lifecycle environment to your orcharhino Proxy Server because it triggers an automated orcharhino Proxy sync every time the CDN updates a repository. This might consume multiple system resources on orcharhino Proxies, network bandwidth between orcharhino and orcharhino Proxies, and available disk space on orcharhino Proxies.
You can add an environment from the orcharhino management UI.
-
In the orcharhino management UI, navigate to Infrastructure > orcharhino Proxies.
-
Select your orcharhino Proxy Server 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 your orcharhino Proxy Server and click Submit.
-
To synchronize the content to your orcharhino Proxy Server, click the Overview tab and click Synchronize.
-
Select either Optimized Sync or Complete Sync.
Adding lifecycle environments to orcharhino Proxy Servers by using Hammer CLI
To distribute content through content-enabled orcharhino Proxy Server, add lifecycle environments to your orcharhino Proxy Server. orcharhino Proxy Server synchronizes the right repositories from orcharhino Server and provides that content to hosts.
Do not assign the Library lifecycle environment to your orcharhino Proxy Server because it triggers an automated orcharhino Proxy sync every time the CDN updates a repository. This might consume multiple system resources on orcharhino Proxies, network bandwidth between orcharhino and orcharhino Proxies, and available disk space on orcharhino Proxies.
You can add an environment by using Hammer CLI.
-
To display a list of all orcharhino Proxy Servers, on orcharhino Server, enter the following command:
$ hammer proxy listNote the orcharhino Proxy ID of the orcharhino Proxy to which you want to add a lifecycle.
-
Using the ID, verify the details of your orcharhino Proxy:
$ hammer proxy info \ --id My_orcharhino_Proxy_ID -
To view the lifecycle environments available for your orcharhino Proxy Server, enter the following command and note the ID and the organization name:
$ hammer proxy content available-lifecycle-environments \ --id My_orcharhino_Proxy_ID -
Add the lifecycle environment to your orcharhino Proxy Server:
$ hammer proxy content add-lifecycle-environment \ --id My_orcharhino_Proxy_ID \ --lifecycle-environment-id My_Lifecycle_Environment_ID \ --organization "My_Organization"Repeat for each lifecycle environment you want to add to orcharhino Proxy Server.
-
Synchronize the content from orcharhino to orcharhino Proxy.
-
To synchronize all content from your orcharhino Server environment to orcharhino Proxy Server, enter the following command:
$ hammer proxy content synchronize \ --id My_orcharhino_Proxy_ID -
To synchronize a specific lifecycle environment from your orcharhino Server to orcharhino Proxy Server, enter the following command:
$ hammer proxy content synchronize \ --id My_orcharhino_Proxy_ID \ --lifecycle-environment-id My_Lifecycle_Environment_ID -
To synchronize all content from your orcharhino Server to your orcharhino Proxy Server without checking metadata:
$ hammer proxy content synchronize \ --id My_orcharhino_Proxy_ID \ --skip-metadata-check trueThis equals selecting Complete Sync in the orcharhino management UI.
-
Removing lifecycle environments from orcharhino Server by using orcharhino management UI
Remove a lifecycle environment from orcharhino Server when it is empty and no longer needed so your content paths stay accurate and easier to manage.
-
In the orcharhino management 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.
Removing lifecycle environments from orcharhino Server by using Hammer CLI
Remove a lifecycle environment from orcharhino Server when it is empty and no longer needed so your content paths stay accurate and easier to manage.
-
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 deletecommand to remove an environment:$ hammer lifecycle-environment delete \ --name "My_Environment" \ --organization "My_Organization"
Removing lifecycle environments from orcharhino Proxy Server by using orcharhino management UI
Remove lifecycle environments from orcharhino Proxy Server when they are obsolete or were added incorrectly, then resynchronize. That way, your orcharhino Proxy Server only stores content your hosts still need.
-
In the orcharhino management UI, navigate to Infrastructure > orcharhino Proxies.
-
Select the orcharhino Proxy Server 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 orcharhino Proxy Server, and then click Submit.
-
To synchronize content to your orcharhino Proxy Server, click the Overview tab, and then click Synchronize.
-
Select either Optimized Sync or Complete Sync.
Removing lifecycle environments from orcharhino Proxy Server by using Hammer CLI
Remove lifecycle environments from orcharhino Proxy Server when they are obsolete or were added incorrectly, then resynchronize. That way, your orcharhino Proxy Server only stores content your hosts still need.
-
Get a list of orcharhino Proxies:
$ hammer proxy listNote down the ID of your orcharhino Proxy Server.
-
Optional: Verify the details of your orcharhino Proxy Server:
$ hammer proxy info \ --id My_orcharhino_Proxy_Server_ID -
Optional: Verify the list of lifecycle environments currently attached to orcharhino Proxy Server:
$ hammer proxy content lifecycle-environments \ --id My_orcharhino_Proxy_Server_IDNote down the Environment ID.
-
Remove the lifecycle environment from orcharhino Proxy Server:
$ hammer proxy content remove-lifecycle-environment \ --id My_orcharhino_Proxy_Server_ID \ --lifecycle-environment-id My_Lifecycle_Environment_IDRepeat this step for every lifecycle environment that you want to remove from orcharhino Proxy Server.
-
Synchronize the content from orcharhino Server to orcharhino Proxy Server:
$ hammer proxy content synchronize \ --id My_orcharhino_Proxy_Server_ID
|
The text and illustrations on this page are licensed by ATIX AG under a Creative Commons Attribution Share Alike 4.0 International ("CC BY-SA 4.0") license. This page also contains text from the official Foreman documentation which uses the same license ("CC BY-SA 4.0"). |