RPM vs Containerized Installation

You can opt to install OpenShift Origin using the RPM or containerized package method. Either installation method results in a working environment, but the choice comes from the operating system and how you choose to update your hosts.

The default method for installing OpenShift Origin on Fedora, CentOS, or RHEL uses RPMs. When targeting a Red Hat Atomic Host system, the containerized method is the only available option, and is automatically selected for you based on the detection of the /run/ostree-booted file.

When using RPMs, all services are installed and updated by package management from an outside source. These modify a host’s existing configuration within the same user space. Alternatively, with containerized installs, each component of OpenShift Origin is shipped as a container (in a self-contained package) and leverages the host’s kernel to start and run. Any updated, newer containers replace any existing ones on your host. Choosing one method over the other depends on how you choose to update OpenShift Origin in the future.

The following table outlines further differences between the RPM and Containerized methods:

RPM Containerized

Installation Method

Packages via yum

Container images via docker

Service Management

systemd

docker and systemd units

Operating System

Red Hat Enterprise Linux

Red Hat Enterprise Linux or Red Hat Atomic Host

Install Method for Containerized Hosts

As with the RPM installation, you can use the advanced installation method for the containerized install.

You can set the Ansible variable containerized=true in an inventory file on a cluster-wide or per host basis.

Required Images

Containerized installations make use of the following images:

  • openshift/origin

  • openshift/node (node + openshift-sdn + openvswitch RPM for client tools)

  • openshift/openvswitch (CentOS 7 + openvswitch RPM, runs ovsdb and ovsctl processes)

  • registry.access.redhat.com/rhel7/etcd

If you need to use a private registry to pull these images during the installation, you can specify the registry information ahead of time. For the advanced installation method, you can set the following Ansible variables in your inventory file, as required:

openshift_docker_additional_registries=<registry_hostname>
openshift_docker_insecure_registries=<registry_hostname>
openshift_docker_blocked_registries=<registry_hostname>

The configuration of additional, insecure, and blocked Docker registries occurs at the beginning of the installation process to ensure that these settings are applied before attempting to pull any of the required images.

Starting and Stopping Containers

The installation process creates relevant systemd units which can be used to start, stop, and poll services using normal systemctl commands. For containerized installations, these unit names match those of an RPM installation, with the exception of the etcd service which is named etcd_container.

This change is necessary as currently RHEL Atomic Host ships with the etcd package installed as part of the operating system, so a containerized version is used for the OpenShift Origin installation instead. The installation process disables the default etcd service.

The etcd package is slated to be removed from RHEL Atomic Host in the future.

File Paths

All OpenShift Origin configuration files are placed in the same locations during containerized installation as RPM based installations and will survive os-tree upgrades.

However, the default image stream and template files are installed at /etc/origin/examples/ for containerized installations rather than the standard /usr/share/openshift/examples/, because that directory is read-only on RHEL Atomic Host.

Storage Requirements

RHEL Atomic Host installations normally have a very small root file system. However, the etcd, master, and node containers persist data in the /var/lib/ directory. Ensure that you have enough space on the root file system before installing OpenShift Origin. See the System Requirements section for details.

Open vSwitch SDN Initialization

OpenShift SDN initialization requires that the Docker bridge be reconfigured and that Docker is restarted. This complicates the situation when the node is running within a container. When using the Open vSwitch (OVS) SDN, you will see the node start, reconfigure Docker, restart Docker (which restarts all containers), and finally start successfully.

In this case, the node service may fail to start and be restarted a few times, because the master services are also restarted along with Docker. The current implementation uses a workaround which relies on setting the Restart=always parameter in the Docker based systemd units.