Overview, concepts, and deployment considerations

Content flow in Red Hat Satellite involves management and distribution of content from external sources to hosts.

Content in Satellite flows from external content sources to Satellite Server. Capsule Servers mirror the content from Satellite Server to hosts.

View larger image

A content view is a deliberately curated subset of content that your hosts can access. By creating a content view, you can define the software versions used by a particular environment or Capsule Server.

Each content view creates a set of repositories across each environment. Your Satellite Server stores and manages these repositories. For example, you can create content views in the following ways:

Application lifecycles are divided into lifecycle environments which represent each stage of the application lifecycle. By linking lifecycle environments, you create an environment path.

You can promote content along the environment path to the next lifecycle environment when required. When you promote a content view from one environment to the next environment in the application lifecycle, Satellite updates the repository and publishes the packages. For example, if development ends on a particular version of an application, you can promote this version to the testing environment and start development on the next version.

Figure 1.1. An environment path containing four environments

View larger image

With Red Hat Satellite, you can import and manage many content types. You can use Red Hat content as well as custom content and organize it into Satellite products.

For example, Satellite supports the following content types:

With Red Hat Satellite, you can provision hosts by using the following methods.

Satellite Server is the central component of a Satellite deployment where you plan and manage the content lifecycle.

A typical Satellite deployment includes one Satellite Server on which you perform the following operations:

Satellite Server delegates content distribution, host provisioning, and communication to Capsule Servers. Satellite Server itself also includes a Capsule.

Satellite Server also contains a fine-grained authentication system. You can grant Satellite users permissions to access precisely the parts of the infrastructure for which they are responsible.

With Capsule Servers, you can extend the reach and scalability of your Satellite deployment. Capsule Servers provide the following functionalities in a Red Hat Satellite deployment:

By using content views, you can specify the exact subset of content that Capsule Server makes available to hosts. For more information, see Section 1.1, “Content and patch management with Red Hat Satellite”.

A host is any Linux client that Red Hat Satellite manages. Hosts can be physical or virtual.

You can deploy virtual hosts on any platform supported by Red Hat Satellite, such as Amazon EC2, Google Compute Engine, KVM, libvirt, Microsoft Azure, OpenStack, Red Hat Virtualization, Rackspace Cloud Services, or VMware vSphere.

With Satellite, you can manage hosts at scale, including monitoring, provisioning, remote execution, configuration management, software management, and subscription management.

Satellite consists of several open source projects integrated with each other, such as the following:

Capsule Servers provide local host management services and can mirror content from Satellite Server.

To mirror content from Satellite Server, Capsule provides the following functionalities:

You can use Capsule to run the following services for infrastructure and host management:

You can configure a Capsule Server for a specific limited purpose by enabling only selected features on that Capsule. Common configurations include the following:

The communication between Satellite Server and hosts registered to a Capsule Server is routed through that Capsule Server. Capsule Server also provides Satellite services to hosts.

Many of the services that Capsule Server manages use dedicated network ports. However, Capsule Server ensures that all communications from the host to Satellite Server use a single source IP address, which simplifies firewall administration.

Figure 1.2. How Satellite components interact when hosts connect to a Capsule

View larger image

Figure 1.3. How Satellite components interact when hosts connect directly to Satellite Server

View larger image

On your Satellite Server, you can define organizations and locations to help organize content, hosts, and configurations. Organizations and locations enable you to arrange Satellite resources into logically structured groups. For example, you can create groups based on ownership, purpose, content, or security level. You can create and manage multiple organizations through Red Hat Satellite, then divide and assign your Red Hat subscriptions to each individual organization.

Satellite Server defines all locations and organizations. Each Capsule Server synchronizes content and handles configuration of hosts in a different location.

Your Satellite Server retains the management function, while the content and configuration is synchronized between your Satellite Server and Capsule Servers assigned to certain locations.

A host group acts as a template for common host settings.

