Como vender alojamento Minecraft com MCSManager

O alojamento Minecraft é o ponto de partida da maioria dos negócios de alojamento de jogos, e por boas razões: a procura é constante, os clientes são pacientes com os pequenos fornecedores, e a fasquia técnica até ao primeiro cliente pagante é realmente baixa. O painel em que se começa costuma ser o que corria no hardware de que se dispunha.

O MCSManager é aquele em que muita gente acaba por parar. É de código aberto, é pequeno, abrange várias máquinas e (a propriedade que decide a questão para muitos) não exige Docker. Esse simples facto coloca-o em hardware onde a família Pterodactyl é impraticável, e vale a pena perceber porquê antes de construir um negócio por cima.

O que é realmente o MCSManager

Duas peças, na forma agora clássica: um painel web e um daemon. O painel é a interface e o lugar onde acontece a administração entre nós; o daemon corre em cada máquina e é o que realmente arranca, para e supervisiona os processos. Um painel pode falar com muitos daemons, portanto crescer significa acrescentar uma máquina em vez de erguer um segundo painel.

Está escrito em TypeScript (Node.js e Vue na interface, Node.js nos daemons), o que o torna leve de operar e fácil de ler no dia em que for preciso saber exatamente o que faz. Cerca de 4800 estrelas no GitHub no momento da redação, ativamente desenvolvido, e traduzido para várias línguas.

O âmbito é Minecraft primeiro, com títulos baseados em Steam ao lado: Palworld, Terraria, Project Zomboid e o resto dessa família. Se o catálogo é «Minecraft, mais o jogo de sobrevivência a que toda a gente joga este ano», isso corresponde de forma limpa ao MCSManager.

A questão do Docker, e porque decide as coisas

O Pterodactyl e os seus descendentes exigem contentores. É uma conceção defensável (dá isolamento e limites de recursos de graça), mas também fixa um piso quanto aos sítios onde se pode correr.

O MCSManager suporta Docker e não o impõe. Os servidores podem correr como simples processos geridos pelo daemon. Três consequências práticas:

• Corre em hardware barato e complicado. Um pequeno VPS onde os contentores aninhados são desagradáveis, uma máquina OpenVZ ou LXC, um computador reaproveitado num escritório: o MCSManager funcionará aí.
• Corre em Windows. Para um amador que se transforma em empresa, é muitas vezes o que está realmente disponível.
• A contrapartida é o isolamento. Sem contentores, «o servidor deste cliente comeu toda a RAM» não é automaticamente um problema de outra pessoa que fica contido. O isolamento e os limites que se quiserem, é o próprio que os organiza: cgroups, utilizadores separados, máquinas separadas, ou ativar o Docker apesar de tudo.

Este último ponto é aquele em que convém pensar antes do décimo cliente e não depois. Fazer correr processos não isolados para pessoas que pagaram é aceitável com três servidores e uma má ideia com trezentos. O painel deixa fazer as duas coisas.

Autenticação e multiutilizador

O MCSManager tem vários utilizadores e chaves de API: é gerada uma chave por utilizador, que é o que autentica o acesso programático, e o daemon tem a sua própria chave como único meio de autenticar um painel perante ele.

Vale a pena ser claro sobre a finalidade desse modelo: os utilizadores do MCSManager são pessoas que operam servidores. Não são clientes com subscrição. Não há plano associado a um utilizador, sem prazo de validade, sem preço, sem fatura, e nada que diga que um utilizador deixou de pagar. Se se der a cada cliente um acesso ao painel, deu-se-lhe uma conta de operação na sua infraestrutura, e o registo de quem lhe deve dinheiro está noutro lado completamente diferente.

Isto não é um defeito. É igual em todos os painéis de jogos, incluindo aqueles pelos quais as pessoas pagam. É simplesmente a linha onde o painel termina e o negócio começa.

O que vender exige realmente

O painel dá a metade máquina: criar um servidor, arrancá-lo, pará-lo, reiniciá-lo, chegar a uma consola, eliminá-lo. A metade comercial é inteiramente sua para construir ou comprar:

• Um formulário de encomenda e um catálogo, com planos que significam alguma coisa em RAM, lugares ou armazenamento.
• Um pagamento que aprovisiona em segundos. No alojamento de jogos não é um luxo: o cliente está normalmente sentado com os amigos à espera de entrar, e um atraso de aprovisionamento medido em minutos é a forma de os perder.
• Um percurso de cobrança: em atraso, avisado, suspenso, reposto. A suspensão importa mais aqui do que no alojamento web, porque um servidor de jogo deixado a correr consome RAM continuamente para alguém que deixou de pagar.
• Capacidade visível, para saber o que se está a suportar em todos esses daemons antes de a fatura de alojamento o dizer.
• Um registo de auditoria, para que «quem eliminou aquele mundo» tenha resposta. No alojamento Minecraft em particular, essa pergunta faz-se, e a resposta tem de valer mais do que um encolher de ombros.
• Um modelo de permissões para a sua equipa, para que um voluntário do suporte possa reiniciar um servidor sem poder eliminar nenhum.

A maioria dos pequenos alojadores de Minecraft faz correr esta metade com uma folha de cálculo, uma ligação de pagamento e muita boa vontade. Isso funciona até deixar de funcionar, e a falha raramente é espetacular: é uma acumulação lenta de servidores que ninguém paga, reembolsos que não se conseguem reconstituir, e uma noite por mês passada a fazer reconciliações à mão.

Uma nota prática sobre o próprio projeto

O MCSManager tem origem na comunidade de língua chinesa e é ainda aí que se encontra o seu centro de gravidade. O painel está corretamente internacionalizado e existe documentação em inglês, mas quando se procura uma resposta aprofundada (um caso-limite no protocolo do daemon, uma implantação invulgar), o material mais rico e as respostas mais rápidas da comunidade estão muitas vezes em chinês. A tradução automática lida bem com isso. Vale a pena saber antes de precisar de ajuda à meia-noite, e não descobri-lo nesse momento.

Onde o Provibr se insere

O suporte a MCSManager está em produção. Um agente dentro da sua própria rede fala com o painel web por http ou https, de modo que nem o painel nem os daemons por trás dele têm de estar expostos à Internet. Criar, arrancar, parar, reiniciar, suspender e remover instâncias funciona, e o que já está no painel pode ser importado. À volta disso está a camada descrita acima: planos e capacidade a um preço unitário, um modelo de permissões para a sua equipa, um registo de atividade completo, e uma API REST e um módulo WHMCS para que aquilo com que já fatura o possa comandar.

O MCSManager já reparte uma única instalação por vários daemons, pelo que crescer significa acrescentar uma máquina e não um segundo painel. O Provibr lê essa lista e coloca o servidor novo na memória livre; havendo mais do que um daemon e nenhum valor por omissão, recusa em vez de adivinhar. Aqui a suspensão é a sério: o MCSManager mantém em baixo, por si mesmo, uma instância expirada, pelo que um cliente com acesso ao painel não a consegue voltar a arrancar.

O que a integração não consegue fazer é apagar as lacunas do painel. Não há consola, porque a do MCSManager corre sobre socket.io, e não há gráficos de utilização, porque o painel não os mede. Também não há reinstalação: o MCSManager só reconstrói a partir de uma predefinição e o Provibr constrói a partir de um comando de arranque. Sem Docker o painel não impõe limite nenhum, e a integração di-lo em vez de fingir o contrário.

O que não fará

Gerir servidores não é gerir o painel. Instalar o MCSManager, atualizá-lo, acrescentar daemons, escolher usar ou não o Docker e cuidar das máquinas por baixo continua a seu cargo. Os mundos, os plugins, os mods e as cópias de segurança ficam no painel, onde continua a usá-los, tal como os seus clientes.

O alojamento de jogos raramente fica só por alojamento de jogos. O Provibr faz correr hoje os seus painéis de controlo, os seus hipervisores e os seus painéis de jogo lado a lado, sob um único inventário, um único modelo de permissões e um único registo de atividade. Servidores Minecraft num painel, o VPS para o qual um cliente evolui noutro, e um único lugar onde se veem ambos.