Como vender alojamento de servidores de jogos com PufferPanel

O PufferPanel é um painel de servidores de jogos leve e auto-hospedado. Instala-se em minutos, faz correr muitos jogos e está agradavelmente livre da complexidade do Pterodactyl. Faltam-lhe também várias coisas que um negócio de alojamento pressupõe existirem.

Esta página trata de vender no PufferPanel com os olhos abertos: o que se automatiza de forma limpa, o que não, e onde fica a fronteira honesta. Tudo aqui foi medido com o PufferPanel 3.0.9.

O PufferPanel não é um fork do Pterodactyl

Vale a pena dizê-lo cedo, porque essa suposição custa dias de trabalho. O Pelican é um fork do Pterodactyl e partilha a maior parte da forma da sua API. O PufferPanel é um projeto independente, e nada se transpõe:

• A autenticação faz-se por credenciais de cliente OAuth2, não por uma chave de API.
• Os servidores são construídos a partir de modelos comunitários por nome, não de eggs numerados.
• Não existe hierarquia nest/egg para percorrer.
• Os identificadores de servidor são escolhidos por si, com oito caracteres, e escolhem-se no momento da criação em vez de se receber um.

Se tem uma integração Pterodactyl e espera apontá-la para o PufferPanel com uma mudança de configuração, está a escrever uma nova integração.

Ligar: OAuth2, e um segredo que se vê uma vez

Crie um cliente OAuth2 no painel, sob a sua conta. Obtém um ID de cliente e um segredo de cliente; ambos entram na automação juntamente com o URL do painel.

Copie o segredo de cliente imediatamente. O PufferPanel mostra-o uma única vez, na criação. Um segredo copiado pela metade dá um simples erro de autenticação em vez de indicar que está incompleto, uma hora muito banal da sua vida, passada a verificar as coisas erradas.

O que o cliente pode fazer depende da conta a que pertence. Não há seletor de âmbito. Para que crie e remova servidores, tem de pertencer a uma conta de administrador. É uma nota de segurança que importa: um cliente OAuth2 numa conta de administrador é uma credencial de administrador, e deve ser tratado como tal.

A porta não se adivinha

Um PufferPanel acabado de instalar serve HTTP simples na porta 8080. Atrás de um reverse proxy, estará na 443. Não há porta que uma automação possa acrescentar em seu nome sem adivinhar, portanto forneça o URL completo: http://panel.example.com:8080 ou https://panel.example.com.

E seja honesto consigo próprio quanto ao transporte. Um painel em http simples funciona, mas o segredo de cliente (uma credencial de administrador) e tudo o que a integração faz circulam então em claro pela rede. Se o painel estiver atrás de TLS com um certificado autoassinado, fixe a sua impressão digital em vez de desativar a verificação. Uma impressão digital ao lado de um endereço http é recusada, porque não há nada para fixar.

Modelos, não eggs

O PufferPanel constrói um servidor a partir de um modelo comunitário (minecraft, factorio, e assim por diante) em vez de um egg numerado definido por si. O nome do modelo é a sua identidade.

Duas consequências que moldam a forma de vender:

A definição completa do modelo tem de ser enviada em linha na criação. O PufferPanel não deixa dizer «faz-me um servidor a partir do modelo X» por referência; toda a definição, com as suas variáveis, vai no pedido. É por isso que encomendar no PufferPanel é, realisticamente, apenas orientado por plano: é preciso um catálogo que contenha o modelo e os seus valores, porque um formulário de texto livre pediria um documento a um cliente.

Os modelos comunitários usam por predefinição um ambiente de anfitrião. Esse ambiente precisa de binários que um anfitrião de painel acabado de instalar não tem: Java, as dependências de um jogo, aquilo que o modelo pressupõe. Deixado como está, o servidor falha a construção com um erro de binário em falta que se lê como um bug da sua plataforma. A solução é mudar para a variante docker do modelo, que os traz na sua imagem. O Provibr fá-lo automaticamente; se construir a própria ponte, faça-o você mesmo, porque o modo de falha é um pedido de suporte de cada vez.

Colocação entre nós, e porque é grosseira

O PufferPanel expõe os seus nós. Não expõe a sua memória, disco ou CPU.

Não é coisa pequena. Um motor de colocação não tem nada por que ordenar: não pode perguntar que nó tem espaço, porque o painel não responde a essa pergunta. O Provibr indica o nó à mesma (um painel de jogos sem qualquer nó não permite encomendas), mas com capacidade desconhecida, e um painel com vários nós é escolhido por ordem de nome em vez de por espaço livre.