With host groups, you can define many settings for hosts, such as lifecycle environment, content view, or Ansible roles that are available to the hosts. Instead of defining the settings individually for each host, you can use host groups to define common settings once and apply them to multiple hosts.

You can create nested host groups.

A host collection is a group of content hosts.

With host collections, you can perform the same action on multiple hosts at once. These actions include installing, removing, and updating packages and errata, and assigning content view environments.

For example, you can use host collections to group hosts by function, department, or business unit.

You can manage and monitor your Satellite infrastructure from a browser with the Satellite web UI. For example, you can use the following navigation features in the Satellite web UI:

You can configure and manage your Satellite Server with CLI commands by using Hammer.

Using Hammer has the following benefits:

To issue Hammer commands, a user must have access to your Satellite Server.

In the background, each Hammer command first establishes a binding to the API, then sends a request. This can have performance implications when executing a large number of Hammer commands in sequence. In contrast, scripts that use API commands communicate directly with the Satellite API and they establish the binding only once.

You can write custom scripts and external applications that access the Satellite API over HTTP with the Representational State Transfer (REST) API provided by Satellite Server. Use the REST API to integrate with enterprise IT systems and third-party applications, perform automated maintenance or error checking tasks, and automate repetitive tasks with scripts.

Using the REST API has the following benefits:

Scripts based on API commands communicate directly with the Satellite API, which makes them faster than scripts based on Hammer commands or Ansible Playbooks relying on modules within redhat.satellite.

With remote execution, you can run jobs on hosts from Capsules by using shell scripts or Ansible roles and playbooks.

Use remote execution for the following benefits in Satellite:

Communication for remote execution occurs through Capsule Server, which means that Satellite Server does not require direct access to the target host, and can scale to manage many hosts.

To use remote execution, you must define a job template. A job template is a command that you want to apply to remote hosts. You can execute a job template multiple times.

Satellite uses ERB syntax job templates. For more information, see Template Writing Reference in Managing hosts.

By default, Satellite includes several job templates for shell scripts and Ansible.

Satellite Ansible Collection is a set of Ansible modules that interact with the Satellite API. You can use these modules to automate many aspects of Satellite administration.

You can automate the installation process of a Satellite Server or Capsule Server by creating a Kickstart file that contains all the information that is required for the installation.

When you run a Red Hat Satellite Kickstart script, the script performs the following actions:

Usage of all Red Hat Satellite components is supported within the context of Red Hat Satellite only as described below.

You can use the following combinations of major versions of Red Hat Enterprise Linux and hardware architectures for registering and managing hosts with Satellite. The Red Hat Satellite Client 6 repositories are also available for these combinations.

You can use the following combinations of major versions of Red Hat Enterprise Linux and hardware architectures for host provisioning with Satellite.

You can use the following combinations of major versions of Red Hat Enterprise Linux and hardware architectures for configuration management with Satellite.

Note that Puppet agent is currently unavailable for Red Hat Enterprise Linux 10.

Installing an instance of Satellite Server on a dedicated server is the first step to a working Satellite infrastructure. You can install a Satellite Server in a connected or disconnected setup:

A disconnected Satellite Server is isolated from Red Hat CDN but you can still provision systems with the latest security updates, errata, packages, and other content. You can use the following methods to import content to a disconnected Satellite Server:

You can deploy Satellite on Amazon Web Services (AWS) in several scenarios.

View larger image

Site-to-site VPN connection between the AWS region and the on-premises data center

View larger image

Direct connection using the external DNS host name

View larger image

Site-to-site VPN connection between AWS regions

View larger image

Direct connection using the external DNS host name

View larger image

Red Hat Satellite includes native support for authentication with a username and password. If you require additional methods of authentication, configure your Satellite Server to use an external authentication source.

Context in Satellite consists of organizations and locations. You can associate most resources, for example hosts, subnets, and domains, with at least one organization and location context.

Resources and users can generally only access resources within their own context, which makes configuring organizations and locations an integral part of access management in Satellite.

