itzg/docker-minecraft-bedrock-server : serveur dédié Minecraft Bedrock conteneurisé avec version sélectionnable – Monter un serveur MineCraft

Démarrage rapide

Ce qui suit démarre un serveur dédié Bedrock exécutant une version par défaut et
exposer le port UDP par défaut :

docker run -d -it -e CLUF=TRUE -p 19132:19132/udp itzg/minecraft-bedrock-server

REMARQUE: si vous prévoyez d'exécuter un serveur pendant une période plus longue, il est fortement recommandé d'utiliser une couche de gestion telle que Docker Compose ou Kubernetes pour permettre une reconfiguration incrémentielle et des mises à niveau d'image.

Mise à niveau vers la dernière version du serveur Bedrock

Avec le VERSION variable définie sur DERNIER, qui est la valeur par défaut, le serveur Bedrock peut être mis à niveau en redémarrant le conteneur. À chaque démarrage, le conteneur vérifie la dernière version et les mises à niveau, si nécessaire.

À la recherche d'un serveur d'édition Java

Pour Minecraft Java Edition, vous devrez utiliser cette image à la place :

itzg/minecraft-serveur

Variables d'environnement

Spécifique au conteneur

• CLUF (pas de valeur par défaut) : doit être défini sur VRAI à
  accepter le contrat de licence utilisateur final Minecraft
• VERSION (DERNIER) : peut être défini sur une version de serveur spécifique ou les valeurs spéciales suivantes peuvent être utilisées :
  • DERNIER : détermine la dernière version et peut être utilisé pour la mise à niveau automatique au démarrage du conteneur
  • PRÉCÉDENT : utilise la version majeure précédemment maintenue. Utile lorsque l'application mobile est progressivement mise à niveau sur tous les appareils
  • 1.11 : la dernière version de 1.11
  • 1.12 : la dernière version de 1.12
  • 1.13 : la dernière version de 1.13
  • 1.14 : la dernière version de 1.14
  • 1.16 : la dernière version de 1.16
  • sinon, toute version de serveur spécifique peut être fournie pour permettre d'éviter les bogues temporaires, etc.
• UID (par défaut dérivé de /Les données propriétaire) : peut être défini sur un ID utilisateur spécifique pour exécuter le
  processus serveur de base
• GID (par défaut dérivé de /Les données propriétaire) : peut être défini sur un ID de groupe spécifique pour exécuter le
  processus serveur de base
• PACKAGE_BACKUP_KEEP (2) : combien de sauvegardes de paquets conserver

Propriétés du serveur

Les variables d'environnement suivantes définiront la propriété équivalente dans server.properties, où chacun est décrit ici.

• NOM DU SERVEUR
• PORT DE SERVEUR
• SERVER_PORT_V6
• MODE DE JEU
• DIFFICULTÉ
• LEVEL_TYPE
• ALLOW_CHEATS
• LE MAXIMUM DE JOUEURS
• MODE EN LIGNE
• WHITE_LIST
• LA DISTANCE DE VUE
• TICK_DISTANCE
• PLAYER_IDLE_TIMEOUT
• MAX_THREADS
• LEVEL_NAME
• LEVEL_SEED
• DEFAULT_PLAYER_PERMISSION_LEVEL
• TEXTUREPACK_REQUIRED
• SERVER_AUTHORITATIVE_MOVEMENT
• PLAYER_MOVEMENT_SCORE_THRESHOLD
• PLAYER_MOVEMENT_DISTANCE_THRESHOLD
• PLAYER_MOVEMENT_DURATION_THRESHOLD_IN_MS
• CORRECT_PLAYER_MOVEMENT

Par exemple, pour configurer un serveur créatif plat au lieu de l'utilisation par défaut :

docker run -d -it --name bds-flat-creative 
  -e CLUF=TRUE -e LEVEL_TYPE=plat -e GAMEMODE=créatif 
  -p 19132:19132/udp itzg/minecraft-bedrock-server

Ports exposés

• UDP 19132 : le port serveur Bedrock.
  REMARQUE que vous devez joindre /udp lors de l'exposition du port, comme -p 19132:19132/udp

