Automatizar a faturação e o aprovisionamento CloudPanel

Um produto de alojamento automatizado tem exatamente três momentos em que o dinheiro e as máquinas se tocam:

1. 01A encomenda é paga: o site tem de existir, corretamente configurado, em segundos.
2. 02A fatura está vencida: o site tem de se apagar e voltar assim que for pago.
3. 03A subscrição termina: o site tem de ser removido, a sério, incluindo os seus dados.

O CloudPanel tem um comando limpo para o primeiro momento e um comando limpo para o terceiro. Para o segundo, não tem absolutamente nada. Isto não é uma pequena nota de rodapé sobre uma integração de resto comum; é o facto determinante da automatização da faturação neste painel, e merece o meio desta página, e não uma linha no fundo.

Os três momentos, e o que o CloudPanel oferece

Tudo passa por clpctl, a ferramenta de linha de comandos do painel. Não há API REST: o CloudPanel é um painel renderizado no servidor mais uma CLI, e a automatização passa por essa CLI ou não passa.

Os dois comandos que existem são bons comandos. site:add:php recebe o domínio, a versão de PHP, um modelo de vhost e o utilizador Linux do site com a sua palavra-passe, e devolve o controlo depois de escrever o vhost, o pool e o diretório pessoal. site:delete --force é uma verdadeira eliminação, não uma eliminação suave. Entre eles fica a lacuna.

O meio em falta, e como se preenche

A suspensão é a ação que um sistema de faturação executa mais do que qualquer outra, porque é a que corre sem supervisão, segundo um calendário, contra contas que ninguém está a ver. É também a única alavanca reversível que tem entre «continuar a alojá-los de graça» e «apagar o negócio deles».

O CloudPanel não tem palavra para isso. Não há site:suspend, não há site:disable, não há um indicador de manutenção no painel, e não há um estado por site que se possa alternar. Por isso, se vende alojamento CloudPanel, a suspensão é algo que se constrói. As opções realistas, com o seu custo honesto:

Parar o pool PHP-FPM do site. Rápido, reversível, e para realmente o serviço do site. Produz, no entanto, um 502 em vez de uma explicação: o seu cliente vê um site avariado e não uma conta suspensa. E é uma operação systemd no anfitrião, não uma operação clpctl, pelo que é da sua responsabilidade mantê-la a funcionar ao longo das atualizações do painel.

Editar o vhost. A configuração NGINX do site é um ficheiro no anfitrião, e uma única linha nele decide se o site responde. Reversível, instantâneo, e não custa ao cliente mais do que o acesso. O senão é que está a escrever num ficheiro que o CloudPanel possui, pelo que importa muitíssimo como se escreve nele.

Eliminar, depois de uma cópia de segurança. Sem ambiguidade, e permanente de uma forma que acabará por lhe custar um cliente que pagou no trigésimo primeiro dia. Restaurar não é um interruptor, com tudo o que isso implica quanto ao DNS, aos certificados e ao correio que terá de enviar a seguir.

Não existe uma quarta opção que seja limpa. O que importa é escolher uma deliberadamente e garantir que a pessoa que atende o telefone sabe qual é. O modo de falha aqui não é técnico: é um agente de apoio a prometer a um cliente que o seu site volta já, num sistema em que voltar significa restaurar uma cópia de segurança.

Como é uma edição de vhost cuidada

A segunda opção é a que vale a pena fazer bem, e «bem» é uma lista curta. É assim que o Provibr o faz, e o raciocínio transfere-se quer use o Provibr, quer o escreva por si próprio.

Marque o que insere. A suspensão é um return 403; envolvido por um comentário de início e um de fim. Removê-lo significa apagar exatamente as linhas entre esses marcadores. Assim, a reativação deixa o ficheiro byte a byte tal como estava, e um return 403; que o cliente lá tenha posto pelas suas próprias razões sobrevive intacto. Um procurar-e-substituir sobre return 403 não teria essa propriedade.

