Manifiesto de la app

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

Formato

Los manifiestos son archivos YAML en el directorio raíz de la app. Deben llamarse manifest.yml o manifest.yaml.

Los manifiestos de apps de Kf pueden tener un único elemento de nivel superior: applications. El elemento applications puede contener una o más entradas de aplicación.

Campos de la aplicación

Los siguientes campos son válidos para objetos en applications:

Campo Tipo Descripción
name string El nombre de la aplicación. El nombre de la aplicación debe contener caracteres alfanuméricos en minúscula y guiones. No debe comenzar con un guion.
path string La ruta de acceso a la fuente de la aplicación. La configuración predeterminada es el directorio del manifiesto.
buildpacks string[] Una lista de paquetes de compilación para aplicar a la app.
stack string Imagen base para usar con apps creadas con un paquete de compilación.
docker object Un objeto de Docker. Consulte la sección de campos de Docker para obtener más información.
env map Pares clave-valor para usar como variables de entorno de la app y la compilación.
services string[] Una lista de nombres de instancias de servicio para vincularlas automáticamente a la app.
disk_quota quantity La cantidad de espacio en el disco que debería obtener la aplicación. La configuración predeterminada es 1 GiB.
memory quantity La cantidad de memoria RAM que se proporciona a la aplicación La configuración predeterminada es de 1 GiB.
cpu quantity La cantidad de CPU que se proporcionará a la aplicación El valor predeterminado es 0.1 (1/10 de una CPU).
instances int Cantidad de instancias de la app que se ejecutarán. El valor predeterminado es 1.
routes object Una lista de rutas en las que la app debe escuchar. Consulta la sección sobre campos de ruta para obtener más información.
no-route boolean Si se establece como verdadero, la aplicación no se podrá enrutar.
random-route boolean Si se establece como verdadero, la app recibirá una ruta aleatoria.
timeout int Cantidad de segundos que se espera hasta que la app está en buen estado.
health-check-type string El tipo de verificación de estado que se usa es port, process, none o http. Predeterminado: port.
health-check-http-endpoint string El extremo al que se orienta como parte de la verificación de estado. Solo es válido si health-check-type es http.
command string El comando que inicia la app. Si se proporciona, se pasará al punto de entrada del contenedor.
entrypoint string Anula el punto de entrada del contenedor de la app.
args string[] Anula los argumentos del contenedor de la app.
ports object Una lista de puertos para exponer en el contenedor. Si se proporciona, la primera entrada de esta lista se usa como el puerto predeterminado.

† Único en Kf

Campos de Docker

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

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

Campos de ruta

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

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

Campos de puerto

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

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

Ejemplos

App mínima

Este es un manifiesto básico con el que se compilará una app mediante la detección automática del paquete de compilación según la fuente subida y, además, se implementará una instancia de ella.

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

App simple

Este es un manifiesto completo para una app de 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
  # 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

App de Docker

Kf puede implementar contenedores de Docker y la aplicación implementada del manifiesto. Estas apps de Docker DEBEN escuchar 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
  cpu: 2
  instances: 1
  routes:
  - route: white-label-app.mycompany.com

App con varios puertos

Esta app tiene varios puertos para exponer una consola del administrador, 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 verificación de estado

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

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

port y http configuran un sondeo de preparación y capacidad de funcionamiento de Kubernetes que garantiza que la aplicación esté lista antes de enviarle tráfico.

La verificación de estado port garantizará que se escuche el puerto encontrado en $PORT. De forma interna, Kf usa un sondeo de TCP.

La verificación de estado http usará el valor configurado en health-check-http-endpoint para verificar el estado de la aplicación. De forma interna, Kf usa un sondeo de HTTP.

La verificación de estado process solo realiza la comprobación si el proceso que se ejecuta en el contenedor está activo. NO configura un sondeo preparación de Kubernetes ni uno de capacidad de respuesta.

Diferencias conocidas

A continuación, se indican las diferencias conocidas entre los manifiestos de Kf y los manifiestos de CF:

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