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 19:29:34 GMT
LOL,  look like Docker support is efficient :-P

I'll update jenkins jobs and destroy apachecloudstack org.

Thanks!




On Tue, Mar 24, 2015 at 3:18 PM, Sebastien Goasguen <runseb@gmail.com>
wrote:

> 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 <pdion@cloudops.com> wrote:
> >
> > 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