Deploy serverless

Apps que escalam sozinhas — do marketplace ao runtime.

No Deploy, desenvolvedores rodam seus próprios apps na eQuantic Cloud como serviços serverless que escalam automaticamente, inclusive a zero quando ociosos.

Criar um serviço#

O assistente é um marketplace por categoria. A categoria Custom (padrão) cobre quatro origens:

As demais categorias trazem ~40 serviços open-source prontos (Postgres, Redis, RabbitMQ, MinIO, Grafana, n8n, Metabase, Keycloak, WordPress…), cada um com formulário de instalação próprio.

Operar o serviço#

• Visão geral com gráficos de CPU/memória e origem/build.
• Deployments com stream de build ao vivo e rollback.
• Escala & recursos — gatilhos de escala (KEDA), scale-to-zero, faixa de instâncias e CPU/memória editáveis a qualquer momento — redimensionar um serviço no ar faz um rolling com a nova fatia, sem recriar nada.
• Health check — aponte a plataforma para o endpoint de probe do seu próprio app, e faça override do command/args do container quando os padrões da imagem não forem os seus.
• Console interativo (drawer), logs runtime ao vivo, variáveis e domínios (TLS automático).
• www em qualquer domínio custom — um botão por domínio, que redireciona www.exemplo.com para exemplo.com com 301 (o padrão, e o que buscador quer: dois hosts servindo conteúdo idêntico são duas URLs canônicas para a mesma página) ou serve os dois. Apontar um CNAME de www para cá não basta: o DNS resolve o nome, e quem responde — e para qual host sai o certificado — se decide depois, a partir da requisição. Então o domínio precisa reivindicar o www para a plataforma rotear e emitir TLS para ele.
• O endereço do próprio serviço — na aba Domínios, escolha o nome em que o serviço atende sob o domínio da plataforma: cura-accounts.apps.equantic.space no lugar do gerado cura-accounts-e49f09.apps.equantic.space. O endereço gerado continua funcionando, com um 301 para o escolhido que mantém o caminho e a query, então um link já compartilhado não quebra. Um nome é de quem chega primeiro em toda a plataforma, e um nome largado fica livre para qualquer um na hora. Todo endereço da aba tem um botão de copiar.
• Configuração avançada (EXPERT) — overrides de recursos/probes e inspeção do manifesto gerado.

As configurações avançadas do assistente trazem os mesmos botões já na criação — os recursos e a faixa de instâncias escolhidos ali são o que o primeiro deployment usa.

Pull Requests abertos também podem ganhar ambientes de preview efêmeros, que sobem como serviços normais e são destruídos automaticamente no merge/fechamento — veja Repositórios & CI/CD.

De onde veio a versão#

A aba Visão geral do serviço diz qual versão está rodando e, quando a imagem é nossa, de onde ela veio: a execução de pipeline que a publicou, o commit por trás daquela execução e o repositório. A tela da execução responde o mesmo pela outra ponta, com uma faixa Implantada em nomeando cada ambiente onde as imagens dela estão rodando.

A ligação é registrada, nunca adivinhada. Um job que publica com o token que a plataforma já injeta fica atribuído àquela execução:

- run: docker login registry.equantic.space -u eqs -p $EQS_TOKEN
- run: docker push registry.equantic.space/acme/api:${{ github.sha }}

Uma imagem puxada de um registry que não é nosso não tem proveniência, e a tela diz isso em vez de mostrar um painel vazio.

Alcançar um serviço a partir de outro#

A string de conexão de um serviço nomeia ele por inteiro — postgres.p-1a2b3c-production.svc.cluster.local — e não só postgres. O nome curto resolve apenas dentro do Space a que ele pertence, e um Space é um namespace do Kubernetes: uma app em outro Space que recebeu o nome curto funcionava até algo reiniciá-la, e aí não resolvia mais o próprio banco.

Copie a conexão pelo painel Conectar do serviço (ou eqs db url <serviço>) e ela funciona de qualquer lugar do workspace.