Manifesto da app

Os manifestos de apps oferecem aos programadores uma forma de registar o ambiente de execução da respetiva app de forma declarativa. Permitem que as apps sejam implementadas de forma consistente e reproduzível.

Formato

Os manifestos são ficheiros YAML no diretório raiz da app. Têm de ter o nome manifest.yml ou manifest.yaml.

Os manifestos de apps Kf podem ter um único elemento de nível superior: applications. O elemento applications pode conter uma ou mais entradas de aplicações.

Campos da candidatura

Os seguintes campos são válidos para objetos em applications:

Campo Tipo Descrição
name string O nome da aplicação. O nome da app deve ser composto por carateres alfanuméricos em minúsculas e travessões. Não pode começar com um traço.
path string O caminho para a origem da app. O valor predefinido é o diretório do manifesto.
buildpacks string[] Uma lista de buildpacks a aplicar à app.
stack string Imagem base a usar para apps criadas com um buildpack.
docker object Um objeto Docker. Consulte a secção Campos do Docker para mais informações.
env map Pares de chave/valor a usar como variáveis de ambiente para a app e a compilação.
services string[] Uma lista de nomes de instâncias de serviços a associar automaticamente à app.
disk_quota quantity A quantidade de disco que a aplicação deve receber. A predefinição é 1 GiB.
memory quantity A quantidade de RAM a disponibilizar à app. O valor predefinido é 1 GiB.
cpu † quantity A quantidade de CPU a fornecer à aplicação. A predefinição é 0,1 (1/10 de uma CPU).
instances int O número de instâncias da app a executar. A predefinição é 1.
routes object Uma lista de rotas nas quais a app deve ouvir. Consulte a secção Campos de trajeto para mais informações.
no-route boolean Se estiver definida como verdadeira, a aplicação não é encaminhável.
random-route boolean Se estiver definida como verdadeira, a app recebe um trajeto aleatório.
timeout int O número de segundos a aguardar até que a app fique em bom estado.
health-check-type string O tipo de verificação de estado a usar: port, process, none ou http. Predefinição: port
health-check-http-endpoint string O ponto final a segmentar como parte da verificação de funcionamento. Só é válido se health-check-type for http.
command string O comando que inicia a app. Se for fornecido, é transmitido ao ponto de entrada do contentor.
entrypoint † string Substitui o ponto de entrada do contentor de apps.
args † string[] Substitui os argumentos do contentor de apps.
ports † object Uma lista de portas a expor no contentor. Se for fornecida, a primeira entrada nesta lista é usada como a porta predefinida.

† Exclusivo do Kf

Campos do Docker

Os seguintes campos são válidos para objetos application.docker:

Campo Tipo Descrição
image string A imagem do Docker a usar.

Campos de trajeto

Os seguintes campos são válidos para objetos application.routes:

Campo Tipo Descrição
route string Um caminho para a app, incluindo o nome do anfitrião, o domínio e o caminho.
appPort int (Opcional) Uma porta personalizada na app para a qual a rota envia tráfego.

Campos de portas

Os seguintes campos são válidos para objetos application.ports:

Campo Tipo Descrição
port int A porta a expor no contentor da app.
protocol string O protocolo da porta a expor. Tem de ser tcp, http ou http2. Predefinição: tcp

Exemplos

App minimalista

Este é um manifesto básico que cria uma app detetando automaticamente o pacote de compilação com base na origem carregada e implementa uma instância da mesma.

---
applications:
- name: my-minimal-application

App simples

Este é um manifesto completo para uma app Java mais tradicional.

---
applications:
- name: account-manager
  # only upload src/ on push
  path: src
  # use the Java buildpack
  buildpacks:
  - java
  env:
    # manually configure the buildpack's Java version
    BP_JAVA_VERSION: 8
    ENVIRONMENT: PRODUCTION
  # use less disk and memory than default
  disk_quota: 512M
  memory: 512M
  # bump up the CPU
  cpu: 0.2
  instances: 3
  # make the app listen on three routes
  routes:
  - route: accounts.mycompany.com
  - route: accounts.datacenter.mycompany.internal
  - route: mycompany.com/accounts
  # set up a longer timeout and custom endpoint to validate
  # when the app comes up
  timeout: 300
  health-check-type: http
  health-check-http-endpoint: /healthz
  # attach two services by name
  services:
  - customer-database
  - web-cache

App Docker

O Kf pode implementar contentores Docker, bem como apps implementadas por manifesto. Estas apps Docker TÊM de ouvir a variável de ambiente PORT.

---
applications:
- name: white-label-app
  # use a pre-built docker image (must listen on $PORT)
  docker:
    image: gcr.io/my-company/white-label-app:123
  env:
    # add additional environment variables
    ENVIRONMENT: PRODUCTION
  disk_quota: 1G
  memory: 1G
  cpu: 2
  instances: 1
  routes:
  - route: white-label-app.mycompany.com

App com várias portas

Esta app tem várias portas para expor uma consola de administração, um Website e um servidor SMTP.

---
applications:
- name: b2b-server
  ports:
  - port: 8080
    protocol: http
  - port: 9090
    protocol: http
  - port: 2525
    protocol: tcp
  routes:
  - route: b2b-admin.mycompany.com
    appPort: 9090
  - route: b2b.mycompany.com
    # gets the default (first) port

Tipos de verificações de funcionamento

O Kf suporta três tipos de verificações de estado de funcionamento diferentes:

  1. port (predefinição)
  2. http
  3. process (ou none)

port e http defina uma sondagem de prontidão e atividade do Kubernetes que garante que a aplicação está pronta antes de lhe enviar tráfego.

A verificação de funcionamento port garante que a porta encontrada em $PORT está a ser monitorizada. Nos bastidores, o Kf usa uma sonda TCP.

A verificação de funcionamento http vai usar o valor configurado em health-check-http-endpoint para verificar o funcionamento da aplicação. Nos bastidores O Kf usa uma sondagem HTTP.

Uma verificação de estado process verifica apenas se o processo em execução no contentor está ativo. NÃO define uma sondagem de prontidão ou atividade do Kubernetes.

Diferenças conhecidas

Seguem-se as diferenças conhecidas entre os manifestos Kf e os manifestos CF:

  • O Kf não suporta campos de manifesto do CF descontinuados. Isto inclui todos os campos ao nível da raiz do manifesto (exceto aplicações) e campos de encaminhamento.
  • O Kf não suporta os seguintes campos do manifesto v2:
    • docker.username
  • O Kf não suporta a deteção automática de portas para contentores Docker.