TripleO and Docker
Change-Id: I7d153b0341e148274590d3d049cf0e2141369e58
This commit is contained in:
James Slagle
parent
35c975a2b3
commit
336248ea1d
|
|
@ -0,0 +1,216 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==================
|
||||
TripleO and Docker
|
||||
==================
|
||||
|
||||
# TODO: file the actual blueprint...
|
||||
https://blueprints.launchpad.net/tripleo/+spec/tripleo-and-docker
|
||||
|
||||
The goal of this spec is to detail how Docker might be used within TripleO to
|
||||
run the services needed for the Overcloud. Docker is an attractive
|
||||
implementation for TripleO because it provides benefits around application
|
||||
isolation, security, and ease of upgrading/downgrading.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
The deployer wants to use Docker containers for Overcloud services, as opposed
|
||||
to using baremetal nodes to deploy overcloud images.
|
||||
|
||||
We should support running each Overcloud service in its own container in order
|
||||
to be as flexible as possible to deploy needs.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
In order to make Docker containers available as deployment targets for the
|
||||
Overcloud, we need Nova Compute nodes configured to use the Docker driver
|
||||
registered with the undercloud Nova.
|
||||
|
||||
Even when you plan to deploy to containers, the undercloud must still be
|
||||
running a Nova compute with the ironic driver in order to allow for scaling
|
||||
itself out to add additional compute nodes.
|
||||
|
||||
To accmplish this, we can run 2 Nova compute processes on each undercloud node.
|
||||
One configured with Nova+Ironic and one configured with Nova+Docker. For the
|
||||
straight baremetal deployment, where Docker is not desired, it will not be
|
||||
included. This would be accomplished via the standard inclusion/exclusion of
|
||||
elements during a diskimage-builder tripleo image build.
|
||||
|
||||
To minimize the changes needed to the elements, we will aim to run a full init
|
||||
stack in the container, such as systemd. This will allow all the services that
|
||||
we need to also be running in the container (cloud-init, os-collect-config,
|
||||
etc). It will also make troubleshooting similar to the baremetal process in
|
||||
that you'd be able to ssh to individual containers, read logs, restart
|
||||
services, turn on debug mode, etc.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
An alternative to having the undercloud deploy additional Docker compute nodes
|
||||
would be to register additional baremetal nodes with the seed vm, and then
|
||||
describe an undercloud stack in a template that is the undercloud controller
|
||||
and it's set of Docker compute nodes. When the undercloud is deployed via the
|
||||
seed, all the nodes are set up initially.
|
||||
|
||||
The drawback with that approach is that the seed is meant to be short-lived in
|
||||
the long term. So, it then becomes difficult to scale out the undercloud if
|
||||
needed. We could offer a hybrid of the 2 models: launch all nodes initially
|
||||
from the seed, but still have the functionality in the undercloud to deploy
|
||||
more Docker compute nodes if needed.
|
||||
|
||||
We should also consider any non-baremetal Nova driver as a possible target of
|
||||
deployment for Overcloud services. Someone may desire to deploy overcloud
|
||||
services running in kvm or libvirt+lxc, etc.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
None
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
We should aim for equivalent security when deploying to containers as we do
|
||||
when deploying to baremetal. To the best of our ability, it should not be
|
||||
possible to compromise the container if an individual service is compromised.
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
We should document the option of deploying to Docker containers in our
|
||||
deployment docs in tripleo-incubator.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
Ideally, deploying an overcloud to containers should result in a faster
|
||||
deployment than deploying to baremetal.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
The main impact to deployers will be the ability to use containers if they
|
||||
wish. They also must understand how to use nova-baremetal/ironic on the
|
||||
undercloud to scale out the undercloud and add additional docker compute nodes
|
||||
if needed.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
Developers working on TripleO will have the option of deploying to containers.
|
||||
This should make testing and developing on some aspects of TripleO easier due
|
||||
to the need for less vm's.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
james-slagle
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
tripleo-image-elements
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
Where needed, we should continue breaking out individual elements into smaller
|
||||
fined grained units. When deploying containers, the service running in the
|
||||
container should be the smallest unit of scale where possible, so that
|
||||
individual services can be scaled up/down as needed.
|
||||
|
||||
nova-api is one such example, which actually installs 5 different services.
|
||||
|
||||
We also need new elements for the nova docker driver and docker registry. The
|
||||
element for the nova docker driver should allow it to be installed alongside
|
||||
another nova compute process (different nova.conf, etc).
|
||||
|
||||
tripleo-heat-templates
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
tripleo-heat-templates would be changed to break out each service where needed
|
||||
into it's own template. For example, instead of having an overcloud control and
|
||||
compute template, we would have template fragments for each service that somone
|
||||
might desire to deploy separately in a container.
|
||||
|
||||
This would follow similarly to what's been done today for cinder and swift, but
|
||||
would take it a step further and break it out into per service templates.
|
||||
|
||||
The Makefile (and if needed, merge.py) would be updated so that the same set of
|
||||
undercloud/overcloud templates could be generated as they are today.
|
||||
|
||||
This change is beneficial because whether you're deploying via baremetal or
|
||||
Docker, you'd be using the same template source.
|
||||
|
||||
Makefile targets would be added for each service in tripleo-heat-templates.
|
||||
|
||||
If needed, separate Makefile targets would be added if the one overcloud.yaml
|
||||
couldn't be used for both a baremetal and Docker deployment.
|
||||
|
||||
The ability to generate a template for an undercloud node that is running both
|
||||
compute+ironic and compute+docker would also be added to the Makefile.
|
||||
|
||||
diskimage-builder
|
||||
^^^^^^^^^^^^^^^^^
|
||||
We'd also need diskimage-builder steps that show how to build images for the
|
||||
docker compute nodes. We'd support the same set of base OS's that we do today,
|
||||
where Docker is well supported (Ubuntu, Fedora, etc).
|
||||
|
||||
Buidling docker images via diskimage-builder ought to be pretty straightforward
|
||||
since a docker image is just a tarball of the file system.
|
||||
|
||||
The resultant images can then be imported into Docker and pushed to a registry
|
||||
that has the undercloud glance configured as a backend. The images will then be
|
||||
available in glance for use by Nova/Heat.
|
||||
|
||||
Nova scheduling filters
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
Since the undercloud will have compute nodes registered with different
|
||||
compute_driver configurations, ComputeFilters and ImagePropertiesFilter may
|
||||
need to be used to make sure the Docker compute nodes are used for the
|
||||
overcloud deployment and the baremetal compute nodes are used for scaling out
|
||||
the undercloud itself. The image property hypervisor_type can be set on images
|
||||
in glance to make sure certain images are deployed to certain hypervisors.
|
||||
|
||||
If needed, an option could be added to load-image to set this property on
|
||||
Docker images.
|
||||
|
||||
tripleo-incubator
|
||||
^^^^^^^^^^^^^^^^^
|
||||
Document how to use Docker to deploy the overcloud.
|
||||
|
||||
Document how to troubleshoot an Overcloud running in Docker.
|
||||
|
||||
Add an option to devtest to use Docker to deploy the overcloud.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
This effort depends on continued development on the nova Docker driver. We
|
||||
would need to drive any missing features or bugfixes that were needed in that
|
||||
project: https://git.openstack.org/cgit/stackforge/nova-docker
|
||||
|
||||
Testing
|
||||
=======
|
||||
We would need a separate set of CI jobs that were configured to deploy an
|
||||
Overclout to Docker. The CI jobs should be considered non-voting since they'd
|
||||
rely on a stackforge project which isn't officially part of OpenStack.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
As yet, there are no official OpenStack docs for TripleO. However, we should
|
||||
update the TripleO specific docs in tripleo-incubator to document how to use
|
||||
Docker for an Overcloud deployment.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
Juno Design Summit etherpad: https://etherpad.openstack.org/p/juno-summit-tripleo-and-docker
|
||||
Loading…
Reference in New Issue