Vender alojamento web com CloudPanel

O CloudPanel é o painel que se instala quando se quer um site a funcionar depressa e mais nada no caminho. É gratuito, instala-se em poucos minutos numa instância cloud nova, e o que sai é uma pilha NGINX e PHP-FPM sem enfeites, com Let's Encrypt, uma base de dados e uma integração Cloudflare. Sem servidor de correio. Sem camadas que não se pediram.

Esse foco é exatamente o que agrada, e é também por isso que vender alojamento nele é um exercício diferente de o fazer no DirectAdmin ou no cPanel. O CloudPanel gere sites num servidor. Não gere clientes que lhe pagam. Não são o mesmo problema, e é da distância entre os dois que trata esta página.

Aquilo à volta do qual o CloudPanel foi realmente construído

Um servidor, e os sites que nele estão.

Cria-se um site (PHP, estático, Node.js, Python ou um reverse proxy) e o CloudPanel escreve um vhost NGINX, um pool PHP-FPM, um utilizador Linux de site e um diretório pessoal. Coloca-se uma base de dados ao lado. Aponta-se-lhe um certificado. É este o ciclo, e é bom: um programador ou uma agência que faz correr vinte sites numa máquina obtém uma interface limpa sobre exatamente aquilo que manipula.

O que não tem é a camada acima disso: um cliente que possui um conjunto de sites, com um plano, uma quota e um interruptor. O CloudPanel tem utilizadores de painel com papéis (administrador, gestor de site, utilizador) e esses utilizadores podem ser restringidos a sites específicos. Mas isso é controlo de acesso para pessoas que iniciam sessão, não uma conta comercial que se possa faturar e desligar.

A distinção parece teórica até ao dia em que o primeiro cliente deixa de pagar.

Toda a superfície de comando cabe numa ferramenta de linha de comando

O CloudPanel não tem API REST. Tudo o que a automatização pode fazer, fá-lo através de clpctl, a ferramenta de linha de comando do próprio painel, que corre no anfitrião como root. É devidamente scriptável (não interativa, opções em vez de perguntas) e cobre as partes que seria de esperar:

Duas coisas nessa tabela merecem atenção antes de se planear seja o que for à sua volta.

A primeira é que a identidade de um site é o seu nome de domínio. Não um id numérico, não um identificador de conta: o domínio. Tudo o que se constrói se apoia nisso, e tem de sobreviver a um cliente que queira mover um domínio entre planos.

A segunda pesa mais, e é o objeto da secção seguinte: não há nessa tabela nenhum verbo para desligar um site.

As três lacunas que contam quando se vende

Não há suspensão

clpctl tem site:add:* e tem site:delete. Entre os dois, não tem nada. Não há site:suspend, não há site:disable, não há interruptor de manutenção. E a interface do painel também não tem equivalente.

Para um negócio de alojamento, essa não é uma lacuna cosmética, porque «a fatura tem trinta dias de atraso» é de longe a situação mais comum sobre a qual será preciso agir, e eliminar o site não é a resposta. Eliminar é irreversível e leva consigo os dados do cliente; um cliente que paga no trigésimo primeiro dia espera encontrar o seu site onde o deixou.

Por isso, tudo o que venda alojamento CloudPanel tem de inventar a suspensão. Os candidatos habituais são parar o pool PHP-FPM do site, ou modificar o vhost para que o site deixe de responder. Ambos funcionam, e o segundo é o melhor dos dois: um pool parado produz um 502, o que, para o cliente, parece um servidor avariado em vez de uma fatura em atraso.

Modificar bem um vhost cabe numa lista mais curta do que parece. Envolva-se o que se insere entre um comentário de início e um de fim, para que a reativação signifique eliminar exatamente essas linhas e mais nada. Faça-se em cada bloco server público, porque um vhost costuma ter um para a porta 80 e um para a 443. E um site suspenso em HTTP mas saudável em HTTPS é pior do que um que não está suspenso de todo, pois parece que resultou. Corra-se nginx -t antes de recarregar, porque isto é um servidor web partilhado e uma configuração má leva consigo todos os sites que nele estão. Façam-se estas três coisas e a suspensão torna-se uma ação vulgar, imediata e totalmente reversível. O Provibr faz exatamente isto: um return 403; marcado, cada bloco público, testado antes de recarregar.

O que nenhum arranjo resolve é que o painel não sabe. O CloudPanel não tem o conceito de site suspenso, pelo que lista um site suspenso como se fosse vulgar. E quem tenha acesso ao painel ou ao anfitrião pode abrir o ficheiro e retirar a linha, incluindo o cliente que se acabou de suspender. É possível tornar o estado legível (a marca está à distância de um grep, e é assim que o Provibr repara numa edição manual), mas não é possível fazer com que o CloudPanel o assuma como seu.

Decida-se o que significa «desligado» antes do primeiro cliente, não depois do primeiro incumpridor.

Não há pacotes

