Linux Containers have emerged as a key open source application packaging and delivery technology, combining lightweight application isolation with the flexibility of image-based deployment methods.

Red Hat Enterprise Linux implements Linux Containers using core technologies such as Control Groups (Cgroups) for Resource Management, Namespaces for Process Isolation, SELinux for Security, enabling secure multi-tenancy and reducing the risk of security exploits. All this is meant to provide you with an environment for producing and running enterprise-quality containers.

Red Hat OpenShift provides powerful command-line and Web UI tools for building, managing and running containers in units referred to as pods. However, sometimes you might want to build and manage individual containers and images outside of OpenShift. Some tools provided to perform those tasks that run directly on RHEL systems are described in this guide.

Unlike other container tools implementations, tools described here do not center around the monolithic Docker container engine and docker command. Instead, we provide a set of command-line tools that can operate without a container engine. These include:

Because these tools are compatible with the Open Container Initiative (OCI), they can be used to manage the same Linux containers that are produced and managed by Docker and other OCI-compatible container engines. However, they are especially suited to run directly on Red Hat Enterprise Linux, in single-node use cases.

For a multi-node container platform, see OpenShift. Instead of relying on the single-node, daemonless tools described in this document, OpenShift requires a daemon-based container engine. Please see Using the CRI-O Container Engine for details.

While this guide introduces you to container tools and images, see Managing Containers for more details on those tools.

If you are still interested in using the docker command and docker service, refer to Using the docker command and service for information on how to use those features in RHEL 7.

Containers provide a means of packaging applications in lightweight, portable entities. Running applications within containers offers the following advantages:

Currently, you can run containers on Red Hat Enterprise Linux 7 (RHEL 7) Server, Workstation, and Atomic Host systems. If you are unfamiliar with RHEL Atomic Host, you can learn more about it from RHEL Atomic Host 7 Installation and Configuration Guide or the upstream Project Atomic site. Project Atomic produces smaller derivatives of RPM-based Linux distributions (RHEL, Fedora, and CentOS) that is made specifically to run containers in OpenStack, VirtualBox, Linux KVM and several different cloud environments.

This topic will help you get started with containers in RHEL 7 and RHEL Atomic Host. Besides offering you some hands-on ways of trying out containers, it also describes how to:

RHEL 7 supports container-related software for the following architectures:

Not all images available for X86_64 architecture are also available for Power PC 8. Table 1 notes which Red Hat container images are supported on each architecture.

The container-related software repositories that you enable with subscription-manager are different for X86_64 and Power 8 systems. See Table 2 for the repository names to use in place of the X86_64 repository names for Power 8.

To get an environment where you can work with individual containers, you can install a Red Hat Enterprise Linux 7 system. Using the RHEL 7 subscription model, if you want to create images or containers, you must properly register and entitle the host computer on which you build them. When you use yum install within a container to add packages, the container automatically has access to entitlements available from the RHEL 7 host, so it can get RPM packages from any repository enabled on that host.

No container engine (such as Docker or CRI-O) is required for you to run containers on your local system. However, configuration settings in the /etc/containers/registries.conf file let you define access to container registries when you work with container tools such as podman and buildah.

Here are example settings in the /etc/containers/registries.conf file:

[registries.search]
registries = ['registry.access.redhat.com', 'registry.redhat.io', 'docker.io']

[registries.insecure]
registries = []

[registries.block]
registries = []

By default, the podman search command searches for container images from registries listed in the [registries.search]`section of the `registries.conf file in the given order. In this case, podman search looks for the requested image in registry.access.redhat.com, registry.redhat.io, and docker.io, in that order.

To add access to a registry that doesn’t require authentication (an insecure registry), you must add the name of that registry under the [registries.insecure] section. Any registries that you want to disallow from access from your local system need to be added under the [registries.block] section.

At first, root privilege (either as the root user or as a regular user with sudo privilege) was required to work with container tools in RHEL. As of RHEL 7.7, the rootless container feature (currently a Technology Preview) lets regular user accounts work with containers. All container tools described in this document can be run as root user. For restrictions on running these from regular user accounts, see the rootless containers section of the Managing Containers guide.

Using podman, you can run, investigate, start, stop, and remove container images. If you are familiar with the docker command, you will notice that you can use the same syntax with podman to work with containers and container images.

# podman pull <registry>[:<port>]/[<namespace>/]<name>:<tag>

# podman login registry.redhat.io
Username: myusername
Password: ************
Login Succeeded!

# podman pull registry.access.redhat.com/ubi7/ubi
# podman pull registry.access.redhat.com/rhel7/rsyslog

# podman images
REPOSITORY
             TAG        IMAGE ID      CREATED       VIRTUAL SIZE
registry.access.redhat.com/rhel7/rsyslog
             latest     39ec6b2004a3  9 days ago    236 MB
registry.access.redhat.com/ubi7/ubi
             latest     967cb403b7ee  3 days ago     215 MB

