Allow image creation to be run via docker-compose

[azanar]

Is your feature request related to a problem? Please describe

Indirectly. I'd like to fix #1020, which is affecting my ability to hack on a C++ project within GitPod.

Describe the behaviour you'd like

I would love to be able to fire up a workspace-images build with just a docker-compose command. Something like:

docker-compose run gitpod-io/workspace-images:latest ./build-all.sh

To build the workplace-images environment, I'd imagine something like:

docker build -t gitpod-io/workspace-images:latest .

Describe alternatives you've considered

The alternative is to fire up image creation via the contributing instruction.

This has two limitations:

1. It couples image creation strongly to GitPod. This isn't ideal for those who pay-as-we-go on GitPod, and would like to limit burning our credits when not necessary.
2. It makes .gitpod.yml unnecessarily complicated, akin to a sort of Greenspun's docker-compose.yml. The workspace-full image comes with docker-compose. This is not to disparage the power of .gitpod.yml. 🙂

Changes required:

1. This repository would grow a Dockerfile, and a docker-compose.yml file. The Dockerfile could be modeled after .gitpod.Dockerfile
2. The Dockerfile could use the dazzle image as a base image, since buildkit could now be pulled in as an entirely separate container.
3. The docker-compose.yml could stand up and network the services much as they are now.
4. Dazzle would want to get a buildkit address from something other than a CLI flag, to avoid needing to pass that flag on every call. My bias would be toward an env var. This would make it simple to pass to all dazzle runs from a single docker-compose setting.
5. If the above incantation is too verbose, it could be wrapped into a script.

Changes 1-3 are captured in a PR coming soon.
Change 4 will be captured in a dazzle PR also coming soon.

Current roadblocks:

The registry connection logic of dazzle very badly wants to connect over https to the registry. Since the network is just a bridge between containers, I'd rather just figure out how to make http work.

Possible improvements:

1. Complete images are moved to a registry not within docker-compose. This could be a passable option for them to get written pretty much anywhere docker push can reach.

Additional context

Worth noting that this would also work with podman.

[kylos101]

Hey @azanar ,

For cmake, please see how I added and tested, #1020 (comment), and lemme know if you have any questions?