cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Luc Dion <pd...@cloudops.com>
Subject Re: [DOCKER] cloudstack organisation
Date Tue, 24 Mar 2015 13:26:13 GMT
some addition inline:

On Tue, Mar 24, 2015 at 9:13 AM, Sebastien Goasguen <runseb@gmail.com>
wrote:

>
> > On Mar 24, 2015, at 1:58 PM, Pierre-Luc Dion <pdion@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 <runseb@gmail.com>
> > wrote:
> >
> >>
> >>> On Mar 20, 2015, at 2:43 AM, Pierre-Luc Dion <pdion@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
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message