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 > >> > >> > >
