Quick Installation - Installing a Cluster | Installation and Configuration

Overview
Before You Begin
Running an Interactive Installation
Defining an Installation Configuration File
Running an Unattended Installation
Verifying the Installation
Uninstalling OpenShift Container Platform
What’s Next?

Overview

The quick installation method allows you to use an interactive CLI utility, the atomic-openshift-installer command, to install OpenShift Container Platform across a set of hosts. This installer can deploy OpenShift Container Platform components on targeted hosts by either installing RPMs or running containerized services.

While RHEL Atomic Host is supported for running containerized OpenShift Container Platform services, the installer is provided by an RPM and not available by default in RHEL Atomic Host. Therefore, it must be run from a Red Hat Enterprise Linux 7 system. The host initiating the installation does not need to be intended for inclusion in the OpenShift Container Platform cluster, but it can be.

This installation method is provided to make the installation experience easier by interactively gathering the data needed to run on each host. The installer is a self-contained wrapper intended for usage on a Red Hat Enterprise Linux (RHEL) 7 system.

In addition to running interactive installations from scratch, the atomic-openshift-installer command can also be run or re-run using a predefined installation configuration file. This file can be used with the installer to:

run an unattended installation,
add nodes to an existing cluster,
upgrade your cluster, or
reinstall the OpenShift Container Platform cluster completely.

Alternatively, you can use the advanced installation method for more complex environments.

To install OpenShift Container Platform as a stand-alone registry, see Installing a Stand-alone Registry.

Before You Begin

The installer allows you to install OpenShift Container Platform master and node components on a defined set of hosts.

By default, any hosts you designate as masters during the installation process are automatically also configured as nodes so that the masters are configured as part of the OpenShift Container Platform SDN. The node component on the masters, however, are marked unschedulable, which blocks pods from being scheduled on it. After the installation, you can mark them schedulable if you want.

Before installing OpenShift Container Platform, you must first satisfy the prerequisites on your hosts, which includes verifying system and environment requirements and properly installing and configuring Docker. You must also be prepared to provide or validate the following information for each of your targeted hosts during the course of the installation:

User name on the target host that should run the Ansible-based installation (can be root or non-root)
Host name
Whether to install components for master, node, or both
Whether to use the RPM or containerized method
Internal and external IP addresses

If you are installing OpenShift Container Platform using the containerized method (optional for RHEL but required for RHEL Atomic Host), see the Installing on Containerized Hosts topic to ensure that you understand the differences between these methods, then return to this topic to continue.

After following the instructions in the Prerequisites topic and deciding between the RPM and containerized methods, you can continue to running an interactive or unattended installation.

Running an Interactive Installation

Ensure you have read through Before You Begin.

You can start the interactive installation by running:

$ atomic-openshift-installer install

Then follow the on-screen instructions to install a new OpenShift Container Platform cluster.

After it has finished, ensure that you back up the ~/.config/openshift/installer.cfg.yml installation configuration file that is created, as it is required if you later want to re-run the installation, add hosts to the cluster, or upgrade your cluster. Then, verify the installation.

Defining an Installation Configuration File

The installer can use a predefined installation configuration file, which contains information about your installation, individual hosts, and cluster. When running an interactive installation, an installation configuration file based on your answers is created for you in ~/.config/openshift/installer.cfg.yml. The file is created if you are instructed to exit the installation to manually modify the configuration or when the installation completes. You can also create the configuration file manually from scratch to perform an unattended installation.

Example 1. Installation Configuration File Specification

version: v2 (1)
variant: openshift-enterprise (2)
variant_version: 3.6 (3)
ansible_log_path: /tmp/ansible.log (4)
deployment:
  ansible_ssh_user: root (5)
  hosts: (6)
  - ip: 10.0.0.1 (7)
    hostname: master-private.example.com (7)
    public_ip: 24.222.0.1 (8)
    public_hostname: master.example.com (8)
    roles: (9)
      - master
      - node
    containerized: true (10)
    connect_to: 24.222.0.1 (11)
  - ip: 10.0.0.2
    hostname: node1-private.example.com
    public_ip: 24.222.0.2
    public_hostname: node1.example.com
    node_labels: {'region': 'infra'} (12)
    roles:
      - node
    connect_to: 10.0.0.2
  - ip: 10.0.0.3
    hostname: node2-private.example.com
    public_ip: 24.222.0.3
    public_hostname: node2.example.com
    roles:
      - node
    connect_to: 10.0.0.3
  roles: (13)
    master:
      <variable_name1>: "<value1>" (14)
      <variable_name2>: "<value2>"
    node:
      <variable_name1>: "<value1>" (14)

