Implantação

A Zenifra publica aplicações HTTP a partir de repositórios Git ou de uma imagem OCI. Com Git, use GitHub ou uma conexão Forgejo. A origem define como a aplicação é construída, atualizada e versionada.

Escolha o método correto

Método	Descrição	Atualização
Repositório Git	A Zenifra usa a conexão, repositório, branch, runtime e comandos definidos no projeto	Manual, automática por branch, por tag ou por release (quatro modos exclusivos, em GitHub e Forgejo)
Imagem OCI	A Zenifra executa uma imagem Docker/OCI já pronta	Manual pela troca da imagem no console, na CLI, na API ou pela GitHub Action

Use um repositório Git quando o time quer publicar diretamente do código-fonte. Escolha GitHub ou Forgejo conforme a conexão disponível. Nos dois provedores, selecione Manual, Automático por branch, Por Tag ou Por Release; use apenas um modo por vez. Consulte as formas de atualização do GitHub e do Forgejo.

Use imagem OCI quando a imagem já é gerada por uma CI externa, quando você precisa promover tags imutáveis ou quando quer controlar o artefato fora da Zenifra.

Fluxo de publicação

Vídeo: publicação de uma aplicação HTTP a partir de uma imagem OCI.

Git: selecione a conexão, o repositório e a branch.
OCI: informe a imagem pública ou privada.
Porta: configure a porta em que a aplicação escuta.
Variáveis: cadastre segredos e configurações.
Online: valide a aplicação na URL pública.

Como uma nova versão entra no ar

Em cada publicação, seja um novo build, a troca da imagem OCI ou uma alteração que reinicia as instâncias, a Zenifra troca as instâncias sem interromper o tráfego:

uma nova instância inicia com a nova versão, enquanto a anterior continua atendendo
as requisições passam a chegar à nova instância; se ela ainda não aceitar conexões na porta do projeto, a requisição é atendida pela instância anterior
a instância anterior continua no ar por 30 segundos depois que a nova inicia e então recebe o sinal SIGTERM

Para aproveitar essa troca:

faça a aplicação escutar na porta do projeto assim que estiver pronta para atender; se ela levar mais de 30 segundos para iniciar, parte das requisições pode falhar durante a troca
trate o SIGTERM para terminar as requisições em andamento antes de encerrar
aplicações que não atendem HTTP, como consumidores de fila, também são atualizadas normalmente: a troca nunca espera a porta responder

Com mais de uma instância, elas são substituídas uma de cada vez.

O que validar depois do deploy

a aplicação responde na URL pública
logs de build não mostram erro
logs da aplicação aparecem no console (disponíveis em todos os planos)
CPU, RAM, storage e requisições HTTP aparecem conforme o plano
domínio próprio aponta para o destino correto, quando configurado
a origem Git só atualiza automaticamente de acordo com a forma escolhida: push na branch, tag criada ou release publicada

Em projetos Git, os logs de build ficam na seção Logs de build da página do projeto. Eles são diferentes dos logs da aplicação em execução.

Health checks

Para validar continuamente uma aplicação HTTP e reiniciar automaticamente uma instância quando uma falha for confirmada, configure Health checks para projetos HTTP. O recurso está disponível a partir do plano Premium, verifica uma rota GET a cada 1 minuto, espera uma resposta 2xx e mantém o histórico de falhas por 30 dias.