Cada bloco server público, não o primeiro. Um vhost tem normalmente um bloco para a porta 80 e um para a 443. Injete num só e obtém um site suspenso em HTTP e um perfeitamente saudável em HTTPS, o que é pior do que não suspender de todo, porque parece que funcionou.

Teste a configuração antes de a recarregar. nginx -t corre primeiro. Uma suspensão que deita abaixo todos os outros sites da máquina não é uma suspensão, e trata-se, por conceção, de um servidor web partilhado.

Torne o estado legível a partir do anfitrião. Como a marca é um comentário num ficheiro, os sites suspensos estão a um grep de distância e o agente relê isso em vez de confiar na sua própria base de dados. Se alguém editar o ficheiro à mão, a sondagem seguinte dá por isso.

O que nada disto muda: o próprio CloudPanel continua sem qualquer noção de site suspenso. O painel mostrá-lo-á como um site comum, porque, do ponto de vista do painel, é-o. Qualquer pessoa com acesso ao CloudPanel, incluindo o cliente que acabou de suspender, pode abrir esse ficheiro e retirar a linha. O estado é legível e é imposto ao nível do servidor web, mas não pertence ao painel, e nenhuma montagem neste painel o pode tornar assim.

Também não há caminho de subida de plano, porque não há pacotes

O CloudPanel não tem planos, nem quotas, nem limites por site. Isso retira um momento inteiro da lista acima: não há chamada «mudar de pacote», porque não há pacote.

Significa também que a diferença entre os seus planos tem de ser real noutro lugar. Se o seu plano de 5 € e o seu plano de 15 € aterram no mesmo CloudPanel com tudo igual, então o que o seu cliente comprou foi um preço, e o primeiro que der por isso dirá aos outros. A imposição vive acima do painel: anfitriões distintos por escalão, quotas ao nível do sistema de ficheiros, ou limites que a sua própria plataforma aplica e conta.

A reconciliação precisa de uma lista, e não há nenhuma

clpctl sabe listar os utilizadores do painel. Não sabe listar os sites: esses vivem na própria base de dados SQLite do painel, no anfitrião.

Para a faturação, isso é um verdadeiro buraco, porque um sistema de faturação deveria poder fazer duas perguntas a qualquer momento: tudo o que faturo ainda existe? e há aqui algo que não estou a faturar? Responde-se a ambas comparando os seus registos com uma lista do que está realmente na máquina. Sem uma lista, fica a saber de um site eliminado à mão quando o cliente escreve, e de um site criado à mão nunca.

Seja o que for que construa sobre o CloudPanel, terá de obter essa lista de um sítio que não seja clpctl, e precisará de acesso ao anfitrião para o fazer. Na prática, existe exatamente um lugar: a própria base de dados do painel, /home/clp/htdocs/app/data/db.sq3, onde um simples select sobre a tabela site dá, de uma só vez, o domínio, o utilizador Linux, o tipo, o modelo de vhost e a versão de PHP. O Provibr lê-a aí.

Isto funciona, e vale a pena ser claro sobre aquilo que se aceita ao fazê-lo. Esse esquema é assunto interno do CloudPanel, não uma interface publicada, pelo que pode mudar numa versão sem que ninguém tenha quebrado uma promessa. Lê-lo é a escolha certa (um sistema de faturação sem reconciliação é pior), mas está na curta lista de coisas a reverificar após uma atualização do painel, a par dos formatos de saída de clpctl.

A credencial não é um token de API

Vale a pena ser franco sobre isto, porque é a maior diferença prática entre automatizar o CloudPanel e automatizar um painel dotado de uma API REST.

clpctl corre como root. Escreve configuração NGINX, cria utilizadores Linux e gere serviços, pelo que o root não é um descuido: é o trabalho. Tudo o que o comanda detém, por isso, acesso administrativo a um servidor web de produção que transporta os sites de outras pessoas, e não um token com âmbito restrito, limitado a uma única superfície de API.

