Add: Server startup on Container startup, Volume cleanup, tail and some comments

[NIREKI]

Regarding #5 and the automatic startup on container start, here is my PR. These are the most important changes I've made:

Auto- Startup with entrypoint in Dockerfile

• Merged entrypoint.sh and start.sh, thus making start.sh the new entrypoint on container startup. This doesn't use the manager because it prints the Log file to stdout.
• Made some cleanups
• This way the server is automatically updated on every container restart
• added restart: unless-stopped to docker-compose.yml

Volume cleanup: added volume for /opt/steamcmd thus steam doesn't pull it's update on every startup RCON Port: added RCON Port to docker-compose.yml (commented, not exposed by default)

Mod Support (@azixus help needed)

• Added MODS arg to .env and basic handling in the start.sh BUT my server isn't starting with mods provided, maybe you could try if it works on your side. Launchparam wise it should work..

Bugs

• Sometimes the server starts normally and appears in the server list, but connecting to it only results in a timeout. I don't think that this has something to do with my changes and is an error on ASA's side -> @azixus are you experiencing similar stuff?

[NIREKI]

This would also need some changes to the documentation

• running docker container logs asa_server for getting tail output
• manager is still working, but startup command is unnessecary
• update command could also be marked unnessecary

If you want to you could contact me on Discord (nirekiki) or smth like that to discuss things further, or we do it under this PR

[lawrencewilson]

Sometimes the server starts normally and appears in the server list, but connecting to it only results in a timeout. I don't think that this has something to do with my changes and is an error on ASA's side -> @azixus are you experiencing similar stuff?

I am experiencing this all the time - in fact, I can't get the server to connect even at all. Server appears in the list on ASA, but I have never been able to connect.

I'm still debugging this problem in my environment and this is happening on @azixus main branch without the changes in this PR.

[NIREKI]

I am experiencing this all the time - in fact, I can't get the server to connect even at all. Server appears in the list on ASA, but I have never been able to connect.

I'm still debugging this problem in my environment and this is happening on @azixus main branch without the changes in this PR.

Yeah it's quite weird. I also have this in the main branch and also with other docker images floating on github.. Really can't figure out what's the problem. I guessed that the server just needs more time to figure things out with ark asa but that doesn't seem to be it.

[azixus]

Thanks for the PR, I'll test the changes today.

Can't say that I've noticed the bug described in #7, I'll spin a new server and see if I experience the bug. After a quick check on the official discord, it looks like a bunch of people are experiencing it:

any idea why some players of my asa server could not connect and getting "Lost/timeout connection lost to host" - they could play the last days, but since the latest update its not possible

Hello everyone! I am struggling with the server I am on with constant timeouts. Is this a server issue or game issue? Can be on the server for a few seconds to a couple minutes before it either crashes or timeouts.

Connection timeout when trying to join servers, constantly.

It's likely a bug on the recent server (or client?) builds. Some people were able to temporarily fix the bug by synchronizing their clock in the Windows settings of the client PC. You might want to try that @lawrencewilson.

[azixus]

Added MODS arg to .env and basic handling in the start.sh BUT my server isn't starting with mods provided, maybe you could try if it works on your side. Launchparam wise it should work..

I just ran the server with the Super Spyglass Plus (929420) and it worked immediately on my side. Displayed "w/mods" in the server list, and I was able to use the mod items.

[NIREKI]

Thanks for the PR, I'll test the changes today.

Thanks, if you have any feedback, let me hear it.

I just ran the server with the Super Spyglass Plus (929420) and it worked immediately on my side. Displayed "w/mods" in the server list, and I was able to use the mod items.

Thats good to hear, maybe it was a problem with yesterdays server build, who knows. (Is it nessecary to display "w/mods"? I guess its not?)

It's likely a bug on the recent server (or client?) builds. Some people were able to temporarily fix the bug by synchronizing their clock in the Windows settings of the client PC. You might want to try that @lawrencewilson.

