"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"
And most of these shops don't need Docker. "But it would be nice if the current `docker` module received some priority with respect to bug fixes and tracked Docker releases closely" We do apply fixes on the docker modules pretty quickly, but they are also not so good about maintaining API compatibility, so it appears to break often - because it does. I'm hoping this stabilizes over time. On Tue, Jun 24, 2014 at 1:31 AM, Steffen Prince <[email protected]> wrote: > > 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 > <https://groups.google.com/d/msgid/ansible-project/e9a7016f-e999-4ab1-b3b1-cc4f60a7cb86%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CA%2BnsWgzck0SU4kL2S37a_30tcNtmkuDkDYCZ%2Bxq7sGbkq5MEsg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
