Deploy

Roda no cluster k3s (repositório k3s-platform), sem infraestrutura própria. O docker-compose.prod.yaml e o Makefile que existem dentro do repositório license-manager são resquício de um modelo anterior de deploy em servidor único — não é o que está em produção hoje.

Como o build funciona

O build não roda em CI do repositório license-manager. O k3s-platform clona o repositório, injeta o Dockerfile/entrypoint.sh/Caddyfile que ele mesmo mantém (runtime/laravel/) e builda dentro do próprio cluster, usando buildkitd nativo em cada arquitetura (amd64 e arm64) — sem emulação QEMU. O resultado é publicado como manifest multi-arch em ghcr.io/finattogroup/license-manager.

O CI do repositório license-manager (GitHub Actions) roda só lint (Pint, Rector, PHPCS) e testes (Pest contra Postgres) — não builda nem publica imagem. Esse CI é o gate de qualidade: o app-build.sh do k3s-platform consulta os checks do commit via gh antes de buildar e recusa buildar um commit com CI vermelho, a menos que rode com SKIP_CI_CHECK=1.

Deploy

No repositório k3s-platform:

make app-release APP=license-manager REF=<commit-sha>

Isso builda a imagem a partir do commit informado, publica ghcr.io/finattogroup/license-manager:<sha> e :sha-<short>, e escreve source.ref e image.tag de volta em apps/license-manager.yaml. O comando não sobe nada sozinho — o passo final é commitar e dar push:

git commit -am "release(license-manager): <sha>" && git push

O ArgoCD detecta a mudança em apps/license-manager.yaml e sincroniza todos os clientes que apontam para platform.app: license-manager — hoje só existe uma instância, clients/license-manager.yaml.

Onde roda

• Cluster k3s, namespace license-manager (nome do arquivo em clients/license-manager.yaml)
• Domínio próprio license-manager.memphislab.com.br — fora do wildcard *.frota.memphislab.com.br, porque não é uma aplicação multi-cliente
• Servido por FrankenPHP em modo clássico (o projeto não usa Laravel Octane), porta 8080, healthcheck em /up
• Fila e agendador (workers, scheduler) desligados no chart: no commit buildado (5cc1381) o projeto não implementa nenhum job ShouldQueue nem tarefa agendada — ligar esses containers deixaria processos ociosos

Variáveis de ambiente

Além do conjunto padrão que o chart do k3s-platform já cobre para qualquer aplicação Laravel (banco, Redis, storage S3, APP_KEY), este serviço declara três chaves próprias em extraSecretKeys (seladas vazias — são contratos com sistemas fora do cluster, ainda não configurados):

• LM_RELEASE_TOKEN — autenticação de quem pode registrar um release
• LM_AGENT_TRIGGER_TOKEN — autenticação para acionar algum agente externo
• NIGHTWATCH_TOKEN — token do Laravel Nightwatch (observability); com NIGHTWATCH_ENABLED=false fixado em extraEnv, não reporta nada até ser preenchido

O bucket S3 dedicado a este serviço é license-manager (clients/license-manager.yaml).

Migrations e primeiro acesso

O job de migrate roda php artisan migrate --force seguido de access:sync-permissions --no-interaction a cada deploy. Nenhum seeder roda em produção — decisão deliberada: AdminUserSeeder criaria o usuário admin@finatto.com.br com senha password num host acessível pela internet. O primeiro administrador precisa ser criado à mão depois do primeiro deploy (make client-shell CLIENT=license-manager, depois php artisan tinker ou um comando equivalente para criar o AdminUser).

Rollback

Reverter o commit que alterou source.ref/image.tag em apps/license-manager.yaml e dar push. O ArgoCD com selfHeal reaplica a versão anterior sozinho. Não existe um comando de rollback dedicado — é o mesmo fluxo de release, apontando para trás.

Diagnóstico

make client-status CLIENT=license-manager   # pods, HPA, PVCs, ingress, Postgres
make client-logs   CLIENT=license-manager
make client-shell  CLIENT=license-manager

Se o painel carregar sem CSS/JS (mixed content), não é um problema deste serviço: é a plataforma que trata a detecção de HTTPS via X-Forwarded-Proto no Caddyfile — já corrigido a nível de plataforma para aplicações em modo clássico do FrankenPHP.