Como vender alojamento de servidores de jogos com Pelican Panel

O Pelican faz correr servidores de jogos. Não recebe encomendas, não envia faturas e não decide que um servidor deve parar por ninguém o ter pago. É dessa lacuna (entre o painel funciona e o negócio funciona) que esta página trata.

O Pelican é um fork do Pterodactyl e, no momento da redação, ainda em beta. O Provibr liga-se a ele como integração live e é testado com o Pelican 1.0.0.

O que o Pelican dá, e o que não dá

O Pelican é um painel de controlo. Conhece bem três coisas:

Aquilo de que o Pelican não tem noção: um cliente, uma fatura, um pagamento, uma subscrição que expira. Existe um indicador suspended num servidor, mas nada no painel o define por si.

Assim, um negócio de alojamento de jogos construído sobre o Pelican tem três partes, não uma:

1. 01O painel: o Pelican, a fazer correr os servidores.
2. 02A loja: onde um cliente escolhe um plano e paga. WHMCS, Blesta, FOSSBilling, o próprio checkout.
3. 03A ponte: aquilo que transforma uma encomenda paga num servidor a funcionar, e uma encomenda por pagar num servidor parado.

A maioria das pessoas constrói essa terceira parte à mão e arrepende-se. É aí que vivem os casos-limite: um nó cheio, uma variável de egg deixada em branco, um cliente que cancela enquanto o instalador ainda corre.

Ligar o Pelican: duas chaves, e uma armadilha

O Pelican tem duas APIs com duas chaves diferentes, e uma ponte de aprovisionamento precisa de ambas. Vêm de dois ecrãs diferentes, e ambas têm de pertencer a uma conta com direitos de administrador.

Conceda à chave de aplicação acesso de leitura e escrita a Server, Node, Allocation, User e Egg. Menos do que isso, e a criação falha a meio, o que é pior do que falhar logo no início.

Dois pontos a este respeito custam uma tarde:

Copie a chave de cliente no momento em que aparece. O Pelican mostra-a uma única vez. Depois, a lista guarda apenas um identificador curto. E esse identificador é aceite como chave, portanto colá-lo dá um simples erro de autenticação em vez de uma indicação de que se copiou a coisa errada. A chave de aplicação pode ser relida integralmente a partir da lista; a de cliente não.

Atenção a que chave vai em que campo. O Pelican também aceita uma chave de cliente na API de gestão, portanto trocá-las não produz um erro visível. O prefixo é a única coisa que as distingue. O Provibr verifica esse prefixo dos dois lados exatamente por esta razão: a alternativa é uma integração que parece autenticar-se e depois se comporta de forma estranha durante uma semana.

Não há aqui atalho por linha de comandos: o Pelican não fornece qualquer comando artisan para chaves de API, portanto ambas se criam através da interface web.

Se o painel apresentar um certificado autoassinado, fixe a sua impressão digital em vez de desativar a verificação. Um painel acessível por http simples funciona, mas ambas as chaves circulam então em claro pela rede. E uma impressão digital ao lado de um endereço http é recusada, porque não há certificado para fixar.

Dos eggs a algo que se possa vender

Um egg não é um produto. Não tem preço, nem nome que um cliente reconheça, nem limites associados. Um plano é a camada que transforma um no outro: contém o egg, a imagem Docker, o comando de arranque e os limites de recursos que um servidor recebe.

Dois detalhes que surpreendem ao definir os limites:

• A memória, o disco e o CPU aceitam 0 para ilimitado.
• O limite de CPU conta-se em percentagem de um núcleo. 100 é um núcleo inteiro, 200 são dois. Um plano vendido como «2 vCPU» é 200, não 2.
• O peso de E/S vai de 0 a 1000, e 500 é o valor habitual.

A regra das variáveis obrigatórias

Um egg define as suas próprias variáveis e marca algumas como obrigatórias. Eis uma decisão que vale a pena copiar, quer se use o Provibr ou não:

Recuse a encomenda quando uma variável obrigatória estiver vazia, mesmo que o próprio Pelican a aceitasse.

O Pelican cria o servidor à mesma. O contentor falha então no primeiro arranque, o cliente vê um servidor morto, e a fila de suporte recebe um pedido que diz «não funciona». Um campo que fica vermelho no momento da encomenda é uma resposta muito melhor do que um servidor que existe e não corre.

O Provibr lê a lista de eggs a partir do painel, portanto o formulário de encomenda oferece os eggs que realmente existem em vez de pedir a alguém que escreva um número.

Onde aterra um servidor

O Pelican indica quanta memória e CPU cada nó tem, e quanto já está distribuído. Uma ponte sensata usa ambos: um novo servidor vai para um nó com espaço para ele, e é recusado com um motivo quando nenhum nó o tem.

⚠️ Os números que o painel indica são contabilidade, não uma medição. Somam os limites dos servidores presentes num nó, incluindo os que ainda estão a ser instalados. Um nó pode, portanto, parecer cheio quando muito pouco está de facto a correr.

Isto importa comercialmente. Se sobrevender (e a maioria dos alojadores de jogos fá-lo, porque um servidor Minecraft ao qual são atribuídos 4 GB raramente usa 4), então os números do Pelican vão travá-lo muito antes do hardware. Calibre os orçamentos de nó em função do que tenciona vender, não do que a máquina pode fisicamente suportar.

O que o cliente toca realmente

Para um servidor de jogo, a consola é o produto. Os comandos, os jogadores que entram e a linha de log que explica uma falha vivem todos aí. O Pelican tem uma consola a sério, e o Provibr transmite-a ao cliente pela mesma ligação de saída que tudo o resto: sem porta separada, sem segundo início de sessão, sem segunda palavra-passe para repor.

Os ficheiros, as cópias de segurança, as bases de dados e os agendamentos ficam no Pelican. É deliberado: são funcionalidades do painel, e reimplementá-las numa segunda interface dá aos clientes dois lugares onde a verdade poderia estar.

Migrar um painel existente

Se já faz correr o Pelican com clientes pagantes, não é preciso reconstruir nada. Os servidores criados fora da ponte ficam intocados; importa-os para que apareçam no painel de controlo e contem para a capacidade.

Importar não toca no servidor. Apenas começa a contá-lo. Enquanto não for importado, não é gerido nem faturado, o que significa que se pode migrar um painel por lotes, ao próprio ritmo, em vez de durante uma janela de manutenção.

O que isto não abrange

Seja claro sobre a fronteira antes de vender com base nela:

• A administração do painel fica no Pelican. Adicionar nós, editar eggs, gerir os utilizadores do painel: nada disso migra.
• Os ficheiros, as cópias de segurança, as bases de dados e os agendamentos também ficam no Pelican.
• O Pelican continua em beta e a sua API muda entre versões. O painel não oferece forma de perguntar que versão está a executar, portanto uma atualização que altere uma resposta manifesta-se como um erro em vez de um aviso prévio. Leia as notas de versão antes de atualizar um painel com que a sua automação fala. Não é uma limitação do Provibr: é uma propriedade do painel, e qualquer ponte que construa a terá.

Não é preciso escolher um único painel

A maioria dos alojadores de jogos acaba por fazer correr mais do que um painel: o Pelican para o novo parque, o Pterodactyl para o que já lá estava, outra coisa para um cliente que insistiu. E a maioria também vende alojamento web ou VPS ao lado disso.

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. Um único número de capacidade, um único conjunto de chaves de API, um único lugar onde a vida de um servidor é registada, seja qual for o painel em que corre.

A página seguinte trata da outra metade: o que acontece a um servidor Pelican quando uma fatura fica por pagar.