@viraptor What I mean by using existing tools is based on my experience using it in production. I doubt docker can do similar. In order to create an image of container I just use the same chef, puppet or ansible playbook I will use for a physical server or a google compute instance i.e. launch a base container,run the playbook on container and then save it as a versioned image in a private image repository if it passes all the tests.

LXD makes it such a trivial job to host private image repository and serve it to a large cluster automatically that I don't need to break a sweat.

This way my infrastructure code is uniform be it compute instance, physical servers or containers. This is a beautiful thing in terms of infrastructure management be it micro-services architecture or monolith.

In our case all the code which launches container, create images, or launch physical server is same codebase following a unified pattern of doing things. In our setup we used many playbooks which we can built leveraging the work done by community for physical servers, VM's and containers.

In the docker world I cannot trust an image completely until I go through the code which is a mixture of how an image is built and which layers are used. If the image is built using successive images I need to really go back to each image code which is again a mixture of scripts, Dockerfile. Being a follower of Zen of Python PEP-20, I like explicit and hence like to know the details of images for use in production and generate them myself from base os images.

I was one of the first users of Docker when it was released, but was bit disappointed later when they try to move away from LXC to built their own layer. I wrote a blog post on it at http://www.vyomtech.com/2014/03/04/docker_and_linux_containe...