1	The version of this installation configuration file. As of OpenShift Container Platform 3.3, the only valid version here is `v2`.
2	The OpenShift Container Platform variant to install. For OpenShift Container Platform, set this to `openshift-enterprise`.
3	A valid version of your selected variant: `3.6`, `3.5`, `3.4`, `3.3`, `3.2`, or `3.1`. If not specified, this defaults to the latest version for the specified variant.
4	Defines where the Ansible logs are stored. By default, this is the */tmp/ansible.log* file.
5	Defines which user Ansible uses to SSH in to remote systems for gathering facts and for the installation. By default, this is the root user, but you can set it to any user that has sudo privileges.
6	Defines a list of the hosts onto which you want to install the OpenShift Container Platform master and node components.
7	Required. Allows the installer to connect to the system and gather facts before proceeding with the install.
8	Required for unattended installations. If these details are not specified, then this information is pulled from the facts gathered by the installer, and you are asked to confirm the details. If undefined for an unattended installation, the installation fails.
9	Determines the type of services that are installed. Specified as a list.
10	If set to true, containerized OpenShift Container Platform services are run on target master and node hosts instead of installed using RPM packages. If set to false or unset, the default RPM method is used. RHEL Atomic Host requires the containerized method, and is automatically selected for you based on the detection of the */run/ostree-booted* file. See Installing on Containerized Hosts for more details.
11	The IP address that Ansible attempts to connect to when installing, upgrading, or uninstalling the systems. If the configuration file was auto-generated, then this is the value you first enter for the host during that interactive install process.
12	Node labels can optionally be set per-host.
13	Defines a dictionary of roles across the deployment.
14	Any ansible variables that should only be applied to hosts assigned a role can be defined. For examples, see Configuring Ansible.

Running an Unattended Installation

Ensure you have read through the Before You Begin.

Unattended installations allow you to define your hosts and cluster configuration in an installation configuration file before running the installer so that you do not have to go through all of the interactive installation questions and answers. It also allows you to resume an interactive installation you may have left unfinished, and quickly get back to where you left off.

To run an unattended installation, first define an installation configuration file at ~/.config/openshift/installer.cfg.yml. Then, run the installer with the -u flag:

$ atomic-openshift-installer -u install

By default in interactive or unattended mode, the installer uses the configuration file located at ~/.config/openshift/installer.cfg.yml if the file exists. If it does not exist, attempting to start an unattended installation fails.

Alternatively, you can specify a different location for the configuration file using the -c option, but doing so will require you to specify the file location every time you run the installation:

$ atomic-openshift-installer -u -c </path/to/file> install

After the unattended installation finishes, ensure that you back up the ~/.config/openshift/installer.cfg.yml file that was used, as it is required if you later want to re-run the installation, add hosts to the cluster, or upgrade your cluster. Then, verify the installation.

Verifying the Installation

After the installation completes:

If you are using a proxy, you must add the IP address of the etcd endpoints to the openshift_no_proxy cluster variable in your inventory file.

If you are not using a proxy, you can skip this step.

In OpenShift Container Platform 3.4, the master connected to the etcd cluster using the host name of the etcd endpoints. In OpenShift Container Platform 3.5, the master now connects to etcd via IP address.

When configuring a cluster to use proxy settings (see Configuring Global Proxy Options), this change causes the master-to-etcd connection to be proxied as well, rather than being excluded by host name in each host’s NO_PROXY setting (see Working with HTTP Proxies for more about NO_PROXY).
1. To workaround this issue, add the IP address of the etcd endpoints to the NO_PROXY environment variable on each master host’s /etc/sysconfig/atomic-openshift-master-controllers file. For example:
  NO_PROXY=<ip_address>
  Use the IP address or host name that the master uses to contact the etcd cluster as the <ip_address>. The <port> should be 2379 if you are using standalone etcd (clustered) or 4001 for embedded etcd (single master, non-clustered etcd). The installer will be updated in a future release to handle this scenario automatically during installation and upgrades (BZ#1466783).
2. Restart the master service for the changes to take effect:
  # systemctl restart atomic-openshift-master

After the installation completes:

Verify that the master is started and nodes are registered and reporting in Ready status. On the master host, run the following as root:

# oc get nodes

NAME                        STATUS                     AGE
master.example.com          Ready,SchedulingDisabled   165d
node1.example.com           Ready                      165d
node2.example.com           Ready                      165d

To verify that the web console is installed correctly, use the master host name and the web console port number to access the web console with a web browser.

For example, for a master host with a host name of master.openshift.com and using the default port of 8443, the web console would be found at https://master.openshift.com:8443/console.
Then, see What’s Next for the next steps on configuring your OpenShift Container Platform cluster.

Uninstalling OpenShift Container Platform

You can uninstall OpenShift Container Platform from all hosts in your cluster using the installer’s uninstall command. By default, the installer uses the installation configuration file located at ~/.config/openshift/installer.cfg.yml if the file exists:

$ atomic-openshift-installer uninstall

Alternatively, you can specify a different location for the configuration file using the -c option:

$ atomic-openshift-installer -c </path/to/file> uninstall

See the advanced installation method for more options.

What’s Next?

Now that you have a working OpenShift Container Platform instance, you can:

Configure authentication; by default, authentication is set to Deny All.
Configure the automatically-deployed integrated Docker registry.
Configure the automatically-deployed router.