# podman images
REPOSITORY                                            TAG    IMAGE ID     CREATED      VIRTUAL SIZE
registry.access.redhat.com/rhel7/rsyslog              latest 39ec6b2004a3 10 days ago  236 MB
registry.access.redhat.com/ubi7/ubi                   latest 967cb403b7ee 10 days ago  215 MB
registry.access.redhat.com/rhscl/postgresql-10-rhel7  1-35   27b15d85ca6b 3 months ago 336 MB

# skopeo inspect docker://registry.access.redhat.com/ubi7/ubi
   {
    "Name": "registry.access.redhat.com/ubi7/ubi",
    "Digest": "sha256:caf8d01ac73911f872d184a73a5e72a1eeb7bba733cbad13e8253b567d16899f",
    "RepoTags": [
        "latest",
        "7.6",
        "7.7"
    ],
    "Created": "2019-08-01T09:29:20.753891Z",
    "DockerVersion": "1.13.1",
    "Labels": {
        "architecture": "x86_64",
        "authoritative-source-url": "registry.access.redhat.com",
        "build-date": "2019-08-01T09:28:54.576292",
        "com.redhat.build-host": "cpt-1007.osbs.prod.upshift.rdu2.redhat.com",
        "com.redhat.component": "ubi7-container",

# podman tag 967cb403b7ee myrhel7

# podman tag 967cb403b7ee myrhel7:7.7

# podman tag 967cb403b7ee jsmith/myrhel7
# podman images | grep 967cb403b7ee
localhost/jsmith/myrhel7             latest  967cb403b7ee   10 days ago  215 MB
localhost/myrhel7                    7.7     967cb403b7ee   10 days ago  215 MB
registry.access.redhat.com/ubi7/ubi  latest  967cb403b7ee   10 days ago  215 MB

# podman save -o myrsyslog.tar registry.access.redhat.com/rhel7/rsyslog
# ls
myrsyslog.tar

# cat myrsyslog.tar | podman import - rhel7/myrsyslog
Getting image source signatures
Copying blob baa75547a1df done
Copying config 6722efbc0c done
Writing manifest to image destination
Storing signatures
6722efbc0ce5591161f773ef6371390965dc54212ac710c7517ee6d55eee6485
# podman images | grep myrsyslog
docker.io/rhel7/myrsyslog   latest  6722efbc0ce5  50 seconds ago   236 MB

# podman rmi rhel-init
7e85c34f126351ccb9d24e492488ba7e49820be08fe53bee02301226f2773293

# podman rmi registry.access.redhat.com/rhel7/rsyslog support-tools
46da8e23fa1461b658f9276191b4f473f366759a6c840805ed0c9ff694aa7c2f
85cfba5cd49c84786c773a9f66b8d6fca04582d5d7b921a308f04bb8ec071205

# podman rmi $(podman images -a -q)
1ca061b47bd70141d11dcb2272dee0f9ea3f76e9afd71cd121a000f3f5423731
ed904b8f2d5c1b5502dea190977e066b4f76776b98f6d5aa1e389256d5212993
83508706ef1b603e511b1b19afcb5faab565053559942db5d00415fb1ee21e96

# podman rmi $(podman images -a -q)
unable to delete eb205f07ce7d0bb63bfe5603ef8964648536963e2eee51a3ebddf6cfe62985f7 (must force) - image is referred to in multiple tags
unable to delete eb205f07ce7d0bb63bfe5603ef8964648536963e2eee51a3ebddf6cfe62985f7 (must force) - image is referred to in multiple tags

# podman rmi -f eb205f07ce7d
eb205f07ce7d0bb63bfe5603ef8964648536963e2eee51a3ebddf6cfe62985f7

Containers represent a running or stopped process spawned from the files located in a decompressed container image. Tools for running containers and working with them are described in this section.

# podman run --rm registry.access.redhat.com/ubi7/ubi cat /etc/os-release
NAME="Red Hat Enterprise Linux Server"
VERSION="7.7 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.7"
PRETTY_NAME="Red Hat Enterprise Linux Server 7.7 (Maipo)"
...

# podman run --rm registry.access.redhat.com/ubi7/ubi ls /root/buildinfo
Dockerfile-ubi7-7.7-99

# podman run --rm registry.access.redhat.com/ubi7/ubi \
    cat /root/buildinfo/Dockerfile-ubi7-7.7-99
FROM sha256:94577870ec362083c6513cfadb00672557fc5dd360e67befde6c81b9b753d06e
RUN mv -f /etc/yum.repos.d/ubi.repo /tmp || :

MAINTAINER Red Hat, Inc.

LABEL com.redhat.component="ubi7-container"
LABEL name="ubi7"
LABEL version="7.7"
...

# podman run --name=mybash -it registry.access.redhat.com/ubi7/ubi /bin/bash
[root@ed904b8f2d5c/]#  yum install nmap
[root@ed904b8f2d5c/]#  ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 00:46 pts/0    00:00:00 /bin/bash
root        35     1  0 00:51 pts/0    00:00:00 ps -ef
[root@49830c4f9cc4/]# exit

# podman ps -a
CONTAINER ID IMAGE                 COMMAND   CREATED        STATUS                PORTS NAMES        IS INFRA
1ca061b47bd7 .../ubi8/ubi:latest   /bin/bash 8 minutes ago  Exited 12 seconds ago       musing_brown false
...

# podman start -ai mybash
[root@ed904b8f2d5c/]#

# podman run --name="log_test" -v /dev/log:/dev/log --rm \
     registry.access.redhat.com/ubi7/ubi logger "Testing logging to the host"
# journalctl -b | grep Testing
Aug 11 18:22:48 rhel76_01 root[6237]: Testing logging to the host

# podman run -d registry.access.redhat.com/rhel7/rsyslog
# podman ps
CONTAINER ID IMAGE          COMMAND         CREATED       STATUS            PORTS NAMES
50e5021715e4 rsyslog:latest /bin/rsyslog.sh 5 seconds ago Up 3 seconds ago  epic_torvalds

# podman ps -a
CONTAINER ID IMAGE           COMMAND    CREATED        STATUS                   PORTS NAMES
86a6f6962042 ubi7/ubi:latest /bin/bash  11 minutes ago Exited (0) 6 minutes ago       mybash

# podman inspect 50e5021715e4
    ...
[
    {
        "Id": "50e5021715e4829a3a37255145056ba0dc634892611a2f1d71c647cf9c9aa1d5",
        "Created": "2019-08-11T18:27:55.493059669-04:00",
        "Path": "/bin/rsyslog.sh",
        "Args": [
            "/bin/rsyslog.sh"
        ],
        "State": {
            "OciVersion": "1.0.1-dev",
            "Status": "running",
            "Running": true,
    ...

# podman inspect --format='{{.NetworkSettings.IPAddress}}' 50e5021715e4
10.88.0.36

# podman inspect --format='{{.State.Pid}}' 50e5021715e4
7544
# ps -ef | grep 7544
root     7544 7531  0 10:30 ?        00:00:00 /usr/sbin/rsyslogd -n
# podman inspect --format='{{.State.StartedAt}}' 50e5021715e4
2019-08-11 18:27:57.946930227 -0400 EDT

# podman start myrhel_httpd
myrhel_httpd

# podman start -a -i agitated_hopper
[root@d65aecc325a4 /]#  exit

# podman stop 74b1da000a11
74b1da000a114015886c557deec8bed9dfb80c888097aa83f30ca4074ff55fb2

# podman kill --signal="SIGHUP" 74b1da000a11
74b1da000a114015886c557deec8bed9dfb80c888097aa83f30ca4074ff55fb2

# podman rm goofy_wozniak

# podman rm clever_yonath furious_shockley drunk_newton

# podman rm $(podman ps -a -q)

Red Hat provides multiple base images that you can use as a starting point for your own images. These images are available through the Red Hat Registry (registry.access.redhat.com and registry.redhat.io) and described in the Red Hat Container Catalog.

For RHEL 7, there are two different versions of each standard, minimal and init base image available. Red Hat also provides a set of Red Hat Software Collections images that you can build on when you are creating containers for applications that require specific runtimes. These include python, php, nodejs, and others.

Although Red Hat does not offer tools for running containers on RHEL 6 systems, it does offer RHEL 6 container images you can use. There are standard (rhel6) and Init (rhel6-init) base image available for RHEL 6, but no minimal RHEL 6 image. Likewise, there are no RHEL 6 UBI images.

UBI images were created so you can build your container images on a foundation of official Red Hat software that can be freely shared and deployed. From a technical perspective, they are nearly identical to legacy Red Hat Enterprise Linux images, which means they have great security, performance, and life cycles, but they are released under a different End User License Agreement. Here are some attributes of Red Hat UBI images:

Although the legacy RHEL base images will continue to be supported, UBI images are recommended going forward. For that reason, examples in the rest of this chapter are done with UBI images.

To find the current set of available Red Hat UBI images, refer to Universal Base Images (UBI): Images, repositories, and packages or search the Red Hat Container Catalog.

To pull UBI images to your system so you can use them with tools such as podman, buildah or skopeo, type the following:

# podman pull registry.access.redhat.com/ubi7/ubi:latest
# podman pull registry.access.redhat.com/ubi7/ubi-minimal:latest

To check that the images are available on your system, type:

# podman images
REPOSITORY                                   TAG    IMAGE ID       CREATED      SIZE
registry.access.redhat.com/ubi7/ubi-minimal  latest  c94a444803e3  8 hours ago  80.9 MB
registry.access.redhat.com/ubi7/ubi          latest  40b488f87628  17 hours ago 214 MB

When pulled in this way, images are available and usable by podman, buildah, skopeo and the CRI-O container image, but they are not available to the Docker service or docker command. To use these images with Docker, you can run docker pull instead.

After you pull a UBI image, you are free to push it to your own registry and share it with others. You can upgrade or add to that image from UBI yum repositories as you like. Here is an example of how to push a UBI image to your own or another third-party repository:

# podman pull registry.redhat.io/ubi7/ubi
# podman tag registry.access.redhat.com/ubi7/ubi registry.example.com:5000/ubi7/ubi
# podman push registry.example.com:5000/ubi7/ubi

While there are few restrictions on how you use this image, there are some restrictions about how you can refer to it. For example, you can’t call that image Red Hat certified or Red Hat supported unless you certify it through the Red Hat Partner Connect Program, either with Red Hat Container Certification or Red Hat OpenShift Operator Certification.

To start a container from a UBI image and run the bash shell in that image (so you can look around inside), do the following (type exit when you are done):

# podman run --rm -it registry.access.redhat.com/ubi7/ubi-minimal:latest /bin/bash
[root@da9213157c51 /]#
# podman run --rm -it registry.access.redhat.com/ubi7/ubi:latest /bin/bash
bash-4.2#

While in the container:

On systems that include the Docker service, you can use docker run instead.

UBI images are built from 100% Red Hat content. These UBI images also provide a subset of Red Hat Enterprise Linux packages which are freely available to install for use with UBI. To add or update software, UBI images are pre-configured to point to the freely available yum repositories that hold official Red Hat RPMs.

To add packages from UBI repos to running UBI containers:

Keep in mind that installing and working with software packages directly in running containers is just for adding packages temporarily or learning about the repos. Refer to the “Build a UBI-based image” for more permanent ways of building UBI-based images.

When you add software to a UBI container, procedures differ for updating UBI images on a subscribed RHEL host or on an unsubscribed (or non-RHEL) system. Those two ways of working with UBI images are illustrated below.

# yum install --disableplugin=subscription-manager bzip2

# yum install zsh

# yum install --enablerepo=rhel-7-server-optional-rpms zsh-html

# microdnf install bzip2

# microdnf install --enablerepo=rhel-7-server-rpms zsh
# microdnf install --enablerepo=rhel-7-server-rpms \
        --enablerepo=rhel-7-server-optional-rpms zsh-html

# yum install bzip2

# microdnf install bzip2

You can build UBI-based container images in the same way you build other images, with one exception. You should disable Red Hat subscriptions when you actually build the images, if you want to be sure that your image only contains Red Hat software that you can redistribute.

Here’s an example of creating a UBI-based Web server container from a Dockerfile with the buildah utility:

RUN microdnf update -y && rm -rf /var/cache/yum
RUN microdnf install httpd -y && microdnf clean all

Red Hat Software Collections offers another set of container images that you can use as the basis for your container builds. These images are built on RHEL standard base images, with some already updated as UBI images. Each of these images include additional software you might want to use for specific runtime environments.

So, if you expect to build multiple images that require, for example, php runtime software, you can use provide a more consistent platform for those images by starting with a PHP software collections image.

Here are examples of Red Hat Software Collections container images built on UBI base images, that are available from the Red Hat Registry (registry.access.redhat.com or registry.redhat.io):

Because these UBI images container the same basic software as their legacy image counterparts, you can learn about those images from the Using Red Hat Software Collections Container Images guide. Be sure to use the UBI image names to pull those images.

Red Hat Software Collections container images are updated every time RHEL base images are updated. Search the Red Hat Container Catalog for details on any of these images. For more information on update schedules, see Red Hat Container Image Updates.

You can download the source code for all UBI base images (excluding the minimal images) by starting up those images with a bash shell and running the following set of commands from inside that container:

      for i in `rpm -qa`
          do
          yumdownloader --source $i
      done

The source code RPM for each binary RPM package is downloaded to the current directory. Because the UBI minimal images include a subset of RPMs from the regular UBI images, running the yumdownloader loop just shown will get you the minimal image packages as well.

Here are a few issues to consider when working with UBI images:

Red Hat partners and customers can request new features, including package requests, by filing a support ticket through standard methods. Non-Red Hat customers do not receive support, but can file requests through the standard Red Hat Bugzilla for the appropriate RHEL product. See also: Red Hat Bugzilla Queue

Red Hat partners and customers can file support tickets through standard methods when running UBI on a supported Red Hat platform (OpenShift/RHEL). Red Hat support staff will guide partners and customers

See also: Open a Support Case

A Web server is one of the most basic examples used to illustrate how containers work. The procedure in this topic does the following:

Here are some tips to help you use the Web Server container:

# ip a | grep docker0 | grep inet
    inet 172.17.42.1/16 scope global docker0

# docker run -d -p 80:80 -v /var/www/html:/var/www/html \
     --name=mywebwithdb webwithdb

Using MariaDB, you can set up a basic database in a container that can be accessed by other applications. The procedure in this topic does the following:

Here are some tips to help you use the Web Server container:

The Docker project was responsible for popularizing container development in Linux systems. The original project defined a command and service (both named docker) and a format in which containers are structured. This chapter provides a hands-on approach to using the docker command and service to begin working with containers in Red Hat Enterprise Linux 7 and RHEL Atomic Host by getting and using container images and working with running containers.

If you are interested in more details on how the docker command works, refer to the following:

To get an environment where you can develop Docker containers, you can install a Red Hat Enterprise Linux 7 system to act as a development system as well as a container host. The docker package itself is stored in a RHEL Extras repository (see the Red Hat Enterprise Linux Extras Life Cycle article for a description of support policies and life cycle information for the Red Hat Enterprise Linux Extras channel).

Using the RHEL 7 subscription model, if you want to create container images, you must properly register and entitle the host computer on which you build them. When you use yum install within a container to add packages, the container automatically has access to entitlements available from the RHEL 7 host, so it can get RPM packages from any repository enabled on that host.

With the docker service running, you can obtain some Docker images and use the docker command to begin working with Docker images in RHEL 7.

RHEL Atomic Host is a light-weight Linux operating system distribution that was designed specifically for running containers. It contains two different versions of the docker service, as well as some services that can be used to orchestrate and manage Docker containers, such as Kubernetes. Only one version of the docker service can be running at a time.

Because RHEL Atomic Host is more like an appliance than a full-featured Linux system, it is not made for you to install RPM packages or other software on. Software is added to Atomic Host systems by running container images.

RHEL Atomic Host has a mechanism for updating existing packages, but not for allowing users to add new packages. Therefore, you should consider using a standard RHEL 7 server system to develop your applications (so you can add a full compliment of development and debugging tools), then use RHEL Atomic Host to deploy your containers into a variety of virtualization and cloud environment.

That said, you can install a RHEL Atomic Host system and use it to run, build, stop, start, and otherwise work with containers using the examples shown in this topic. To do that, use the following procedure to get and install RHEL Atomic Host.

Whether you are using the docker service in RHEL Atomic Host or on a RHEL Server, you can change the behavior of the docker service. Ways of changing the behavior of the docker service include:

When the docker daemon starts in RHEL or RHEL Atomic Host, it reads the settings in the /etc/sysconfig/docker file and adds them to the docker daemon command line. See available options by typing the following command:

$ docker daemon --help

The following are a few options you may want to consider adding to your /etc/sysonfig/docker file so that they are picked up when your docker daemon runs.

OPTIONS='--selinux-enabled --log-driver=journald'

OPTIONS='--selinux-enabled --log-driver=journald --signature-verification=false -H tcp://0.0.0.0:2375'

[registries.search]
registries = ["reg1.example.com", "reg2.example.com"]

[registries.insecure]
registries = ["reg3.example.com"]

[registries.block]
registries = ['docker.io']

A Docker registry provides a place to store and share docker containers that are saved as images that can be shared with other people. While you can build and store container images on your local system without installing a registry, or use the Docker Hub Registry to share your images with the world, installing a private registry lets you share your images with a private group of developers or users.

With the registry software available with RHEL and RHEL Atomic Host, you can pull images from the Red Hat Customer Portal and push or pull images to and from your own private registry. You see what images are available to pull from the Red Hat Customer Portal (using docker pull) by searching the Red Hat Container Images Search Page.

This section describes how to start up a local registry, load Docker images to your local registry, and use those images to start up docker containers. The version of the Docker Registry that is currently available with Red Hat Enterprise Linux is Docker Registry 2.0.

# docker pull <registry>[:<port>]/[<namespace>/]<name>:<tag>

# docker pull registry.access.redhat.com/rhel7/rhel

# docker images
REPOSITORY
             TAG        IMAGE ID      CREATED       VIRTUAL SIZE
registry.access.redhat.com/rhel7/rhel
             latest     95612a3264fc  6 weeks ago   203.3 MB
registry.access.redhat.com/rhel7/rhel-tools
             latest     3b7bd2d69242  6 weeks ago   1.219 GB
registry.access.redhat.com/rhel7/cockpit-ws
             latest     3bf463e43334  6 weeks ago   220.1 MB
registry.access.redhat.com/aep3_beta/aep-docker-registry
             latest     3c272743b20a  6 weeks ago   478.5 MB
registry.access.redhat.com/rhel7/etcd
             latest     c0a7c32e9eb9  9 weeks ago   241.7 MB

If images have been pulled or loaded into your local registry, you can use the docker command docker images to view those images. Here’s how to list the images on your local system:

# docker images
REPOSITORY                                   TAG     IMAGE ID     CREATED      VIRTUAL SIZE
registry.access.redhat.com/rhel7/rhel-tools  latest  3b7bd2d69242 6 weeks ago  1.219 GB
registry.access.redhat.com/rhel7/cockpit-ws  latest  3bf463e43334 6 weeks ago  220.1 MB
registry.access.redhat.com/rhel7/rhel        latest  95612a3264fc 6 weeks ago  203.3 MB

Now that you have the docker and docker-distribution services running, with a few containers available, you can start investigating the Docker environment and looking into what makes up a container. Run docker with the version and info options to get a feel for your Docker environment.

docker version: The version option shows which versions of different Docker components are installed.

# docker version
Client:
 Version:         1.10.3
 API version:     1.22
Package version: docker-common-1.10.3-44.el7.x86_64
 Go version:      go1.4.2
 Git commit:      7ffc8ee-unsupported
 Built:           Fri Jun 17 15:27:21 2016
 OS/Arch:         linux/amd64

Server:
 Version:         1.10.3
 API version:     1.22
 Package version: docker-common-1.10.3-44.el7.x86_64
 Go version:      go1.4.2
 Git commit:      7ffc8ee-unsupported
 Built:           Fri Jun 17 15:27:21 2016
 OS/Arch:         linux/amd64

docker info: The info option lets you see the locations of different components, such as how many local containers and images there are, as well as information on the size and location of Docker storage areas.

# docker info
Containers: 9
Images: 25
Server Version: 1.10.3
Storage Driver: devicemapper
 Pool Name: docker-253:0-21214-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 107.4 GB
 Backing Filesystem:
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 5.367 GB
 Data Space Total: 107.4 GB
 Data Space Available: 5.791 GB
 Metadata Space Used: 4.706 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.143 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.107-RHEL7 (2015-12-01)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-327.18.2.el7.x86_64
Operating System: Red Hat Enterprise Linux Atomic Host 7.2
CPUs: 1
Total Memory: 1.907 GiB
Name: atomic-7.2-12
ID: JSDA:MGJV:ALYX:N6RC:YXER:M4OJ:GYR2:GYQK:BPZX:GQOA:F476:WLQY

Docker images that are now on your system (whether they have been run or not) can be managed in several ways. The docker run command lets you say which command to run in a container. Once a container is running, you can stop, start, and restart it. You can remove containers you no longer need (in fact you probably want to). Before you run an image, it is a good idea to investigate its contents.

Investigate a container image After you pull an image to your local system and before you run it, it is a good idea to investigate that image. Reasons for investigating an image before you run it include:

Tools (such as openscap) are being integrated with container tools to allow them to scan a container image before you run it. In the mean time, however, you can use docker inspect to get some basic information about what an image does. You also have the option of mounting the image to your host system and using tools from the host to investigate what’s in the image. Here is an example of investigating what a container image does before you run it:

In the near future, look for software scanning features, such as Openscap or Black Duck, to be available for scanning your container images. When they are, you will be able to use the atomic scan command to scan your images.

Running Docker containers

When you execute a docker run command, you essentially spin up and create a new container from a Docker image. That container consists of the contents of the image, plus features based on any additional options you pass on the docker run command line.

The command you pass on the docker run command line sees the inside the container as its running environment so, by default, very little can be seen of the host system. For example, by default, the running applications sees:

If you want to make a directory from the host available to the container, map network ports from the container to the host, limit the amount of memory the container can use, or expand the CPU shares available to the container, you can do those things from the docker run command line. Here are some examples of docker run command lines that enable different features.

EXAMPLE #1 (Run a quick command): This docker command runs the ip addr show eth0 command to see address information for the eth0 network interface within a container that is generated from the RHEL image. Because this is a bare-bones container, we mount the /usr/sbin directory from the RHEL 7 host system for this demonstration (mounting is done by the -v option), because it contains the ip command we want to run. After the container runs the command, which shows the IP address (172.17.0.2/16) and other information about eth0, the container stops and is deleted (--rm).

# docker run -v /usr/sbin:/usr/sbin \
    --rm rhel /usr/sbin/ip addr show eth0
20: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 4e:90:00:27:a2:5d brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.10/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::4c90:ff:fe27:a25d/64 scope link tentative
       valid_lft forever preferred_lft forever

If you feel that this is a container you wanted to keep around and use again, consider assigning a name to it, so you can start it again later by name. For example, I named this container myipaddr:

# docker run -v /usr/sbin:/usr/sbin \
    --name=myipaddr rhel /usr/sbin/ip addr show eth0
20: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 4e:90:00:27:a2:5d brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.10/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::4c90:ff:fe27:a25d/64 scope link tentative
       valid_lft forever preferred_lft forever

# docker start -i myipaddr
22: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 4e:90:00:27:a2:5d brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.10/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::4c90:ff:fe27:a25d/64 scope link tentative
       valid_lft forever preferred_lft forever

EXAMPLE #2 (View the Dockerfile in the container): This is another example of running a quick command to inspect the content of a container from the host. All layered images that Red Hat provides include the Dockerfile from which they are built in /root/buildinfo. In this case you do not need to mount any volumes from the host.

# docker run --rm registry.access.redhat.com/rhel7/rsyslog  ls /root/buildinfo
Dockerfile-rhel7-rsyslog-7.2-21

Now you know what the Dockerfile is called, you can list its contents:

# docker run --rm registry.access.redhat.com/rhel7/rsyslog \
    cat /root/buildinfo/Dockerfile-rhel7-rsyslog-7.2-21
FROM 6c3a84d798dc449313787502060b6d5b4694d7527d64a7c99ba199e3b2df834e
MAINTAINER Red Hat, Inc.
ENV container docker
RUN yum -y update; yum -y install rsyslog; yum clean all

LABEL BZComponent="rsyslog-docker"
LABEL Name="rhel7/rsyslog"
LABEL Version="7.2"
LABEL Release="21"
LABEL Architecture="x86_64"
...

EXAMPLE #3 (Run a shell inside the container): Using a container to launch a bash shell lets you look inside the container and change the contents. Here, I set the name of the container to mybash. The -i creates an interactive session and -t opens a terminal session. Without -i, the shell would open and then exit. Without -t, the shell would stay open, but you wouldn’t be able to type anything to the shell.

Once you run the command, you are presented with a shell prompt and you can start running commands from inside the container:

# docker run --name=mybash -it rhel /bin/bash
[root@49830c4f9cc4/]#

Although there are very few applications available inside the base RHEL image, you can add more software using the yum command. With the shell open inside the container, run the following commands:

[root@49830c4f9cc4/]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)
[root@49830c4f9cc4/]# nmap
bash: nmap: command not found
[root@49830c4f9cc4/]# yum install -y nmap
[root@49830c4f9cc4/]# # nmap 192.168.122.1

Starting Nmap 6.40 ( http://nmap.org ) at 2016-05-10 08:55 EDT
Nmap scan report for 192.168.122.1
Host is up (0.00042s latency).
Not shown: 996 filtered ports
PORT     STATE SERVICE
22/tcp   open  ssh
53/tcp   open  domain
5000/tcp open  upnp
...
[root@49830c4f9cc4/]# exit

Notice that the container is a RHEL 7.2 container. The nmap command is not included in the RHEL base image. However, you can install it with yum as shown above, then run it within that container. To leave the container, type exit.

Although the container is no longer running once you exit, the container still exists with the new software package still installed. Use docker ps -a to list the container:

# docker ps -a
CONTAINER ID  IMAGE COMMAND      CREATED        STATUS                    PORTS  NAMES
49830c4f9cc4  rhel  "/bin/bash"  2 minutes ago  Exited (0) 2 seconds ago        mybash
...

You could start that container again using docker start with the -ai options. For example:

# docker start -ai mybash
[root@a0aee493a605/]#

EXAMPLE #4 (Bind mounting log files): One way to make log messages from inside a container available to the host system is to bind mount the host’s /dev/log device inside the container. This example illustrates how to run an application in a RHEL container that is named log_test that generates log messages (just the logger command in this case) and directs those messages to the /dev/log device that is mounted in the container from the host. The --rm option removes the container after it runs.

# docker run --name="log_test" -v /dev/log:/dev/log --rm rhel logger "Testing logging to the host"
# journalctl -b | grep Testing
May 10 09:00:32 atomic-7.2-12 logger[15377]: Testing logging to the host

Investigating from outside of a Docker container

Let’s say you have one or more Docker containers running on your host. To work with containers from the host system, you can open a shell and try some of the following commands.

docker ps: The ps option shows all containers that are currently running:

# docker ps
CONTAINER ID IMAGE       COMMAND     CREATED         STATUS       PORTS    NAMES
0d8b2ded3af0 rhel:latest "/bin/bash" 10 minutes ago  Up 3 minutes          mybash

If there are containers that are not running, but were not removed (--rm option), the containers are still hanging around and can be restarted. The docker ps -a command shows all containers, running or stopped.

# docker ps -a
CONTAINER ID  IMAGE       COMMAND    CREATED      STATUS                PORTS  NAMES
92b7ed0c039b  rhel:latest /bin/bash  2 days ago   Exited (0) 2 days ago        agitated_hopper
eaa96236afa6  rhel:latest /bin/bash  2 days ago   Exited (0) 2 days ago        prickly_newton

See the section "Working with Docker containers" for information on starting, stopping, and removing containers that exist on your system.

docker inspect: To inspect the metadata of an existing container, use the docker inspect command. You can show all metadata or just selected metadata for the container. For example, to show all metadata for a selected container, type:

# docker inspect mybash
[{
        "Labels": {
            "Architecture": "x86_64",
            "Authoritative_Registry": "registry.access.redhat.com",
            "BZComponent": "rhel-server-docker",
            "Build_Host": "rcm-img03.build.eng.bos.redhat.com",
            "Name": "rhel7/rhel",
            "Release": "56",
            "Vendor": "Red Hat, Inc.",
            "Version": "7.2"
    ...

docker inspect --format: You can also use inspect to pull out particular pieces of information from a container. The information is stored in a hierarchy. So to see the container’s IP address (IPAddress under NetworkSettings), use the --format option and the identity of the container. For example:

# docker inspect --format='{{.NetworkSettings.IPAddress}}' mybash
172.17.0.2

Examples of other pieces of information you might want to inspect include .Path (to see the command run with the container), .Args (arguments to the command), .Config.ExposedPorts (TCP or UDP ports exposed from the container), .State.Pid (to see the process id of the container) and .HostConfig.PortBindings (port mapping from container to host). Here’s an example of .State.Pid and .HostConfig.PortBindings:

# docker inspect --format='{{.State.Pid}}' mybash
5007
# docker inspect --format='{{.HostConfig.PortBindings}}' mybash
map[8000/tcp:[map[HostIp: HostPort:8000]]]

Investigating within a running Docker container

To investigate within a running Docker container, you can use the docker exec command. With docker exec, you can run a command (such as /bin/bash) to enter a running Docker container process to investigate that container.

The reason for using docker exec, instead of just launching the container into a bash shell, is that you can investigate the container as it is running its intended application. By attaching to the container as it is performing its intended task, you get a better view of what the container actually does, without necessarily interrupting the container’s activity.

Here is an example using docker exec to look into a running container named myrhel_httpd, then look around inside that container.

The commands just run from the bash shell (running inside the container) show you several things. The container holds a RHEL Server release 7.1 system. The process table (ps -ef) shows that the httpd command is process ID 1 (followed by five other httpd processes), /bin/bash is PID 12 and ps -ef is PID 35. Processes running in the host’s process table cannot be seen from within the container. The container’s file system consumes 414M of the 9.8G available root file system space.

There is no separate kernel running in the container (uname -r shows the host system’s kernel: 3.10.0-229.1.2.el7.x86_64). The rpm -qa command lets you see the RPM packages that are included inside the container. In other words, there is an RPM database inside of the container. Viewing memory (free -m) shows the available memory on the host (although what the container can actually use can be limited using cgroups).

Starting and stopping containers

If you ran a container, but didn’t remove it (--rm), that container is stored on your local system and ready to run again. To start a previously run container that wasn’t removed, use the start option. To stop a running container, use the stop option.

Starting containers: A docker container that doesn’t need to run interactively can start with only the start option and the container ID or name:

# docker start myrhel_httpd
myrhel_httpd

To start a container so you can work with it from the local shell, use the -a (attach) and -i (interactive) options. Once the bash shell starts, run the commands you want inside the container and type exit to kill the shell and stop the container.

# docker start -a -i agitated_hopper
bash-4.2# exit

Stopping containers: To stop a running container that is not attached to a terminal session, use the stop option and the container ID or number. For example:

# docker stop myrhel_httpd
myrhel_httpd

The stop option sends a SIGTERM signal to terminate a running container. If the container doesn’t stop after a grace period (10 seconds by default), docker sends a SIGKILL signal. You could also use the docker kill command to kill a container (SIGKILL) or send a different signal to a container. Here’s an example of sending a SIGHUP signal to a container (if supported by the application, a SIGHUP causes the application to re-read its configuration files):

# docker kill --signal="SIGHUP" myrhel_httpd

Removing containers

To see a list of containers that are still hanging around your system, run the docker ps -a command. To remove containers you no longer need, use the docker rm command, with the container ID or name as an option. Here is an example:

# docker rm goofy_wozniak

You can remove multiple containers on the same command line:

# docker rm clever_yonath furious_shockley drunk_newton

If you want to clear out all your containers, you could use a command like the following to remove all containers (not images) from your local system (make sure you mean it before you do this!):

# docker rm $(docker ps -a -q)

So far we have grabbed some existing docker container images and worked with them in various ways. To make the process of running the exact container you want less manual, you can create a Docker image from scratch or from a container you ran that combines an existing image with some other content or settings.

You can add names to images to make it more intuitive to understand what they contain. Using the docker tag command, you essentially add an alias to the image, that can consist of several parts. Those parts can include:

registryhost/username/NAME:tag

You can add just NAME if you like. For example:

# docker tag 474ff279782b myrhel7

In the previous example, the rhel7 image had a image ID of 474ff279782b. Using docker tag, the name myrhel7 now also is attached to the image ID. So you could run this container by name (rhel7 or myrhel7) or by image ID. Notice that without adding a :tag to the name, it was assigned :latest as the tag. You could have set the tag to 7.2 as follows:

# docker tag 474ff279782b myrhel7:7.2

To the beginning of the name, you can optionally add a user name and/or a registry name. The user name is actually the repository on Docker.io that relates to the user account that owns the repository. Tagging an image with a registry name was shown in the "Tagging Images" section earlier in this document. Here’s an example of adding a user name:

# docker tag 474ff279782b cnegus/myrhel7
# docker images | grep 474ff279782b
rhel7           latest  474ff279782b  7 months ago  139.6 MB
myrhel7         latest  474ff279782b  7 months ago  139.6 MB
myrhel7         7.1     474ff279782b  7 months ago  139.6 MB
cnegus/myrhel7  latest  474ff279782b  7 months ago  139.6 MB

Above, you can see all the image names assigned to the single image ID.

If you want to save a Docker image you created, you can use docker save to save the image to a tarball. After that, you can store it or send it to someone else, then reload the image later to reuse it. Here is an example of saving an image as a tarball:

# docker save -o myrhel7.tar myrhel7:latest

The myrhel7.tar file should now be stored in your current directory. Later, when you ready to reuse the tarball as a container image, you can import it to another docker environment as follows:

# cat myrhel7.tar | docker import - cnegus/myrhel7

To see a list of images that are on your system, run the docker images command. To remove images you no longer need, use the docker rmi command, with the image ID or name as an option. (You must stop any containers using an image before you can remove the image.) Here is an example:

# docker rmi rhel

You can remove multiple images on the same command line:

# docker rmi rhel fedora

If you want to clear out all your images, you could use a command like the following to remove all images from your local registry (make sure you mean it before you do this!):

# docker rmi $(docker images -a -q)

At this point, you should be able to get Red Hat Docker installed with the docker and docker-distribution services working. You should also have one or more Docker images to work with, as well as know how to run containers and build your own images.