Bootstrapping Servers¶

Initial bootstrap considerations¶

The nature of bootstrapping means that the environment that Ansible executes in during the initial bootstrap may look different to that seen after bootstrapping is complete. For example:

• The kolla_user user account may not yet have been created. If this is normally used as the ansible_user when executing Kolla Ansible, a different user account must be used for bootstrapping.
• The Python virtual environment may not exist. If a virtualenv is normally used as the ansible_python_interpreter when executing Kolla Ansible, the system python interpreter must be used for bootstrapping.

Each of these variables may be passed via the -e argument to Kolla Ansible to override the inventory defaults:

kolla-ansible bootstrap-servers -i INVENTORY -e ansible_user=<bootstrap user> -e ansible_python_interpreter=/usr/bin/python

Subsequent bootstrap considerations¶

It is possible to run the bootstrapping process against a cloud that has already been bootstrapped, for example to apply configuration from a newer release of Kolla Ansible. In this case, further considerations should be made.

It is possible that the Docker engine package will be updated. This will cause the Docker engine to restart, in addition to all running containers. There are three main approaches to avoiding all control plane services restarting simultaneously.

The first option is to use the --limit command line argument to apply the command to hosts in batches, ensuring there is always a quorum for clustered services (e.g. MariaDB):

kolla-ansible bootstrap-servers -i INVENTORY --limit controller0,compute[0-1]
kolla-ansible bootstrap-servers -i INVENTORY --limit controller1,compute[2-3]
kolla-ansible bootstrap-servers -i INVENTORY --limit controller2,compute[4-5]

The second option is to execute individual plays on hosts in batches:

kolla-ansible bootstrap-servers -i INVENTORY -e kolla_serial=30%

The last option is to use the Docker live-restore configuration option to avoid restarting containers when the Docker engine is restarted. There have been issues reported with using this option however, so use it at your own risk.

Ensure that any operation that causes the Docker engine to be updated has been tested, particularly when moving from legacy Docker packages to Docker Community Edition. See Package repositories for details.

Package repositories¶

If the enable_docker_repo flag is set, then a package repository for Docker packages will be configured. There are two sets of package repositories provided by Docker - ‘legacy’ packages from https://dockerproject.org, and new ‘Community Edition’ packages from https://download.docker.com. To use legacy packages, set docker_legacy_packages to true, or to use new packages set it to false. The new packages are used by default.

Various other configuration options are available beginning docker[_(new|legacy)]_(apt|yum)_. Typically these do not need to be changed.

Configuration¶

The docker_storage_driver variable is optional. If set, it defines the storage (graph) driver to use for Docker.

The docker_runtime_directory variable is optional. If set, it defines the runtime (--graph) directory for Docker.

The docker_registry variable, which is not set by default, defines the address of the Docker registry. If the variable is not set, Dockerhub will be used.

The docker_registry_insecure variable, which defaults to true if docker_registry is set, or false otherwise, defines whether to configure docker_registry as an insecure registry. Insecure registries use HTTP rather than HTTPS.

The docker_log_max_file variable, which defaults to 5, defines the maximum number of log files to retain per container. The docker_log_max_size variable, which defaults to 50m, defines the maximum size of each rotated log file per container.

The docker_custom_option variable is optional. If set, it defines additional options to pass to the Docker engine via the Systemd unit file.