Let's try to use this http://www.packer.io/docs/builders/docker.html it integrates well with both docker and puppet
2014-02-10 Matthew Mosesohn <[email protected]>: > I'm not trying to go in that direction. I'm trying to build single > containers that run puppet... like a single class that runs classes > nailgun, nailgun::user, nailgun::venv, and nailgun::supervisor without > ostf, naily, postgres, etc for isolation. > > Yes, we may end up using some puppet manifests to orchestrate upgrades > just because there are a few providers that can do this. Starting and > stopping containers involves running commands and grabbing the > generated IDs and a bash script may not be the most elegant method. We > should use a smart tool that is atomic and can fail where we need it > and provide useful feedback. > > On Mon, Feb 10, 2014 at 6:41 PM, Vladimir Kuklin <[email protected]> > wrote: > > Matt > > > > You can easily rewrite puppet modules by writing Puppet provider for > Docker > > exec and applying puppet defaults class by class: e.g: > > > > Exec {provider=>Docker, ENV=>"export container_id=#{ID}"} > > > > > > On Mon, Feb 10, 2014 at 5:36 PM, Bogdan Dobrelya <[email protected] > > > > wrote: > >> > >> On 02/10/2014 03:07 PM, Dmitry Ilyin wrote: > >> > Actually it's a very promising idea to move to atomic lxc container > for > >> > our master node. > >> > > >> > Volumes used to run these containers could be packaged and easily > >> > installed or updated by just replacing the file by the new version. > >> > Container will also be compleatly independent and any changing would > not > >> > break any neighbour container. (Well... except database structures...) > >> > > >> > Such containers will be able to speak to each other through unix or > tcp > >> > sockets. > >> > Building such containers will require us to invent some automated > system > >> > but their installation and use would be much more reliable then our > >> > current technology. > >> > This method can also combine configuration flexibility of > >> > puppet-deployed nodes with speed and reliability of image-based > >> > provisioned systems. > >> > > >> > We should also look into using the same approach for controller and > even > >> > compute nodes. It could help us to find solution to our long lasting > >> > OpenStack upgrading problem. > >> AFIK, the main issue of Openstack upgrades is DB schema related (all > >> objects must have a versioning info, see > >> https://blueprints.launchpad.net/nova/+spec/unified-object-model, for > >> example). I doubt docker could help here. Please correct me, If I'm > wrong. > >> > > >> > > >> > 2014-02-10 Evgeniy L <[email protected] <mailto:[email protected]>>: > >> > > >> > Hi, > >> > > >> > > >> > As many of you may already know we started design/implementation > of > >> > master node upgrade feature. Here you can read the design document > >> > > >> > < > https://docs.google.com/a/mirantis.com/document/d/1Mem9LP7ysaHNNSltlCLPw36jHix5ULlKmsMgTViHfog/ > >. > >> > > >> > > >> > So, it's just status update of this feature. > >> > > >> > We want to use docker as containers management tool. > >> > > >> > > >> > *Here is Docker's pros and cons* > >> > > >> > Pros > >> > > >> > + > >> > > >> > > http://stackoverflow.com/questions/17989306/what-does-docker-add-to-just-plain-lxc > >> > > >> > + rest API (it will be very useful in case of plugins, when we'll > be > >> > able to setup new container from inside another container) > >> > > >> > + lxc requires us to design our own build process and networking > >> > > >> > + docker has a standard dockerfile format and tools to build > images > >> > and store them in git and do version management > >> > > >> > Cons > >> > > >> > - additional complexity > >> > > >> > - non-persistent containers, it can be solved with volumes > >> > > >> > > >> > > http://www.tech-d.net/2013/12/16/persistent-volumes-with-docker-container-as-volume-pattern/ > >> > > >> > > >> > > http://www.offermann.us/2013/12/tiny-docker-pieces-loosely-joined.html > >> > > >> > http://crosbymichael.com/advanced-docker-volumes.html > >> > > >> > - regarding non-persistent containers will be a lot of questions > >> > like "I patched nailgun but when I rerun container all changes are > >> > gone" (can be solved with documentation) > >> > > >> > > >> > Let us know if you have any ideas or questions. > >> > > >> > Thanks > >> > > >> > -- > >> > Mailing list: https://launchpad.net/~fuel-dev > >> > Post to : [email protected] > >> > <mailto:[email protected]> > >> > Unsubscribe : https://launchpad.net/~fuel-dev > >> > More help : https://help.launchpad.net/ListHelp > >> > > >> > > >> > > >> > > >> > >> > >> -- > >> Best regards, > >> Bogdan Dobrelya, > >> Skype #bogdando_at_yahoo.com > >> Irc #bogdando > >> > >> -- > >> Mailing list: https://launchpad.net/~fuel-dev > >> Post to : [email protected] > >> Unsubscribe : https://launchpad.net/~fuel-dev > >> More help : https://help.launchpad.net/ListHelp > > > > > > > > > > -- > > Yours Faithfully, > > Vladimir Kuklin, > > Senior Deployment Engineer, > > Mirantis, Inc. > > +7 (495) 640-49-04 > > +7 (926) 702-39-68 > > Skype kuklinvv > > 45bk3, Vorontsovskaya Str. > > Moscow, Russia, > > www.mirantis.com > > www.mirantis.ru > > [email protected] > > > > -- > > Mailing list: https://launchpad.net/~fuel-dev > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~fuel-dev > > More help : https://help.launchpad.net/ListHelp > > > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
