Automatização da faturação para o PufferPanel

A maioria das páginas sobre automatização de faturação começa pelo caminho feliz. Esta começa pela lacuna, porque no PufferPanel é a lacuna que determina a conceção.

O PufferPanel não tem suspensão. Sem coluna, sem ponto de acesso. O estado de um servidor só conhece running e installing. Tudo o que se segue decorre disso.

Medido no PufferPanel 3.0.9.

Duas camadas de faturação, e não são a mesma coisa

O que cobra aos seus próprios clientes fica inteiramente dentro do seu sistema de faturação. O Provibr nunca vê uma fatura de cliente e nunca fala com os seus clientes. O seu sistema de faturação detém a decisão, a camada de aprovisionamento detém a execução.

O ciclo de vida, em correspondência

Quatro dessas cinco linhas são comuns. A segunda não é.

A lacuna da suspensão, e como conceber em torno dela

Quando uma plataforma suspende um servidor de jogos PufferPanel (para impor um limite de licença, ou porque a instruiu para tal por falta de pagamento), para o contentor e bloqueia o acesso a esse servidor no painel da própria plataforma. O servidor não corre, e o seu cliente não o pode iniciar a partir do seu painel de controlo.

Mas o bloqueio é uma noção de plataforma, não de painel. Qualquer pessoa com acesso direto à instalação do PufferPanel pode voltar a iniciar o servidor. O PufferPanel não impõe nada, porque não tem nada com que impor.

Vale a pena dizê-lo com clareza em vez de o enterrar, porque muda aquilo que se deve vender:

Se está na segunda ou na terceira linha e a imposição da cobrança importa, use um painel com um verdadeiro indicador de suspensão. O Pelican tem um, e um servidor suspenso ali permanece suspenso, independentemente de quem inicie sessão.

Uma via intermédia, para quem quiser manter o PufferPanel: rescindir mais cedo. Como uma suspensão é branda, trate-a como uma etapa de aviso e não como uma etapa de imposição, e desloque a imposição real para a eliminação, com uma política de conservação e uma cópia de segurança feita antes, comunicada com antecedência. É uma decisão de produto, não uma decisão técnica.

A regra que molda tudo: nada é instantâneo

O seu painel vive na sua própria rede, e uma plataforma sensata alcança-o através de um agente que se liga para o exterior: sem porta de entrada, sem buraco no firewall. A consequência é inevitável: um ponto de acesso que altera uma máquina não pode responder com o resultado. Responde que a encomenda foi aceite:

POST /v1/servers/{serverId}/actions/suspend
Authorization: Bearer pvk_...
Idempotency-Key: dunning-inv-10482

{
  "command": {
    "id": "cmd_...",
    "kind": "game.suspend",
    "status": "pending"
  }
}

202 Accepted, não 200. Depois lê esse comando até que o seu estado seja definitivo: done, failed, timed_out ou cancelled. Um comando falhado transporta o próprio código de erro do agente, com os seus argumentos. A leitura é diferente: um inventário, um endereço ou uma fatura responde imediatamente, porque isso vem de uma base de dados e não do seu anfitrião.

Desenhe os seus ganchos de cobrança em torno disto. Um gancho que trata «a API respondeu» como «o trabalho está feito» reportará uma suspensão bem-sucedida que nunca aconteceu, precisamente no dia em que isso importava.

Repetir em segurança

Tudo o que cria algo aceita um cabeçalho Idempotency-Key da sua própria autoria. Repita o mesmo pedido com o mesmo valor e obtém de volta o primeiro resultado, em vez de um segundo servidor. Indexe-o em algo estável do seu lado (o ID da fatura, o ID do serviço, a etapa de cobrança), porque webhooks reenviados e crons de quinze minutos são normais, e ambos devem ser inofensivos. Reutilizar esse valor para um pedido diferente é recusado deliberadamente: uma chave que significa duas coisas não significa nada.

Os verbos, e quando são permitidos

Um servidor de jogos aceita seis ações através da API: start · stop · restart · kill · suspend · resume, protegidas pelo estado atual do servidor:

É possível suspender um servidor que já está parado, e isso é deliberado: uma imposição que se pode contornar carregando em «stop» não é uma imposição. suspend a partir de installing segue a mesma lógica: um cancelamento que chega a meio da instalação não deve esperar que a instalação termine.

Encomendar é guiado pelo plano, e tem de ser

