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.

Nota: Si especificas un appPort, ese puerto DEBE también declararse en el campo ports.

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.

Nota: El campo protocol es una sugerencia sobre el tráfico que pasa por el puerto. La malla de servicios usa la sugerencia para mejorar el seguimiento y las métricas.

Advertencia: En la actualidad, Kf no es compatible con el enrutamiento basado en puertos TCP. Debes usar Kubernetes LoadBalancer si quieres exponer un puerto TCP a Internet. Los puertos están disponibles en la dirección interna <app-name>.<space> de la app del clúster.

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.