timche
commented
2 years ago So if I were to start the image docker-csgo:pug-practice it's already installed and runs the server in seconds with a concrete set of packages (steam client, metamod, sourcemod, practivemode, etc..).
This is not 100% correct. You need to mount a volume to the container where the server files will be installed (as explained here). The image takes care of automating the server installation and optionally installing all the mods as well depending on the image. The volume is the state.
Configuration would be done over ENV_VARS just like now, but starting a container would not install or update the dependencies again.
This definitely would have some drawbacks like a higher maintenance burden, but most of it could be automated.
This is not correct. Any environment variable ending with _VERSION can be changed and will trigger an update or downgrade on container start.
What are the reasons that the installation of the server, plugins, etc. is part of the container's CMD (entry-point)? Couldn't we make this part of the image build process?
The server files are too big for an image (around 20 GB). Also some files must be stored in a volume.
You should try to read and go through the shell scripts to get an understanding what is happening:
maxkerp
Hi, there. First of all thanks so much for putting in all the work and making it super easy to run a practicemode or pug server in minutes. It's much appreciated! :heart:
I'm no docker expert, but some of the design decisions surprise me. I suspect that I'm probably missing some information and that there are good reasons for this setup, but out of curiosity I want to ask some questions.
The way I got to know docker is, that you build images in a way so that the contents of it are very much defined and constant/immutable. So if I were to start the image
docker-csgo:pug-practiceit's already installed and runs the server in seconds with a concrete set of packages (steam client, metamod, sourcemod, practivemode, etc..). Configuration would be done over ENV_VARS just like now, but starting a container would not install or update the dependencies again. The containers would be stateless and all customization are done by either volumes or building upon the image itself (inherting from it).This definitely would have some drawbacks like a higher maintenance burden, but most of it could be automated.
What are the reasons that the installation of the server, plugins, etc. is part of the container's
CMD(entry-point)? Couldn't we make this part of the image build process?I only looked at the repo for about an hour, so I'm sorry if I missed very obvious reasons :grimacing:
One more question: Where is the state (e.g saved nades, and so on) actually stored by steam? As far as I'm concerned this would definitely need to be put into a volume in order to make the container stateless.
Sincerely, Max :v: