Aplicações

Uma aplicação roda a partir de uma imagem de contêiner ou de um repositório do GitHub que o Orbit compila no seu servidor.

Publicando

• Um deploy espera até 3 minutos pelo health check da aplicação e até um minuto pelo certificado. Defina ORBIT_HEALTH_TIMEOUT e ORBIT_CERTIFICATE_TIMEOUT (por exemplo 5m) no orbit.service para mudar qualquer um dos dois.
• Uma aplicação que sai logo depois de iniciar (uma migração que falhou, uma variável faltando) falha dizendo que parou logo depois de iniciar, com o código de saída e as últimas linhas, em vez de parecer um health check que nunca respondeu.
• Rollbacks colocam um deploy anterior de volta, com os recursos que a aplicação tem agora.

Endereços e domínios

• Endereços gerados usam sslip.io: <serviço>-<projeto>.<ip-do-servidor-com-traços>.sslip.io em produção, com o nome do ambiente antes do projeto nos demais. Funcionam assim que as portas 80 e 443 do servidor estão acessíveis pela internet. O Let's Encrypt emite os certificados por HTTP; até isso acontecer, o endereço responde em HTTP.

• Domínios próprios precisam de um registro DNS no seu provedor:

  • um registro A para o IPv4 do servidor, para um domínio raiz (example.com);
  • um CNAME para o endereço gerado, para qualquer coisa abaixo dele (www.example.com).

  O Orbit confere a cada 30 segundos e passa a rotear o domínio quando o registro aponta para o servidor. Desligue o proxy (a nuvem laranja da Cloudflare) até o certificado sair: o Orbit compara o endereço resolvido com o do servidor, e o Let's Encrypt valida por HTTP.

Variáveis e segredos

As variáveis valem a partir do próximo deploy. Segredos são guardados selados e nunca mais aparecem depois de salvos. Conectar um banco adiciona uma referência como DATABASE_URL, cujo valor o Orbit preenche na hora do deploy.

Logs

A saída de uma aplicação aparece em Logs em poucos segundos. O Orbit guarda as últimas 1.000 linhas de cada serviço. Valores de variáveis secretas e padrões comuns de credenciais viram •••••••• antes de qualquer coisa ser guardada. A saída mais antiga continua no servidor até o Kubernetes descartá-la:

sudo k3s kubectl -n orbit-<projeto>-<ambiente> logs deploy/<serviço>

Recursos

Memória, CPU e instâncias de uma aplicação mudam nas suas Configurações, sempre depois de uma prévia.

• A prévia mostra o que a mudança reserva no servidor frente à capacidade dele. Ela conta 1 GB e 250m de CPU para o runtime e tudo o mais que está no servidor, avisa quando os builds perdem o espaço deles ou quando o novo limite fica abaixo do que a aplicação usou nas últimas 24 horas, e diz que várias instâncias num servidor só não são alta disponibilidade.
• Aplicando: o Orbit troca as instâncias uma por vez. Quando não há espaço para uma segunda instância, ele para a que está rodando antes, e a prévia avisa isso como indisponibilidade. Se as novas instâncias não ficarem prontas, o Orbit volta os valores anteriores.

Falta de memória

Uma aplicação morta por passar do limite de memória duas vezes em 30 minutos ganha um incidente e aparece como degradada. O incidente mostra os reinícios, o gráfico de memória com o limite, o tráfego de entrada e o último deploy, cada um com a sua origem, e separa as causas possíveis dos fatos. Aumentar o limite por ali passa pela prévia de recursos; o Orbit então observa por 10 minutos e resolve o incidente se nenhum reinício acontecer. Sem correção, um incidente se resolve depois de uma hora sem reinícios.

Autoscaling

Escalar automaticamente nas mesmas Configurações faz as instâncias acompanharem a CPU, entre um mínimo e um máximo.

