Document how to customise an image (optionally with templating)

[webbertakken]

Since this has only been discussed in a few issues (I rememeber some older discussions on gitlab) or discord, it could be useful to add a section in the documentation on how to precisely customize images for different file support.

We had an idea of adding some overhead during the pipeline runs to inject (install) blender on each build,this is the plugin system from Webber's comment above. Until we have support for this (if we accept to go that way), I think including an easy to follow guide in the documentation could be helpful for many.

Right now, all we have is this:
https://game.ci/docs/docker/customize-docker-images

It is helpful, but I think it can be improved. Just another idea on top of this, we could use the power of mdx (react in markdown files) to allow people to pick their unity version, the tool they want and generate some ready to use scripts to publish what they need.

Example: A react component that generates a script from a form

• dropdown: unity version
• checkboxes: the tools (file formats) you need (blender, etc)
• dropdown: GameCI version (feeding from docker releases list, auto picking the latest
• input text: docker username

result: a shell script that eases building and publishing customized docker images to docker hub.

Now this should be discussed and accepted in an issue before it gets developed to avoid wasting precious developer time 🙏

Originally posted by @GabLeRoux in game-ci/docker#181 (comment)

[cloudymax]

Thia one has been on my mind a lot because I feel like it a bit counter-intuitive from the standpoint that docker images are supposed to be immutable, single process, and versioned - but we ABSOLUTELY NEED the flexibility of customization between users as Unity is huge and has endless use cases.

I don't think there's a great way to instantly impart the context awareness of the many idiosyncracies and gachas that will arrise as the Docker ecosystem is split between Linux/Mac/Windows/x86/Arm and eventually WASM. Those all would require special changes to the images or underlying infra in different ways that are (right now at least) moving targets while apple sorts out Rosetta and windows itterates on WSL/WSL2/Arm. Let's not forget that in addition to Apt, wed need to cover brew, pip, flatpak, snap, go get, 3rd party Debs, chocolaty, Winget, etc... Which would be hell to natively inside a single docker container.

However, we can still customize the images without opening up the dockerfile by utilizing CM tools like puppet/chef/Ansible to attach to the container and perform declared actions

Typically, this is frowned on as it obfuscates some of the actions taken when inspecting the container only - but we are already breaking container beat practices by shipping the huge hoker it takes to run untiy so why stop now lol.

We also lose granular control over the layer count of the image by doing the above, however I think that there is a peripheral solution that we would probably run into anyway and that is building docker images inside K8s requires privileged mode, a security no-no.

Right now, the solutions to that issue I have seen are Google's Kaniko: https://github.com/GoogleContainerTools/kaniko or switching to a podman/buildah based setup.

Kaniko solves our security problem, and as a byproduct, also solves our image layer problem because all Kaniko builds are compressed into a single layer and bolted onto a scratch image. This has another fun side effect of shrinking most images compared to their docker-built counter-parts.

I think that by using a CM tool that defines build steps/package lists in a separate yaml/json/xml file then building the docker image via Kaniko we could provide the flexibility of custizable images via a friendlier abstraction.