Chapter 1. Introduction to Red Hat Satellite

Red Hat Satellite 6 is the evolution of Red Hat's life cycle management platform. It provides the capabilities that administrators have come to expect in a tool focused on managing systems and content for a global enterprise. Satellite 6 covers the use cases requested by Satellite 5 customers, but also includes functionality that enables larger scale, federation of content, better control of systems during the provisioning process, and a much more simplified approach to life cycle management. Satellite 6 also further evolves the inherent approach to certificate-based entitlements and integrated subscription management. Satellite 6 is based on years of customer feedback and is an evolution of previous versions.

1.1. Red Hat Satellite 6 System Architecture

The following diagram represents the high-level architecture of Red Hat Satellite 6.
Red Hat Satellite 6 System Architecture

Figure 1.1. Red Hat Satellite 6 System Architecture

There are four stages through which content flows in this architecture:
External Content Sources
The Red Hat Satellite Server can consume diverse types of content from various sources. The required connection is the one with Red Hat Customer Portal, which is the primary source of software packages, errata, Puppet modules, and container images. In addition, you can use other supported content sources (Git repositories, Docker Hub, Puppet Forge, SCAP repositories) as well as your organization's internal data store.
Red Hat Satellite Server
The Red Hat Satellite Server enables you to plan and manage the content life cycle and the configuration of Capsule Servers and hosts through GUI, CLI, or API.
The Satellite Server organizes the life cycle management by using organizations as principal division units. Organizations isolate content for groups of hosts with specific requirements and administration tasks. For example, the OS build team can use a different organization than the web development team.
The Satellite Server also contains a fine-grained authentication system to provide Satellite operators with permissions to access precisely the parts of the infrastructure that lie in their area of responsibility.
Capsule Servers
Capsule Servers mirror content from the Satellite Server to establish content sources in various geographical locations. This allows host systems to pull content and configuration from the Satellite Capsule Servers in their location and not from the central Satellite Server. The recommended minimal number of Capsule Servers is therefore given by the number of geographic regions where the organization that uses Satellite operates.
Using Content Views, you can specify the exact subset of content that the Capsule Server makes available to hosts. See Figure 1.2, “Content Life Cycle in Red Hat Satellite 6” for a closer look at life cycle management with the use of Content Views.
The communication between managed hosts and the Satellite Server is routed through the Capsule Server that can also manage multiple services on behalf of hosts. Many of these services use dedicated network ports, but the Capsule Server ensures that a single source IP address is used for all communications from the host to the Satellite Server, which simplifies firewall administration.
Managed Hosts
Hosts are the recipients of content from Capsule Servers. Hosts can be either physical or virtual (deployed on KVM, VMware vSphere, OpenStack, Amazon EC2, Rackspace Cloud Services, Google Compute Engine, or in a Docker container). The Satellite Server can have directly managed hosts. The base system running a Capsule Server is also a managed host of the Satellite Server.
The following diagram provides a closer look at the distribution of content from the Satellite Server to Capsules.
Content Life Cycle in Red Hat Satellite 6

Figure 1.2. Content Life Cycle in Red Hat Satellite 6

By default, each organization has a Library of content from external sources. Content Views are subsets of content from the Library created by intelligent filtering. You can publish and promote Content Views into life cycle environments (typically Dev, QA, and Production). When creating a Capsule Server, you can choose which life cycle environments will be copied to that Capsule and made available to managed hosts.
Content Views can be combined to create Composite Content Views. For example, it is beneficial to have a separate Content View for packages required by an operating system and a separate one for packages required by an application. Which Content Views should be promoted to which Capsule Server depends on the Capsule's intended functionality. Any Capsule Server can run DNS, DHCP, and TFTP as infrastructure services that can be supplemented, for example, with content or configuration services.
You can update the Capsule Server by creating a new version of a Content View using synchronized content from the Library. The new Content View version is then promoted through life cycle environments. You can also create in-situ updates of Content Views, which means that a minor version of the Content View is created in its current life cycle environment without promoting it from the Library.