Managing application lifecycles

This chapter outlines the application lifecycle in orcharhino and how to create and remove application lifecycles for orcharhino and orcharhino Proxy.

Best Practices for Patching Content Hosts

  • Registering hosts to orcharhino requires orcharhino Clients, which contain the subscription-manager package, katello-host-tools package, and their dependencies. Use the bootstrap.py script to register existing hosts. For more information, see Registering Hosts Using the Bootstrap Script.

  • When registering hosts manually, ensure to provide the necessary configuration files and certificates.

  • Use the management UI to install, upgrade, and remove packages from managed hosts. You can update content hosts with job templates using SSH and Ansible.

  • Apply errata on content hosts using the management UI.

  • Modify or replace job templates to add custom steps. This allows you to run commands or execute scripts on managed hosts.

  • When running bulk actions on managed hosts, we recommend bundling them by the same major operating system version, especially when upgrading packages.

  • Select via remote execution - customize first to define the time when patches are applied on managed hosts when performing bulk actions.

  • When patching packages on managed hosts using the default package manager, orcharhino receives a list of packages and repositories to recalculate applicable errata and available updates.

  • You cannot apply errata to packages that are not part of the repositories on orcharhino and the attached content view.

  • Modifications to installed packages using rpm or dpkg are sent to orcharhino with the next run of apt, yum, or zypper.

Introduction to application lifecycle

The application lifecycle is a concept central to orcharhino’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

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.

The orcharhino Application Lifecycle
Figure 1. The orcharhino Application Lifecycle

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 orcharhino lifecycle environments

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

For more information, see Promoting a Content View.

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

  1. In the orcharhino management UI, navigate to Content > Lifecycle > Lifecycle Environments.

  2. Click New Environment Path to start a new application lifecycle.

  3. In the Name field, enter a name for your environment.

  4. In the Description field, enter a description for your environment.

  5. Click Save.

  6. 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

  1. 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"

  2. 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"

  3. To view the chain of the lifecycle environment, enter the following command:

    $ hammer lifecycle-environment paths --organization "My_Organization"

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 lifecycle environment Production.

  • Default use case: Fixed stages in each lifecycle environment paths, for example Development, Test, and Production.

    • Promote content views to lifecycle environments.

    • To make content from Test available in Production, promote the content view version 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.

    • Promote the content view to a specific stage, for example 2021-Q1 and only ever publish new minor versions when adding incremental updates from errata.

    • When patching content hosts, change the lifecycle environment from 2020-Q4 to 2021-Q1 using the management UI, the API, a Hammer script, 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 Proxies running Pulp 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 only serves content for one operating system in a single lifecycle environment path, it only synchronizes actually required content.

Adding lifecycle environments to orcharhino Proxies

If your orcharhino Proxy has the content functionality enabled, you must add an environment so that orcharhino Proxy can synchronize content from orcharhino Server and provide content to host systems.

Do not assign the Library lifecycle environment to your orcharhino Proxy 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 use Hammer CLI on orcharhino Server or the orcharhino management UI.

Procedure

  1. In the orcharhino management UI, navigate to Infrastructure > orcharhino Proxies, and select the orcharhino Proxy that you want to add a lifecycle to.

  2. Click Edit and click the Lifecycle Environments tab.

  3. From the left menu, select the lifecycle environments that you want to add to orcharhino Proxy and click Submit.

  4. To synchronize the content on the orcharhino Proxy, click the Overview tab and click Synchronize.

  5. Select either Optimized Sync or Complete Sync.

    For definitions of each synchronization type, see Recovering a Repository.

CLI procedure

  1. To display a list of all orcharhino Proxies, on orcharhino Server, enter the following command:

    $ hammer proxy list

    Note the orcharhino Proxy ID of the orcharhino Proxy to which you want to add a lifecycle.

  2. Using the ID, verify the details of your orcharhino Proxy:

    $ hammer proxy info \
