On Sat, Jun 21, 2014 at 1:15 PM, Steffen Prince <[email protected]> wrote:
> @mpdehaan: Are you saying you see Ansible being called from Dockerfiles, > as from a RUN instruction? What does this offer above using Dockerfile > instructions directly? Since Docker interprets each instruction as a layer, > it seems you would lose the benefits of layer reuse if you called out to > Ansible for all your configuration. > I mean this: http://www.ansible.com/blog/2014/02/12/installing-and-building-docker-with-ansible What does Ansible offer over automating your entire infrastructure with just bash scripts? Exactly that. No one is really using much more than the base image support in docker for "layers". So deploy Ubuntu, apply Ansible for config. If you want to deploy ansible on top of other images, use this too. By no means does running Ansible instead of Dockerfiles having bash in them change the equation. > > I had considered Ansible to be a good tool for a Docker deployment on the > scale of a handful of hosts, fixed in number, and a few dozen containers. I > don't think of this small number of container hosts as a cloud/PaaS. With > respect to the containers in this context, I think of them more as > processes than as VMs, where Docker is desired to provide packaging and > isolation. > Doesn't matter - they are actually really small VMs/jails and can get arbitrarily large. Let's ignore the hype about whether it's a VM or not, it's serving the same purpose, but optimized a bit more towards running many containers oversubscribed rather than providing more complete isolation. Different tradeoff. > In this context, I think the manual placement and linking that the current > Ansible Docker module provides is a good fit. Given that Ansible should > already be in the toolkit for container host base configuration, it seems > logical to also use it for simple container orchestration. > I can see why some people don't want to contend with learning other layers of management software. I'm also not a big fan of continuing to provide glue to make that easier, as in the end, it's going to look inferior to the real thing. > > For the use case I described, I perceive some of the other engines such as > Fleet, Flynn, Deis, Centurion to be too heavyweight - I don't think small > deployments require dynamic placement, automatic container migration, or > service discovery that tools like these are trying to provide. I think > growing in to such tools when the cluster reaches a certain size is wise, > rather than taking on all that complexity up front just to run a relatively > small number of containers. > 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. > > On Thursday, June 19, 2014 2:17:04 PM UTC-7, Michael DeHaan wrote: > >> Right, I would agree. >> >> Build images with Ansible - stick in registry or wherever. "Cloud" >> thing may provide this. >> >> Have Ansible tell "cloud" scheduler how many images to deploy into >> "cloud" from registry. >> >> >> >> >> On Wed, Jun 18, 2014 at 12:28 PM, Drew Northup <[email protected]> >> wrote: >> >>> On Wednesday, June 18, 2014 11:33:20 AM UTC-4, Michael DeHaan wrote: >>>> >>>> Right, I'm saying this isn't sustainable or a good approach for most >>>> infrastructures - and while it may be fine for you I want to avoid steering >>>> people down that path as it has all the perils of "manual cloud" circa >>>> 2005-ish. >>>> >>> >>> For continued sanity of all involved I'd agree that avoiding manual >>> cloud partitioning is strongly recommended. It is ok for small experiments, >>> and not much more than that. >>> >>> As I was discussing with Paul Durivage yesterday, fleetd in CoreOS >>>> actually does provide this functionality too -- I was thinking more WRT the >>>> CoreOS base image solving a different problem. >>>> >>>> So having a module that allows Ansible to tell CoreOS "I want X >>>> instances of this image" would be pretty neat to see. Submissions welcome! >>>> >>> >>> I've been trying to work out how to leverage both Ansible and Docker >>> containers (may they be hosted using CoreOS, Project Atomic, Shipper...I >>> really don't care which at this point so long as it won't set the >>> datacenter on fire or something) going forward. My current thinking has the >>> existing docker module used as a system for building container images >>> pushed to a local registry. Something else (fleet, geard, mesos, Shipper's >>> gadget) manages the placement of containers onto hosts, after Ansible tells >>> it what to do. (Everyone sails off happily into the sunset...) >>> >>> That's my highly idealistic vision anyway. We'll see what happens. >>> >>> -- >>> 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/9a025224-1ae1-4eac-9d83- >>> 30ff4b1cdbca%40googlegroups.com >>> <https://groups.google.com/d/msgid/ansible-project/9a025224-1ae1-4eac-9d83-30ff4b1cdbca%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/d15e39b6-489e-4471-88c0-21f08b34b74a%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/d15e39b6-489e-4471-88c0-21f08b34b74a%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%2BnsWgzUCCGrHD4uyo0_dzaE338yLTWJomOru3e%3Ddm4G0SQjWA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