Nalguns painéis é possível compor uma encomenda à mão. No PufferPanel, na prática, não, e a razão é estrutural: o PufferPanel exige a definição completa do modelo em linha quando um servidor é criado. Não existe «criar um a partir do modelo X por referência», pelo que a definição tem de vir de um catálogo. Um plano de jogo transporta o nome do modelo e os limites de recursos; a encomenda aponta para o plano. Se construir a sua própria ponte, acabará por construir este catálogo de qualquer forma.

Dois detalhes medidos em que é fácil tropeçar:

• Os modelos comunitários usam por predefinição um ambiente de anfitrião, que precisa de binários que um anfitrião de painel acabado de instalar não tem. Mude para a variante docker do modelo, ou cada encomenda falha com um erro de binário em falta que se lê como um bug de plataforma.
• A eliminação para o servidor primeiro. O daemon recusa-se a remover um contentor em execução; uma eliminação contra um servidor a correr devolve um 500.

O que não está lá deliberadamente

• Sem faturação baseada no uso. O ponto de acesso de estatísticas do PufferPanel reporta apenas a percentagem de CPU e a memória, sem disco, sem rede, sem tempo de atividade. Dois dos quatro gráficos padrão de um servidor de jogos ficariam permanentemente vazios, pelo que os gráficos de uso estão desligados para este fornecedor. Não é possível faturar ao contador dados que não existem.
• Sem consola no painel de controlo. A consola do PufferPanel assenta em sondagem e não num terminal em direto; um handshake WebSocket conforme à especificação em /console devolve 200 JSON em vez de 101. Os seus clientes obtêm a consola no próprio PufferPanel.
• Sem colocação que tenha em conta a capacidade. O PufferPanel expõe os seus nós mas não a sua memória, disco ou CPU, pelo que um painel com vários nós é escolhido por ordem de nome, e não por espaço livre. O planeamento da capacidade fica a seu cargo.
• Sem mudança de plano numa só chamada. Trocar de plano é uma reinstalação, com as consequências que isso implica para os dados do cliente.
• Sem ciclo de reconciliação de inventário. A sincronização _ListAccounts do WHMCS rescinde qualquer serviço ausente da resposta, e «ausente» tem causas inocentes: um âmbito de API mais estreito, um membro restrito a parte do inventário, uma limitação de débito, uma página curta cujo cursor não foi seguido. Cada uma eliminaria máquinas de clientes.

Fazê-lo a partir do WHMCS em vez de código

Se já usa o WHMCS, o Provibr fornece um módulo de aprovisionamento como um simples zip que instala por si próprio. Um produto do WHMCS aponta para um plano do Provibr; o fluxo de encomenda normal do WHMCS trata de criar, suspender, reativar e rescindir. Duas decisões nele valem a pena copiar, mesmo para a sua própria ponte:

Uma entrega ainda em curso conta como êxito. Se o orçamento de espera expirar enquanto o instalador trabalha, o módulo reporta êxito: a encomenda foi aceite, e o WHMCS não tem um estado «em instalação» (Pending ali significa ainda não aconteceu nada, o que é falso). Um comando que falha verdadeiramente é diferente: o serviço fica Pending e o administrador vê porquê.

Um servidor que já desapareceu é uma rescisão bem-sucedida. Um 404 significa várias coisas ao mesmo tempo (ID desconhecido, outra conta, não visível para este membro, já eliminado) e, para um gancho de rescisão, a ação certa é a mesma em todas: não há nada para limpar.

Contar a capacidade, e como isso se cruza com a cobrança

A faturação da plataforma conta a capacidade, não o uso, com uma regra que apanha toda a gente no primeiro mês: cada servidor conta, esteja a correr ou não. Só um servidor suspenso não conta, e um servidor eliminado também não: parar uma máquina não liberta um lugar.

Isto encaixa-se bem com a cobrança: um cliente que suspende deixa de contar enquanto estiver suspenso, e volta a contar quando paga e o reativa.

O PufferPanel a par de tudo o resto

Não é obrigatório escolher um único painel. O Provibr cobre os seus painéis de controlo, os seus hipervisores e os seus painéis de jogo num único painel de controlo, com uma única API e um único número de capacidade.

POST /v1/servers/{id}/actions/suspend faz a mesma coisa quer por baixo esteja um servidor Pelican, um servidor PufferPanel ou uma conta de alojamento DirectAdmin. As diferenças vivem no fornecedor, não no seu código de integração. E onde um fornecedor realmente não consegue fazer algo, obtém uma recusa que nomeia a capacidade em falta, em vez de uma ausência silenciosa de efeito.