Na prática: se faz correr mais do que um nó PufferPanel, o planeador de capacidade é você. Nada na cadeia o impedirá de sobrecarregar um nó, porque nada na cadeia o vê a encher-se.

Ciclo de vida: o que funciona

Criar, arrancar, parar, reiniciar, matar, reinstalar e eliminar funcionam todos.

Um detalhe medido: a eliminação para primeiro o servidor, porque o daemon recusa-se a remover um contentor em execução. Uma eliminação lançada contra um servidor em funcionamento devolve um 500 se essa etapa for omitida, exatamente o tipo de bug que aparece na primeira vez que um cliente cancela um servidor Minecraft muito ativo a uma sexta-feira à noite.

Três coisas que o PufferPanel não tem

Esta é a secção a ler antes de se comprometer com o PufferPanel como plataforma de venda.

Sem suspensão

O PufferPanel não tem suspensão própria. Sem coluna, sem endpoint; o estado de um servidor só conhece running e installing.

Portanto, quando uma plataforma «suspende» um servidor de jogo PufferPanel por falta de pagamento, o que acontece na realidade é: o contentor é parado, e o acesso a ele é bloqueado no painel da plataforma. É algo real e útil, mas não é imposto pelo próprio PufferPanel, o que significa que qualquer pessoa com acesso direto à instalação do PufferPanel pode voltar a arrancar o servidor.

Se os clientes não têm acesso ao painel subjacente, não há problema. Se têm, a cobrança tem um buraco, e nenhuma dose de automação o fecha. É uma propriedade do painel, não de qualquer ferramenta que se coloque à frente dele. Compare com o Pelican, que tem um verdadeiro indicador suspended.

Sem consola em direto

O PufferPanel tem uma consola, mas assenta em sondagem: GET /console devolve logs em base64 com um cursor epoch, e POST /console envia um comando. Um handshake WebSocket conforme à especificação contra /console devolve 200 JSON em vez de 101, experimentado tanto com um token bearer como com um cookie de sessão.

O relé de consola do Provibr é um túnel (transporta WebSockets NDJSON do Wings e VNC), e um modelo por sondagem não lhe encaixa sem construir uma segunda forma de relé. Por isso, a consola está desativada para o PufferPanel, deliberadamente, em vez de entregar um botão de consola que conduz a um separador que recai para a vista geral.

Para um servidor de jogo, a consola é, sem dúvida, o produto. Venda em conformidade: os clientes obtêm-na no próprio PufferPanel, não no seu painel de controlo.

Quase nenhum dado de utilização

O endpoint de estatísticas do PufferPanel indica a percentagem de CPU e a memória em bytes. Sem disco, sem rede, sem tempo de atividade.

O conjunto de gráficos habitual para um servidor de jogo é CPU, memória, disco e rede. Dois desses quatro ficariam permanentemente vazios. Um gráfico fixo a zero para sempre é pior do que nenhum gráfico, portanto os gráficos de utilização também estão desativados para o PufferPanel.

Então, quando é o PufferPanel a escolha certa?

É um painel genuinamente bom, e as fronteiras acima não o desqualificam: são apenas específicas. O PufferPanel serve-lhe se:

• Os clientes não têm acesso direto ao anfitrião do painel, tornando irrelevante a ausência de imposição da suspensão.
• Vende planos fixos em vez de recursos medidos.
• Faz correr um único nó, ou não se importa de ser o próprio planeador de capacidade.
• Valoriza um painel pequeno, rápido e com poucas dependências em vez de profundidade funcional.

Serve-lhe menos bem se vende a um público técnico com acesso ao painel, ou se os gráficos de utilização por servidor fazem parte daquilo que cobra.

Não é preciso escolher um único painel

A resposta realista para a maioria dos alojadores de jogos é ambos. O PufferPanel para a gama leve, o Pelican ou o Pterodactyl onde a consola e a imposição de regras importam, e provavelmente alojamento web ou VPS ao lado de tudo isso.

O Provibr faz correr os seus painéis de controlo, os seus hipervisores e os seus painéis de jogo lado a lado num único painel de controlo, com uma única API e um único número de capacidade a cobrir tudo. Quando um fornecedor não consegue fazer algo, a plataforma recusa com um motivo que nomeia a capacidade em falta, em vez de fingir o contrário.

A página seguinte detalha os caminhos da encomenda ao servidor e da fatura por pagar: automação de faturação com PufferPanel.