WIP: create base and base-x11 images, move common init functionality to them

[zb140]

I had so much fun refactoring the compose files, I did some refactoring on the Dockerfiles too 😁

The biggest improvements are

• I created a base and a base-x11 image. These are used to keep container init logic like creating users, ensuring device access, etc in one central location. They also provide a central place to change the "actual" base distro for all containers at the same time.
• All containers are now based on ubuntu:22.04. This fixes build issues associated with ubuntu:21.04 being EOL.
• Streamlined the container startup process to eliminate duplicated code
• Made some (admittedly small) optimizations for image size

If anyone wants to give these images a try, I've published builds of them on my own GitHub account (eg ghcr.io/zb140/gow-sunshine:refactor).

This PR is not quite ready for merge as-is. Some things that still need doing:

• In order to get the images built on GitHub, there's a bunch of places that reference images in my GitHub account. Those would need to change to the real GoW account.
• I had to modify .github/workflows/docker-build.yml in a couple of places. Most notably, I had to disable parallel builds because I couldn't figure out how to specify dependencies between matrix entries. If that turns out to be impossible, I'll need to figure out a different solution.
• The Sunshine Dockerfile in this branch is currently set up to build the forked branch that contains the Pulseaudio crash fix. We'll probably want to switch that to something else, or else not merge this until after that bug is fixed.
• Probably other stuff that I haven't thought of. (Anyone who has any thoughts, feel free to chime in and add tasks 😄)

[Sparticuz]

My testing of pulseaudio revealed:

• We don't need ipc: ${XORG_IPC} in compose/headless.yml for the pulseaudio container
• We aren't pushing pulseaudio over tcp/udp, so EXPOSE 4713 is useless in images/pulseaudio/Dockerfile. (
• There are some settings here that we might want to add. (default-server, and enable-shm)

[ABeltramo]

We aren't pushing pulseaudio over tcp/udp, so EXPOSE 4713 is useless in images/pulseaudio/Dockerfile.

It's effectively not doing anything though right?
I would like to keep it there because it's a nice hint to what the default port will be. Bear in mind that while the default for us is to share the socket nothing should prevent users to instead use the network socket, the end goal is to make general porpoise images that can be used in different environments (desktop, headless, ...).

I agree on all the rest, most of the current settings are the result of experiments that lead to a "working" environment, we should probably revisit them and choose better defaults.

[zb140]

I've just pushed a new version that includes a handful of small changes. Most notably, I refactored the build workflow into a reusable component that does the actual work of building/publishing, and a caller component that builds the images in the correct order, including in parallel where possible.

Still blocking this merge:

• The sunshine bug. I could just remove the switch to New Sunshine from this branch, but the bugfix should be merged soon, and there's no real rush to get this out by any particular time.
• All of the stuff that I changed to be able to build/publish images in my own GitHub account need to be reverted.

I've been using my images for a week or so at this point and they seem to be working well. If anyone else has taken the time to give them a try, I'd love to hear your thoughts!

[ABeltramo]

I really like the direction where this is heading; unfortunately I can't really try this on my test machine because seems like run-gow build doesn't work for me..

[ABeltramo]

This will have to be changed before merging

[ABeltramo]

Nice, I really like this.. We ended up never using the manual trigger but I like to be able to specify which image needs to be updated!

[Sparticuz]

Should this also run apt-get upgrade to update all the packages in the base?

[zb140]

In the Dockerfile best practices guide, they used to recommend not running apt-get upgrade inside a container, but they removed that comment about a year ago. I'm not sure why they got rid of it, but I think common practice is still to assume the base images are generally kept up to date. I'm happy either way though -- if we think it's better to run upgrade I'll make the change.

[Sparticuz]

I think we need to do some research into this, (unless @ABeltramo knows) if every game containers needs the drivers, then it should go here, otherwise, if only xorg requires the drivers, then it should go there.

[zb140]

I tried looking around on Google and couldn't really come to any obvious conclusions. I'm inclined to merge as-is and we can always move packages around in future revisions as we learn more about what the requirements are. What does everyone think? @ABeltramo @Sparticuz

[zb140]

I believe this change is pretty much ready to go, apart from the Sunshine PR getting merged. It's such a small change, hopefully it will get reviewed and merged soon. In the meantime, we could consider just merging this (which uses the branch with the bugfix directly) and switch back to "main" Sunshine after the merge.

[ABeltramo]

First off, thanks for all your work on this!! I have tested it, and it works perfectly on my system too.

I think there are still a couple of things to fix before merging it:

Build images

Unless I'm missing something, there's no easy way to build images when someone doesn't want to pull from the registry or even for us to debug and test things.
I've manually run the followings:

