Manifest dell'app

I file manifest dell'app consentono agli sviluppatori di registrare l'ambiente di esecuzione della loro app in modo dichiarativo. Consentono un deployment coerente e riproducibile delle app.

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. La il nome dell'app deve essere minuscolo caratteri alfanumerici e trattini bassi. Non deve iniziare con un trattino.
path	string	Il percorso all'origine del dell'app. Per impostazione predefinita è il file manifest .
buildpacks	string[]	Un elenco di buildpack a cui applicare l'app.
stack	string	Immagine di base da utilizzare per le app create con un buildpack.
docker	object	Un oggetto docker. Guarda il Docker Sezione Campi per ulteriori informazioni informazioni.
env	map	Le coppie chiave/valore da utilizzare come le variabili di ambiente un'app e una build.
services	string[]	Un elenco di nomi di istanze di servizio di associarsi automaticamente dell'app.
disk_quota	quantity	La quantità di spazio su disco che deve essere assegnata all'applicazione. Valori predefiniti a 1 GiB.
memory	quantity	La quantità di RAM da fornire all'app. Il valore predefinito è 1 GB.
cpu †	quantity	La quantità di CPU che fornisce un'applicazione. Il valore predefinito è 100 min (1/10 di una CPU).
instances	int	Il numero di istanze dell'app da eseguire. Il valore predefinito è 1.
routes	object	Un elenco di percorsi che l'app deve ascolta. Visualizza i campi del percorso per ulteriori informazioni.
no-route	boolean	Se impostato su true, l'applicazione non sarà instradabile.
random-route	boolean	Se è impostato su true, l'app viene assegnato un percorso casuale.
timeout	int	Il numero di secondi di attesa per mantenere l'integrità dell'app.
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 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 dell'app containerizzato.
ports †	object	Un elenco di porte da esporre containerizzato. 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.

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

Nota: se specifichi un valore appPort, questa porta DEVE essere dichiarata anche nel campo ports.

Campi port

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. Predefinita: tcp

Nota: il campo protocol è un suggerimento sul traffico che passa attraverso la porta. L'indicazione viene utilizzata dal service mesh per migliorare il monitoraggio e le metriche.

Avviso: al momento Kf non supporta il routing basato sulla porta TCP. Devi utilizzare un parametro Kubernetes LoadBalancer se vuoi esporre una porta TCP su internet. Le porte sono disponibili nell'indirizzo dell'app interno del cluster <app-name>.<space>.

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 i pod dell'applicazione sottostanti.
annotations	string -> string map	Annotazioni da aggiungere all'app e i pod dell'applicazione sottostanti.

Nota: i metadati di Kf sostituiscono i metadati personalizzati per determinate risorse per garantire che gli elementi della piattaforma come il routing e la registrazione continuino a funzionare.

Esempi

App minima

Si tratta di un manifest essenziale che consente di creare un'app tramite il rilevamento automatico il buildpack in base all'origine caricata ed eseguire il deployment di un'istanza.

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

App semplice

Si tratta di 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 dei container Docker e dell'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 l'idoneità e l'attività di Kubernetes probe che assicura che l'applicazione sia pronta prima di inviarle 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 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 CF ritirati. Sono inclusi tutti i campi al livello principale del manifest (tranne le applicazioni) e i campi di routing.
• Kf non supporta i seguenti campi manifest v2:
  • docker.username
• Kf non supporta il rilevamento automatico delle porte per i container Docker.