Agrees. There are many users using docker, but for different goals. Depends on requirements, the solutions are also different.
1. What OS ? 2. Use docker for packaging , demo or testing changes ? 3. Are packages ready ? official releases, nightly build or need to build packages from source code ? 4. Is mysql or madiadb cluster installed in the docker or external? 5. use simulator or physical resources ? Currently the all-in-1 docker image built from tools/docker/Dockerfile just works for me. 1. Ubuntu 20.04 2. demo or testing code changes 3. Build packages from source 4. Mysql is installed in docker image 5. Simulator is supported. Did not use physical resources yet but it seems not to be an issue. We can consider using separated docker images, for example 1 for packaging, 1 or 3 for db, 1 or 3 for management servers. It is more flexible. We can use docker-compose, swarm, or kubernetes to setup such an environment. -Wei On Wednesday, 17 November 2021, Marcus <shadow...@gmail.com> wrote: > Cool, we are on the same page there. I think I have something working to > share soon. > > I did also consider just installing RPMs or DEBs into a Docker image like a > standard install, which might be a good pattern for official releases so we > can rely on the same package dependency resolution for all of the > requirements. > > For development it is extra work to set up the packaging environment and > more time to run the RPM/DEB package process every time you want to try a > build but that’s still an option as well. Right now I’m just copying the > necessary files into a new Docker image stage like you might do in an RPM > spec. > > I feel like I also ran into an issue with some hard coding for x86_64 in > regards to the RPMs, which a direct build and package into Dockerfile > avoided. > > On Wednesday, November 17, 2021, Wei ZHOU <ustcweiz...@gmail.com> wrote: > > > Hi Marcus, > > > > Sometimes I use the docker images to build a simulator environment. the > > docker images are built from tools/docker/Dockerfile > > I have uploaded some images to > > https://hub.docker.com/repository/docker/ustcweizhou/ > cloudstack-simulator > > > > The docker images are very large indeed (1.78 GB after compression). I > > think it is because of two reasons > > (1) a jetty server is running , which requires the build of whole project > > (2.0 GB, including .java, .class and .jar) > > (2) run UI via `npm start` which it requires some npm components (~600GB > in > > ui/node_modules/) > > > > I was thinking of installing cloudstack-management and cloudstack-ui > > instead of running jetty/UI from source code. > > I finally gave it up because there is no package for cloudstack simulator > > on ubuntu 20.04 ( as said I normally use it for simulator). > > > > -Wei > > > > On Tue, 9 Nov 2021 at 18:15, Marcus <shadow...@gmail.com> wrote: > > > > > Hi all, I've been familiarizing myself with the Docker image tooling in > > > CloudStack, and I have a few questions. I've been playing with a > > > multi-stage build that shrinks the image from ~4Gi to ~800Mi, packages > > just > > > the jar, some UI, and a JDK thinking that it might be more usable. > > > > > > 1) Is there anyone actively using these Dockerfiles? It might be > > > interesting to know what workflows they're a part of and whether they > can > > > be changed or if new files should be created. > > > > > > 2) I see the Dockerfile.marvin points to a 'builds.cloudstack.org' to > > pull > > > a Marvin bundle, which seems to be down. Do these artifacts need to be > > > moved to 'download.cloudstack.org' or is this just a temporary outage, > > or > > > is it only reachable from CI? I do see the 'latest' tag pulls (which is > > > three years old). > > > > > >
