Pelican

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

• A chave de aplicação, de Admin → API Keys. Começa por papp_ e gere os servidores: criar, suspender, reinstalar, eliminar. Dê-lhe acesso de leitura e escrita a Server, Node, Allocation, User e Egg.
• A chave de cliente, da sua própria Profile → API Keys. Começa por pacc_ e transporta os comandos de energia, os valores de utilização em direto e a consola.

Quatro campos, e só o último é opcional.

• O endereço do painel, por exemplo https://panel.example.com. Acrescente uma porta apenas se o painel funcionar mesmo numa; atrás de um proxy inverso responde na porta predefinida do seu esquema.
• A chave de aplicação começada por papp_.
• A chave de cliente começada por pacc_.
• A impressão digital TLS do painel, necessária apenas quando o seu certificado é autoassinado.

Se o painel apresentar um certificado autoassinado, preencha a sua impressão digital. O agente passa então a confiar nesse certificado em concreto em vez de desligar a verificação. Leia-a com:

openssl s_client -connect <host>:443 </dev/null 2>/dev/null | \
  openssl x509 -noout -fingerprint -sha256

Deixe o campo vazio para um certificado de uma autoridade pública e também quando o painel só estiver acessível por http. Uma impressão digital ao lado de um endereço http é recusada, porque não há certificado para fixar. Um painel em http simples funciona, mas as duas chaves viajam então sem encriptação pela sua rede.

Um servidor é construído a partir de um egg: uma imagem Docker, um comando de arranque e um conjunto de variáveis que o próprio egg define. O Provibr lê a lista a partir do seu painel, por isso o formulário de encomenda oferece os eggs que tem de facto, em vez de pedir um número.

Um plano de jogos guarda o egg, a imagem, o comando de arranque e os limites que um servidor recebe. Ligue-o a uma ou mais integrações Pelican e passa a ser encomendável.

A memória, o disco e o CPU aceitam 0 para sem limite, e o limite de CPU conta em percentagem de um núcleo: 100 é um núcleo completo, 200 são dois. O peso de E/S vai de 0 a 1000 e 500 é o valor habitual.

O Pelican comunica quanta memória e quanto CPU cada nó tem, e quanto disso já foi distribuído. O Provibr usa ambos: um servidor novo vai para um nó com espaço para ele e é recusado com uma razão quando nenhum nó tem espaço.

Toda a vida de um servidor de jogos, a partir do painel ou através da API:

• Criá-lo a partir de um plano e removê-lo quando o cliente sai.
• Iniciá-lo, pará-lo, reiniciá-lo e forçá-lo a parar.
• Suspendê-lo e reativá-lo. É também o que acontece automaticamente quando uma conta ultrapassa o seu limite.
• Reinstalá-lo, o que executa novamente o script de instalação do seu egg.

Um servidor de jogos é conduzido a partir da sua consola: comandos, jogadores e a linha de registo que explica uma falha. Corre no painel pela mesma ligação de saída que tudo o resto, por isso não há uma porta separada nem um segundo início de sessão.

Os servidores que criou fora do Provibr ficam intactos. Pode importá-los para que apareçam no painel e contem para a sua capacidade, que é a forma de transferir um painel existente sem reconstruir nada.

Os ficheiros, as cópias de segurança, as bases de dados e os agendamentos ficam no painel Pelican, tal como gerir o painel e os próprios nós. O Provibr cobre a vida de um servidor e a sua consola, não a administração do seu painel.