1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
|
# Overview
Users may now deploy containerized versions of OpenShift Origin, OpenShift
Enterprise on [Atomic Host](https://projectatomic.io) 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 don't 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
* note openshift3/* 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](https://github.com/projectatomic/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.
|
