Manifiesto de la aplicación

Los manifiestos de aplicaciones permiten a los desarrolladores registrar el entorno de ejecución de sus aplicaciones de forma declarativa. Permiten que las aplicaciones se implementen de forma coherente y reproducible.

Formato

Los manifiestos son archivos YAML que se encuentran en el directorio raíz de la aplicación. Deben llamarse manifest.yml o manifest.yaml.

Los archivos de manifiesto de aplicaciones de Kf solo pueden tener un elemento de nivel superior: applications. El elemento applications puede contener una o varias entradas de aplicación.

Campos de la solicitud

Los siguientes campos son válidos para los objetos de applications:

Campo Tipo Descripción
name string Nombre de la aplicación. El nombre de la aplicación debe estar formado por caracteres alfanuméricos en minúscula y guiones. No debe empezar por un guion.
path string Ruta de acceso al origen de la aplicación. El valor predeterminado es el directorio del manifiesto.
buildpacks string[] Lista de buildpacks que se aplicarán a la aplicación.
stack string Imagen base que se usará para las aplicaciones creadas con un paquete de compilación.
docker object Un objeto de acoplamiento. Consulta la sección DockerFields para obtener más información.
env map Pares clave-valor que se usarán como variables de entorno de la aplicación y la compilación.
services string[] Lista de nombres de instancias de servicio que se van a vincular automáticamente a la aplicación.
disk_quota quantity Cantidad de espacio en disco que debe obtener la aplicación. El valor predeterminado es 1 GiB.
memory quantity Cantidad de RAM que se va a proporcionar a la aplicación. El valor predeterminado es 1 GiB.
cpu † quantity Cantidad de CPU que se va a proporcionar a la aplicación. El valor predeterminado es 100 m (1/10 de una CPU).
instances int Número de instancias de la aplicación que se van a ejecutar. El valor predeterminado es 1.
routes object Lista de rutas en las que debe escuchar la aplicación. Consulta la sección Campos de ruta para obtener más información.
no-route boolean Si se le asigna el valor true, la aplicación no se podrá enrutar.
random-route boolean Si se le asigna el valor true, la aplicación recibirá una ruta aleatoria.
timeout int Número de segundos que se debe esperar para que la aplicación esté en buen estado.
health-check-type string El tipo de comprobación de estado que se va a usar: port, process, none o http. Predeterminado: port
health-check-http-endpoint string El endpoint al que se dirige como parte de la comprobación del estado. Solo es válido si health-check-type es http.
command string El comando que inicia la aplicación. Si se proporciona, se pasará al punto de entrada del contenedor.
entrypoint † string Anula el punto de entrada del contenedor de la aplicación.
args † string[] Anula los argumentos del contenedor de la aplicación.
ports † object Lista de puertos que se van a exponer en el contenedor. Si se proporciona, se usa la primera entrada de esta lista como puerto predeterminado.
metadata object Etiquetas adicionales para las aplicaciones y sus recursos subyacentes.

† Exclusivo de Kf

Campos de Docker

Los siguientes campos son válidos para los objetos application.docker:

Campo Tipo Descripción
image string La imagen de Docker que se va a usar.

Campos de ruta

Los siguientes campos son válidos para los objetos application.routes:

Campo Tipo Descripción
route string Una ruta a la aplicación que incluya el nombre de host, el dominio y la ruta.
appPort int (Opcional) Un puerto personalizado en la aplicación al que la ruta enviará el tráfico.

Campos de puerto

Los siguientes campos son válidos para los objetos application.ports:

Campo Tipo Descripción
port int El puerto que se va a exponer en el contenedor de la aplicación.
protocol string El protocolo del puerto que se va a exponer. Debe ser tcp, http o http2. Predeterminado: tcp

Campos de metadatos

Los siguientes campos son válidos para los objetos application.metadata:

Campo Tipo Descripción
labels string -> string map Etiquetas que se añadirán a la aplicación y a los pods de la aplicación subyacente.
annotations string -> string map Anotaciones que se añadirán a la aplicación y a los pods de la aplicación subyacente.

Ejemplos

Aplicación mínima

Se trata de un manifiesto básico que compilará una aplicación detectando automáticamente el paquete de compilación en función de la fuente subida e implementará una instancia de la aplicación.

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

Aplicación sencilla

Este es un manifiesto completo de una aplicación Java más tradicional.

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

Aplicación Docker

Kf puede desplegar contenedores Docker, así como aplicaciones desplegadas mediante manifiesto. Estas aplicaciones Docker DEBEN recibir solicitudes en la variable de entorno 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

Aplicación con varios puertos

Esta aplicación tiene varios puertos para exponer una consola de administración, un sitio web y un servidor 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

Tipos de comprobaciones del estado

Kf admite tres tipos de comprobación de estado diferentes:

  1. port (predeterminado)
  2. http
  3. process (o none)

port y http definen una comprobación de preparación y vivacidad de Kubernetes que asegura que la aplicación esté lista antes de enviarle tráfico.

La comprobación del estado port se asegurará de que se esté monitorizando el puerto $PORT. En segundo plano, Kf usa una comprobación TCP.

La http comprobación del estado usará el valor configurado en health-check-http-endpoint para comprobar el estado de la aplicación. Información técnica Kf usa una comprobación HTTP.

Una process comprobación de estado solo comprueba si el proceso que se ejecuta en el contenedor está activo. NO define una comprobación de preparación o de vivacidad de Kubernetes.

Diferencias conocidas

Estas son las diferencias conocidas entre los manifiestos de Kf y los de CF:

  • Kf no admite campos de manifiesto de CF obsoletos. Esto incluye todos los campos del nivel raíz del manifiesto (excepto las aplicaciones) y los campos de enrutamiento.
  • A Kf le falta la compatibilidad con los siguientes campos del manifiesto de la versión 2:
    • docker.username
  • Kf no admite la detección automática de puertos para contenedores Docker.