Duas consequências para quem liga faturação a isto. A extensão dos danos é diferente: um token de API de painel que vaze permite a alguém criar e eliminar contas, ao passo que uma credencial de shell que vaze no servidor web é uma outra conversa, com um conjunto diferente de obrigações. E o menor privilégio é trabalho seu: não há uma caixa de permissões em que apoiar-se, pelo que a delimitação de âmbito se concebe, em vez de se configurar.

Onde vive realmente a fatura

Vale a pena ser explícito, porque é o mal-entendido mais comum: o Provibr não fatura os seus clientes. Não lhes envia qualquer fatura, não anda atrás deles para cobrar, e não sabe o que lhes cobra. Essa relação é sua.

O que o Provibr fatura é a capacidade que o próprio reserva: quantas contas de alojamento pode ter em funcionamento em simultâneo, por mês, a um preço unitário escalonado. O que cobra aos seus próprios clientes, e como, fica inteiramente dentro do seu próprio sistema de faturação.

Há duas formas de ligar as duas metades:

Um módulo WHMCS. Se já usa o WHMCS, instale o módulo de aprovisionamento do Provibr e faça um produto do WHMCS apontar para um plano web do Provibr. O seu cliente mantém uma conta, uma fatura e um identificador de acesso. O módulo é um simples zip que instala por si próprio, e corre dentro do seu WHMCS. Não há nada a ativar do nosso lado.

A API REST. Se usa o FOSSBilling, o Blesta, algo interno, ou uma folha de cálculo e uma tarefa cron, comande-a diretamente. Uma chave, um URL de base, e exatamente as permissões que o membro por trás da chave já tem.

A única regra para o comandar a partir do seu próprio código

Tudo o que toca numa máquina é assíncrono, e tem de ser. A sua infraestrutura só é alcançável através do agente que está dentro da sua própria rede, e esse agente liga para o exterior. Por isso, um ponto de acesso que altera uma conta não pode responder com o resultado. Responde que a encomenda foi aceite e entrega-lhe um comando para seguir, que lê até que o seu estado seja definitivo: concluído, falhado, expirado ou cancelado.

A leitura nunca funciona assim. Um inventário, um endereço ou uma fatura responde imediatamente, porque essa resposta vem de uma base de dados e não do seu anfitrião.

A consequência prática para um gancho de faturação: não marque a encomenda como concluída com base na resposta de aceitação. A primeira resposta que obtém diz «enviámos», não «funcionou».

Suspender é também controlar os seus próprios custos

Uma ligação fácil de não notar, e é a razão pela qual o meio em falta acima custa tanto dinheiro como boa vontade. No Provibr, um servidor suspenso deixa de contar para a capacidade que paga. Para uma conta de alojamento não existe «parado»: há ativo, e há suspenso.

Assim, a etapa de cobrança que já queria por razões comerciais liberta também o lugar que está a pagar, desde que a suspensão seja uma ação real e não uma nota na sua própria base de dados. É esse o argumento prático para a construir em vez de deixar o meio vazio: uma conta por pagar que ainda não decidiu eliminar é capacidade que continua a pagar.

Tudo o que precede sobre o painel é uma propriedade do CloudPanel e não a descrição de uma integração, e isso é deliberado: as lacunas são reais e não nos compete fazê-las desaparecer por vontade. O que uma integração pode fazer é escolher com cuidado qual das três opções toma, e dizer em voz alta o que essa escolha ainda não resolve.

Se também vende VPS, servidores de jogos ou contas cPanel, os mesmos três momentos aplicam-se a todos eles, e podem viver num único inventário. O Provibr faz correr hoje os seus painéis de controlo, os seus hipervisores e os seus painéis de jogo lado a lado, com um único conjunto de permissões e um único registo de atividade para o conjunto.