
Thanks to the fix for bug #1738663 it is no longer necessary to run prepare separately to generate the environment file and the images file. Change-Id: Ice0fcb4e6b8f5f18694d989f5152cb23a3d88569 Related-Bug: #1738663
6.4 KiB
Containers based Overcloud Deployment
This documentation explains how to deploy a fully containerized overcloud on Docker. This feature is now the default in Queens.
The requirements for a containerized overcloud are the same as for any other overcloud deployment. The real difference is in where the overcloud services will be deployed (containers vs base OS).
Architecture
The docker-based overcloud architecture is not very different from the baremetal/VM based one. The services deployed in the traditional baremetal overcloud are also deployed in the docker-based one.
One obvious difference between these two types of deployments is that the Openstack services are deployed as containers in a container runtime rather than directly on the host operating system. This reduces the required packages in the host to the bare minimum for running the container runtime and managing the base network layer.
Manual overcloud deployment
This section explains how to deploy a containerized overcloud manually. For an automated overcloud deployment, please follow the steps in the Using TripleO Quickstart section below.
Preparing the environment
To prepare your environment, you must follow all the steps described
in the basic-deployment-cli
documentation. Stop right at the
deploy-the-overcloud
section.
A tag needs to be specified which is unique to the images being
deployed. This makes it possible to later update the overcloud to newer
image versions. It also makes it easier to determine what images you are
running in the overcloud. This unique tag can be discovered by running
the command
openstack overcloud container image tag discover
with a
known stable tag such as latest
. The following command will
return the tag from the RDO docker registry using the stable tag
current-tripleo-rdo
:
openstack overcloud container image tag discover \
--image trunk.registry.rdoproject.org/master/centos-binary-base:current-tripleo-rdo \
--tag-from-label rdo_version
Note
The tag is actually a Delorean hash. You can find out the versions of packages by using this tag. For example, ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7 tag, is in fact using this Delorean repository.
The option
--image trunk.registry.rdoproject.org/master/centos-binary-base:current-tripleo-rdo
will typically be replaced with a value specific to the environment. You
may wish to use stable tag tripleo-passed-ci
for a more
stable set of containers.
It is necessary to generate a heat environment file which specifies
the container image parameters. These parameters will deploy the
overcloud with images from a specific repository with the discovered
<tag>
.
The openstack overcloud container image prepare
command
is an easy way to generate these parameters. The following command will
generate a heat environment file ~/docker_registry.yaml to deploy an overcloud
with container images from RDO docker registry:
openstack overcloud container image prepare \
--namespace trunk.registry.rdoproject.org/master \
--tag <tag> \
--output-env-file ~/docker_registry.yaml
The option
--namespace trunk.registry.rdoproject.org/master
will
typically be replaced with a value specific to the environment. Run with
--help
to see the other options available for controlling
what is generated.
It is possible to limit the output to only the images that are going
to be used in the deployment by specifying the heat environment files
with the --environment-file
option and the roles file with
the --roles-file
option.
Populate local docker registry
Serving container images from a local registry is optional, but it can make overcloud deployment faster and more reliable. For development purposes an insecure docker registry is already setup to listen on port 8787 as part of the undercloud install.
To copy the images from one registry to another, the above prepare command is modified to also generate the overcloud_containers.yaml file. This describes the source and destination image locations consumed by the upload command.
To copy the pre-built images coming from the rdoproject registry to the local repository,
the following commands are run. The first sets up the
overcloud_containers.yaml
configuration file containing the
pull and push destinations:
openstack overcloud container image prepare \
--namespace trunk.registry.rdoproject.org/master \
--tag <tag> \
--push-destination 192.168.24.1:8787 \
--output-env-file ~/docker_registry.yaml \
--output-images-file overcloud_containers.yaml
Then upload the images to the local registry using the generated file:
openstack overcloud container image upload --config-file overcloud_containers.yaml
Or build and push the images <build_container_images>
yourself. This is useful if you wish to customize the containers or
modify an existing one.
Deploying the containerized Overcloud
A containerized overcloud deployment follows all the steps described
in the baremetal deploy-the-overcloud
documentation with the exception
that it requires extra environment files to be added to the
openstack overcloud deploy
command:
-e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml
-e ~/docker_registry.yaml
If deploying with highly available controller nodes, include the following extra environment file in addition to the above and in place of the environments/puppet-pacemaker.yaml file:
-e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml
Using TripleO Quickstart
Note
Please refer to the TripleO Quickstart docs for more info about quickstart, the minimum requirements, the setup process and the available plugins.
The command below will deploy a containerized overcloud on top of a baremetal undercloud:
bash quickstart.sh --config=~/.quickstart/config/general_config/containers_minimal.yml $VIRTHOST