Ability to deploy TripleO in Containers.
Linux containers are changing how the industry deploys applications by offering a lightweight, portable and upgradeable alternative to deployments on a physical host or virtual machine.
Since TripleO already manages OpenStack infrastructure by using OpenStack itself, containers could be a new approach to deploy OpenStack services. It would change the deployment workflow but could extend upgrade capabilities, orchestration, and security management.
Benefits of containerizing the openstack services include:
- Upgrades can be performed by swapping out containers.
- Since the entire software stack is held within the container, interdependencies do not affect deployments of services.
- Containers define explicit state and data requirements. Ultimately if we moved to kubernetes all volumes would be off the host making the host stateless.
- Easy rollback to working containers if upgrading fails.
- Software shipped in each container has been proven to work for this service.
- Mix and match versions of services on the same host.
- Immutable containers provide a consistent environment upon startup.
The intention of this blueprint is to introduce containers as a method of delivering an OpenStack installation. We currently have a fully functioning containerized version of the compute node but we would like to extend this to all services. In addition it should work with the new composable roles work that has been recently added.
The idea is to have an interface within the heat templates that adds information for each service to be started as a container. This container format should closely resemble the Kubernetes definition so we can possibly transition to Kubernetes in the future. This work has already been started here:
There are some technology choices that have been made to keep things usable and practical. These include:
- Using Kolla containers. Kolla containers are built using the most popular operating system choices including CentOS, RHEL, Ubuntu, etc. and are a good fit for our use case.
- We are using a heat hook to start these containers directly via docker. This minimizes the software required on the node and maps directly to the current baremetal implementation. Also maintaining the heat interface keeps the GUI functional and allows heat to drive upgrades and changes to containers.
- Changing the format of container deployment to match Kubernetes for potential future use of this technology.
- Using CentOS in full (not CentOS Atomic) on the nodes to allow users to have a usable system for debugging.
- Puppet driven configuration that is mounted into the container at startup. This allows us to retain our puppet configuration system and operate in parallel with existing baremetal deployment.
Once the node is up and running, there is a systemd service script that runs which starts the docker agents container. This container has all of the components needed to bootstrap the system. This includes:
- heat agents including os-collect-config, os-apply-config etc.
- puppet-agent and modules needed for the configuration of the deployment.
- docker client that connects to host docker daemon.
- environment for configuring networking on the host.
This containers acts as a self-installing container. Once started, this container will use os-collect-config to connect back to heat. The heat agents then perform the following tasks:
- Set up an etc directory and runs puppet configuration scripts. This generates all the config files needed by the services in the same manner it would if run without containers. These are copied into a directory accessible on the host and by all containerized services.
- Begin starting containerized services and other steps as defined in the heat template.
Currently all containers are implemented using net=host to allow the services to listen directly on the host network(s). This maintains functionality in terms of network isolation and IPv6.
There shouldn’t be major security impacts from this change. The deployment shouldn’t be affected negatively by this change from a security standpoint but unknown issues might be found. SELinux support is implemented in Docker.
Very little impact:
- Runtime performance should remain the same.
- We are noticing a slightly longer bootstrapping time with containers but that should be fixable with a few easy optimizations.
This work aims to allow for resilent, transparent upgrades from baremetal overcloud deployments to container based ones.
The developer work flow changes slighly. Instead of interacting with the service via systemd and log files, you will interact with the service via docker.
TripleO CI would need a new Jenkins job that will deploy an overcloud in containers by using the selected solution.