🇺🇸 English version comming soon

Servidor Minecraft - Parte 2: Rodando com Docker

Na Parte 1 desta série, instalamos o servidor Minecraft (Bedrock e Java) diretamente no sistema operacional, gerenciando o processo manualmente com screen/tmux. Neste artigo, damos um passo natural adiante: rodar o mesmo servidor em um container Docker, usando as imagens mantidas pela comunidade do projeto itzg/docker-minecraft-server e itzg/docker-minecraft-bedrock-server.

As vantagens em relação à instalação bare metal:

• Reinício automático em caso de falha (restart: unless-stopped);
• Persistência de dados isolada e explícita, via volumes;
• Configuração declarativa, em um único arquivo versionável;
• Isolamento do processo do restante do sistema.

Pré-requisito: Docker e Docker Compose já instalados. Se ainda não tiver, instale. Se não souber como, veja a minha série "Docker para desenvolvedores", la mostro na parte 1 como instalar o docker.

Rodando o Minecraft Bedrock com Docker

version: "3.8"

services:
  minecraft-bedrock:
    image: itzg/minecraft-bedrock-server:latest
    container_name: minecraft-bedrock-server
    restart: unless-stopped
    ports:
      - "19132:19132/udp"
    environment:
      EULA: "TRUE"
      GAMEMODE: "survival"
      MAX_PLAYERS: "10"
      MOTD: "Servidor Bedrock Minecraft!"
      WHITELIST: "false"
      OPS: "seu_username"
    volumes:
      - minecraft-bedrock-data:/data

volumes:
  minecraft-bedrock-data:
    driver: local

Pontos importantes:

• ports: "19132:19132/udp": o Bedrock usa UDP, diferente da maioria dos serviços de rede, repare no sufixo /udp explícito;
• EULA: "TRUE": aceita automaticamente a licença do Minecraft, evitando a etapa manual do eula.txt vista na Parte 1;
• OPS: já concede permissão de operador ao usuário informado, na primeira inicialização;
• minecraft-bedrock-data: volume nomeado, garantindo que o mundo e as configurações sobrevivam a atualizações e recriações do container.

Rodando o Minecraft Java com Docker

version: "3.8"

services:
  minecraft-java:
    image: itzg/minecraft-server:latest
    container_name: minecraft-java-server
    restart: unless-stopped
    ports:
      - "25565:25565"
    environment:
      EULA: "TRUE"
      GAMEMODE: "survival"
      MAX_PLAYERS: "10"
      MOTD: "Servidor Java Minecraft!"
      WHITELIST: "false"
      OPS: "seu_username"
    volumes:
      - minecraft-java-data:/data

volumes:
  minecraft-java-data:
    driver: local

Importante: diferente do Bedrock, o Minecraft Java usa TCP, não UDP, a porta deve ser mapeada como "25565:25565" (TCP é o protocolo padrão do Docker quando nenhum é especificado), sem o sufixo /udp.

Subindo os servidores

Cada servidor pode ficar em seu próprio arquivo docker-compose.yaml (recomendado, para gerenciá-los de forma independente) ou ambos no mesmo arquivo, como dois serviços distintos.

docker compose up -d

Acompanhando os logs de inicialização (o primeiro start pode demorar alguns minutos, baixando os arquivos do servidor):

docker compose logs -f

Gerenciando o servidor via console

As imagens do itzg incluem uma ferramenta de RCON (rcon-cli) embutida no container, permitindo executar comandos do servidor sem precisar anexar ao processo diretamente:

docker exec -it minecraft-java-server rcon-cli

Dentro do RCON, os mesmos comandos vistos na Parte 1 funcionam normalmente:

whitelist add novo_jogador
op novo_jogador

Para o Bedrock, o container também aceita comandos via send-command (dependendo da versão da imagem) ou diretamente pelas variáveis de ambiente WHITELIST e OPS no docker-compose.yaml, reiniciando o container para aplicar mudanças.

As imagens do itzg têm uma quantidade grande de variáveis de ambiente disponíveis (dificuldade, tipo de mundo, plugins, mods, etc.), vale consultar a documentação oficial de cada imagem no Docker Hub para a lista completa e atualizada, já que novas opções são adicionadas com frequência.

Repositório itzg no Docker Hub

Próximos passos

Com o Minecraft rodando em containers Docker, já temos reinício automático, persistência e configuração declarativa. Mas isso ainda roda em um único host, se a máquina cair, o servidor cai junto. Na Parte 3 desta série, vamos levar o mesmo servidor para dentro de um cluster Kubernetes, ganhando recursos como armazenamento gerenciado via PersistentVolumeClaim e a possibilidade de rodar em qualquer nó disponível do cluster.

Continua na Parte 3.