Might have to check that myself, as I also can't join my server, only some servers work for me.

[lawrencewilson]

I've resolved a networking snag on our ARK server instance. The default bridge networking on my Docker setup was prompting the server to broadcast its internal Docker IP, not the host's external IP, causing connectivity issues for external clients.

Switching the network_mode to 'host' in the Docker configuration has effectively corrected this. It enabled the ARK server to advertise the correct external IP address, ensuring proper client connections. Below is the updated docker-compose.yml snippet, illustrating the removal of port exposures and the network_mode change:

version: '3'

services:
  asa_server:
    tty: true
    container_name: asa_server
    restart: unless-stopped
    build:
      context: .
    env_file:
      - .env
    volumes:
      - shooter_game:/opt/arkserver
      - steam_data:/opt/steamcmd
    network_mode: host
    deploy:
      resources:
        limits:
          memory: 16g
    memswap_limit: 16g

volumes:
  shooter_game:
  steam_data:

[NIREKI]

@lawrencewilson do I understand your proposal right, that this fixes the timeout error?

I will have to test this, and if it works I will add it to this PR.

Port exposure should anyways be handled with UFW or similar firewall rules

[NIREKI]

@lawrencewilson do I understand your proposal right, that this fixes the timeout error? I will have to test this, and if it works I will add it to this PR. Port exposure should anyways be handled with UFW or similar firewall rules

After some quick testing this doesn't change or fix anything on my side. @azixus But I think changing the network mode to 'host' makes this script easier to use for docker beginners. What are your views on that?

[azixus]

Is it nessecary to display "w/mods"? I guess its not?

Yeah, I meant in the server list, there's a w/mods section.

After some quick testing this doesn't change or fix anything on my side. @azixus But I think changing the network mode to 'host' makes this script easier to use for docker beginners. What are your views on that?

I'm a bit reluctant about that change, it would expose all ports that the container is listening to. It would also force us to use different RCON ports, for different servers. I would argue that it makes the container harder to use because, for instance, in ubuntu, docker bypasses UFW by default as it adds custom iptables rules. Hence, you don't have to set a rule manually.

[NIREKI]

Is it nessecary to display "w/mods"? I guess its not?

Yeah, I meant in the server list, there's a w/mods section.

After some quick testing this doesn't change or fix anything on my side. @azixus But I think changing the network mode to 'host' makes this script easier to use for docker beginners. What are your views on that?

I'm a bit reluctant about that change, it would expose all ports that the container is listening to. It would also force us to use different RCON ports, for different servers. I would argue that it makes the container harder to use because, for instance, in ubuntu, docker bypasses UFW by default as it adds custom iptables rules. Hence, you don't have to set a rule manually.

Alright, then no change on this side. As mentioned, this also doesn't change anything on my side as the server always exposes the right IP adress and gets discovered by server listing tools with the right IP etc.

The timout also accurs when using 'open ip:port' in the console.

[lawrencewilson]

@lawrencewilson do I understand your proposal right, that this fixes the timeout error? I will have to test this, and if it works I will add it to this PR. Port exposure should anyways be handled with UFW or similar firewall rules

After some quick testing this doesn't change or fix anything on my side. @azixus But I think changing the network mode to 'host' makes this script easier to use for docker beginners. What are your views on that?

Its probably best to leave it as the default network in Docker, unless more people face issues with timeouts. If this works for the vast majority of people, leaving it in a bridged network is more secure and you can control ports.

It's very likely I've done something to my docker host that is non-standard so I will do some more investigation to see if there is a reason the default bridged network doesn't work on my host.

For the people who do face permanent timeouts connecting to their Ark server, the way I determined my server was advertising the wrong IP was to open WireShark and snif to see where it was going, sure enough I was either trying to find the Ark server on 127.0.0.1:7777 or 172.28.0.2 which smelled like docker.

Also, randomly I got this message in game: