Backup doesn't work when Bedrock server is running on a docker swarm

[s-dukes]

When Minecraft Bedrock Server is running on a docker swarm, the container name is appended with a random numbers/letters each time the stack is started, because of this the backup cannot connect to the container using the defined name.

This could be fixed by taking the name defined in the config.yml in this this instance "bds_minecraft_bedrock" and running the command below to get the container id which can then be used successfully as the name.

$(docker ps -q -f name=bds_minecraft_bedrock)

Cheers Si

[Kaiede]

Kubernetes throws a wrench in things too. There's something happening recently that may or may not impact you here?

I've been working with itzg on adding SSH console support to the java/bedrock containers, and I've just merged the support in bedrockifier a few minutes ago. So instead of connecting via the container's name, it connects to the hostname for the container.

However, I think the catch might be that the hostname in this case is still the container name, or is the individual node's container hidden behind a more usable hostname? If the swarm hostnames are random, this might not help much. Unfortunately, I'm not super up to speed on swarm, as everything lives on a single VM for me.

[s-dukes]

Thanks for the reply, I'll take a look at the SSH option and see if its viable.

I'm completely new to docker, but as usual jumped in at the deep end with the whole swarm thing.

Currently I'm running a script on the host which literally runs the command below to switch out the name in the config file with the current container id, which has it working at least. "bds_minecraft_bedrock" in this case is the stack service name.

sudo sed -i -r "s/^( - name: ).*/\1 $(docker ps -q -f name=bds_minecraft_bedrock)/" /backup/config.yml

Cheers Si

---

From: Kaiede @.> Sent: 06 January 2024 21:51 To: Kaiede/Bedrockifier @.> Cc: s-dukes @.>; Author @.> Subject: Re: [Kaiede/Bedrockifier] Backup doesn't work when Bedrock server is running on a docker swarm (Issue #76)

Kubernetes throws a wrench in things too. There's something happening recently that may or may not impact you here?

I've been working with itzg on adding SSH console support to the java/bedrock containers, and I've just merged the support in bedrockifier a few minutes ago. So instead of connecting via the container's name, it connects to the hostname for the container.

However, I think the catch might be that the hostname in this case is still the container name, or is the individual node's container hidden behind a more usable hostname? If the swarm hostnames are random, this might not help much. Unfortunately, I'm not super up to speed on swarm, as everything lives on a single VM for me.

— Reply to this email directly, view it on GitHubhttps://github.com/Kaiede/Bedrockifier/issues/76#issuecomment-1879839085, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIC4Q6ARGEZOLENFWSOKZMTYNHBO5AVCNFSM6AAAAABBPZYICCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZHAZTSMBYGU. You are receiving this because you authored the thread.Message ID: @.***>

[Kaiede]

It's in the test tag now, and itzg's containers should have support in the latest tag. Examples using docker-compose are here until I can write up more complete documentation: https://github.com/Kaiede/Bedrockifier/tree/main/Examples

I would be interested to see how it helps, as one reason for this work was to make Kubernetes easier to support.

[s-dukes]

Just tested… it works!!! 😊 but I did have to set the hostname in the docker compose via the hostname environment variable.

Below is a sanitised copy of my docker compose:

version: '3.4'

services: minecraft_bedrock: image: itzg/minecraft-bedrock-server deploy: placement: constraints:

