Deploy de aplicação

Uma aplicação é publicada a partir de uma imagem OCI. A imagem pode vir do build da própria plataforma (veja Builds e supply chain) ou de um registry permitido pela administração da plataforma.

Criar a aplicação

Dentro de um ambiente, use Nova aplicação e informe:

Campo	Regra
Nome e slug	O slug é único no ambiente.
Tipo	Web (padrão), que recebe tráfego HTTP, ou Worker, sem porta. Veja Aplicações worker.
Imagem	Registry, repositório e digest: registry.exemplo/time/api@sha256:<64 caracteres hexadecimais>.
Porta interna	Entre 1024 e 65535. Só para Web.
Instâncias, CPU e memória	Um tamanho predefinido ou valores livres: CPU em milicores e memória em MiB (mínimo 256 MiB), dentro dos limites do plano.
Comando e argumentos	Opcionais.
Health check HTTP	Caminho usado para saber se a instância está saudável. Só para Web.

Por que digest e não tag

A imagem é sempre referenciada pelo digest sha256, que identifica um conteúdo imutável. Tags como latest podem mudar de conteúdo sem aviso e por isso são recusadas. Imagens de registries fora da lista permitida também são recusadas.

Antes de criar o deploy, a plataforma verifica a assinatura e a proveniência da imagem. Uma imagem sem assinatura válida é recusada, e o portal mostra o motivo.

Ciclo de vida do deploy

Cada deploy recebe um número de versão sequencial e passa pelos estados:

Estado	Significado
PENDING	Pedido aceito, aguardando processamento.
RECONCILING	A plataforma está levando o runtime ao estado desejado.
RUNNING	Todas as instâncias estão saudáveis.
FAILED	O runtime recusou o workload, não houve capacidade ou o prazo de 10 minutos expirou. O motivo aparece no portal.
SUPERSEDED	Substituído por um deploy mais novo.
ROLLED_BACK	Substituído por um rollback.

Só um deploy por aplicação fica em andamento por vez. Falhas transitórias são repetidas automaticamente, com intervalo crescente, até 5 tentativas. O portal atualiza o status sem recarregar a página.

Aplicações worker

Consumidores de fila, bots e processadores não atendem HTTP. Crie a aplicação com o tipo Worker:

• não há porta, Service nem rota de entrada; a página da aplicação mostra Sem endpoint público, e uma rota ou domínio apontando para um worker é recusado;
• a saúde vem do próprio processo: o deploy chega a RUNNING quando as instâncias ficam 30 segundos em execução sem reiniciar, e termina FAILED se o processo entra em crash loop;
• opcionalmente, um comando de liveness (lista de argumentos, sem shell, com timeout) reinicia a instância quando falha;
• quota, redimensionamento, logs, variáveis, segredos, sandbox e auditoria funcionam como numa aplicação Web.

Enviar porta ou caminho de health check para um worker, ou criar uma aplicação Web sem porta, responde 400.

Tamanhos e redimensionamento

CPU e memória podem mudar sem recriar a aplicação. No portal, use Recursos na página da aplicação (Developer ou acima) e escolha um tamanho:

Tamanho	vCPU	Memória
nano	0,25	512 MiB
micro	0,5	1 GiB
small	1	2 GiB
medium	2	4 GiB
large	4	8 GiB

Os valores do catálogo podem ser ajustados pela administração da plataforma. O modo avançado aceita CPU e memória livres dentro dos limites do plano e mostra o consumo real no nó: o que você pediu mais o overhead da máquina virtual do sandbox. Esse overhead não entra na sua quota.

O redimensionamento cria um deploy novo (gatilho RESIZE) com a mesma imagem e configuração. A troca é gradual: uma instância extra sobe antes de uma antiga sair, então a URL continua respondendo. Quando o namespace não tem folga nem para essa instância extra, o portal avisa antes de confirmar que haverá uma indisponibilidade breve. Um tamanho que estoura a quota do plano é recusado com o motivo (quota-exceeded, com a quota de vCPU ou de memória). O rollback para uma versão anterior também volta os recursos daquela versão.

Alterar a especificação

Porta, CPU, memória, comando, argumentos e região também mudam no lugar pela API, com PATCH (veja API). Cada mudança efetiva cria um deploy novo (gatilho UPDATE) com o mesmo digest; o id da aplicação não muda e campo ausente fica como está. A validação de plano e de quota é a mesma do redimensionamento.

Trocar a região só é aceito para uma região do catálogo com cluster disponível para o seu plano; a aplicação sobe no cluster de destino e a antiga só sai depois que a nova chega a RUNNING. Sem cluster no destino, a resposta é 422 region.unavailable.

Instâncias e logs

