Chapter 1. Introduction
In the context of system management, we define content as the software installed on systems. This includes, but is not limited to, the base operating system, middleware services, and end user applications. Red Hat Satellite 6 provides tools to manage the various types of content for Red Hat Enterprise Linux systems. This provides system administrators with an easy way to collect a range of content, keep it up to date, and use it to provision new systems and update existing systems.
This guide aims to provide an end-to-end scenario to demonstrate how to manage your content. This guide is targeted at system administrators with a newly installed Satellite Server.
1.1. Overview of Red Hat Satellite 6 Content Management
Content management in the context of Red Hat Satellite 6 means a work flow that provides a sustainable repository for multiple content types. For Red Hat content, Red Hat Satellite 6 also uses subscription information so that it knows what content is available to a user. This means Red Hat Satellite 6 uses components to manage the following:
- Subscription management, which includes tools to manage Red Hat software subscriptions, and associated content, over a secure connection. This provides a means for organizations to manage their Red Hat subscription information.
- Content management, which includes applications to download and store content in custom repositories. This provides organizations with a method to store Red Hat content and organize it in various ways.
1.2. Defining the Application Life Cycle
The application life cycle is a concept central to Red Hat Satellite 6’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
Ultimately, the stages in an application life cycle depend on your organization and its software development methods. However, Red Hat Satellite 6 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 Red Hat Satellite 6. Each environment uses a specific collection of content. Red Hat Satellite 6 defines these content collections as a Content View. Each Content View acts as a filter where we can define what repositories, packages, and Puppet modules to include in a particular environment. This provides a method for you to define specific sets of content to designate to each environment.
The concept of the application life cycle depends on a certain level of progression. For example, environments in the early stages of an application life cycle might use newer and pre-release packages for development and testing of new features. Likewise, environments in the later stages might use only stable packages to suit production-level software. If the packages in development pass testing, you can promote the development Content View across the application life cycle so that it becomes the Content View for the production environment. This ensures that your application life cycle progresses with the development of your application.
Figure 1.1. The Red Hat Satellite 6 Application Life Cycle
1.3. Defining Content Management Types
Red Hat Satellite 6 manages different content types. This includes:
- RPM Packages
- Red Hat Satellite 6 provides a method to import RPM files from repositories related to your Red Hat subscriptions. This means Satellite Server downloads the RPM files from Red Hat’s Content Delivery Network and stores them locally. You can use these repositories and their RPM files in Content Views.
- Kickstart Trees
- Red Hat Satellite 6 obtains the kickstart trees for creating a new system. New systems access these kickstart trees over a network to use as base content for their installation. Red Hat Satellite 6 also contains some predefined kickstart templates (and the ability to create your own), which are used to provision new systems and customize the installation.
- ISO and KVM Images
- Red Hat Satellite 6 downloads and manages media for installation and provisioning. For example, Satellite downloads, stores and manages ISO images and KVM guest images for specific Red Hat Enterprise Linux versions.
- Puppet Modules
- Red Hat Satellite 6 offers the ability to upload Puppet modules alongside RPM content so that it can configure the system’s state after provisioning. Users can also manage Puppet classes and parameters as part of the provisioning process.
- Container Images
- Red Hat Satellite 6 can act as a registry for container images. This provides a method to create containers using Red Hat Enterprise Linux Atomic Host.
- OSTree
- Red Hat Satellite 6 can import OSTree branches and publish this content to a HTTP location.
1.4. Defining our Scenario
This guide uses an example scenario to demonstrate Red Hat Satellite 6’s features. In this scenario, a software development company called ACME recently installed Red Hat Satellite 6 and its system administrators want to start importing and managing Red Hat content. The end goal for ACME is to:
- Have a set of content sources imported for their organization. This includes content from their Red Hat subscription and their own custom content.
- Have an application life cycle defined based on their software development process.
- Have their Satellite Server ready so they can provision new Red Hat Enterprise Linux hosts and register existing Red Hat Enterprise Linux hosts.
This guide only focuses on content management. Further features, such as host provisioning, environment architecture, and Satellite Server management, are covered in other guides in the Red Hat Satellite 6 series.
This guide provides both steps for using either the Red Hat Satellite 6 Web UI or its CLI tool (hammer
). Use either depending on your preferred method of interacting with Red Hat Satellite 6. If using the CLI and do not want to include authentication details each time you enter a hammer
command, create a CLI configuration file for the local user:
# mkdir ~/.hammer # cat > .hammer/cli_config.yml <<EOF :foreman: :host: 'https://satellite.example.com/' :username: 'admin' :password: 'p@55w0rd!' EOF
All uses of the hammer
command in this guide use the configuration file and omit the authentication details.
Some CLI commands can use the --async
option to perform certain tasks asynchronously. For example, you can synchronize content and publish Content Views as a asynchronous task rather than monitoring it. This guide omits the --async
so that users can monitor progress of tasks to completion. If including the --async
option for certain tasks, ensure the task completes before moving on to the next task.
1.5. Defining Content Management Storage
Red Hat Satellite 6 hosts repositories for RPM and Puppet content, including content synchronized with Red Hat’s Content Delivery Network and your own custom repositories. Such repositories grow in size over time. This means you must estimate adequate size requirements to suit your environment and scale future requirements accordingly.
Red Hat Satellite 6 stores and manages repository content in /var/lib/pulp
. It is recommended to mount this directory onto a large local partition that you can scale. For example, use Logical Volume Manager (LVM) to create this partition.
Do not mount /var/lib/pulp
on an NFS share. Parts of Red Hat Satellite 6 use transient SQLite databases, which have issues over NFS. If you aim to use an NFS share, only mount the /var/lib/pulp/content
directory, which contains the main source content units. Red Hat recommends the use of high-bandwidth, low-latency storage for the /var/lib/pulp
file system. Red Hat Satellite has many operations that are I/O-intensive so usage of high-latency, low-bandwidth storage could result in performance degradation.
Red Hat Satellite 6 synchronize and stores packages from Red Hat’s Content Delivery Network. This includes repositories for Red Hat Enterprise Linux and other Red Hat software. The recommended storage requirements for Red Hat content are as follows:
During Production Phase 1 of a major Red Hat Enterprise Linux version:
- At least 40GB for each binary package repository
- At least 80GB for each debug-info repository
After Production Phase 1 of a major Red Hat Enterprise Linux version:
- The estimated annual growth rates of these repositories are 10GB per binary package repository and 20GB per debug-info repository
For more information about Red Hat Production Phases, see "Red Hat Enterprise Linux Life Cycle".
All repositories vary in size. These specifications are recommendations and must be adjusted according to the repositories you want to synchronize.
Red Hat Satellite 6 provides users with the ability to create Content Views. Content Views act as a snapshot of a user-defined content collection at a particular point in time. This provides a means to create customized content collections from preexisting repositories.
Each unit of content in a Content View uses a symbolic link to the Definitive Media Library stored in the /var/lib/pulp/content
directory. In addition, each repository in a Content View contains metadata about the content belonging to the Content View. This means a Content View using a minimal number of packages uses a small amount of storage. However, the storage size adds up when you use multiple Content Views and a large number of packages per view.
For example, a Content View using the Red Hat Enterprise Linux 7 RPMs repository might contain over 7000 packages. In terms of disk space, this might only result in less than 100MB of symbolic links. However, take into account the following:
- The number of Content Views containing this repository
- The number of versions per Content View
- The number of life cycle environments using the promoted view
- Any additional content, such as kickstart trees or Live CD content
To help reduce the amount of storage that Content Views consume, use the following recommendations:
- Remove unused versions of Content Views. If you are not using a Content View in a life cycle environment and you have no intention of reusing it, delete it to reclaim the storage used.
- Use filters in Content Views. Filters limit the content that appears in a Content View. This helps you define only the necessary content required for your view and excludes redundant content. This reduces the size of each Content View significantly.
-
Monitor the
/var/lib/pulp/nodes
directory. Red Hat Satellite 6 uses this directory to construct Content Views. -
Monitor the
/var/lib/pulp/published
directory. Red Hat Satellite 6 uses this directory to publish Content Views.
Red Hat Satellite 6 also uses the following databases for its content management components:
-
Main database - PostgreSQL database stored in
/var/lib/pgsql
. The storage requirements depend on a number of factors including organizations, environments, registered systems, and Content Views. -
Content database - MongoDB database stored in
/var/lib/mongodb
. The storage requirements depend on the number of packages and Content Views for your Red Hat Satellite 6 environment. This usually takes a large amount of storage. Reserve at minimum 10GB for the Content database and plan for an estimated 5GB per repository. It is recommended to mount this directory onto a large local partition that you can scale. For example, use Logical Volume Manager (LVM) to create this partition.
Do not mount /var/lib/mongodb
on an NFS share. Red Hat recommends the usage of high-bandwidth, low-latency storage for the /var/lib/mongodb
file system. Red Hat Satellite has many operations that are I/O-intensive so usage of high-latency, low-bandwidth storage could result in performance degradation.
1.6. Chapter Summary
In this chapter, we explored the base concept of content management in the context of Red Hat Satellite 6. This includes defining phases of the Red Hat Satellite 6 application life cycle and the different types of content that Red Hat Satellite 6 manages. This chapter also defined the scope of our example scenario and provided storage requirements to suit your content management needs.
The next chapter looks at creating organizations to store content.