• node.hostname == docker-node-2 restart_policy: condition: on-failure delay: 5s max_attempts: 3 window: 120s hostname: bedrock_private environment: EULA: "TRUE" VERSION: LATEST UID: 0 GID: 0 TZ: europe/london PACKAGE_BACKUP_KEEP: 2 ENABLE_SSH: "true" SSH_ENABLE: "TRUE" RCON_PASSWORD: fauxverysecurepassword SERVER_NAME: Bedrock at Home SERVER_PORT: 19132 SERVER_PORT_V6: 19133 GAMEMODE: survival DIFFICULTY: hard LEVEL_TYPE: ALLOW_CHEATS: "false" MAX_PLAYERS: 10 ONLINE_MODE: "true" ALLOW_LIST: VIEW_DISTANCE: 32 TICK_DISTANCE: 8 PLAYER_IDLE_TIMEOUT: 0 MAX_THREADS: 0 LEVEL_NAME: Bedrock at Home LEVEL_SEED: myseed DEFAULT_PLAYER_PERMISSION_LEVEL: member TEXTUREPACK_REQUIRED: "false" SERVER_AUTHORITATIVE_MOVEMENT: server-auth PLAYER_MOVEMENT_SCORE_THRESHOLD: 20 PLAYER_MOVEMENT_DISTANCE_THRESHOLD: 0.3 PLAYER_MOVEMENT_DURATION_THRESHOLD_IN_MS: 500 CORRECT_PLAYER_MOVEMENT: "false" ALLOW_LIST_USERS: OPS: MEMBERS: VISITORS: ENABLE_LAN_VISIBILITY: "true" expose:
  • 2222 ports:
  • "19132:19132/udp" volumes:
  • bedrock_data:/data stdin_open: true tty: true backup: image: kaiede/minecraft-bedrock-backup:test deploy: placement: constraints:
• node.hostname == docker-node-2 restart: on-failure depends_on:
  • "minecraft_bedrock" environment: BACKUP_INTERVAL: "3h" TZ: "Europe/London" volumes:
  • /var/run/docker.sock:/var/run/docker.sock
  • bedrock_backup:/backups
  • bedrock_data:/server volumes: bedrock_data: driver: glusterfs name: "gv0/volumes/minecraft_data" bedrock_backup: driver: glusterfs name: "gv0/volumes/minecraft_backup"

Can you confirm which of these are correct?

  ENABLE_SSH: "true"
  SSH_ENABLE: "TRUE"

I think your documentation has it one way and itzg the other.

Thanks for the help!

From: Kaiede @.> Sent: Sunday, January 7, 2024 6:06 AM To: Kaiede/Bedrockifier @.> Cc: s-dukes @.>; Author @.> Subject: Re: [Kaiede/Bedrockifier] Backup doesn't work when Bedrock server is running on a docker swarm (Issue #76)

It's in the test tag now, and itzg's containers should have support in the latest tag. Examples using docker-compose are here until I can write up more complete documentation: https://github.com/Kaiede/Bedrockifier/tree/main/Examples

I would be interested to see how it helps, as one reason for this work was to make Kubernetes easier to support.

— Reply to this email directly, view it on GitHubhttps://github.com/Kaiede/Bedrockifier/issues/76#issuecomment-1879966210, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIC4Q6GIUZ74HX7KSVUG6D3YNI3KXAVCNFSM6AAAAABBPZYICCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZHE3DMMRRGA. You are receiving this because you authored the thread.Message ID: @.**@.>>

[Kaiede]

I did have to set the hostname in the docker compose

Hmm, so when using docker-compose, I’ve seen that it does create hostnames for the services that are reachable from within the private network. It’s not quite the container name in my experience. For example, I have ~/minecraft/docker-compose.yml

services: 
  # My Java Server
  yosemite:
    … etc …
  # My Bedrock Server
  cascades:
    … etc …
  backup:
     … etc …

The containers themselves wind up being minecraft_yosemite, minecraft_cascades and minecraft_backup. However, my config.yml for the backup uses yosemite:2222 and cascades:2222 for the ssh address, since that’s the hostname generated for me by docker-compose. Does this work for docker swarm or not, I wonder?

This is one reason I need time to update the documentation, to try to capture some of the subtleties of the new system.

Can you confirm which of these are correct?

The docker-compose.yml on my personal server is using ENABLE_SSH, so that’s the correct one. I’ll double check the examples and fix it there.

[s-dukes]

Tested and yes using the service name also works with swarm, setting a hostname isn't required if you use the service name set in the compose for the SSH connection.

So my bad, I just assumed the hostname would be needed, clearly there is some kind of resolution happening in the background of docker translating service names as well.

[Kaiede]

Tested and yes using the service name also works with swarm, setting a hostname isn't required if you use the service name set in the compose for the SSH connection.

Good to know. I’ll keep that in mind when writing up the docs.

[Kaiede]

Since it sounds like SSH is working well for this scenario, and the work is now fully released with updates to the Wiki, I'll go ahead and close this.