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 0,1 (1/10 CPUs).
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 sie auf "true" gesetzt ist, kann die Anwendung nicht geändert werden.
random-route	boolean	Bei Einstellung auf "true" 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.

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

Hinweis: Wenn Sie einen appPort angeben, MUSS dieser Port auch im Feld ports deklariert werden.

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

Hinweis: Das Feld protocol enthält einen Hinweis zum Traffic über den Port. Der Hinweis wird vom Service Mesh für besseres Tracing und Messwerte verwendet.

Warnung: Kf wird derzeit nicht unterstützt. TCP-Port-Routing. Sie müssen einen Kubernetes-LoadBalancer verwenden, wenn Sie einen TCP-Port für das Internet freigeben möchten. Ports sind über die Cluster-interne Anwendungsadresse <app-name>.<space> verfügbar.

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
  # bump up the CPU
  cpu: 0.2
  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
  cpu: 2
  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.