Volumes

• /Les données : l'emplacement où le serveur téléchargé est développé et exécuté. Contient également le
  fichier de propriétés de configuration server.properties

Vous pouvez créer un volume nommé et l'utiliser comme :

docker volume créer mc-volume
docker run -d -it --name mc-server -e CLUF=TRUE -p 19132:19132/udp -v mc-volume:/data itzg/minecraft-bedrock-server

Si vous utilisez un volume nommé et que vous souhaitez que le processus de base s'exécute en tant qu'utilisateur non root, vous devrez pré-créer le volume et chown à l'utilisateur souhaité.

Par exemple, si vous souhaitez que le serveur bedrock s'exécute avec l'ID d'utilisateur 1000 et l'ID de groupe 1000, créez et créez le volume nommé "bedrock" en utilisant :

docker run --rm -v bedrock:/data alpine chown 1000:1000 /data

Si vous utilisez course de docker puis faites simplement référence à ce volume « fondement » dans le -v argument. Si vous utilisez un fichier de composition, déclarez le volume en tant qu'externe à l'aide de ce type de déclaration :

volumes:
  substrat rocheux:
    externe:
      Nom: substrat rocheux

De liaison

Lors de l'exécution du conteneur sur votre réseau local, vous pouvez trouver et vous connecter au serveur dédié
dans la partie "LAN Games" de l'onglet "Friends", tels que :

Autorisations

Le serveur dédié Bedrock nécessite que des autorisations soient définies avec des XUID. Il existe divers outils pour les rechercher en ligne et ils
sont également imprimés dans le journal lorsqu'un joueur se joint. Il existe 3 niveaux d'autorisations et 3 options pour configurer chaque groupe :

• SPO est utilisé pour définir les opérateurs sur le serveur.

-e OPS "1234567890,0987654321"

• MEMBRES est utilisé pour définir les membres sur le serveur.

-e MEMBRES "1234567890,0987654321"

• VISITEURS est utilisé pour définir les visiteurs sur le serveur.

-e VISITEURS "1234567890,0987654321"

Liste blanche

Il existe deux manières de gérer une liste blanche. La première consiste à définir le WHITE_LIST variable d'environnement sur true et mappée dans un fichier whitelist.json personnalisé pour le conteneur. L'autre consiste à utiliser le WHITE_LIST_USERS variable d'environnement pour lister les utilisateurs qui doivent être ajoutés à la liste blanche. Cette liste contient les noms des joueurs. Le serveur recherchera les noms et ajoutera le XUID pour correspondre au joueur.

-e WHITE_LIST_USERS="joueur1,joueur2,joueur3"

À partir du 1.16.230.50, ALLOW_LIST, ALLOW_LIST_USERS, et le fichier liste d'autorisation.json sera utilisé à la place.

Modules complémentaires

Également connu sous le nom de packs de comportement ou de ressources, afin d'ajouter des mods dans votre serveur, vous pouvez suivre ces étapes, testées avec OPS (One Player Sleep) et bedrocktweaks

1. Installez d'abord le mcpack ou le mcaddon côté client, juste pour faciliter la copie des fichiers sur le serveur, pour Windows 10, les fichiers doivent être situés sur C:UsersUSERAppDataLocalPackagesMicrosoft.MinecraftUWP_*LocalStategamescom.mojang.
2. Copiez les dossiers des mods à partir de behavior_packs ou de resource_packs dans le volume du serveur.

Si vous souhaitez les installer sans utiliser de client, vous devriez pouvoir décompresser les mods directement dans le volume du serveur, .mcaddon devrait aller dans behavior_packs et .mcpack dans resource_packs. Les fichiers .mcaddon et .mcpack sont en fait renommés en .zip.

3. Sur le volume du serveur, nous devrons éditer valid_known_packs.json, vous pouvez simplement copier et coller la définition d'un autre pack et remplacer le chemin, l'uuid et la version par le mod en cours d'installation, l'uuid et la version peuvent être trouvés sur le comportement du mod ou la ressource _packs/mod/manifest.json, le chemin est le chemin vers le dossier du mod.

				
"file_system" : "RawPath",
"path" : "behavior_packs/Foxy'sOneP",
"uuid" : "5f51f7b7-85dc-44da-a3ef-a48d8414e4d5",
"version" : "3.0.0"

