Fichier manifeste d'application

Les fichiers manifestes d'applications permettent aux développeurs d'enregistrer l'environnement d'exécution de leur application de manière déclarative. Ils permettent de déployer des applications de manière cohérente et reproductible.

Format

Les fichiers manifestes sont des fichiers YAML situés dans le répertoire racine de l'application. Ils doivent être nommés manifest.yml ou manifest.yaml.

Les fichiers manifestes des applications Kf ne sont autorisés à contenir qu'un seul élément de premier niveau : applications. L'élément applications peut contenir une ou plusieurs entrées d'application.

Champs d'application

Les champs suivants sont valides pour les objets situés sous applications :

Champ	Type	Description
name	string	Nom de l'application. Le nom de l'application doit contenir des caractères alphanumériques en minuscule et des tirets. Il ne doit pas commencer par un tiret.
path	string	Chemin d'accès à la source de l'application. Défini par défaut sur le répertoire du fichier manifeste.
buildpacks	string[]	Liste des packs de création à appliquer à l'application.
stack	string	Image de base à utiliser pour les applications créées avec un pack de création.
docker	object	Objet Docker. Pour en savoir plus, consultez la section "Champs Docker".
env	map	Paires clé/valeur à utiliser comme variables d'environnement pour l'application et la compilation.
services	string[]	Liste des noms d'instances de service à lier automatiquement à l'application.
disk_quota	quantity	Espace disque que l'application doit obtenir. La valeur par défaut est 1 Gio.
memory	quantity	Quantité de mémoire RAM à fournir à l'application. La valeur par défaut est 1 Gio.
cpu †	quantity	Quantité de ressources processeur à fournir à l'application. La valeur par défaut est de 100 m (1/10e du processeur).
instances	int	Nombre d'instances de l'application à exécuter. La valeur par défaut est 1.
routes	object	Liste des routes sur lesquelles l'application doit écouter. Pour en savoir plus, consultez la section "Champs de routage".
no-route	boolean	Si ce champ est défini sur "true", l'application ne peut pas être routée.
random-route	boolean	Si ce champ est défini sur "true", une route aléatoire est attribuée à l'application.
timeout	int	Nombre de secondes d'attente pour que l'application soit opérationnelle.
health-check-type	string	Type de vérification d'état à utiliser : port, process, none ou http. Valeur par défaut : port
health-check-http-endpoint	string	Point de terminaison à cibler lors de la vérification d'état. Valide uniquement si health-check-type est défini sur http.
command	string	Commande qui lance l'application. Si elle est spécifiée, l'application est transférée au point d'entrée du conteneur.
entrypoint †	string	Remplace le point d'entrée du conteneur de l'application.
args †	string[]	Remplace les arguments du conteneur de l'application.
ports †	object	Liste des ports à exposer sur le conteneur. Si cette commande est spécifiée, la première entrée de cette liste est utilisée comme port par défaut.
metadata	object	Tags supplémentaires pour les applications et leurs ressources sous-jacentes.

† unique à Kf

Champs Docker

Les champs suivants sont valides pour les objets application.docker :

Champ	Type	Description
image	string	Image Docker à utiliser.

Champs de routage

Les champs suivants sont valides pour les objets application.routes :

Champ	Type	Description
route	string	Route vers l'application comprenant le nom d'hôte, le domaine et le chemin d'accès.
appPort	int	(Facultatif) Port personnalisé de l'application vers lequel la route envoie le trafic.

Remarque : Si vous spécifiez un port appPort, il DOIT également être déclaré dans le champ ports.

Champs de port

Les champs suivants sont valides pour les objets application.ports :

Champ	Type	Description
port	int	Port auquel le conteneur de l'application doit avoir accès.
protocol	string	Protocole du port à exposer. La valeur doit être tcp, http ou http2. Par défaut, tcp.

Remarque : Le champ protocol indique le trafic qui passe par le port. L'indicateur est utilisé par le maillage de services pour obtenir un meilleur traçage et des métriques plus précises.

Avertissement : Actuellement, Kf n'est pas compatible avec le routage basé sur le port TCP. Vous devez utiliser un équilibreur de charge Kubernetes si vous souhaitez exposer un port TCP sur Internet. Les ports sont disponibles sur l'adresse de l'application interne <app-name>.<space> du cluster.

Champs de métadonnées

Les champs suivants sont valides pour les objets application.metadata :

Champ	Type	Description
labels	string -> string map	Libellés à ajouter à l'application et aux pods d'application sous-jacents.
annotations	string -> string map	Annotations à ajouter à l'application et aux pods d'application sous-jacents.

Remarque : Les métadonnées de Kf remplacent les métadonnées personnalisées pour certaines ressources, afin de garantir le bon fonctionnement des éléments de la plate-forme, tels que le routage et la journalisation.

Exemples

Application minimale

Il s'agit d'un fichier manifeste épuré qui crée une application en détectant automatiquement le pack de création en fonction de la source importée et en y déployant une instance.

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

Application simple

Il s'agit d'un fichier manifeste complet pour une application Java plus traditionnelle.

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

Application Docker

Kf peut déployer des conteneurs Docker ainsi que le fichier manifeste d'une application. Ces applications Docker DOIVENT écouter la variable d'environnement 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

Application avec plusieurs ports

Cette application dispose de plusieurs ports pour exposer une console d'administration, un site Web et un serveur 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

Types de vérification d'état

Kf accepte trois types de vérification d'état :

1. port (par défaut)
2. http
3. process (ou none)

port et http définissent une vérification d'aptitude et d'activité Kubernetes qui garantit que l'application est prête avant de lui envoyer du trafic.

La vérification d'état port permet de s'assurer que le port trouvé sur $PORT est en cours d'écoute. Kf utilise une vérification TCP en arrière-plan.

La vérification d'état http utilise la valeur configurée dans health-check-http-endpoint pour vérifier l'état de l'application. Une vérification HTTP est effectuée en arrière-plan.

Une vérification d'état process vérifie uniquement si le processus est bien en cours d'exécution sur le conteneur. Elle ne configure PAS de vérification d'aptitude ou d'activité Kubernetes.

Différences connues

Voici les différences connues entre les fichiers manifestes Kf et les fichiers manifestes Cloud Foundry :

• Kf n'est pas compatible avec les champs des fichiers manifestes Cloud Foundry obsolètes. Cela inclut tous les champs au niveau racine du fichier manifeste (autres que les applications) et les champs de routage.
• Kf n'est pas compatible avec les champs des fichiers manifestes v2 suivants :
  • docker.username
• Kf n'est pas compatible avec la détection automatique des ports pour les conteneurs Docker.