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 de 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 ter carateres alfanuméricos em minúsculas e travessões. Não pode começar com um hífen.
path	string	O caminho para a origem da app. A predefinição é 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 as 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. Predefinição para 1 GiB.
memory	quantity	A quantidade de RAM a fornecer à app. O valor predefinido é 1 GiB.
cpu †	quantity	A quantidade de CPU para fornecer a aplicação. A predefinição é 100 m (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 que a app deve monitorizar. Para mais informações, consulte a secção Campos de trajeto.
no-route	boolean	Se estiver definida como verdadeira, não é possível encaminhar a aplicação.
random-route	boolean	Se estiver definida como verdadeira, é atribuída à app uma rota aleatória.
timeout	int	O número de segundos a aguardar para 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 da app.
ports †	object	Uma lista de portas a expor no contentor. Se for fornecida, a primeira entrada nesta lista é usada como a porta predefinida.
metadata	object	Etiquetas adicionais para aplicações e os respetivos recursos subjacentes.

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

Nota: se especificar um appPort, essa porta TEM de ser declarada também no campo ports.

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

Nota: o campo protocol é uma sugestão sobre o tráfego que passa pela porta. A sugestão é usada pela service mesh para uma melhor monitorização e métricas.

Aviso: atualmente, o Kf não suporta o encaminhamento baseado em portas TCP. Tem de usar um Kubernetes LoadBalancer se quiser expor uma porta TCP à Internet. As portas estão disponíveis no endereço da app interno do cluster <app-name>.<space>.

Campos de metadados

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

Campo	Tipo	Descrição
labels	string -> string map	Etiquetas a adicionar à app e aos Pods da aplicação subjacente.
annotations	string -> string map	Anotações a adicionar à app e aos pods da aplicação subjacente.

Nota: os metadados do Kf substituem os metadados personalizados para determinados recursos para garantir que os elementos da plataforma, como o encaminhamento e o registo, continuam a funcionar.

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