Smaller footprint with alpine linux

[CyberT3C]

Hello Valheim Community,

as i am building my own server docker image right now with a different approach i was wondering if we can connect on the base needs and problems.

I am thinking about a build on the alpine linux base image to reduce the size of the image. I was also wondering if this could boost the performance just a little bit. I've read alot rumors about this. Some people have performace problems with alpine linux,

In my personal expereience alpine linux was always performing a little bit better than debian and had some less timeouts or a little bit better average response time over thousands of iterations. But this where basic Webapps with a standard DB backend (Clusters)
I have no clue about the unity server output. It might have different needs

have a nice day
niklas

offtopic

My different approach:

Make a Watch Docker Container for the Steamapp which will trigger a version update if needed,
Make Watch Docker Container for the Valheim Plus version ...

Provide backup process outside the gameserver container (copying the data from volumes should always be part of another unit / process)

[lloesche]

Hi @CyberT3C , couple of thoughts on the topic.

The major advantage of Alpine over Debian is its size because of the use of musl libc. 3 MB vs. 50 MB for Debian. Since you're planning on running a game server that is linked against glibc you won't be able to use musl libc and will have to install glibc within Alpine which is going to reduce that size advantage to zero. Also the Valheim server itself is about 1 GB in size, so the few MB more or less for Alpine vs. Debian seem like a moot point.

In my personal expereience alpine linux was always performing a little bit better than debian and had some less timeouts or a little bit better average response time over thousands of iterations

To me this does not make much sense from a technical point of view but feel free to link some benchmarks. Going down the stack, the thing that processes connections first is the Linux kernel which runs on your host system, not within the container. Then the libc which does the syscalls to the kernel and provides the interface your software is calling to do things like open sockets, poll them, etc. and then your software i.e. Valheim server is processing the information it received on those sockets. No part of Alpine or Debian has anything to do with how connections are handled how they perform or what timeouts they have.
Now when it comes to apps that ship with Alpine vs. Debian I would actually expect Debian to perform better just because glibc is a overall better performing library than musl libc. The point of musl is size (and cleaner code to some degree) and not performance after all. But again if you'd simply recompile and link against glibc the performance difference would be zero.

Your approach of keeping each function in a separate Docker container sounds clean and makes a lot of sense. The approach I went for with this image was to make it as easy to use and low maintenance as possible esp. for NAS users, at the expense of some separation of constraints and functionality. Though thinking about it, having to pull multiple containers kind of counter acts the whole "Smaller footprint with alpine linux" idea. Still it's definitely cleaner.

There is another really good Valheim Docker container at https://github.com/mbround18/valheim-docker
They are using the same upstream container you are currently using. Have you checked them out? They have a neat tool for managing the server called Odin. Maybe it could be useful.

[TheCatLady]

I agree that an Alpine base image is not suitable for this application / use case.

That said, @lloesche I do find your decision to use Debian interesting. 😅 Any reason why you didn't go with Ubuntu? Ubuntu base images are pretty popular, and I believe they are also slightly smaller than the Debian base images. Most of the bulk of this image is going to come from the Valheim server itself though. If you want to stick with Debian, perhaps we can see if the -slim variant images would work?

[lloesche]

@TheCatLady no particular reason but I figured SteamOS is based on Debian (as is Ubuntu) so it is likely a well tested base to run steamcmd in. I'm a Fedora package maintainer and use Fedora on my Desktop and Servers, so all my ❤️ goes to the Fedoraproject 🙂 but I use Alpine in most of my container images like e.g. mesosphere/cloudkeeper where I can compile against musl libc and my goal is to keep the size small.

perhaps we can see if the -slim variant images would work

It does but when I tested it I didn't want to give up tools like ping and ip that are useful for debugging. But since then I added a busybox with all applets compiled in (the one that comes with Debian was missing syslogd or crond, don't remember exactly which one) so we could just symlink the tools we're giving up to the already existing busybox binary. Do you want to prepare a PR?

[TheCatLady]

Yeah I can do that later! Also, any reason why you don't pin a versioned tag for the base image? It's considered good practice to do so, and we can use Dependabot to update the version when there's new ones available (and the GitHub workflow will verify it builds successfully on the new version!).

[lloesche]

Laziness mostly. I built this image mainly for myself and a couple of friends. They are also the reason there are Synology screenshots 🙂 I do PRs sometimes but often push to main. It's a fun project. Maintaining versions sounds like what I do at work. This is not work. I try to make sure to build anything I add in a backwards compatible way so that people can rely on :latest working with whatever config they already have without the burden of having to care about versions and compatibility between them.

Then consider the container itself. It is automatically downloading the latest versions of ValheimPlus and valheim dedicated server. If either of those do a breaking change (like for instance when valheim server moved to SIGINT for shutdowns) I don't want people to be stuck on a pinned version and then explain in 10 issues how to switch to another one. Many of this image's users are using a WebUI to run the server, are not familiar with Docker or the shell and just happy they got valheim server running. They are my highest priority. Anybody else with the knowledge to do so can just fork or build their own with ease.

If anything I was contemplating adding a container internal upgrade mechanism for the scripts of this repo. Like whenever a new commit appears in main the container should check it out, upgrade itself and if required restart everything so that users would never have to manually download a new container image ever again 🙂
A zero maintenance self-upgrading self-healing Valheim server akin to an appliance if you want.

I realize this goes fully against the idea of containers but then what do I care, my number one concern is user convenience. I'm happy if the user starts this container and can play Valheim with their friends forever, never having to worry about the container or any other technical aspect ever again.

Edit: oh, for the base image. I skipped that part and thought you were talking about versioning this image. Dockerhub is configured to rebuild the image whenever the base image updates. We should actually add that to the Github image as well if that can be configured.

[TheCatLady]

@lloesche Oh lol yeah I didn't mean versioning this repo itself.

The most common way to manage the base image version (as well as any other dependency versions) is to use Dependabot. I can PR the config for that as well, it would be good to have it to monitor for any updates to the actions we use in the CI workflow too. I would be happy to monitor Dependabot PRs and merge them when the checks pass, so you don't have to worry about it :)