• Instâncias são adicionadas enquanto a CPU média fica acima da fração alvo do limite de CPU, e removidas depois que ela fica abaixo por 5 minutos.
• A prévia reserva memória e CPU para o máximo, então escalar nunca fica sem espaço, e outras mudanças naquele servidor também contam o máximo.
• Deploys e mudanças de recursos mantêm o número de instâncias que o autoscaler escolheu, dentro dos novos limites.
• As métricas do serviço mostram um gráfico de Instâncias, e a linha do tempo lista cada vez que instâncias foram adicionadas ou removidas, com a CPU que levou a isso.
• Limites: até 10 instâncias, alvo entre 20% e 95%, e jobs agendados não escalam. Todas as instâncias rodam no servidor da aplicação, então o autoscaling lida com carga, não com a perda desse servidor.

Sob carga HTTP num cluster de teste, uma aplicação foi de 1 para 3 instâncias em menos de 2 minutos e voltou para 1 em até 10 minutos depois que a carga parou.

Servidores

Uma aplicação roda num servidor só por padrão. Com mais de um servidor, as Configurações dela ganham a seção Servidores, para mudá-la de servidor ou espalhar as instâncias entre vários.

• Espalhando: as instâncias se dividem por igual, uma por servidor quando possível. O autoscaling continua espalhando as que ele adiciona.
• Quando um servidor se perde: as instâncias dele voltam nos outros servidores. Num cluster de teste com três servidores isso levou cerca de um minuto e meio, a maior parte esperando o Kubernetes declarar o servidor perdido. As outras instâncias continuam atendendo enquanto isso.
• A prévia mostra quantas instâncias cada servidor teria no máximo do autoscaling e o que fica livre, e recusa um servidor que não está pronto, que não tem espaço ou que tem outra arquitetura de CPU que a de uma imagem compilada.
• Sobrevivendo a uma perda: a prévia também simula a perda de cada servidor escolhido. Os outros precisam ter espaço para as instâncias que iriam para eles, além de tudo que já está lá, inclusive instâncias de outras aplicações que também mudariam. Se não tiverem, ela diz qual servidor e quanta memória falta, e recusa. Cada servidor passa a guardar esse espaço, então mudanças depois nele (outra aplicação, um banco, um redimensionamento) não conseguem ocupá-lo, e a página de Servidores mostra quanto ele guarda.
• Imagens: uma imagem compilada é copiada para cada servidor escolhido antes de uma instância começar ali. Imagens de um registry são baixadas por cada servidor.
• O que isso não cobre:
  • com uma instância só, a aplicação para até essa instância subir em outro servidor, então use duas ou mais;
  • o tráfego continua entrando pelo servidor principal, então perder o principal deixa a aplicação inacessível mesmo com as instâncias rodando em outros servidores;
  • mover instâncias depende do plano de controle do cluster, que roda só no servidor principal.

Workers e jobs

Adicione um worker ou um job na Visão geral de uma aplicação, em Boas companhias. Ele reaproveita o código e as configurações da aplicação, com nome e comando de início próprios, no mesmo ambiente.

• Um worker não tem endereço. O deploy dele falha se ele reiniciar ou sair nos primeiros 10 segundos.
• Um job roda no seu agendamento em UTC, ou na hora com Rodar agora. Quando uma execução ainda está rodando no próximo horário, esse horário é pulado. O Orbit guarda as últimas cinco execuções com sucesso e as cinco com falha, com saída e código de saída, e o job aparece como degradado enquanto a última execução tiver falhado. Um agendamento novo vale a partir do próximo deploy.

sudo k3s kubectl -n orbit-<projeto>-production get cronjobs,jobs,pods
sudo k3s kubectl -n orbit-<projeto>-production logs job/<execução>

Builds

• Uma aplicação de repositório é compilada no servidor a cada deploy de um commit novo. Publicar de novo o mesmo commit com as mesmas configurações reaproveita a imagem.
• O primeiro build de cada stack baixa as imagens base: conte alguns minutos para Next.js ou Nuxt e menos de um minuto para sites pequenos em Go, Python ou estáticos. Os builds seguintes do mesmo projeto são mais rápidos.
• Os builds rodam no servidor principal, ao lado das suas aplicações. Um build de Next.js ou Nuxt pode usar 1,5 GB de memória por um ou dois minutos, então um servidor de 2 GB não deve fazer build quando está com pouca memória.
• Cada serviço guarda as suas dez imagens mais recentes, e o cache de build se limpa sozinho conforme o disco enche.