PL, So my bad, I actually own the cloudstack org on Docker hub. I just added you as a member. You can publish your images there and delete the apachecloudstack org. I think it’s better to just use ‘cloudstack'
> On Mar 24, 2015, at 2:26 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote: > > some addition inline: > > On Tue, Mar 24, 2015 at 9:13 AM, Sebastien Goasguen <run...@gmail.com> > wrote: > >> >>> On Mar 24, 2015, at 1:58 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote: >>> >>> I've played a little with Docker over the weekend, here are some thought >>> and I'd like to have some input from community around this, >>> >>> 1. simulator: >>> I'v create a Jenkins[1] job that build a simulator container an push it >> to >>> the docker org: apachecloudstack [2]. It is only done for master branch >> at >>> the moment and the image is fairly big, ~2GB, using Sebastien's >> Dockerfile. >>> >> >> Cool. >> And yes the image is big, we can modify the Dockerfile to remove some >> maven stuff and make it smaller. >> Maybe even just run the jar like Ian has done for devcloud. >> >>> This will be perform for other branches but based on commit instead of >>> daily, probably. >>> >>> 2. cloudstack-management + database >>> >>> As the current simulator image contain MySQL, Maven, CloudStack git >> repo,.. >>> it's quite big and not the "Docker" way, IMO. >> >> Correct. I just did it for devs…this is not meant for any type of prod >> > This should be clear that it is not for prod since the DB would have been > pre-installed > > >>> So I'd like to see how it >>> would make sense provide two containers instead of one: >>> 1. cloudstack-database: mysql database with the initialized DB's (cloud, >>> cloud_usage)... >>> 2. cloudstack-management: pre installed cloudstack-management server >>> including tomcat dependencies,... >>> 3. cloudstack-usage: pre installed cloudstack-usage >>> >> >> You can create a mgt server image and then link it to two or one mysql >> containers. >> the mgt server image can be setup with the packages. >> >> I ran into problems with IP tables etc. since our setup scripts are not >> meant for containers. > > I've experience this too, the container would be prepared without > "cloudstack-setup-management" as it expect to modify firewall which is not > available into container. > > >> >> >>> This imply that build of those containers would be done thru Jenkins for >>> the most part and use of Dockerfile might be difficult, which wouldn't >>> allow to use dockers automatic builds. >>> >> >> you could have dockerfiles and an auto build in docker hub. >> Just use the build trigger in docker hub to setup a hook in the jenkins >> job that builds the latest packages. >> > > The way I'm seeing things, because the DB would pre-initiated and into a > separate container, I would not use dockerfile to build it, unless there is > a way to create link at build, this is to provide the smallest container as > possible. > > Also, I would use package (RPM,deb) to install cloudstack-management so it > will enforce the test/validation of packaging, and would make containers > more close to prod like deployement. > > >> >> You could put the dockerfile in /tools or something > > Good Idea I'll place Dockerfiles into /tools/docker > > > >>> >>> >>> [1] http://jenkins.buildacloud.org/job/build-master-simulator-docker/ >>> [2] https://registry.hub.docker.com/repos/apachecloudstack/ >>> >>> >>> On Fri, Mar 20, 2015 at 4:04 AM, Sebastien Goasguen <run...@gmail.com> >>> wrote: >>> >>>> >>>>> On Mar 20, 2015, at 2:43 AM, Pierre-Luc Dion <pd...@cloudops.com> >> wrote: >>>>> >>>>> Look like some work as been done to have a Dockerfile in our repo which >>>>> build a CloudStack container easily. I'm curious to know if one of us >> own >>>>> the cloudstack organisation and if so, if it would make sense to start >> to >>>>> have our own automated build of container for CloudStack. I would >> easily >>>>> see 2 build job for two containers: cloudstack-management and >>>>> cloudstack-simulator. >>>>> we could easily build a nightly build of master and offer latest GA >>>>> releases. >>>>> >>>>> Look like it would be easy to automate builds and the simulator >> container >>>>> could be use for the CI as it is for the fast-simulator jenkins tasks. >>>>> >>>>> >>>>> any thought? >>>> >>>> +1, I committed the Dockerfile. >>>> >>>> But yes we should have a cloudstack organization in docker hub and setup >>>> automated builds. >>>> >>>> Ideally we can also setup a drone.io instance to do some continuous >>>> deployment…but this ties with the overalll jenkins/testing infra that we >>>> really need to get cleaned up and organized. >>>> >>>> -sebastuen
