Deploy serverless

Apps que escalam sozinhas — do marketplace ao runtime.

No Deploy, os programadores correm os seus próprios apps na eQuantic Cloud como serviços serverless que escalam automaticamente, inclusive a zero quando estão inativos.

Criar um serviço#

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

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

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, intervalo de instâncias e CPU/memória editáveis a qualquer altura — redimensionar um serviço a correr fá-lo avançar num 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 as predefinições da imagem não forem as suas.
• Console interativo (drawer), registos de runtime ao vivo, variáveis e domínios (TLS automático).
• www em qualquer domínio próprio — um botão por domínio, que redirecciona www.exemplo.com para exemplo.com com 301 (o predefinido, e o que os motores de busca querem: dois hosts a servir conteúdo idêntico são dois URLs canónicos para a mesma página) ou serve os dois. Apontar um CNAME de www para cá não chega: o DNS resolve o nome, e quem responde — e para que host sai o certificado — decide-se depois, a partir do pedido. O domínio tem de reclamar o www para a plataforma o encaminhar e emitir TLS para ele.
• O endereço do próprio serviço — no separador Domínios, escolha o nome em que o serviço responde sob o domínio da plataforma: cura-accounts.apps.equantic.space em vez do gerado cura-accounts-e49f09.apps.equantic.space. O endereço gerado continua a funcionar, com um 301 para o escolhido que mantém o caminho e a query, pelo que uma ligação já partilhada não se perde. Um nome é de quem o pede primeiro em toda a plataforma, e um nome abandonado fica livre para qualquer um de imediato. Cada endereço do separador tem um botão para o copiar.
• Configuração avançada (EXPERT) — overrides de recursos/probes e inspeção do manifesto gerado.

As definições avançadas do assistente trazem os mesmos botões logo na criação — os recursos e o intervalo de instâncias escolhidos aí são aquilo com que o primeiro deployment corre.

Os Pull Requests abertos também podem ter ambientes de preview efémeros, que arrancam como serviços normais e são destruídos automaticamente no merge/fecho — consulte Repositórios & CI/CD.

De onde veio a versão#

O separador Visão geral do serviço diz que versão está a correr e, quando a imagem é nossa, de onde veio: a execução de pipeline que a publicou, o commit por trás dessa execução e o repositório. O ecrã da execução responde ao mesmo pela outra ponta, com uma faixa Implantada em a nomear cada ambiente onde as suas imagens estão a correr.

A ligação é registada, nunca adivinhada. Um job que publica com o token que a plataforma já injecta fica atribuído a essa 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 o ecrã di-lo em vez de mostrar um painel vazio.

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

A string de ligação de um serviço nomeia-o por inteiro — postgres.p-1a2b3c-production.svc.cluster.local — e não apenas postgres. O nome curto resolve só dentro do Space a que pertence, e um Space é um namespace do Kubernetes: uma app noutro Space que recebeu o nome curto funcionava até algo a reiniciar, e depois já não resolvia a própria base de dados.

Copie a ligação pelo painel Ligar do serviço (ou eqs db url <serviço>) e funciona de qualquer ponto do workspace.