4. Enfin créer sur le volume du serveur worlds/$level-name/world_behavior_packs.json, vous devrez ajouter une entrée pour chaque mod comme sur le manifest.json précédent, nous n'avons besoin que de l'uuid maintenant appelé pack_id et de la version remplaçant les points par des virgules et les guillemets doubles par [ ].

Vous pouvez également créer un worlds/$level-name/world_resource_packs.json mais j'ai vu que mettre à la fois des packs de ressources et de comportement dans le même json fonctionne très bien

[
	
		"pack_id" : "5f51f7b7-85dc-44da-a3ef-a48d8414e4d5",
		"version" : [ 3, 0, 0 ]
	
	
	
	
]

5. Redémarrez le serveur et les mods devraient être activés maintenant ! lors de la connexion, vous recevrez une invite vous demandant si vous souhaitez "Télécharger et rejoindre" ou simplement "Rejoindre", vous devez Télécharger et rejoindre si vous voulez réellement voir le nouveau pack de ressources ajouté au serveur.
   Cette invite est exclusive aux packs de ressources, car ils modifient l'apparence de Minecraft, tandis que les packs de comportement modifient le fonctionnement de Minecraft et n'ont pas besoin d'être téléchargés ou installés côté client.

Si vous souhaitez forcer le pack de ressources sur tous les clients, il existe une option texturepack-required=false dans server.properties qui devrait être changé en vrai.
Les packs de ressources peuvent être supprimés en allant dans Paramètres > Stockage > Données en cache, puis en sélectionnant le pack et en cliquant sur la corbeille.

Pour plus d'informations, FoxyNoTail a réalisé une vidéo expliquant la même chose sur un serveur fonctionnant sous Windows.

Plus d'information

Pour plus d'informations sur la gestion des serveurs dédiés Bedrock en général, consultez cet article Reddit.

Exécuter les commandes du serveur

En supposant que vous ayez démarré le conteneur avec stdin et tty activés (comme en utilisant -ce), vous pouvez vous attacher à la console du conteneur par son nom ou son ID en utilisant :

docker attach CONTAINER_NAME_OR_ID

Une fois connecté, vous pouvez exécuter n'importe quelle commande côté serveur, comme faire de votre lecteur l'administrateur :

Une fois terminé, détachez-vous de la console du serveur en utilisant Ctrl-p, Ctrl-q

Déploiement avec Docker Compose

Le répertoire examples contient un exemple de fichier de composition Docker qui déclare :

• un service exécutant le conteneur du serveur bedrock et exposant le port UDP 19132
• un volume à rattacher au service

La configuration du service comprend quelques exemples de configuration des propriétés du serveur via des variables d'environnement :

environnement:
  CLUF: "VRAI"
  MODE DE JEU: survie
  DIFFICULTÉ: Ordinaire

De avec dans le exemples répertoire, vous pouvez déployer la composition en utilisant :

Vous pouvez suivre les journaux en utilisant :

docker-compose journaux -f bds

Déployer avec Kubernetes

Le répertoire examples contient un exemple de fichier manifeste Kubernetes qui déclare :

• une revendication de volume persistant (à l'aide de la classe de stockage par défaut)
• un déploiement de pod qui utilise le PVC déclaré
• un service de type LoadBalancer

Le déploiement du pod comprend quelques exemples de configuration des propriétés du serveur via des variables d'environnement :

env:
- Nom: CLUF
  valeur: "VRAI"



- Nom: MODE DE JEU
  valeur: survie
- Nom: DIFFICULTÉ
  valeur: Ordinaire

Le fichier est déployable tel quel sur la plupart des clusters, mais a été confirmé sur Docker for Desktop et Google Kubernetes Engine :

kubectl applique -f exemples/kubernetes.yml

Vous pouvez suivre les journaux du déploiement en utilisant :

kubectl logs -f deploy/bds

Solutions communautaires