Satellite 6.1 Docker Management and Workflow

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

One of the first things you will want to do, after coming up to speed with Docker, is probably setup a Registry Server. The Docker project provides a basic Registry Server which people often set up for sharing images in their organization. This is a good starting place, but many organizations quickly outgrow this registry server. Often, administrators and release engineers want more control and better governance around versioning and authentication.

With Satellite 6.1 and the Docker Plugin, this is a snap. The Docker Plugin is installed out of the box and only takes minutes to configure. The Docker plugin is quite flexible and allows a user to consume upstream content from the Red Hat Registry, Docker Hub, and internal Registries. It even allows administrators to pull images from Content View.

Content Views give developers and administrators a way to quickly move Docker images through a controlled Dev/QA/Prod development lifecyle and can even help facilitate a Continuous Integration/Continuous Deployment lifecycle.

Since the Docker plugin leverages the modern design of Satellite 6.1 as a framework, the user is provided with some very desirable capabilities:

• Enterprise on premise registry
• LDAP/AD integration
• Provisioning
• Auditing
• Graphical User Interface (GUI)
• Command Line Interface (CLI) and REST
• Easy to deploy and manage
• Role Based Access Controls (RBAC)
• Security

Quick Walkthrough

The goal of this walk through is to show how with a few commands, you can have an enterprise on premise registry setup and running. This walk through will use Content View and a standard Life Cycle Path with the following workflow:

Add an External Registry Server

First we are going to add a simple external Registry in Satellite. This is a simple pass through. When container hosts are provisioned, they will pull their data directly from the external registry server but everything will be controlled and audited from within Satellite.

For this example, we are going to connect to the official Red Hat Registry, but Satellite can be configured to pull content from any upstream registry server, internal or external. From the web interface, users can even search the external registry for content.

Containers -> Registries -> New Registry

Once added, it will be listed under Registries:

Containers -> Registries

Add a Content View & Life Cycle

Next, let's add all of the necessary data structures within Satellite to leverage Content Views. All of this can be done with just a few commands, making it easy to setup a new Satellite Server.

Leveraging Content Views synchronized data to the Satellite server which simplifies firewall rules and provides a single point of demarcation between the internal and external world:

Create Product & Repo

hammer product create --name='Containers' --organization='Default Organization'
hammer repository create --name='rhel' --organization='Default Organization' --product='Containers' --content-type='docker' --url='https://registry.access.redhat.com' --docker-upstream-name='rhel' --publish-via-http="true"
hammer product synchronize --organization='Default Organization' --name='Containers'

Create Content View, Add Repository & Publish

hammer content-view create --organization='Default Organization' --name "Production Registry" --description "Production Registry"
hammer content-view add-repository --organization "Default Organization" --name "Production Registry" --repository "rhel" --product "Containers"
hammer content-view publish --organization='Default Organization' --name "Production Registry"

Promote Content View

hammer content-view version promote --organization 'Default Organization' --to-lifecycle-environment Development --content-view "Production Registry" --async
hammer content-view version promote --organization 'Default Organization' --to-lifecycle-environment QA --content-view "Production Registry" --async
hammer content-view version promote --organization 'Default Organization' --to-lifecycle-environment Production --content-view "Production Registry" --async

Add a Compute Resource

Now we are going to add a RHEL 7 or RHEL 7 Atomic host to be managed by the Satellite Server. First we need to configure the Docker Daemon to allow remote access to the API. This is not secure, so don't do it in production without restricting access to the Satellite server with firewall rules.

vi /etc/sysconfig/docker

Now modify the OPTIONS Line to look like this. Notice the debug configuration. This is not mandatory but will definitely help if you run into trouble.

OPTIONS='--selinux-enabled -H unix:///var/run/docker.sock -H tcp://0.0.0.0:4243 --debug=true'

Now add the Satellite Servers Certificate

curl http://sat6-rhel7.crunchtools.com/pub/katello-server-ca.crt > /etc/pki/ca-trust/source/anchors/katello-server-ca.crt
update-ca-trust

Now create the compute resource in Satellite

hammer compute-resource create --organizations 'Default Organization' --locations 'Default Location' --provider docker --name atomic7.crunchtools.com --url http://atomic7.crunchtools.com:4243

You are now done with all of the configuration. Let's get on to deploying containers!

Provision Containers

In this section we are going to demonstrate how to provision a container from DockerHub, an External Registry Server and from a Content View. It is important to understand that when provisioning from DockerHub or an external Registry, the container will be deployed with the content directly from the upstream registry server. There is no temporal control (aka snapshot) of the content.

DockerHub -> Satellite -> Container
External Registry -> Satellite -> Container

With a Content View, you can still pull content from an upstream registry server, but you have the advantage of finer grained control over which images can be deployed where. You can have newer versions of the same repository in Development and QA, with fully tested versions in Production. With Satellite you get all of this in a single server.

