The International Simutrans Forum

 

Author Topic: playing with docker  (Read 323 times)

0 Members and 1 Guest are viewing this topic.

Offline sdog

  • Devotee
  • *
  • Posts: 2044
playing with docker
« on: August 31, 2020, 04:55:16 PM »
I'll be toying around with Docker and Alpine Linux a bit and thought Simutrans (S) might be a good subject. Some first thoughts on what to do:

see if S compiles against musl instead of glibc

get binary to run in container

get S's logs and errors to STDOUT and STDERR, respectively

move all relevant settings from config to env vars

automate build for container images in dev container

Do we provide headless Paksets? I remember a patch from Dwachs from about 2012 where (then new) headless servers stopped loading pngs from paksets. For this it would be nice to strip the pictures entirely to keep image size (or download) low.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10143
  • Languages: De,EN,JP
Re: playing with docker
« Reply #1 on: September 01, 2020, 02:00:21 AM »
Why would you pack a 5 MB size executable that is known to run and compile on almost any Linux platform into a docker container? Fells to me to go shopping with a steamroller ...

Offline Matthew

  • *
  • Posts: 388
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: playing with docker
« Reply #2 on: September 01, 2020, 03:31:58 AM »
I noticed that ceeac is also trying to use Docker as part of his effort to use Github Actions:



Now, obviously he is trying to use it a s a build system whereas you are trying to use it to run a server. And no Windows builds are actually being output yet, so it seems like this is still a work in progress.

But I just make that connection in case there's anything there that might help you along the way.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5663
  • Languages: EN, NO
Re: playing with docker
« Reply #3 on: September 01, 2020, 05:27:26 AM »
Why would you pack a 5 MB size executable that is known to run and compile on almost any Linux platform into a docker container? Fells to me to go shopping with a steamroller ...
To run it on cloud platforms, possibly.

move all relevant settings from config to env vars
It this is about simuconf.tab, I think there are too many of them to be wieldy as environment variables. Having them in a configuration file that is either embedded in a derived image, or mounted at runtime, seems a better solution.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10143
  • Languages: De,EN,JP
Re: playing with docker
« Reply #4 on: September 01, 2020, 05:40:05 AM »
To run it on cloud platforms, possibly.
It this is about simuconf.tab, I think there are too many of them to be wieldy as environment variables. Having them in a configuration file that is either embedded in a derived image, or mounted at runtime, seems a better solution.
Still you can have a docker image with GCC etc. (there are few dependcies for a server). ./configure make and you are done. It is probably even easier than fiddle with docker in the first case ... Ok, on windows this would be different, but I am not sure you do windows based cloud computing without a good reason to actually do so.

Offline sdog

  • Devotee
  • *
  • Posts: 2044
Re: playing with docker
« Reply #5 on: September 01, 2020, 10:29:48 AM »
Why would you pack a 5 MB size executable that is known to run and compile on almost any Linux platform into a docker container? Fells to me to go shopping with a steamroller ...

To see if I can do it?

There is also a bit of benefit to it. As Ters said, deplyoing it to cloud services. Renting a root server slot is on the way out.

It would be easy of course to run an Arch image, run a terminal and just pull Simutrans with a package manager, configure it, bind mount a volume for save games, and write a start script. But then I'd be done already in the time it took to write this posting. And it wouldn't do any good for anyone else. That's why I'm playing around with building docker images that run Simutrans.

Simutrans is a good for such a toy project. First it's in C++, second it is not large, third there's nothing really usable out there.

Docker is of course also outmoded and on its way out. But Docker experience in part translates to Kubernetes. Plus it might take a while untill most organisations migrate to the latter.

ps.: I see now how I mislead you. I should have called this toying with docker since it is about playing with docker, not about playing Simutrans.

Offline sdog

  • Devotee
  • *
  • Posts: 2044
Re: playing with docker
« Reply #6 on: September 01, 2020, 10:38:21 AM »
Quote
move all relevant settings from config to env vars
It this is about simuconf.tab, I think there are too many of them to be wieldy as environment variables. Having them in a configuration file that is either embedded in a derived image, or mounted at runtime, seems a better solution.
I thought only about a few settings (eg autosave, bits_per_month) that are often changed between servers. However, I think it might be easier to make all simuconf.tab settings changeable by envs. If an env exists override the setting. Either through once with a script on server startup or permanently through a daemon.