Hi all, I've had various discussions about $subject, which have been re-started lately due to some excellent work going on in the Heat community (Rabi Mishra's work integrating SoftwareDeployments with various container launching tools [1])
tl;dr It's now possible to launch containers via heat SoftwareConfig resources in much the same way as we currently apply puppet manifests. I'm also aware there has been some great work going on around the kolla community making things work well with both docker-compose and atomic. I'm interested in discussing the next steps, which would appear to involve providing an optional way to deploy services via containers using TripleO. It seems that we can potentially build on the existing abstractions which were added for puppet integration, e.g: https://github.com/openstack/tripleo-heat-templates/blob/master/overcloud-resource-registry-puppet.yaml We could have an alternative resource-registry which maps in a different set of templates (which have the same parameter interfaces) which bootstrap a container host, and deploy each service in a container. This might look something like: https://github.com/hardys/heat-templates/blob/docker-host/hot/software-config/example-templates/example-docker-script.yaml This is just a simple example using "docker run", but similar (probably much cleaner) approaches will be possible using atomic, docker-compose and other tools. For example, here's an example of how we might bootstrap a pristine atomic image, install a privileged container hosting the agents needed to talk to heat, then use that container to launch containers with the services: https://review.openstack.org/#/c/164572/6/hot/software-config/example-templates/example-pristine-atomic-docker-compose.yaml Similar example for docker-compose: https://github.com/openstack/heat-templates/blob/master/hot/software-config/example-templates/example-docker-compose-template.yaml There does seem to be a variety of tools folks prefer, but the pattern appears to be the same in most cases: 1. Provide input parameters to the template 2. Map parameters to an environment consumable by the container-launching tool 3. Run the tool and wait for success It may be possible to abstract the details of the various tools inside the heat hooks, such that you could e.g choose the tool you want via a template parameter - e.g it should be possible to build the templates in a way which is somewhat tool-agnostic, if we get the heat interfaces refined correctly. What do people think, is this direction reasonable? I'm keen to figure out how we do a simple PoC which will bottom out the details, but it'd be great to get some feedback on the general approach. Thanks! Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
