Managing Application Life Cycles

This chapter outlines the application life cycle in orcharhino and how to create and remove application life cycles for orcharhino and orcharhino Proxy.

Best Practices for Patching Content Hosts

  • Attaching hosts to orcharhino requires the orcharhino clients which contain the subscription-manager package, katello-host-tools, and their dependencies. Use the bootstrap.py script to attach existing hosts. When attaching 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 using 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 Life Cycle

The application life cycle is a concept central to orcharhino’s content management functions. The application life cycle defines how a particular system and its software look at a particular stage. For example, an application life cycle might be simple; you might only have a development stage and production stage. In this case the application life cycle might look like this:

  • Development

  • Production

However, a more complex application life cycle might have further stages, such as a phase for testing or a beta release. This adds extra stages to the application life cycle:

  • Development

  • Testing

  • Beta Release

  • Production

orcharhino provides methods to customize each application life cycle stage so that it suits your specifications.

Each stage in the application life cycle 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 life cycle 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 life cycle 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.

application life cycle

Promoting Content across the Application Life Cycle

In the application life cycle chain, when content moves from one environment to the next, this is called promotion.

Example Content Promotion Across orcharhino Life Cycle 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 life cycle.

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 life cycle 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 life cycle:

Development Testing Production

exampleware-2.0-0.noarch.rpm

exampleware-1.1-0.noarch.rpm

exampleware-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

exampleware-2.0-0.noarch.rpm

exampleware-2.0-0.noarch.rpm

exampleware-2.0-0.noarch.rpm

For more information, see Promoting a Content View.

Creating a Life Cycle Environment Path

To create an application life cycle 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 Environments.

  2. Click New Environment Path to start a new application life cycle.

  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 life cycle 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.

Removing Life Cycle Environments from orcharhino Server

Use this procedure to remove a life cycle environment.

Procedure
  1. In the orcharhino management UI, navigate to Content > Life Cycle Environments.

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

  3. Click Remove to remove the environment.

CLI procedure
  1. List the life cycle environments for your organization and note the name of the life cycle 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 Life Cycle Environments from orcharhino Proxy

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

You can use both the orcharhino management UI and the Hammer CLI to remove life cycle 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 life cycle from.

  2. Click Edit and click the Life Cycle Environments tab.

  3. From the right menu, select the life cycle 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 capsule list
  2. To verify orcharhino Proxy’s details, enter the following command:

    # hammer capsule info \
    --id orcharhino Proxy_ID
  3. Verify the list of life cycle environments currently attached to orcharhino Proxy and take note of the Environment ID:

    # hammer capsule content lifecycle-environments \
    --id orcharhino Proxy_ID
  4. Remove the life cycle environment from orcharhino Proxy:

    # hammer capsule content remove-lifecycle-environment \
    --id orcharhino Proxy_ID
    --lifecycle-environment-id Lifecycle_Environment_ID

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

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

    # hammer capsule content synchronize \
    --id orcharhino Proxy_ID

Adding Life Cycle Environments to orcharhino Proxys

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 life cycle to.

  2. Click Edit and click the Life Cycle Environments tab.

  3. From the left menu, select the life cycle 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 Proxys, on orcharhino Server, enter the following command:

    # hammer capsule list

    Note the orcharhino Proxy ID of the orcharhino Proxy that you want to add a life cycle to.

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

    # hammer capsule info --id capsule_id
  3. To view the life cycle environments available for your orcharhino Proxy, enter the following command and note the ID and the organization name:

    # hammer capsule content available-lifecycle-environments --id capsule_id
  4. Add the life cycle environment to your orcharhino Proxy:

    # hammer capsule content add-lifecycle-environment \
    --id capsule_id --organization "My_Organization" \
    --lifecycle-environment-id lifecycle-environment_id

    Repeat for each life cycle 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 capsule content synchronize --id capsule_id
    • To synchronize a specific life cycle environment from your orcharhino Server to orcharhino Proxy, enter the following command:

      # hammer capsule content synchronize --id external_capsule_id \
      --lifecycle-environment-id lifecycle-environment_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").