Deploying Red Hat Satellite on Amazon Web Services

Red Hat Satellite 6.7

Reference guide for deploying Red Hat Satellite Server and Capsules on Amazon Web Services

Red Hat Satellite Documentation Team

Abstract

Use this guide to deploy Red Hat Satellite Server and Capsules on Amazon Web Services (AWS) Elastic Compute Cloud (Amazon EC2).

Chapter 1. Use Case Considerations

Because Amazon Web Services is an image-only service, there are common Satellite use cases that do not work, or require extra configuration in an Amazon Web Service environment. If you plan to use Satellite on AWS, ensure that the use case scenarios that you want to use are available in an AWS environment.

1.1. Use Cases Known to Work

You can perform the following Red Hat Satellite use cases on AWS:

Subscriptions

Not all Red Hat subscriptions are eligible to run in public cloud environments. For more information about subscription eligibility, see the Red Hat Cloud Access Page. You can create additional organizations and then import additional manifests to the organizations. For more information, see Creating an Organization in the Content Management Guide.

Multi-homed Satellite and Capsule

Multi-homed Satellite is not supported.

Multi-homed Capsule is supported, to implement this, you can configure Capsules with a load balancer. For more information, see Configuring Capsules with a Load Balancer.

You must do this when Satellite Server or Capsule Server has different internal and external DNS host names and there is no site-to-site VPN connection between the locations where you deploy Satellite Server and Capsule Server.

On demand content sources

You can use the On demand download policy to reduce the storage footprint of the Red Hat Enterprise Linux server that runs Satellite. When you set the download policy to On Demand, content syncs to the Satellite Server or Capsule Server when a content host requests it.

For more information, see Importing Red Hat Content in the Content Management Guide.

1.2. Use Cases that Do Not Work

In AWS, you cannot manage the DHCP. Because of this, most of Satellite Server’s kickstart and PXE provisioning models are unusable. This includes:

  • PXE Provisioning
  • Discovery and Discovery Rules
  • ISO Provisioning methods.

    • PXE-Less Discovery (iPXE)
    • Per-host ISO
    • Generic ISO
    • Full-host ISO

Chapter 2. Deployment Scenarios

There are three deployment scenarios for Red Hat Satellite in Amazon Web Services:

  1. One region setup
  2. Connecting on-premise and AWS region
  3. Connecting different regions

Scenario 1: One region setup

aws image1

The least complex configuration of Satellite Server in Amazon Web Services consists of both the Satellite Server and the content hosts residing within the same region and within the Virtual Private Cloud (VPC).

You can also use a different availability zone.

Scenario 2: Connecting on-premise and AWS region

Create a VPN connection between the on-premise location and the AWS region where the Capsule resides.

It is also possible to use the external host name of Satellite Server when you register the instance which runs Capsule Server.

Option 1: Site-to-Site VPN connection between the AWS region and the On-Premise Datacenter

aws image2

Option 2: Direct connection using the External DNS host name

aws image3

Scenario 3: Connecting different regions

Create a site-to-site VPN connection between the different regions so that you can use the Internal DNS host name when you register the instance that runs Capsule Server to the Satellite Server.

If you do not establish a site-to-site VPN connection, use the external DNS host name when you register the instance that runs Capsule Server to the Satellite Server.

Note

Most Public Cloud Providers do not charge for data being transferred into a region, or between availability zones within a single region; however, they do charge for data leaving the region to the Internet.

Option 1: Site-to-Site VPN connection between AWS regions

aws image4

Option 2: Direct connection using the External DNS host name

aws image5

Chapter 3. Prerequisites

Before you can install and register Red Hat Satellite and Capsule, you must set up accounts with Amazon Web Services (AWS) and create and start Red Hat Enterprise Linux instances on AWS.

3.1. Amazon Web Service Assumptions

To use this guide, you must have a working knowledge of the following aspects of Amazon Web Services:

  • Creating and accessing Red Hat Enterprise Linux images in AWS
  • Editing network access in AWS Security
  • Creating EC2 instances and how to create EBS volumes
  • Launching instances
  • Importing and exporting virtual machines in AWS.
  • Using AWS Direct Connect

To install Satellite in an AWS environment, you must ensure that your AWS set up meets the System Requirements in Installing Satellite Server from a Connected Network.

To install Capsule in an AWS environment, you must ensure that your AWS set up meets the System Requirements in Installing Capsule Server.

For more information about Amazon Web Services and terminology, see Amazon Elastic Compute Cloud Documentation.

For more information about Amazon Web Services Direct Connect, see What is AWS Direct Connect?

3.2. Red Hat Cloud prerequisites

To use this guide, you must complete the following steps:

  • Register with Red Hat Cloud Access.
  • Migrate any Red Hat subscriptions that you want to use.
  • Create an AWS instance and deploy a Red Hat Enterprise Linux virtual machine to the instance.
  • Ensure that your subscriptions are eligible for transfer to Red Hat Cloud. For more information, see Red Hat Cloud Access Program Details.

For more information about deploying Red Hat Enterprise Linux in AWS, see How to Locate Red Hat Cloud Access Gold Images on AWS EC2.

3.3. Red Hat Satellite-specific prerequisites

  • Ensure that the Amazon EC2 instance type meets or exceeds the System Requirements in Installing Satellite Server from a Connected Network. For the best performance, use an AWS Storage Optimized instance.
  • Use Storage Requirements in Installing Satellite Server from a Connected Network to understand and assign the correct storage to your AWS EBS volumes.
  • Store the synced content on an EBS volume that is separate to the boot volume.
  • Mount the synced content EBS volume separately in the operating system.
  • Optional: store other data, for example, the mongodb directory on a separate EBS volume.
  • If you want the Satellite Server and Capsule Server to communicate using external DNS hostnames, open the required ports for communication in the AWS Security Group that is associated with the instance.

3.4. Preparing for the Red Hat Satellite Installation

In your AWS environment, complete the following steps:

  1. Launch an EC2 instance of a Red Hat Enterprise Linux AMI.
  2. Connect to the newly created instance.
  3. If you use a Red Hat Gold Image, remove the RHUI client and set the enabled parameter in the product-id.conf to 1.

    # yum remove -y rh-amazon-rhui-client*
    # yum clean all
    # cat << EOF > /etc/yum/pluginconf.d/product-id.conf
    > [main]
    > enabled=1
    > EOF

Chapter 4. Installing Satellite Server on AWS

On your AWS environment, complete the following steps:

  1. Connect to the new instance.
  2. Use Installing Satellite Server from a Connected Network to install Satellite Server.

Chapter 5. Installing Capsule on AWS

On your AWS environment, complete the following steps:

  1. Connect to the new instance.
  2. Install Capsule Server. For more information, see Installing Capsule Server.

Chapter 6. Registering Hosts to Satellite Using The Bootstrap Script

When you install Satellite Server and Capsule Server, you must then register the content hosts on EC2 instances to Satellite with the bootstrap script.

For more information about using the bootstrap script, see Registering Hosts to Red Hat Satellite Using The Bootstrap Script in the Managing Hosts guide.

Install the Katello Agent. For more information, see Installing the katello Agent.

Note that the Katello agent is deprecated and will be removed in a future Satellite version. Migrate your workloads to use the remote execution feature to update clients remotely. For more information, see Host Management Without Goferd and Katello Agent in the Managing Hosts Guide.

Legal Notice

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.