--id Myorcharhino-proxy_ID_

  3. To view the lifecycle environments available for your orcharhino Proxy, enter the following command and note the ID and the organization name:

    $ hammer proxy content available-lifecycle-environments \
--id Myorcharhino-proxy_ID_

  4. Add the lifecycle environment to your orcharhino Proxy:

    $ hammer proxy content add-lifecycle-environment \
--id Myorcharhino-proxy_ID_ \
--lifecycle-environment-id My_Lifecycle_Environment_ID
--organization "My_Organization"

    Repeat for each lifecycle environment you want to add to orcharhino Proxy.

  5. Synchronize the content from orcharhino to orcharhino Proxy.

    • To synchronize all content from your orcharhino Server environment to orcharhino Proxy, enter the following command:

      $ hammer proxy content synchronize \
--id Myorcharhino-proxy_ID_

    • To synchronize a specific lifecycle environment from your orcharhino Server to orcharhino Proxy, enter the following command:

      $ hammer proxy content synchronize \
--id Myorcharhino-proxy_ID_
--lifecycle-environment-id My_Lifecycle_Environment_ID

    • To synchronize all content from your orcharhino Server to your orcharhino Proxy without checking metadata:

      $ hammer proxy content synchronize \
--id Myorcharhino-proxy_ID_ \
--skip-metadata-check true

      This equals selecting Complete Sync in the orcharhino management UI.

Removing lifecycle environments from orcharhino Server

Use this procedure to remove a lifecycle environment.

Procedure

  1. In the orcharhino management UI, navigate to Content > Lifecycle Environments.

  2. Click the name of the lifecycle environment that you want to remove, and then click Remove Environment.

  3. Click Remove to remove the environment.

CLI procedure

  1. 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"

  2. Use the hammer lifecycle-environment delete command to remove an environment:

    $ hammer lifecycle-environment delete \
--name "My_Environment" \
--organization "My_Organization"

Removing lifecycle environments from orcharhino Proxy

When lifecycle environments are no longer relevant to the host system or environments are added incorrectly to orcharhino Proxy, you can remove the lifecycle environments from orcharhino Proxy.

You can use both the orcharhino management UI and the Hammer CLI to remove lifecycle environments from orcharhino Proxy.

Procedure

  1. In the orcharhino management UI, navigate to Infrastructure > orcharhino Proxies, and select the orcharhino Proxy that you want to remove a lifecycle from.

  2. Click Edit and click the Lifecycle Environments tab.

  3. From the right menu, select the lifecycle environments that you want to remove from orcharhino Proxy, and then click Submit.

  4. To synchronize orcharhino Proxy’s content, click the Overview tab, and then click Synchronize.

  5. Select either Optimized Sync or Complete Sync.

CLI procedure

  1. Select orcharhino Proxy that you want from the list and take note of its id:

    $ hammer proxy list

  2. To verify orcharhino Proxy’s details, enter the following command:

    $ hammer proxy info \
--id My_orcharhino_Proxy_ID

  3. Verify the list of lifecycle environments currently attached to orcharhino Proxy and take note of the Environment ID:

    $ hammer proxy content lifecycle-environments \
--id My_orcharhino_Proxy_ID

  4. Remove the lifecycle environment from orcharhino Proxy:

    $ hammer proxy content remove-lifecycle-environment \
--id My_orcharhino_Proxy_ID \
--lifecycle-environment-id My_Lifecycle_Environment_ID

    Repeat this step for every lifecycle environment that you want to remove from orcharhino Proxy.

  5. Synchronize the content from orcharhino Server’s environment to orcharhino Proxy:

    $ hammer proxy content synchronize \
--id My_orcharhino_Proxy_ID

The text and illustrations on this page are licensed by ATIX AG under a Creative Commons Attribution–Share Alike 3.0 Unported ("CC-BY-SA") license. This page also contains text from the official Foreman documentation which uses the same license ("CC-BY-SA").