4 ms·

> You can certainly provision docker containers using ansible / chef / puppet. It's not popular, because they do way more than is required in those situations n

by u801e 8y ago

> You can certainly provision docker containers using ansible / chef / puppet. It's not popular, because they do way more than is required in those situations normally Could you elaborate on what you're referring to what they're doing beyond what's required? > A lot of larger applications on dockerhub are done that way From what I understand, you have to write the configuration management in a different way such that it doesn't require restarting services after configuration files have been updated. Converting an existing playbook or cookbook to work that way isn't trivial depending on how many things it's doing to provision the server.

viraptor 8y ago
> what they're doing beyond what's required? Chef, puppet, ansible and other config management tools are designed to run nicely in an existing system. That means if you want to do action X, they'll usually check if it's possible, try to resolve internal dependencies, handle potential errors, register the state change for report and other things. Most of that is unnecessary when you're building a docker image from scratch. You control all the dependencies - they're the lines before this one. You don't care about nice reports of partial failures - they should cause immediate aborts. You don't care about managing state - each step is it's own fully defined state. For example, if I remember correctly, chef will query available package list when you request something installed. It will also continue running independent recipes if the installation fails. When building images I want literally "apt-get install foo || crash_and_burn". > you have to write the configuration management in a different way such that it doesn't require restarting services after configuration files have been updated In my experience with cfmgmt - this needs to be implemented whether you build images or update running systems. There always comes a time when you want to change something but not trigger service updates. When building images that time is always.
- vikrantrathore 8y ago
  @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_containers_lxc_1_0_release.html http://www.vyomtech.com/2014/03/04/docker_and_linux_containe...

by u801e 8y ago

viraptor 8y ago

> what they're doing beyond what's required? Chef, puppet, ansible and other config management tools are designed to run nicely in an existing system. That means if you want to do action X, they'll usually check if it's possible, try to resolve internal dependencies, handle potential errors, register the state change for report and other things. Most of that is unnecessary when you're building a docker image from scratch. You control all the dependencies - they're the lines before this one. You don't care about nice reports of partial failures - they should cause immediate aborts. You don't care about managing state - each step is it's own fully defined state. For example, if I remember correctly, chef will query available package list when you request something installed. It will also continue running independent recipes if the installation fails. When building images I want literally "apt-get install foo || crash_and_burn". > you have to write the configuration management in a different way such that it doesn't require restarting services after configuration files have been updated In my experience with cfmgmt - this needs to be implemented whether you build images or update running systems. There always comes a time when you want to change something but not trigger service updates. When building images that time is always.

vikrantrathore 8y ago
@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_containers_lxc_1_0_release.html http://www.vyomtech.com/2014/03/04/docker_and_linux_containe...