Manifesto do app

Os manifestos do app servem para que os desenvolvedores registrem o ambiente de execução do aplicativo de maneira declarativa. Eles permitem que os aplicativos sejam implantados de forma consistente e reproduzível.

Formato

Os manifestos são arquivos YAML no diretório raiz do aplicativo. Eles precisam ser chamados de manifest.yml ou manifest.yaml.

Os manifestos do app do Kf têm um único elemento de nível superior: applications. O elemento applications contém uma ou mais entradas de aplicativo.

Campos do aplicativo

Os campos a seguir são válidos para objetos applications:

Campo Tipo Descrição
name string O nome do aplicativo. O nome do aplicativo precisa conter caracteres alfanuméricos minúsculos e traços. Não é possível começar com um traço.
path string O caminho para a origem do aplicativo. O padrão é o diretório do manifesto.
buildpacks string[] Uma lista de pacotes de versão para aplicar ao aplicativo.
stack string Imagem base a ser usada para aplicativos criados com um pacote de versão.
docker object Um objeto Docker. Consulte a seção Campos do Docker para mais informações.
env map Os pares de chave-valor a serem usados como variáveis de ambiente do aplicativo e da versão.
services string[] Uma lista de nomes de instâncias de serviço para vincular automaticamente ao aplicativo.
disk_quota quantity A quantidade de disco que o aplicativo precisa receber. O padrão é 1GiB.
memory quantity A quantidade de RAM para fornecer o aplicativo. O padrão é 1 GiB.
cpu † quantity A quantidade de CPU para fornecer o aplicativo. O padrão é 0,1 (1/10 de CPU).
instances int O número de instâncias do aplicativo a serem executadas. O padrão é 1.
routes object Uma lista de rotas que o aplicativo precisa detectar. Consulte a seção Campos de rota para saber mais.
no-route boolean Se definido como verdadeiro, o aplicativo não será roteável.
random-route boolean Se definido como verdadeiro, o aplicativo receberá uma rota aleatória.
timeout int O número de segundos para aguardar a integridade do aplicativo.
health-check-type string O tipo de verificação de integridade a usar port, process, none ou http. Padrão: port
health-check-http-endpoint string O endpoint a ser segmentado como parte da verificação de integridade. Válido apenas se health-check-type for http.
command string O comando que inicia o aplicativo. Se fornecido, será passado para o ponto de entrada do contêiner.
entrypoint † string Substitui o ponto de entrada do contêiner do aplicativo.
args † string[] Substitui os argumentos do contêiner do aplicativo.
ports † object Uma lista de portas a serem expostas no contêiner. Se fornecida, a primeira entrada nesta lista será usada como a porta padrão.

† Exclusivo para Kf

Campos do Docker

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

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

Campos de rota

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

Campo Tipo Descrição
route string Uma rota para o aplicativo, incluindo nome do host, domínio e caminho.
appPort int (Opcional) Uma porta personalizada no aplicativo para onde a rota enviará tráfego.

Campos de porta

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

Campo Tipo Descrição
port int A porta a ser exposta no contêiner do aplicativo.
protocol string O protocolo da porta a ser exposta. Precisa ser tcp, http ou http2. Padrão: tcp

Exemplos

Aplicativo mínimo

Esse é um manifesto básico que criará um aplicativo detectando automaticamente o pacote de versão com base na fonte enviada e implantará uma instância dele.

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

Aplicativo simples

Este é um manifesto completo para um aplicativo 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

Aplicativo Docker

O Kf implanta contêineres do Docker, bem como o aplicativo implantado pelo manifesto. Esses aplicativos do Docker PRECISAM detectar 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

Aplicativo com várias portas

Este aplicativo tem várias portas para expor um Admin Console, um site 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ção de integridade

O Kf é compatível com três tipos diferentes de verificação de integridade:

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

port e http definem uma sondagem de prontidão e atividade do Kubernetes que garante ao aplicativo estar pronto antes de enviar tráfego para ele.

A verificação de integridade port garante que a porta encontrada em $PORT seja detectada. Em segundo plano, o Kf usa uma sondagem TCP.

A verificação de integridade http usará o valor configurado em health-check-http-endpoint para verificar a integridade do aplicativo. Em segundo plano, o Kf usa uma sondagem HTTP.

Uma verificação de integridade process só verifica se o processo em execução no contêiner está ativo. Ela NÃO define uma sondagem de prontidão ou ativação do Kubernetes.

Diferenças conhecidas

Veja a seguir as diferenças conhecidas entre os manifestos Kf e FC:

  • O Kf não é compatível com campos de manifesto de CF obsoletos. Isso inclui todos os campos no nível raiz do manifesto (exceto aplicativos) e campos de roteamento.
  • O Kf não é compatível com os seguintes campos de manifesto v2:
    • docker.username
  • O Kf não é compatível com a detecção automática de portas para contêineres do Docker.