Skip to content

Latest commit

 

History

History
105 lines (79 loc) · 4.41 KB

README_CONTAINERIZED_INSTALLATION.md

File metadata and controls

105 lines (79 loc) · 4.41 KB

Overview

Users may now deploy containerized versions of OpenShift Origin, OpenShift Enterprise, or Atomic Enterprise Platform on Atomic Host or RHEL, Centos, and Fedora. This includes OpenvSwitch based SDN.

Installing on Atomic Host

When installing on Atomic Host you will automatically have containerized installation methods selected for you based on detection of /run/ostree-booted

Installing on RHEL, Centos, or Fedora

Currently the default installation method for traditional operating systems is via RPMs. If you wish to deploy using containerized installation you may set the ansible variable 'containerized=true' on a per host basis. This means that you may easily deploy environments mixing containerized and RPM based installs. At this point we suggest deploying heterogeneous environments.

CLI Wrappers

When using containerized installations openshift-ansible will deploy a wrapper script on each master located in /usr/local/bin/openshift and a set of symbolic links /usr/local/bin/oc, /usr/local/bin/oadm, and /usr/local/bin/kubectl to ease administrative tasks. The wrapper script spawns a new container on each invocation so you may notice it's slightly slower than native clients.

The wrapper scripts mount a limited subset of paths, ~/.kube, /etc/origin/, and /tmp. Be mindful of this when passing in files to be processed by oc or oadm. You may find it easier to redirect input like this :

oc create -f - < my_file.json

Technical Notes

Requisite Images

Based on your openshift_deployment_type the installer will make use of the following images. Because you may make use of a private repository we've moved the configuration of docker additional, insecure, and blocked registries to the beginning of the installation process ensuring that these settings are applied before attempting to pull any of the following images.

Origin
    openshift/origin
    openshift/node (node + openshift-sdn + openvswitch rpm for client tools)
    openshift/openvswitch (centos7 + openvswitch rpm, runs ovsdb ovsctl processes)
    registry.access.redhat.com/rhel7/etcd
OpenShift Enterprise
    openshift3/ose
    openshift3/node
    openshift3/openvswitch
    registry.access.redhat.com/rhel7/etcd
Atomic Enterprise Platform
    aep3/aep
    aep3/node
    aep3/openvswitch
    registry.access.redhat.com/rhel7/etcd
  • note openshift3/* and aep3/* images come from registry.access.redhat.com and rely on the --additional-repository flag being set appropriately.

Starting and Stopping Containers

The installer will create relevant systemd units which can be used to start, stop, and poll services via normal systemctl commands. These unit names match those of an RPM installation with the exception of the etcd service which will be named 'etcd_container'. This change is necessary as currently Atomic Host ships with etcd package installed as part of Atomic Host and we will instead use a containerized version. The installer will disable the built in etcd service. etcd is slated to be removed from os-tree in the future.

File Paths

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

The examples are installed into /etc/origin/examples rather than /usr/share/openshift/examples because that is read-only on Atomic Host.

Storage Requirements

Atomic Host installs by default have a small root filesystem. However the etcd, master, and node containers will persist data in /var/lib. Please ensure that you have enough space on the root filesystem. This is usually handled by docker-storage-setup; set e.g. ROOT_SIZE=20G in /etc/sysconfig/docker-storage-setup in early host boot, such as inside a cloud-init boot hook.

OpenvSwitch SDN Initialization

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

The node service may fail to start and be restarted a few times because the master services are also restarted along with docker. We currently work around this by relying on Restart=always in the docker based systemd units.