
itzg/docker-minecraft-bedrock-server : serveur dédié Minecraft Bedrock conteneurisé avec version sélectionnable – Monter un serveur MineCraft
[bzkshopping keyword= »Minecraft » count= »8″ template= »grid »]
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 surVRAI
à
accepter le contrat de licence utilisateur final MinecraftVERSION
(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 conteneurPRÉCÉDENT
: utilise la version majeure précédemment maintenue. Utile lorsque l'application mobile est progressivement mise à niveau sur tous les appareils1.11
: la dernière version de 1.111.12
: la dernière version de 1.121.13
: la dernière version de 1.131.14
: la dernière version de 1.141.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 baseGID
(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 basePACKAGE_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 configurationserver.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 fichierliste 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
- 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
. - 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.
- 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"
- 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 ]
]
- 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
dansserver.properties
qui devrait être changé envrai
.
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
Commentaires
Laisser un commentaire