Closed thasmo closed 8 years ago
I was thinking about this. A posible no-complete list of commands:
.tar.gz
. I don't know how and where but something like this would be nice.docker start container log | more
or docker start container log | grep login > login_reports.log
log
but with the chatlog.I understand that this commands are used in this way:
docker run [...] dstacademy/server start
# or
docker start my_server_container update
We don't need stop or restart. Those are free:
docker stop my_server_container
# or
docker restart my_server_container
I was thinking about a console
command too. But I think that it must work in other way... I need to research a bit more about ENTRYPOINT
too...
It's possible to attach to the running server/console just via docker attach <container>
.
Be sure to check out ENTRYPOINT
and CMD
and i.e. the MySQL entrypoint script, or any other official image. They've best-practice baked in. :)
I vote for start
as default and update
for running the steam update script and exiting.
I don't think we need backup, server administrators only need to backup volumes and how they do that, is their issue. I think creating a backup
command will not add something useful to the container, which is better than anything people can easily do with a volume.
Printing logs sounds interesting. What do you think about log --type=[server|chat]
, and server
is the default?
In addition, what I think should be implemented is signal trapping. I don't have too much experience with this, but we need to make sure, that the DST server shuts down and saves the world, when someone runs docker stop <container>
. We need to listen for the SIGTERM
and maybe also the SIGKILL
signals and shuts down the DST server cleanly.
Thoughts?
start --update=[true|false]
Starts the server and optionally checks for updates.update
Checks for updates but exits afterwards.log --type=[server|chat]
Returns/prints a log.Just fooling around. :)
About "shut down the DST server cleanly". Is there any wiki article or forum topic talking about best practices? I mean, what must you do to stop a DST server cleanly? All the guides closes the server and that's it.
A lot of game servers send a broadcast message to the user "We are going to shut down the server in X minutes/seconds, please, go out!". What do you think in doing something like that too?
I have no expirience with the signals neither but we must investigate.
When on the server's console, one can shutdown the server cleanly by running c_shutdown(true)
. This tells the server to save the current world/session and then shuts down the server. I'm not sure the server stops cleanly otherwise, when the container gets stopped.
A broadcast message would be very nice, although it shouldn't delay the shutdown for too long. 10 seconds maximum and/or configureable.
Sending announcements is also possible from the console using c_announce("Announcement here.")
.
So, first we need to find out if the server cleanly shuts down if it gets a SIGTERM
signal. And if not, we need to listen for it, and trigger a shutdown of the server. If we want to send a shutdown message anyway, we mandatorily need to trap the signal in all cases.
For the record, I'm not sure which signals are the proper ones. There's SIGINT
, SIGTERM
and SIGKILL
any many others, which we probably do not need to take care of.
Here's an example for trapping a signal: https://rimuhosting.com/knowledgebase/linux/misc/trapping-ctrl-c-in-bash
Another one: http://hacktux.com/bash/control/c
I agree with you about the backup
. We can write a paragraph about how to do a volume backup in the documentation.
About the --update
... I'll prefer to enforce the image update. And I found a huge pro of this option: Your servers are much less time down.
docker pull dstacademy/server # the server is running while you are doing this!
docker rm -f dst_overworld
docker run [...] dstacademy/server
Your servers just stops to change the image. They have all the data already! Is more, you don't need to stop your servers if the pull
say that you are up to date!
I'm not saying that we must not give the update option. We must give it. I'm saying that I don't want to give it too easy to use to try to enforce the other use. And for too easy I mean --update=[true|false]
. I think that you had a TOO good idea :stuck_out_tongue:
Basically, just for updating the game and mods (not the image) you can just do this:
docker-compose restart
or docker restart <container>
.
Using docker rm -f <container>
will probably kill your server without a proper save-game, so you will lose data, although it's the fastest.
Not so sure what you mean about my too good idea?! :D
Yes, docker restart
seems a much better option.
With too good Idea mean that I like it, it seems very handy. But I think that with a so much easy way less people would use the pull
and restart
way. And I think that the second one is better for the reason I gave before.
Yeah, but I think it's two different things. Updating the game/mods is needed when a new version is released by Klei, so the server is compatible with all steam clients. The other thing is to update the image to get new fixes and/or features, but that's something totally different. People may want to use the same image as long as possible because upgrading the image could mean work. Work to update variables, volume paths, etc.
So we can not assume people will always update the image when a new game update is released, although I understand your thoughts and would also like to get people to update the images as often as possible.
That's the problem. The image update must be completely painless. Just:
docker pull dstacademy/server
docker restart <container> or docker-compose restart
If we acomplish that we can try to promote that method. And I'm not thinking in our updates. If they want to stay in the v1.0
when we are at the v3.0
it's ok for me, that's their choice.
docker restart <container>
will not update the image for the container. Once a container has been started, the image will stay the same I believe.
So, the process to update the image and start new containers is:
docker pull <image>
docker-compose stop
docker-compose rm
docker-compose up -d
or
docker pull <image>
docker stop <container>
docker rm <container>
docker run <image>
For updating the game/mods it's enough to execute docker-compose restart
or docker restart <container>
.
I researched a bit. With docker you must remove the image first as you say: https://github.com/docker/docker/issues/15725
But it seems that with compose up
you can make it easier: https://github.com/docker/docker/issues/15725
I didn't use compose yet so tell me what do you think. If you are not convinced yet I agree with add the --update
flag.
Looking at the postgresql's entrypoint it seems handy for me give the option of compose start <container_id> bash
or any other command you can imagine. The problem of this is how to avoid collisions between or three commands and the default ones. Any thoughts about this?
Any other command?
We need a --help
command too docker run dstacademy/server --help
It show our different commands.
When implementing this, we can probably also remove support for the variable UPDATE_ON_BOOT
.
What do you think if we change true
and false
for all
and none
start --update=[all|none|game|mods]
Already done that. See above. :)
Currently the entrypoint script just initializes some things and forwards arguments to the null-renderer. We should refactor the entrypoint script to handle useful commands like
update
,reset
etc.help
Print all available options.
start --update=[true|false|game|mods]
defaultStart the server and optionally update files.
true
is default and updates game and mods.false
skips updates.game
updates the game only.mods
updates mods only.update --type=[all|game|mods]
Run game and mod updates and stop the container.
all
is default and updates game and mods.game
updates the game only.mods
updates mods only.log --type=[server|chat]
Return a log to stdout.
server
is default and prints the server log.chat
prints the chat log.