By installing Capsule Servers, you extend the reach and scalability of your Satellite deployment. Setting up a Capsule Server registers the base operating system on which you are installing to Satellite Server and configures the new Capsule Server to provide the required services within your Satellite deployment.

You can install a Capsule Server in each of your geographic locations. By assigning a Capsule to each location, you decrease the load on Satellite Server, increase redundancy, and reduce bandwidth usage.

Decide what services you want to enable on each Capsule Server. You can configure the DNS, DHCP, and TFTP services on one of your Capsule Servers or you can use an external server to provide these services to your Capsule Servers.

A Red Hat subscription manifest is a set of encrypted files that contains your subscription information. Satellite Server uses this information to access the Red Hat CDN and find what repositories are available for the associated subscription.

To ensure that your Satellite Server can manage software and provide it to your hosts, you must create repositories and synchronize them.

Creating repositories allows you to choose the specific software required for your environment. By creating only the necessary repositories, you avoid downloading unnecessary content.

Synchronizing repositories downloads the content from Red Hat CDN or another source to your Satellite Server. The synchronized content is stored on your Satellite Server, eliminating the need for hosts to access the repositories. You can synchronize repositories manually, or you can create a sync plan to ensure synchronization runs on a regular basis.

When defining your content lifecycle in Satellite, you can use content views and lifecycle environments to define which hosts can access which content and content versions. By default, Satellite includes the Default Organization View content view and the Library lifecycle environment.

In smaller deployments or when you do not require content versioning and environment promotion, you can associate a host to the Library environment under the Default Organization View without configuring additional lifecycle environments.

Users in Satellite can have one or more roles assigned. These roles are associated with permissions that enable users to perform specified administrative actions in Satellite. Permission filters define the actions allowed for a certain resource type.

Satellite provides a set of predefined roles with permissions sufficient for standard tasks. You can also configure custom roles.

The following types of roles are commonly defined within various Satellite deployments:

After your basic Satellite infrastructure is in place, you can start configuring provisioning to ensure that Satellite can seamlessly create, configure, and manage hosts.

The process depends on whether you want to provision bare-metal hosts, virtual machines, or cloud instances, but it includes defining installation media, configuring provisioning templates, and other tasks. If you are provisioning virtual machines or cloud instances, you must also integrate your compute provider with Satellite by connecting the provider as a compute resource to Satellite.

The following Satellite features support automating the provisioning of your hosts:

Choose a disaster recovery plan that best helps ensure the continuity of Satellite services in your deployment.

Satellite offers a range of additional capabilities that you can use to further enhance your Satellite deployment. For example:

Your infrastructure might require multiple isolated subnets even if Red Hat Satellite is deployed in a single geographic location. This can be achieved for example by deploying multiple Capsule Servers with DHCP and DNS services, but the recommended way is to create segregated subnets using a single Capsule. This Capsule is then used to manage hosts and compute resources in those segregated networks to ensure they only have to access the Capsule for provisioning, configuration, errata, and general management. For more information on configuring subnets, see Managing hosts.

Red Hat recommends to create at least one Capsule Server per geographic location. This practice can save bandwidth since hosts obtain content from a local Capsule Server. Synchronization of content from remote repositories is done only by the Capsule, not by each host in a location. In addition, this layout makes the provisioning infrastructure more reliable and easier to configure.

View larger image

The following section provides general scenarios for deploying content views as well as lifecycle environments.

The default lifecycle environment called Library gathers content from all connected sources. It is not recommended to associate hosts directly with the Library as it prevents any testing of content before making it available to hosts. Instead, create a lifecycle environment path that suits your content workflow. The following scenarios are common:

The following content view scenarios are common:

The optimal solution depends on the nature of your host environment. Avoid creating a large number of content views, but keep in mind that the size of a content view affects the speed of related operations (publishing, promoting). Also make sure that when creating a subset of packages for the content view, all dependencies are included as well. Note that Kickstart repositories should not be added to content views, as they are used for host provisioning only.

If you plan to have more than one Red Hat Network account, or if you want to manage systems belonging to another entity that is also a Red Hat Network account holder, then you and the other account holder can assign subscriptions, as required, to manifests. A customer that does not have a Satellite subscription can create a Subscription Asset Manager manifest, which can be used with Satellite, if they have other valid subscriptions. You can then use the multiple manifests in one Satellite Server to manage multiple organizations.

If you must manage systems but do not have access to the subscriptions for the RPMs, you must use Red Hat Enterprise Linux Satellite Add-On. For more information, see Satellite Add-On.

The following diagram shows two Red Hat Network account holders, who want their systems to be managed by the same Satellite installation. In this scenario, Example Corporation 1 can allocate any subset of their 60 subscriptions, in this example they have allocated 30, to a manifest. This can be imported into the Satellite as a distinct Organization. This allows system administrators the ability to manage Example Corporation 1’s systems using Satellite completely independently of Example Corporation 2’s organizations (R&D, Operations, and Engineering).

Figure 2.1. Satellite Server with multiple manifests

View larger image

When creating a Red Hat subscription manifest:

Red Hat Satellite allows the use of future-dated subscriptions in the manifest. This enables uninterrupted access to repositories when future-dated subscriptions are added to a manifest before the expiry date of existing subscriptions.

Note that the Red Hat subscription manifest can be modified and reloaded to Satellite Server in case of any changes in your infrastructure, or when adding more subscriptions. Manifests should not be deleted. If you delete the manifest from the Red Hat Customer Portal or in the Satellite web UI it will unregister all of your content hosts.

The fact that host groups can be nested to inherit parameters from each other allows for designing host group hierarchies that fit particular workflows. A well planned host group structure can help to simplify the maintenance of host settings. This section outlines four approaches to organizing host groups.

Figure 2.2. Host group structuring examples

View larger image

Red Hat Satellite uses Inter-Satellite Synchronization (ISS) to synchronize content between two Satellite Servers including those that are air gapped.

You can use ISS in cases such as:

There are different ways of using ISS. The way you can use depends on your multi-server setup that can fall to one of the following scenarios.

2.2.6.1. ISS network sync in a disconnected scenario

Copy link

In a disconnected scenario, there is the following setup:

• The upstream Satellite Server is connected to the Internet. This server consumes content from the Red Hat Content Delivery Network (CDN) or custom sources.
• The downstream Satellite Server is completely isolated from all external networks.
• The downstream Satellite Server can communicate with a connected upstream Satellite Server over an internal network.

Figure 2.3. Satellite ISS disconnected scenario

View larger image

You can configure your downstream Satellite Server to synchronize content from the upstream Satellite Server over the network.

2.2.6.2. ISS export sync in an air-gapped scenario

Copy link

In an air-gapped scenario, there is the following setup:

• The upstream Satellite Server is connected to the Internet. This server consumes content from the Red Hat CDN or custom sources.
• The downstream Satellite Server is completely isolated from all external networks.
• The downstream Satellite Server does not have a network connection to a connected upstream Satellite Server.

Figure 2.4. Satellite ISS air-gapped scenario

View larger image

The only way for an air-gapped downstream Satellite Server to receive content updates is by exporting payload from the upstream Satellite Server, bringing it physically to the downstream Satellite Server, and importing the payload. For more information, see Synchronizing Content Between Satellite Servers in Managing content.

You can configure your downstream Satellite Server to synchronize content by using exports.

Preboot execution environment (PXE) provides the ability to boot a system over a network. Instead of using local hard drives or a CD-ROM, PXE uses DHCP to provide host with standard information about the network, to discover a TFTP server, and to download a boot image. For more information about setting up a PXE server see the Red Hat Knowledgebase solution How to set-up/configure a PXE Server.

You can use HTTP booting to boot systems over a network using HTTP.