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. Valeur par défaut du 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 Quantité de disque que l'application doit atteindre. La valeur par défaut est 1 Gio.
memory quantity Quantité de mémoire RAM pour l'application. La valeur par défaut est 1 Gio.
cpu † quantity Quantité de processeurs à fournir à l'application. La valeur par défaut est de 0,1 (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 le 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 fonctionnelle.
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 dans le cadre 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 fournie, 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 auxquels le conteneur doit avoir accès. Si plusieurs ports sont fournis, la première entrée de cette liste est utilisée comme port par défaut.

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

Champs du 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.

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

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
  cpu: 2
  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érifications 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.