O CloudPanel não tem planos, nem quotas, nem limites por site. Sem quota de disco, sem limite de largura de banda, sem «este site pode ter três bases de dados». O que mais se aproxima de um pacote é um modelo de vhost, ou seja, uma configuração NGINX: útil, mas não é um limite, e não vai impedir ninguém de usar 400 GB.

Isto significa que o catálogo de produtos não pode viver no painel. Aquilo que separa o plano de 5 € do plano de 15 € tem de ser definido, aplicado e medido algures acima do CloudPanel. Se não for aplicado em lado nenhum, não é um plano. É uma sugestão.

Não há lista de sites

Há user:list para os acessos ao painel. Não há site:list. Os próprios sites vivem na base de dados SQLite do painel, no anfitrião.

Isto importa mais do que parece, porque uma lista é aquilo de que a reconciliação é feita. Sem ela não é possível responder «o que estou a faturar ainda existe?», não é possível detetar um site que alguém eliminou à mão, e não é possível importar um servidor existente seja para onde for.

A saída é ler essa base de dados diretamente: /home/clp/htdocs/app/data/db.sq3, um select sobre a tabela site, e tem-se cada domínio com o seu utilizador, o seu modelo e a sua versão de PHP. É o que o Provibr faz, e aquilo a que tudo o que seja sério acaba por chegar. Fique-se apenas ciente de que se está a ler um esquema interno e não uma interface: pode mudar numa versão sem que isso seja uma promessa quebrada, pelo que fica na lista das coisas a reverificar após uma atualização do painel.

E uma restrição de conceção por baixo de tudo isto

clpctl corre como root no anfitrião. Isto não é um detalhe de implementação que se possa contornar: escreve configuração NGINX, cria utilizadores Linux e gere serviços de sistema, e isso exige os privilégios que exige.

A consequência é que automatizar o CloudPanel é uma questão de privilégios antes de ser uma questão de integração. Tudo o que comande clpctl (o próprio script, uma tarefa agendada, uma ferramenta de implementação) corre como root num servidor web de produção que aloja os sites de outras pessoas. Seja o que for que se construa, construa-se sabendo que a credencial em jogo não é um token de API de âmbito limitado; é acesso administrativo à máquina. Mantenha-se estreito, mantenha-se auditável, e mantenha-se longe de tudo aquilo a que um cliente possa chegar.

O que tem de existir acima do painel

Retire-se o que é específico do painel e a lista é a mesma para qualquer painel de controlo, o que é a parte útil (não muda se mais tarde se trocar de painel):

• Um formulário de encomenda e um catálogo, com planos que signifiquem algo aplicável.
• Um pagamento que despoleta o aprovisionamento em segundos, não num dia útil.
• Um percurso de cobrança (em atraso, avisado, suspenso, restaurado) com uma ação definida em cada passo.
• Capacidade visível, para se saber quantas contas se transportam e o que custam antes de a fatura o dizer.
• Um registo de auditoria, para que «quem eliminou aquele site» tenha resposta.
• Um modelo de permissões para as pessoas que trabalham consigo, para que o suporte possa reiniciar algo sem poder eliminar tudo.

Nada disso vem com o CloudPanel, e nada disso é o que o CloudPanel procura ser.

Onde o Provibr se encaixa

O suporte para o CloudPanel já funciona. Um agente dentro da sua própria rede liga-se ao anfitrião por SSH e corre o clpctl tal como se faria à mão, pelo que nada é instalado no painel e nenhuma porta tem de ficar exposta à internet. Criar um site, suspendê-lo, retomá-lo e removê-lo funciona, e os sites que já lá estavam só são importados se os marcar. À volta fica a camada descrita acima: planos e capacidade, um preço por unidade, um modelo de permissões, um registo de atividade, e uma API REST e um módulo WHMCS para o comandar a partir daquilo com que já se factura.

O que a integração não consegue fazer é apagar as lacunas acima, porque são propriedades do painel. A suspensão é a parte inventada: uma regra NGINX marcada que devolve 403, inserida em cada bloco de servidor público e verificada antes de recarregar; retomar remove-a e o site volta byte a byte. O modelo de vhost fica fixo assim que o site existe, pelo que não há mudança de plano: passar para outro modelo ou outra versão de PHP obriga a recriá-lo, e o Provibr di-lo em vez de fingir que houve uma alteração. Também não há consola nem gráfico de consumo, porque o CloudPanel não mede nenhum dos dois.

O que não fará

Vale a pena dizê-lo agora e não mais tarde: gerir contas não é gerir o painel. Instalar o CloudPanel, atualizá-lo, alterar definições do servidor, afinar o NGINX e cuidar das bases de dados e dos certificados que os clientes criam: isso fica do seu lado, no painel, onde é o seu lugar.

Não é preciso apostar o negócio num só painel. O Provibr faz correr lado a lado os seus painéis de controlo, os seus hipervisores e os seus painéis de jogo, sob um só inventário, um só modelo de permissões e um só registo de atividade. Um painel NGINX leve para os clientes que querem velocidade numa só máquina, algo com uma árvore de revendedores para os que pedem o cPanel pelo nome, e um só lugar onde se veem ambos.