docker build -t ghcr.io/games-on-whales/base:edge --build-arg BUILD_OWNER=games-on-whales --build-arg BUILD_TAG=edge  images/base
docker build -t ghcr.io/games-on-whales/base-app:edge --build-arg BUILD_OWNER=games-on-whales --build-arg BUILD_TAG=edge  images/base-app
docker build -t ghcr.io/games-on-whales/xorg:edge --build-arg BUILD_OWNER=games-on-whales --build-arg BUILD_TAG=edge  images/xorg
docker build -t ghcr.io/games-on-whales/pulseaudio:edge --build-arg BUILD_OWNER=games-on-whales --build-arg BUILD_TAG=edge  images/pulseaudio
docker build -t ghcr.io/games-on-whales/sunshine:edge --build-arg BUILD_OWNER=games-on-whales --build-arg BUILD_TAG=edge  images/sunshine
docker build -t ghcr.io/games-on-whales/steam:edge --build-arg BUILD_OWNER=games-on-whales --build-arg BUILD_TAG=edge  images/steam

There are possibly two problems here:

• Order matters: you'll have to build base first, then base-app, then the rest. If we ever change this or add other dependencies this order needs to be updated/documented
• It can't be done just by using docker-compose (probably). I'm not sure if you can specify those base and base-app to be build requirements without also creating running containers.

I'm not sure what's the best way to "fix" this, at the very least this should be documented, but maybe we should support it in the bash script; what do you guys think?

Hardcoding ghcr.io

We are currently pushing images both to the GitHub registry and Docker hub.
I think that it would be best to also have the base registry as a build argument instead of being hardcoded as ghcr.io.

[zb140]

Great points! For the build, how about a workflow that manually builds an image (including dependencies) that can be run locally with https://github.com/nektos/act ? That way we don't need to build our own dependency handling etc into a build script.

I'm happy to add the registry as a build arg. If we build one image with FROM ghcr.io/... and another with FROM [dockerhub], will they have the same checksum as long as the base images have the same checksum?

[ABeltramo]

Great points! For the build, how about a workflow that manually builds an image (including dependencies) that can be run locally with https://github.com/nektos/act ? That way we don't need to build our own dependency handling etc into a build script.

That's one way of keeping it consistent, I like it. Can you add a couple of lines to the relative docs page?

I'm happy to add the registry as a build arg. If we build one image with FROM ghcr.io/... and another with FROM [dockerhub], will they have the same checksum as long as the base images have the same checksum?

The checksum should be based on the content of the images IIRC.
Ideally though, we should build once and then add both tags and push (I believe that's how it used to be but I might be wrong here)..

[zb140]

The checksum should be based on the content of the images IIRC.
Ideally though, we should build once and then add both tags and push (I believe that's how it used to be but I might be wrong here)..

Yeah, we're just building it once and tagging it for both. I was concerned that if we add a build arg for the registry it might end up getting built twice. But I suppose the "main" build would just pick one and always build with the same registry.

I'll work on adding these changes (including the docs update) a bit later today.

[zb140]

I'll work on adding these changes (including the docs update) a bit later today.

Famous last words 😉 I've had a super hectic couple of days, but I fully expect things to go back to normal-ish by this weekend.

[zb140]

We are currently pushing images both to the GitHub registry and Docker hub.
I think that it would be best to also have the base registry as a build argument instead of being hardcoded as ghcr.io.

I actually ended up just making the whole base image name a build argument; this way, we don't have 3 separate args that get combined to make the image name, and it's much easier to build the base images locally and use them instead of our published images. I've also put lots of detail in the docs about how to build any or all of the images locally.

Also, I started down the path of using https://github.com/nektos/act to build images locally, but I ran into a few issues:

• Configuring and executing the build locally is a bit overly complicated. For instance, specifying which image you want to build requires creating a JSON file in a specific format.
• Building the base images as well as app images was going to require multiple passes anyway
• Specifying multiple images to build at the same time requires even more complicated configuration
• It's a separate tool to install

I ended up adding a couple of environment variables (in env/build.env) to specify which images to use for base and base-app, and configuring the compose files to provide them as build arguments. By default it will build using our published images, but people are free to build their own base images locally and specify them instead. Much easier to explain in the docs, and doesn't require any complicated setup or config 😄

I played around locally with building various combinations of base and app images, and it seems to be working well. Let me know what you think!

[ABeltramo]

First off, sorry for the time it took me to review the latest changes..

I ended up adding a couple of environment variables (in env/build.env) to specify which images to use for base and base-app, and configuring the compose files to provide them as build arguments. By default it will build using our published images, but people are free to build their own base images locally and specify them instead. Much easier to explain in the docs, and doesn't require any complicated setup or config

I just tried out this by following the few steps outlined in the docs, I like it a lot! I think this is the easiest way, and it makes perfect sense with how Docker works.

All works on my test system too, are we finally ready to merge this? 😅

[zb140]

I made one small change to prevent an annoying but harmless warning about missing env vars for building your own images even when you're not trying to build them. I think it's ready to go! Unless someone objects, I'll probably go ahead and merge it this afternoon.