Thanks for creating this, much appreciated. Works great. It doesn't appear to have any zones/pods/hosts setup though, as you can do with the cloudstack simulator for the dev environment.
Could we add some info on this page about how to run it and perhaps login? https://registry.hub.docker.com/u/apachecloudstack/simulator/ I was able to start it with the following: docker run -p 8080:8080 apachecloudstack/simulator Cheers! On Tue, Mar 24, 2015 at 7:29 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote: > 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 <run...@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 <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 > > > > >
