On Sunday, June 22, 2014 9:16:24 AM UTC-7, Michael DeHaan wrote: > > I mean this: > > > http://www.ansible.com/blog/2014/02/12/installing-and-building-docker-with-ansible > > <http://www.google.com/url?q=http%3A%2F%2Fwww.ansible.com%2Fblog%2F2014%2F02%2F12%2Finstalling-and-building-docker-with-ansible&sa=D&sntz=1&usg=AFQjCNFeChm3OBufPZEOHxyWKFUBKmRvRw> >
Awesome! I was dreading having to port our existing Ansible roles to Docker instructions. Now Docker bash instructions seem like a step backwards. I think you are right about the non-base layers not being terribly important, but it makes sense to me to try to put the seldom-changed, slow configuration tasks into separate layers. This should speed up builds significantly. Fortunately, you can do this with separate RUN instructions to execute playbooks containing those tasks. As an example, consider installing a non-system Python environment in its own playbook. We already use roles this way: a "Python 3" role, for example. I guess that's where our levels of interest differ - Ansible is used by a > lot of people with home setups and low-load startups, but it's really > designed for industry deployments and so forth, so we don't want to > advocate avenues that cause problems later. > > As such, I'm merely cautioning that manually placing Docker-containers is > a very "pre-cloud" way to do things, akin to keeping a spreadsheet of where > your virtual machines run. > > When something is too heavyweight, the question is really what does that > mean? Is it something someone doesn't want to learn, does it consume too > many resources, or is it something someone doesn't want to manage? > > And then the question really arises as to who is asking and for what > purpose. In many small shops, this may be in fact totally ok. I'm just > saying it doesn't scale, and as such, is a bit less interesting to me > trying to build that out. > > I guess what I'm saying is I don't want to be a baby-cloud and all the > extra bolts and underpinnings it would require to make that viable, as > pretty soon people wonder about storage and monitoring and other bits - and > better placement engines - how to migrate systems, etc. > > I'd rather our provisioning modules leverage other tools that already do > these things. > > And I do recognize many of these are still too new and evolving yet. > I put a lot of value on simplicity, but I will take the more complex solution if it solves a real problem and "just works". There's just not enough of a problem of placing and linking several dozen containers using "unmagical" automation tools. It is obvious this more manual approach will not scale with either very large or highly dynamic clusters. But there are so many shops that will never run in to this kind of scaling problem, and I think it is unproductive for them to swallow PaaS-scale solutions. At least with the current generation of fancy container orchestrators, I really doubt there's a good ROI. That said, I do understand the focus on large-scale automation. And I see your point about not wanting to waste effort on building in more Docker orchestration than what the current `docker` module offers. But it would be nice if the current `docker` module received some priority with respect to bug fixes and tracked Docker releases closely. I think a lot of us using Ansible and Docker for small-medium scale setups would be very happy! With respect to Laurent's original problem, I guess I would accept a little downtime to run some ad-hoc commands to move the container, after putting the new configuration into Ansible. I would not expect Ansible to manage container migration for me. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/e9a7016f-e999-4ab1-b3b1-cc4f60a7cb86%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
