App-Manifest

Mit App-Manifesten können Entwickler die Ausführungsumgebung ihrer Anwendung deklarativ aufzeichnen. Sie ermöglichen die konsistente und reproduzierbare Bereitstellung von Anwendungen.

Format

Manifests sind YAML-Dateien im Stammverzeichnis der Anwendungen. Sie müssen den Namen manifest.yml oder manifest.yaml haben.

Kf-App-Manifeste können ein einzelnes Top-Level-Element haben: applications. Das applications-Element kann einen oder mehrere Anwendungseinträge enthalten.

Anwendungsfelder

Die folgenden Felder sind für Objekte unter applications gültig:

Feld Typ Beschreibung
name string * der Name der Anwendung Der Name der Anwendung darf alphanumerische Zeichen in Kleinbuchstaben und Bindestriche enthalten. Er darf nicht mit einem Bindestrich beginnen.
path string Der Pfad zur Quelle der Anwendung. Standardmäßig wird das Verzeichnis des Manifests verwendet.
buildpacks string[] Eine Liste von Buildpacks, die auf die Anwendung angewendet werden sollen.
stack string Basis-Image zur Verwendung für Anwendungen, die mit einem Buildpack erstellt wurden.
docker object Ein Docker-Objekt. Weitere Informationen finden Sie im Abschnitt "Docker-Felder".
env map Schlüssel/Wert-Paare zur Verwendung als Umgebungsvariablen für die Anwendung und den Build.
services string[] Eine Liste mit Dienstinstanznamen, die automatisch an die Anwendung gebunden werden.
disk_quota quantity Der Speicherplatz, den die Anwendung erhalten soll. Die Standardeinstellung ist 1 GiB.
memory quantity Das RAM-Volumen für die Anwendung. Der Standardwert ist 1 GiB.
cpu quantity Der Umfang der CPU, der die Anwendung bereitstellen soll. Der Standardwert ist 100 m (1/10 CPU).
instances int Die Anzahl der Instanzen, die von der Anwendung ausgeführt werden sollen. Der Standardfaktor ist 1.
routes object Eine Liste mit Routen, die die Anwendung überwachen soll. Weitere Informationen finden Sie im Abschnitt "Routenfelder".
no-route boolean Wenn auf "true" gesetzt, kann die Anwendung nicht geändert werden.
random-route boolean Wenn auf "true" gesetzt, erhält die Anwendung eine zufällige Route.
timeout int Die Anzahl der Sekunden, die gewartet wird, bis die Anwendung fehlerfrei ausgeführt wird.
health-check-type string Der Typ der zu verwendenden Systemdiagnose zur Verwendung von port, process, none oder http. Standardwert: port
health-check-http-endpoint string Der Endpunkt, auf den ausgerichtet werden soll, als Teil der Systemdiagnose. Nur gültig, wenn health-check-type http ist.
command string Der Befehl, der die Anwendung startet. Falls angegeben, wird dies an den Containereinstiegspunkt übergeben.
entrypoint string Überschreibt den Einstiegspunkt des Anwendungscontainers.
args string[] Überschreibt die Argumente, die der Anwendungscontainer verwendet.
ports object Eine Liste der Ports, die im Container verfügbar gemacht werden sollen. Wenn angegeben, wird der erste Eintrag in dieser Liste als Standardport verwendet.
metadata object Zusätzliche Tags für Anwendungen und ihre zugrunde liegenden Ressourcen.

† nur für Kf

Docker-Felder

Die folgenden Felder sind für application.docker-Objekte gültig:

Feld Typ Beschreibung
image string Das zu verwendende Docker-Image.

Routenfelder

Die folgenden Felder sind für application.routes-Objekte gültig:

Feld Typ Beschreibung
route string Eine Route zur Anwendung, einschließlich Hostname, Domain und Pfad.
appPort int Optional: Ein benutzerdefinierter Port in der Anwendung, an den die Route Traffic sendet.

Port-Felder

Die folgenden Felder sind für application.ports-Objekte gültig:

Feld Typ Beschreibung
port int Der Port, der im Container der Anwendung verfügbar gemacht werden soll.
protocol string Das Protokoll des freizugebenden Ports. Es muss tcp, http oder http2 sein. Standardeinstellung: tcp

Metadaten-Felder

Die folgenden Felder sind für application.metadata-Objekte gültig:

Feld Typ Beschreibung
labels string -> string map Labels, die der Anwendung und den zugrunde liegenden Anwendungs-Pods hinzugefügt werden sollen.
annotations string -> string map Annotationen, die der Anwendung und den zugrunde liegenden Anwendungs-Pods hinzugefügt werden sollen.

Beispiele

Minimale Anwendung

Dies ist ein einfaches Manifest zur Erstellung einer Anwendung, indem das Buildpack automatisch anhand der hochgeladenen Quelle erkannt und eine Instanz dieser bereitgestellt wird.

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

Einfache Anwendung

Dies ist ein vollständiges Manifest für eine eher traditionelle Java-Anwendung.

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

Docker-Anwendung

Kf kann sowohl Docker-Container als auch per Manifest bereitgestellte Anwendungen bereitstellen. Diese Docker-Anwendungen MÜSSEN die Umgebungsvariable PORT überwachen.

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

Anwendung mit mehreren Ports

Diese Anwendung verfügt über mehrere Ports, um eine Admin-Konsole, eine Website und einen SMTP-Server verfügbar zu machen.

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

Systemdiagnosetypen

Kf unterstützt drei verschiedene Systemdiagnosetypen:

  1. port (Standard)
  2. http
  3. process (oder none)

port und http legen eine Bereitschafts- und Aktivitätsprüfung von Kubernetes fest, damit die Anwendung bereit ist, bevor Traffic an sie gesendet wird.

Die Systemdiagnose port sorgt dafür, dass der Port von $PORT überwacht wird. Intern verwendet das Kf eine TCP-Prüfung.

Die Systemdiagnose http prüft den konfigurierten Wert der Anwendung mit dem konfigurierten Wert in health-check-http-endpoint. Intern verwendet Kf eine HTTP-Prüfung.

Eine process-Systemdiagnose prüft nur, ob der auf dem Container ausgeführte Prozess aktiv ist. Es wird KEINE Kubernetes-Bereitschafts- oder Aktivitätsprüfungen festgelegt.

Bekannte Unterschiede

Es sind folgende Unterschiede zwischen Kf-Manifesten und CF-Manifesten bekannt:

  • Kf unterstützt keine verworfenen CF-Manifestfelder. Dies schließt alle Felder auf der Stammebene des Manifests (außer Anwendungen) und Routingfelder ein.
  • Die folgenden v2-Manifestfelder werden von Kf nicht unterstützt:
    • docker.username
  • Kf unterstützt die automatische Erkennung von Ports für Docker-Container nicht.