At first, you might say to yourself, well I can do that with Docker Tags right? While life cycle management could be done with good policy and Docker Tags, Content Views provide the technical controls and adhere to the principals of infrastructure as code. Administrators control which versions of a repository are available instead of relying on easily outdated documentation.

Users can't pull newer or older versions by mistake. In fact the administrator has complete control over which sets of data container hosts receive based solely on the URL they connect to. As will be seen later in the Docker Tags section, there are separate unique URLS for Development, QA and Production. This is very convenient when coordinating between developer's laptops and server running in production.

In the following example, the Satellite server is really acting like three different registry servers (Development/QA/Production).

DockerHub -> Satellite (Development -> QA -> Production) -> Container
External Registry -> Satellite (Development -> QA -> Production) -> Container

OK, now that you understand the concepts, let's get started....

Provision a Container From Docker Hub

This pulls the latest Fedora image from the upstream Docker.io Registry server:

hammer docker container create \
--organizations 'Default Organization' \
--locations 'Default Location' \
 --compute-resource atomic7.crunchtools.com \
--repository-name docker.io/fedora \
--tag latest \
--name fedoratest \
--command bash

Provision Container from External Registry

OK, now it's time to provision a container from the external registry server we created:

hammer docker container create \
--organizations 'Default Organization' \
--locations 'Default Location' \
 --compute-resource atomic7.crunchtools.com \
--registry-id 1 \
--repository-name rhel \
--tag latest \
--name bashtest \
--command bash

Provision Container from Content View

Now it's time to show the real power of Satellite Server. From the web interface, at step two, you simply select the Content View you want to deploy from.

Containers -> New Container

When deploying from the command line we must first get the URL of the repository we want to pull from. In this case we are going to pull the "rhel" repository from the Production life Cycle Environment:

hammer repository info --id `hammer repository list --content-type docker --organization 'Default Organization' --content-view "Production Registry" --environment Production | grep docker | grep rhel | awk '{print $1}'`

The output looks like the following. Notice the piece of information we are after is the "Published At:" section. We are going to use the default_organization-production-production_registry-containers-rhel portion to provision the container from within Satellite, but developers can use the full URL when pulling images down to their laptops!

ID:                 18
Name:               rhel
Label:              rhel
Organization:       Default Organization
Red Hat Repository: no
Content Type:       docker
URL:                
Publish Via HTTP:   yes
Published At:       sat6-rhel7.crunchtools.com:5000/default_organization-production-production_registry-containers-rhel
Product:            
    ID:   3
    Name: Containers
GPG Key:            

Sync:               
    Status:
Created:            2015/07/07 19:42:54
Updated:            2015/07/07 19:42:54
Content Counts:     
    Docker Images: 6
    Docker Tags:   7

And voila, we can provision any tag we want from the Production Version of the Content View. This is very powerful in allowing developers to pull the same controlled content that is in production.

hammer docker container create \
--organizations 'Default Organization' \
--locations 'Default Location'  \
--compute-resource atomic7.crunchtools.com \
--repository-name "default_organization-production-production_registry-containers-rhel" \
--tag "7.1-9" \
--name rhelcvtest3 \
--command bash

List Containers

Now list the containers that were created

hammer docker container list

scotttest2          | rhel                                                                | latest | bash    | atomic7.crunchtools.com
bashtest            | rhel                                                                | latest | bash    | atomic7.crunchtools.com
fedoratest          | docker.io/fedora                                                    | latest | bash    | atomic7.crunchtools.com
rhelcvtest          | rhel                                                                | latest | bash    | atomic7.crunchtools.com
rhelcontentviewtest | default_organization-production-production_registry-containers-rhel | 7.1-6  | bash    | atomic7.crunchtools.com
rhelcvtest2         | default_organization-production-production_registry-containers-rhel | latest | bash    | atomic7.crunchtools.com
rhelcvtest3         | default_organization-production-production_registry-containers-rhel | 7.1-9  | bash    | atomic7.crunchtools.com

Docker Tags

One final really cool feature is the Docker Tags page. From this page administrators and developers can list all of the docker tags and associated URLs. Notice the Published At column. Administrators can share these URLs so that users can pull certain versions of content directly to their laptops for development and testing.

From within the web interface:

Content -> Docker Tags
  

Conclusion

We demonstrated how easy it is to deploy an on premise, enterprise registry server with Red Hat Satellite 6.1 and the Docker plugin. Workflows are quick and easy to setup with a powerful command line interface (CLI). The choice of the CLI or web interface makes it easy to provision and manage containers long term. The foundations provided in this article will arm administrators, release engineers, and developers with workflows they can rely on for years to come.

Future articles will go deeper into how to build a production ready workflow between developers and systems administrators.