Manifest dell'app

I manifest delle app consentono agli sviluppatori di registrare l'ambiente di esecuzione della propria app in modo dichiarativo. Consentono di eseguire il deployment delle app in modo coerente e riproducibile.

Formato

I manifest sono file YAML nella directory principale dell'app. Devono essere denominati manifest.yml o manifest.yaml.

I manifest delle app Kf possono avere un solo elemento di primo livello: applications. L'elemento applications può contenere una o più voci di applicazione.

Campi di applicazione

I seguenti campi sono validi per gli oggetti in applications:

Campo Tipo Descrizione
name string Il nome dell'applicazione. Il nome dell'app deve essere composto da lettere minuscole, caratteri alfanumerici e trattini. Non deve iniziare con un trattino.
path string Il percorso della fonte dell'app. Il valore predefinito è la directory del manifest.
buildpacks string[] Un elenco di buildpack da applicare all'app.
stack string Immagine di base da utilizzare per le app create con un buildpack.
docker object Un oggetto Docker. Per ulteriori informazioni, consulta la sezione Docker Fields.
env map Coppie chiave/valore da utilizzare come variabili di ambiente per l'app e la compilazione.
services string[] Un elenco di nomi di istanze di servizio da associare automaticamente all'app.
disk_quota quantity La quantità di spazio su disco che deve essere assegnata all'applicazione. Il valore predefinito è 1 GiB.
memory quantity La quantità di RAM da fornire all'app. Il valore predefinito è 1 GB.
cpu quantity La quantità di CPU da fornire all'applicazione. Il valore predefinito è 100 m (1/10 di una CPU).
instances int Il numero di istanze dell'app da eseguire. Il valore predefinito è 1.
routes object Un elenco di route su cui l'app deve ascoltare. Per saperne di più, consulta la sezione Campi route.
no-route boolean Se impostato su true, l'applicazione non sarà instradabile.
random-route boolean Se impostato su true, all'app verrà assegnato un percorso casuale.
timeout int Il numero di secondi di attesa perché l'app diventi stabile.
health-check-type string Il tipo di controllo di integrità da utilizzare:port, process, none ohttp. Valore predefinito: port
health-check-http-endpoint string L'endpoint da scegliere come target nell'ambito del controllo di integrità. Valido solo se health-check-type è http.
command string Il comando che avvia l'app. Se specificato, verrà passato all'entry point del container.
entrypoint string Esegue l'override dell'entrypoint del container dell'app.
args string[] Sostituisce gli argomenti del container dell'app.
ports object Un elenco di porte da esporre sul contenutore. Se specificato, viene utilizzata la prima voce di questo elenco come porta predefinita.
metadata object Tag aggiuntivi per le applicazioni e le relative risorse sottostanti.

† Unica per Kf

Campi Docker

I seguenti campi sono validi per gli oggetti application.docker:

Campo Tipo Descrizione
image string L'immagine Docker da utilizzare.

Campi Route

I seguenti campi sono validi per gli oggetti application.routes:

Campo Tipo Descrizione
route string Un percorso per l'app che include nome host, dominio e percorso.
appPort int (Facoltativo) Una porta personalizzata nell'app a cui il percorso invierà il traffico.

Campi porta

I seguenti campi sono validi per gli oggetti application.ports:

Campo Tipo Descrizione
port int La porta da esporre nel contenitore dell'app.
protocol string Il protocollo della porta da esporre. Deve essere tcp, http o http2. Valore predefinito: tcp

Campi dei metadati

I seguenti campi sono validi per gli oggetti application.metadata:

Campo Tipo Descrizione
labels string -> string map Etichette da aggiungere all'app e ai pod dell'applicazione sottostante.
annotations string -> string map Annotazioni da aggiungere all'app e ai pod dell'applicazione sottostante.

Esempi

App minima

Si tratta di un manifest di base che creerà un'app rilevando automaticamente il buildpack in base al codice sorgente caricato e ne eseguirà il deployment di un'istanza.

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

App semplice

Questo è un manifest completo per un'app Java più tradizionale.

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

Kf può eseguire il deployment di container Docker e di app di cui è stato eseguito il deployment del manifest. Queste app Docker DEVONO ascoltare la variabile di 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 con più porte

Questa app ha più porte per esporre una console di amministrazione, un sito web e un server 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

Tipi di controllo di integrità

Kf supporta tre diversi tipi di controllo di integrità:

  1. port (valore predefinito)
  2. http
  3. process (o none)

port e http hanno impostato un probe di attività e idoneità Kubernetes che garantisce che l'applicazione sia pronta prima di inviare il traffico.

Il controllo di integrità port garantisce che la porta trovata all'indirizzo $PORT sia in ascolto. Dietro le quinte, Kf utilizza un probe TCP.

Il controllo di integrità http utilizzerà il valore configurato in health-check-http-endpoint per controllare l'integrità dell'applicazione. Al suo interno, Kf utilizza un probe HTTP.

Un controllo di integrità process verifica solo se il processo in esecuzione sul container è attivo. NON imposta un probe di idoneità o di attività Kubernetes.

Differenze note

Di seguito sono riportate le differenze note tra i manifest Kf e i manifest CF:

  • Kf non supporta i campi manifest di CF ritirati. Sono inclusi tutti i campi a livello di radice del manifest (diversi dalle applicazioni) e i campi di routing.
  • In Kf non è supportato i seguenti campi manifest v2:
    • docker.username
  • Kf non supporta il rilevamento automatico delle porte per i container Docker.