A página da aplicação lista as instâncias com estado (STARTING, HEALTHY, UNHEALTHY, TERMINATED), reinícios e horário de início. Também mostra as últimas linhas de log (até 1000) de uma instância ou de todas, com segredos reconhecidos mascarados.

Em breve

Logs centralizados com retenção, métricas e traces da aplicação ainda não estão disponíveis.

Escalar e reverter

• Escalar: altere o número de instâncias, de 0 até o limite do plano. A plataforma cria um novo deploy com a mesma imagem.
• Rollback: escolha qualquer versão anterior que tenha chegado a RUNNING. A plataforma cria um novo deploy com a imagem e a especificação daquela versão.
• Excluir: remove os workloads do runtime e libera as quotas.

Deploy, escala, redimensionamento (application.resized), alteração, rollback e exclusão ficam registrados na auditoria.

Segurança aplicada a todo workload

Você não configura nada disso; a plataforma aplica a todo workload de cliente:

• Cada instância roda em sandbox de máquina virtual (runtime class definido pelo plano).
• Sem privilégios: contêiner não-root, nenhuma capability, sem escalada de privilégio, seccomp padrão, sem acesso à rede, aos processos ou aos diretórios do nó e sem token automático de service account.
• Cada combinação de organização, projeto e ambiente tem namespace próprio com rede fechada por padrão: entra só o tráfego vindo da borda da plataforma e sai só o DNS. Endereços de metadata de nuvem e redes de gestão ficam bloqueados.
• A aplicação nunca é exposta diretamente por LoadBalancer ou NodePort; o acesso público passa pelo gateway e pelo WAF.
• Requests e limits de CPU e memória iguais aos da especificação, com quota por namespace derivada do plano.

Quotas

Criar, alterar e escalar aplicações respeita as quotas de aplicações, instâncias, vCPU e memória do plano, somando todas as aplicações ativas da organização. Ao exceder, a operação é recusada com uma mensagem clara. Veja Planos, recursos e limites.

Marketplace

Também é possível instalar um aplicativo do Marketplace em um ambiente. A instalação pede consentimento para as permissões declaradas, cria uma aplicação e um deploy fixados no digest da versão aprovada e não recebe atualizações sem ação sua. Só versões publicadas, assinadas e compatíveis com o seu plano aparecem no catálogo.

API

As rotas ficam sob /api/v1/orgs/{orgId}/projects/{projectId}/environments/{envId}/applications.

Método e rota	O que faz
POST /	Cria a aplicação (type web ou worker, size ou cpuMillis/memoryMiB, livenessCommand e livenessTimeoutSeconds para worker)
GET /{appId}	Aplicação e deploys, com ETag: W/"<versão>"
PATCH /{appId}	Altera porta, CPU, memória, comando, argumentos e região (application/merge-patch+json, If-Match obrigatório)
GET /{appId}/resources	Tamanhos disponíveis, limites do plano, uso da quota e consumo real no nó
PUT /{appId}/resources	Redimensiona com { "size": "micro" } ou { "cpuMillis": 500, "memoryMiB": 1024 } (If-Match obrigatório)
POST /{appId}/deployments	Novo deploy, opcionalmente com outra imagem
POST /{appId}/scale	Muda o número de instâncias
POST /{appId}/deployments/{deploymentId}/rollback	Volta para um deploy que chegou a RUNNING
DELETE /{appId}	Exclui a aplicação

Exemplo de PATCH, que só muda a memória:

curl -X PATCH "$ATLAS_API/api/v1/orgs/$ORG/projects/$PROJ/environments/$ENV/applications/$APP" \
  -H "Authorization: Bearer $CODA_TOKEN" \
  -H 'Content-Type: application/merge-patch+json' \
  -H 'If-Match: W/"7"' \
  -d '{"memoryMiB": 1024}'

No merge patch, null em command ou args limpa a lista. A resposta 200 traz a aplicação com a versão nova e o deploy criado em latest, e o cabeçalho ETag com a versão nova.

Concorrência otimista (ETag e If-Match)

O GET de projeto, ambiente, aplicação, rota, domínio próprio e variáveis devolve ETag: W/"<versão>"; a versão sobe a cada alteração. Mande esse valor em If-Match para alterar sem sobrescrever a mudança de outra pessoa:

Situação	Resposta
PATCH da aplicação ou PUT .../resources sem If-Match	428 precondition.required
If-Match com uma versão antiga	412 precondition.failed; nada muda. Leia o recurso de novo e repita
PUT, PATCH ou DELETE existentes sem If-Match	Aceitos como antes, para não quebrar clientes atuais

O portal, o SDK e o provider OpenTofu já enviam o If-Match. No portal, um 412 mostra Alterado por outra pessoa com a opção de recarregar; no provider, o apply pede tofu refresh.