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 é 1 GiB.
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 é 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 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.
metadata	object	Tags adicionais para aplicativos e os respectivos recursos subjacentes.

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

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

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: o Kf não é compatível no momento 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 aplicativo <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 subjacentes do aplicativo.
annotations	string -> string map	Anotações a serem adicionadas ao app e aos pods subjacentes 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

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
  # 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

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
  # 2 CPUs
  cpu: 2000m
  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.