Hi Roman, Yes it's true, but pay attention at their criteria<http://blog.docker.io/2013/08/getting-to-docker-1-0/>of production ready product also many companies already use it in production. And recently they introduced<http://blog.docker.io/2014/02/docker-0-8-quality-new-builder-features-btrfs-storage-osx-support/> quality release. Anyway I think it's better to use docker than reinventing the wheel and to implement our own "production ready" container management system in several month.
Thanks On Tue, Feb 11, 2014 at 3:25 PM, Roman Zhnichkov <[email protected]>wrote: > Guys, > official Docker web site <https://www.docker.io/learn_more/> states > that it is not production ready. > > Why are we considering this solution for our carrier grade OpenStack life > cycle management tool? > > -- > Roman Zhnichkov > > > > On Mon, Feb 10, 2014 at 11:25 AM, Roman Alekseenkov < > [email protected]> wrote: > >> Team, >> >> We know some of the Docker engineering folks. If you need to talk to them >> about best practices, please let me know. >> >> Roman >> >> >> On Mon, Feb 10, 2014 at 8:45 AM, Dmitry Ilyin <[email protected]>wrote: >> >>> 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 >>> >>> >> >> -- >> 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
