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 apps sejam implantados de forma consistente e reproduzível.

Formato

Os manifestos são arquivos YAML no diretório raiz do app. 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. Precisa conter caracteres alfanuméricos minúsculos e traços. Não é permitido começar com um traço.
path	string	O caminho da origem do app. O padrão é o diretório do manifesto.
buildpacks	string[]	Uma lista de buildpacks para usar no aplicativo.
stack	string	Imagem base que será usada em apps criados com um buildpack.
docker	object	Um objeto Docker. Consulte a seção "Campos do Docker" para mais informações.
env	map	Os pares de chave-valor que serão usados como variáveis de ambiente do app e da versão.
services	string[]	Uma lista com os nomes das 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 é 1 GiB.
memory	quantity	A quantidade de RAM que será fornecida para o app. O padrão é 1 GiB.
cpu †	quantity	A quantidade de CPU que será fornecida para o aplicativo. O padrão é 0,1 (1/10 de CPU).
instances	int	O número de instâncias do app que serão executadas. O padrão é 1.
routes	object	Uma lista de rotas que o app 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 app vai 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 pretendido como parte da verificação de integridade. Válido apenas se health-check-type for http.
command	string	O comando que inicia o app. Se fornecido, será transmitido ao ponto de entrada do contêiner.
entrypoint †	string	Substitui o ponto de entrada do contêiner do app.
args †	string[]	Substitui os argumentos do contêiner do aplicativo.
ports †	object	Uma lista de portas que serão visíveis 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 que 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 app, incluindo nome do host, domínio e caminho.
appPort	int	(Opcional) Uma porta personalizada no aplicativo para onde a rota enviará tráfego.

Observação: se você especificar um appPort, essa porta também precisará ser declarada no campo ports.

Campos de porta

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

Campo	Tipo	Descrição
port	int	A porta que será visível no contêiner do app.
protocol	string	O protocolo da porta que será visível. Precisa ser tcp, http ou http2. Padrão: tcp

Observação: o campo protocol é uma dica sobre o tráfego que passa pela porta. A dica é usada pela malha de serviço para melhorar o rastreamento e as métricas.

Aviso: no momento, o Kf não é compatível com roteamento baseado em porta TCP. Use um LoadBalancer do Kubernetes se quiser expor uma porta TCP à internet. As portas estão disponíveis no endereço interno do cluster do app <app-name>.<space>.

Exemplos

App mínimo

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

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

App 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

App do Docker

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

App 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 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 atividade do Kubernetes.

Diferenças conhecidas

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

• O Kf não é compatível com campos de manifesto de CF descontinuados. 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.