Open Stack

----- Original Message -----
> Same thing works with cloud init too...
> 
> 
> I've been waiting on systemd working inside a container for a while. it seems
> to work now.

oh no...

> The idea being its hard to write a shell script to get everything up and
> running with all the interactions that may need to happen. The init system's
> already designed for that. Take a nova-compute docker container for example,
> you probably need nova-compute, libvirt, neutron-openvswitch-agent, and the
> celiometer-agent all backed in. Writing a shell script to get it all started
> and shut down properly would be really ugly.
>
> You could split it up into 4 containers and try and ensure they are
> coscheduled and all the pieces are able to talk to each other, but why?
> Putting them all in one container with systemd starting the subprocesses is
> much easier and shouldn't have many drawbacks. The components code is
> designed and tested assuming the pieces are all together.

What you need is a dependency model that is enforced outside of the containers. Something
that manages the order containers are started/stopped/recovered in. This allows
you to isolate your containers with 1 service per container, yet still express that
container with service A needs to start before container with service B.

Pacemaker does this easily. There's even a docker resource-agent for Pacemaker now.
https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/docker

-- Vossel

ps. don't run systemd in a container... If you think you should, talk to me first.

> 
> You can even add a ssh server in there easily too and then ansible in to do
> whatever other stuff you want to do to the container like add other
> monitoring and such....
> 
> Ansible or puppet or whatever should work better in this arrangement too
> since existing code assumes you can just systemctl start foo;
> 
> Kevin
> ________________________________________
> From: Lars Kellogg-Stedman [lars at redhat.com]
> Sent: Tuesday, October 14, 2014 12:10 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [kolla] on Dockerfile patterns
> 
> On Tue, Oct 14, 2014 at 02:45:30PM -0400, Jay Pipes wrote:
> > With Docker, you are limited to the operating system of whatever the image
> > uses.
> 
> See, that's the part I disagree with.  What I was saying about ansible
> and puppet in my email is that I think the right thing to do is take
> advantage of those tools:
> 
>   FROM ubuntu
> 
>   RUN apt-get install ansible
>   COPY my_ansible_config.yaml /my_ansible_config.yaml
>   RUN ansible /my_ansible_config.yaml
> 
> Or:
> 
>   FROM Fedora
> 
>   RUN yum install ansible
>   COPY my_ansible_config.yaml /my_ansible_config.yaml
>   RUN ansible /my_ansible_config.yaml
> 
> Put the minimal instructions in your dockerfile to bootstrap your
> preferred configuration management tool. This is exactly what you
> would do when booting, say, a Nova instance into an openstack
> environment: you can provide a shell script to cloud-init that would
> install whatever packages are required to run your config management
> tool, and then run that tool.
> 
> Once you have bootstrapped your cm environment you can take advantage
> of all those distribution-agnostic cm tools.
> 
> In other words, using docker is no more limiting than using a vm or
> bare hardware that has been installed with your distribution of
> choice.
> 
> > [1] Is there an official MySQL docker image? I found 553 Dockerhub
> > repositories for MySQL images...
> 
> Yes, it's called "mysql".  It is in fact one of the official images
> highlighted on https://registry.hub.docker.com/.
> 
> > >I have looked into using Puppet as part of both the build and runtime
> > >configuration process, but I haven't spent much time on it yet.
> >
> > Oh, I don't think Puppet is any better than Ansible for these things.
> 
> I think it's pretty clear that I was not suggesting it was better than
> ansible.  That is hardly relevant to this discussion.  I was only
> saying that is what *I* have looked at, and I was agreeing that *any*
> configuration management system is probably better than writing shells
> cript.
> 
> > How would I go about essentially transferring the ownership of the RPC
> > exchanges that the original nova-conductor container managed to the new
> > nova-conductor container? Would it be as simple as shutting down the old
> > container and starting up the new nova-conductor container using things
> > like
> > --link rabbitmq:rabbitmq in the startup docker line?
> 
> I think that you would not necessarily rely on --link for this sort of
> thing.  Under kubernetes, you would use a "service" definition, in
> which kubernetes maintains a proxy that directs traffic to the
> appropriate place as containers are created and destroyed.
> 
> Outside of kubernetes, you would use some other service discovery
> mechanism; there are many available (etcd, consul, serf, etc).
> 
> But this isn't particularly a docker problem.  This is the same
> problem you would face running the same software on top of a cloud
> environment in which you cannot predict things like ip addresses a
> priori.
> 
> --
> Lars Kellogg-Stedman <lars at redhat.com> | larsks @ {freenode,twitter,github}
> Cloud Engineering / OpenStack          | http://blog.oddbit.com/
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>