docker minecraft bedrock server
2024.11.0
A seguir, inicia um servidor dedicado de rocha executando uma versão padrão e expondo a porta UDP padrão:
docker run -d -it -e EULA=TRUE -p 19132:19132/udp -v mc-bedrock-data:/data itzg/minecraft-bedrock-serverNOTA : Se você planeja executar um servidor por um longo período de tempo, é altamente recomendado usando uma camada de gerenciamento como o Docker Compõe ou o Kubernetes para permitir a reconfiguração incremental e as atualizações de imagens.
Com a variável VERSION definida como "mais recente", que é o padrão, o servidor Bedrock pode ser atualizado reiniciando o contêiner. Em todas as startups, o contêiner verifica a versão mais recente e as atualizações, se necessário.
A versão mais recente de visualização pode ser solicitada definindo VERSION para "visualizar".
Para o Minecraft Java Edition, você precisará usar esta imagem:
ITZG/Minecraft-Server
EULA (sem inadimplência): deve ser definido como TRUE para aceitar o contrato de licença de usuário final do MinecraftVERSION (o padrão é LATEST ): pode ser definido como uma versão específica do servidor ou os seguintes valores especiais podem ser usados:LATEST : determina a versão mais recente (não premienda) e pode ser usada para atualizar automaticamente no início do contêinerPREVIEW : determina a versão mais recente de visualização e a atualização automáticaPREVIEW como "true"UID (padrão derivado /data ): pode ser definido como um ID de usuário específico para executar o processo do servidor BedrockGID (padrão derivado /data ): pode ser definido como um ID de grupo específico para executar o processo do servidor BedrockTZ (sem padrão): pode ser definido como um fuso horário específico como America/New_York . Isso definirá o fuso horário para o contêiner do Docker e, portanto, seus logs. Adicionalmente, se você deseja sincronizar o tempo com o host, poderá montar o arquivo /etc/localtime do host para o contêiner como /etc/localtime:/etc/localtime:ro .PACKAGE_BACKUP_KEEP ( 2 ): quantos backups de pacotes para manter As seguintes variáveis de ambiente definirão a propriedade equivalente no server.properties , onde cada uma é descrita aqui. Normalmente, cada propriedade é configurada pelo equivalente superior_snake_case.
SERVER_NAMEGAMEMODEFORCE_GAMEMODEDIFFICULTYALLOW_CHEATSMAX_PLAYERSONLINE_MODEWHITE_LISTALLOW_LISTSERVER_PORTSERVER_PORT_V6ENABLE_LAN_VISIBILITYVIEW_DISTANCETICK_DISTANCEPLAYER_IDLE_TIMEOUTMAX_THREADSLEVEL_NAMELEVEL_SEEDLEVEL_TYPEDEFAULT_PLAYER_PERMISSION_LEVELTEXTUREPACK_REQUIREDCONTENT_LOG_FILE_ENABLEDCONTENT_LOG_LEVELCONTENT_LOG_CONSOLE_OUTPUT_ENABLEDCOMPRESSION_THRESHOLDCOMPRESSION_ALGORITHMSERVER_AUTHORITATIVE_MOVEMENTPLAYER_POSITION_ACCEPTANCE_THRESHOLDPLAYER_MOVEMENT_SCORE_THRESHOLDPLAYER_MOVEMENT_ACTION_DIRECTION_THRESHOLDPLAYER_MOVEMENT_DISTANCE_THRESHOLDPLAYER_MOVEMENT_DURATION_THRESHOLD_IN_MSCORRECT_PLAYER_MOVEMENTSERVER_AUTHORITATIVE_BLOCK_BREAKINGSERVER_AUTHORITATIVE_BLOCK_BREAKING_PICK_RANGE_SCALARCHAT_RESTRICTIONDISABLE_PLAYER_INTERACTIONCLIENT_SIDE_CHUNK_GENERATION_ENABLEDBLOCK_NETWORK_IDS_ARE_HASHESDISABLE_PERSONADISABLE_CUSTOM_SKINSSERVER_BUILD_RADIUS_RATIOALLOW_OUTBOUND_SCRIPT_DEBUGGINGALLOW_INBOUND_SCRIPT_DEBUGGINGFORCE_INBOUND_DEBUG_PORTSCRIPT_DEBUGGER_AUTO_ATTACHSCRIPT_DEBUGGER_AUTO_ATTACH_CONNECT_ADDRESSSCRIPT_WATCHDOG_ENABLESCRIPT_WATCHDOG_ENABLE_EXCEPTION_HANDLINGSCRIPT_WATCHDOG_ENABLE_SHUTDOWNSCRIPT_WATCHDOG_HANG_EXCEPTIONSCRIPT_WATCHDOG_HANG_THRESHOLDSCRIPT_WATCHDOG_SPIKE_THRESHOLDSCRIPT_WATCHDOG_SLOW_THRESHOLDSCRIPT_WATCHDOG_MEMORY_WARNINGSCRIPT_WATCHDOG_MEMORY_LIMITOP_PERMISSION_LEVELEMIT_SERVER_TELEMETRYMSA_GAMERTAGS_ONLYITEM_TRANSACTION_LOGGING_ENABLEDPor exemplo, para configurar um servidor criativo e plano em vez do uso padrão:
docker run -d -it --name bds-flat-creative
-e EULA=TRUE -e LEVEL_TYPE=flat -e GAMEMODE=creative
-p 19132:19132/udp itzg/minecraft-bedrock-serverSERVER_PORT . A porta IPv6 não é exposta por padrão. Observe que você deve anexar /udp ao expor a porta, como -p 19132:19132/udp e IPv4 e IPv6 devem estar ativados na sua máquina host. /data : o local onde o servidor baixado é expandido e executado. Também contém as propriedades de configuração File server.properties Você pode criar um named volume e usá -lo como:
docker volume create mc-volume
docker run -d -it --name mc-server -e EULA=TRUE -p 19132:19132/udp -v mc-volume:/data itzg/minecraft-bedrock-server Se você estiver usando um volume nomeado e deseja que o processo de rocha seja executado como um usuário sem raiz, precisará pré-criar o volume e chown lo para o usuário desejado.
Por exemplo, se você deseja que o servidor Bedrock seja executado com o ID do usuário 1000 e o ID do grupo 1000, crie e chame o volume chamado "Bedrock" usando:
docker run --rm -v bedrock:/data alpine chown 1000:1000 /data Se estiver usando docker run , basta fazer referência a esse volume "Bedrock" no argumento -v . Se estiver usando um arquivo de composição, declare o volume como externo usando esse tipo de declaração:
volumes :
bedrock :
external :
name : bedrock Ao executar o contêiner na sua LAN, você pode encontrar e se conectar ao servidor dedicado na parte "LAN Games" da guia "Friends", como:
O servidor dedicado da Bedrock exige que as permissões sejam definidas com Xuids. Existem várias ferramentas para procurar essas coisas on -line e elas também são impressas no log quando um jogador se une. Existem 3 níveis de permissões e 3 opções para configurar cada grupo:
OPS é usado para definir operadores no servidor. -e OPS= " 1234567890,0987654321 "MEMBERS são usados para definir os membros no servidor. -e MEMBERS= " 1234567890,0987654321 "VISITORS são usados para definir visitantes no servidor. -e VISITORS= " 1234567890,0987654321 " Existem duas maneiras de lidar com uma lista de permissões:
O primeiro é definir a variável de ambiente ALLOW_LIST como true e mapear em um arquivo allowlist.json (anteriormente conhecido como "whitelist.json") que é personalizado para o contêiner.
O outro é definir a variável de ambiente ALLOW_LIST_USERS para uma lista separada por vírgula de nomes de usuário de tag de jogadores e seus Xuids correspondentes. Cada nome de usuário deve ser seguido por seu Xuid, separado por um cólon. O servidor usará esses detalhes para corresponder ao jogador.
Existem várias ferramentas para procurar Xuids on -line e elas também são impressas no log quando um jogador se junta ao servidor.
-e ALLOW_LIST_USERS= " player1:1234567890,player2:0987654321 " Também conhecido como Comportamento ou Pacotes de Recursos, para adicionar mods ao seu servidor, você pode seguir estas etapas, testadas com OPS (Sleep One Player Sleep) e Bedrocktweaks
C:UsersUSERAppDataLocalPackagesMicrosoft.MinecraftUWP_*LocalStategamescom.mojang .Se você deseja instalá -los sem usar um cliente, poderá descompactar os mods diretamente no volume do servidor, o .mcaddon deve entrar em comportamento_packs e .mcpack em resource_packs. .Mcaddon e .mcpack são na verdade renomeados .zip arquivos.
worlds/$level-name/world_behavior_packs.json , você precisará adicionar uma entrada para cada mod, como no manifesto anterior.json, precisamos apenas do UUID agora chamado pack_id e a versão que substitui os pontos com pontos com vírgulas e citações duplas com [].Você também pode criar um
worlds/$level-name/world_resource_packs.jsonmas eu vi que colocar os pacotes de recursos e comportamento no mesmo JSON funciona bem
[
{
"pack_id" : "5f51f7b7-85dc-44da-a3ef-a48d8414e4d5",
"version" : [ 3, 0, 0 ]
}
]
Se você deseja forçar o pacote de recursos em todos os clientes, há uma opção
texturepack-required=falsenoserver.propertiesque devem ser alteradas paratrue. Os pacotes de recursos podem ser excluídos entrando em configurações> armazenamento> dados em cache, selecionando o pacote e clicando na lata de lixo.
Para obter mais informações, a Foxynotail fez um vídeo explicando o mesmo em um servidor em execução no Windows.
Para obter mais informações sobre o gerenciamento de servidores dedicados à Bedrock em geral, consulte esta postagem do Reddit.
Esta imagem vem com um script chamado send-command que enviará um comando e argumento de rock para o console do servidor Bedrock. A saída do comando só será visível nos logs do contêiner.
Por exemplo:
docker exec CONTAINER_NAME_OR_ID send-command gamerule dofiretick false
Como alternativa, com o stdin e o TTY ativado (como usar -it ), anexe ao console do contêiner pelo seu nome ou ID usando:
docker attach CONTAINER_NAME_OR_IDEnquanto anexado, você pode executar quaisquer comandos do lado do servidor, como op'ing seu jogador para ser administrador:
gamerule dofiretick false
Quando terminar, destaque-se do console do servidor usando Ctrl-P, Ctrl-Q
O diretório de exemplos contém um exemplo de arquivo de composição do docker que declara:
/data do contêiner services :
bds :
image : itzg/minecraft-bedrock-server
environment :
EULA : " TRUE "
ports :
- " 19132:19132/udp "
volumes :
- ./data:/data
stdin_open : true
tty : trueInicie o servidor e execute em segundo plano usando:
docker compose up -dVocê pode seguir os logs a qualquer momento usando:
docker compose logs -fO diretório de exemplos contém um exemplo de arquivo de manifesto de Kubernetes que declara:
A implantação do POD inclui alguns exemplos de configuração das propriedades do servidor por meio de variáveis de ambiente:
env :
- name : EULA
value : " TRUE "
- name : GAMEMODE
value : survival
- name : DIFFICULTY
value : normalO arquivo é implantável como está na maioria dos clusters, mas foi confirmado no Docker for Desktop e Google Kubernetes Engine:
kubectl apply -f examples/kubernetes.ymlVocê pode seguir os registros da implantação usando:
kubectl logs -f deployment/bds@TheTinkerdad fornece um excelente tutorial sobre como hospedar várias instâncias em uma única porta (19132) para que seja descoberta: https://www.youtube.com/watch?v=DS0_eszjbfs
Ao tentar criar essa imagem do Docker, verifique se todos os arquivos
.shtêm uma sequência de extremidade da linha deLFnãoCLRFou a compilação falhará.
