path: root/
diff options
authorScott Dodson <>2015-10-05 12:53:10 -0400
committerScott Dodson <>2015-12-15 15:45:45 -0500
commit8e7c5c970b8adc83fd6d5cad115f4edb06b36d98 (patch)
tree408ffd1864ae9cd34ef238d5c5a9ff2aa59193d9 /
parenta0b6fc7db1be2cf6190d982f90e96f4c39a4c699 (diff)
Containerization work by @sdodson
Diffstat (limited to '')
1 files changed, 101 insertions, 0 deletions
diff --git a/ b/
new file mode 100644
index 000000000..5f51b9507
--- /dev/null
+++ b/
@@ -0,0 +1,101 @@
+# 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 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)
+ OpenShift Enterprise
+ openshift3/ose
+ openshift3/node
+ openshift3/openvswitch
+ Atomic Enterprise Platform
+ aep3/aep
+ aep3/node
+ aep3/openvswitch
+ * note openshift3/* and aep3/* images come from 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 normally have a very 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.
+### 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.