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. 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 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 a serem usados como variáveis de ambiente do aplicativo e do build.
services	string[]	Uma lista de nomes de instâncias de serviço a serem vinculados automaticamente ao aplicativo.
disk_quota	quantity	A quantidade de espaço em disco que o aplicativo precisa receber. O padrão é 1 GiB.
memory	quantity	A quantidade de memória RAM para fornecer o aplicativo. O padrão é 1 GiB.
cpu †	quantity	A quantidade de CPU para fornecer o aplicativo. O padrão é 100 m (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 "true", o aplicativo não será roteável.
random-route	boolean	Se definido como "true", o aplicativo receberá uma rota aleatória.
timeout	int	O tempo de espera, em segundos, para o aplicativo ficar em bom estado de integridade.
health-check-type	string	O tipo de verificação de integridade a ser usado 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 inicializa 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.
metadata	object	Tags adicionais para aplicativos e os respectivos recursos.

† 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 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.

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. Você precisa usar um LoadBalancer do Kubernetes para expor uma porta TCP à internet. As portas estão disponíveis no endereço interno do cluster do app <app-name>.<space>.

Campos de metadados

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

Campo	Tipo	Descrição
labels	string -> string map	Identificadores a serem adicionados ao app e aos pods do aplicativo.
annotations	string -> string map	Anotações a serem adicionadas ao app e aos pods do aplicativo.

Observação: os metadados do Kf substituem os metadados personalizados em determinados recursos para garantir que os elementos da plataforma, como roteamento e geração de registros, continuem funcionando.

Exemplos

Aplicativo mínimo

É um manifesto básico que vai 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

É 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
  # Increase default CPU from .1 to .2
  cpu: 200m
  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
  # 2 CPUs
  cpu: 2000m
  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 que o aplicativo está 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ó confirma 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.