2014-06-21 19:15 GMT+02:00 Steffen Prince <[email protected]>: > @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 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. > > 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. > > 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. >
This is exactly where we are. For one, tools like Fleet, Flynn, Deis, etc., etc. seem heavyweight when we consider our current needs. Also, the tools do not seem mature enough ... heck, even us are probably not mature enough yet!! The road towards maturity is certainly not a "big bang", and managing our dozen of stateless container instances, each one dedicated to a specific need (not talking about horizontal scalability of dozens of anonymous / interchangeable role-only based nodes here!) will be done via a static inventory file for the time being. It seems that the Docker module will fill most if not all our needs in the mean time. Thanks to all for your insights and good advices! -- Laurent > > 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/CAKVVxfqd2zDmksf-ETjkJqGMYanzR5stdRbpXxV_yX91VGbE_g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
