Requisitos para empaquetar tu aplicación

En esta página se describen los requisitos para empaquetar tu aplicación de Kubernetes y las directrices para cumplirlos.

Tu paquete de aplicación es un paquete de imágenes de contenedor y archivos de configuración que se implementan en los clústeres de Kubernetes de los usuarios. Para poder desplegar tu aplicación en Google Kubernetes Engine desde la consola de Google Cloud , el paquete de la aplicación debe incluir un contenedor de despliegue. El contenedor de implementación envía los archivos de configuración y los metadatos de visualización a la API de Kubernetes.

Tu paquete de aplicación permite a los usuarios hacer lo siguiente: Google Cloud

• Descubrir tu aplicación en el catálogo de Cloud Marketplace
• Despliega la aplicación en su clúster de GKE o GKE Enterprise mediante la Google Cloud consola
• Interactúa con la aplicación en ejecución mediante la Google Cloud consola

Además de admitir la implementación a través de la Google Cloud consola, tu paquete debe incluir los pasos que deben seguir los usuarios para implementar tu aplicación mediante una interfaz de línea de comandos (CLI) con herramientas como kubectl o Helm.

Para ver ejemplos de paquetes de aplicaciones, consulta el repositorio de GitHub de las soluciones Click to Deploy de Google. El repositorio contiene paquetes de aplicaciones de código abierto populares, como WordPress y Elasticsearch.

Antes de empezar

• Asegúrate de haber configurado tu Google Cloud entorno.
• Crea un repositorio de Git público para los archivos de configuración, la guía del usuario y otros recursos para ejecutar tu aplicación. Puedes alojar el repositorio con un proveedor como GitHub o Cloud Source Repositories, o en tu propio servidor. Te recomendamos que uses un repositorio específico para cada producto que distribuyas.

Información general

La aplicación debe cumplir los siguientes requisitos:

• Tu repositorio de Git debe contener un archivo LICENSE, que incluye la licencia de código abierto del repositorio.

• Tu repositorio de Git debe contener un archivo de configuración que despliegue tu aplicación. El archivo de configuración puede ser un manifiesto YAML de Kubernetes o un gráfico de Helm.

  La configuración debe incluir un recurso personalizado Application, que describe la aplicación.

  Consulta los requisitos de tu configuración.

• Tu aplicación debe ejecutarse en nodos que usen un procesador x86.

• Si quieres que tu aplicación sea compatible con Istio, consulta las limitaciones de los clústeres que ejecutan Istio.

• Si tu aplicación es comercial (no BYOL), debe informar de su uso a Google para que se facture correctamente a tus clientes. Te recomendamos que integres tu aplicación con el agente de facturación basada en el uso, que envía informes de uso a Google.

  Consulta los requisitos para integrar el agente de facturación.

• Todas las imágenes de contenedor de tu aplicación deben subirse a tu registro en Artifact Registry o Container Registry. Tu registro también debe incluir una imagen de deployer, que envía la configuración de la aplicación a la API de Kubernetes cuando los usuarios despliegan la aplicación desde la consola de Google Cloud .

  Consulta los requisitos para crear imágenes de aplicaciones.

• Debes incluir pruebas de integración para la aplicación.

  Consulta los requisitos del proceso de verificación.

• Debes incluir una guía de usuario con los pasos para implementar la aplicación desde la línea de comandos, configurarla y usarla.

  Consulta los requisitos de la guía de usuario.

Requisitos de configuración

Puedes proporcionar tu configuración como un manifiesto de Kubernetes o como un gráfico de Helm.

Tu configuración debe cumplir los siguientes requisitos:

• Para proteger a los usuarios de las APIs inestables, utiliza solo recursos de Kubernetes beta o disponibles para todos los usuarios.

• Tu configuración debe desplegar un recurso personalizado Application. El recurso Application contiene la información que ven los usuarios cuando implementan su aplicación a través de la interfaz de usuario de Cloud Marketplace.

  El recurso Application es un recurso personalizado que agrega los componentes de Kubernetes asociados a tu aplicación y permite a los usuarios gestionar estos recursos como un grupo.

  Para obtener información sobre cómo crear un recurso Application y ver ejemplos, consulta el repositorio Application de GitHub.

• Tu configuración debe usar parámetros que se puedan sustituir, ya sea con envsubst o como marcas.

  Se deben poder sustituir los siguientes parámetros:

  • Espacio de nombres: todos los recursos de tu configuración deben pertenecer a un único espacio de nombres. Los usuarios de Cloud Marketplace configuran este espacio de nombres cuando implementan tu aplicación. Evita codificar espacios de nombres en tus manifiestos para que los recursos que especifiques se creen en el espacio de nombres que seleccionen los usuarios. A veces, los espacios de nombres también aparecen en las definiciones de recursos, como cuando se hace referencia a un ServiceAccount en un RoleBinding. Cualquier referencia de este tipo debe parametrizarse.

  • Nombre de la aplicación: el nombre de la instancia del recurso Application. Esta cadena debe incluirse en el nombre de cada uno de los recursos de la aplicación para evitar conflictos de nombres si se implementan varias instancias de la aplicación en un mismo espacio de nombres.

  • Imágenes de contenedor: todas las referencias de imágenes, como las de un PodSpec, deben poder sustituirse para que Cloud Marketplace pueda invalidarlas y dirigir a imágenes publicadas en nuestro Artifact Registry. También permite a los clientes sustituir imágenes modificadas.

  • Secreto de licencia: si tu aplicación realiza una medición comercial, debe aceptar el nombre de un recurso Secret como parámetro. El secreto contiene las credenciales de informes de uso, que tu aplicación usa para enviar datos de uso a Google.

    Consulta más información sobre los parámetros de configuración en GitHub.

• Debe ser posible implementar tu aplicación con herramientas del lado del cliente. Por ejemplo, si usas Helm, la implementación debe funcionar con la marca de línea de comandos --client-only.

Limitaciones en clústeres con Istio

Si quieres que tu aplicación sea compatible con Istio, consulta las limitaciones descritas en esta sección. Para obtener una descripción general de Istio, consulta ¿Qué es Istio?

Si tus clientes ejecutan Istio en sus clústeres, Istio controla el tráfico de red entre los pods de tu aplicación de forma predeterminada. Esto puede bloquear la comunicación de red en los siguientes casos:

• Si tus pods ejecutan comandos kubectl que usan la dirección IP del clúster, es posible que los comandos fallen.

• Si tu aplicación usa la comunicación de pod a pod o basada en IP, es posible que falle el paso de formación del clúster.

• Es posible que se bloqueen las conexiones externas a servicios de terceros, como los repositorios de paquetes del SO. Los clientes deben configurar el tráfico de salida de Istio para habilitar el acceso a servicios externos.

Te recomendamos que configures las conexiones entrantes con Istio Gateway en lugar de con recursos LoadBalancer o Ingress.

Si usas Helm para la configuración, utiliza la propiedad x-google-marketplace ISTIO_ENABLED en el esquema de la imagen de implementación. Si esta propiedad es true, el desplegador debe modificar el despliegue, por ejemplo, esperando a que el sidecar de Istio esté listo.

Para ayudar a tus clientes a configurar la comunicación entre los pods de la aplicación, te recomendamos que añadas pasos a las secciones posteriores a la implementación de tu documentación.

Requisitos para integrar el agente de facturación

Si vendes una aplicación comercial, te recomendamos que la integres con el agente de facturación basada en el uso (UBB).

El agente gestiona la autenticación y los informes al endpoint de informes de uso de Google: Service Control. Cuando hayas enviado tu modelo de precios, el equipo de Cloud Marketplace creará un servicio para tu aplicación con el que se generarán informes y las métricas de facturación para medir el uso.

El agente también gestiona la agregación local, la recuperación tras fallos y los reintentos. En el caso de la métrica de horas de uso, el agente se puede configurar para que envíe automáticamente señales de mantenimiento.

El agente también expone el estado de los informes, lo que permite que tu aplicación detecte si el agente está enviando correctamente los datos de uso.

Los clientes compran la aplicación en Cloud Marketplace para adquirir una licencia, que se adjunta a la aplicación en el momento de la implementación.

Cuando integres tu aplicación con el agente de facturación, ten en cuenta cómo se comporta tu aplicación cuando fallan los informes de uso, lo que puede indicar una de las siguientes situaciones:

• El cliente ha cancelado su suscripción.

• Es posible que el cliente haya inhabilitado el canal de denuncia por error. Por ejemplo, los clientes pueden quitar o configurar incorrectamente el agente por error, o la red puede impedir que el agente acceda al endpoint de informes de Google.

Sigue las prácticas recomendadas para informar del uso y gestionar los casos en los que Google no recibe datos de uso y no se factura a los clientes.

Integrar el agente de facturación

Puedes integrar el agente como un contenedor sidecar, que se ejecuta en el mismo pod que tu aplicación, o bien mediante el SDK.

En el enfoque de sidecar, el agente se ejecuta en su propio contenedor, en el mismo pod de Kubernetes que el contenedor de la aplicación. Tu aplicación se comunica con la interfaz REST local del agente.

En el enfoque del SDK, el agente debe compilarse o vincularse en el archivo binario de tu aplicación. El SDK se implementa de forma nativa en Go, con enlaces para Python.

En general, el enfoque de sidecar requiere menos esfuerzo de integración, mientras que el SDK es más robusto para evitar que se inhabilite por error.

Para ver los pasos detallados de la integración, consulta el archivo README del repositorio de GitHub Usage-based Billing Agent. Para ver una implementación de ejemplo, consulta los repositorios de la aplicación y las herramientas.

Credenciales para registrar el uso

El agente de facturación requiere credenciales que le permitan enviar informes de uso a Google. Cloud Marketplace genera estas credenciales cuando los usuarios despliegan la aplicación desde Cloud Marketplace y se asegura de que existan como Secret en el espacio de nombres de Kubernetes de destino antes de que se despliegue la aplicación. El nombre de este secreto se transfiere a tu aplicación como la propiedad REPORTING_SECRET del esquema.

Para ver un ejemplo de manifiesto que usa el secreto de informes, consulta el ejemplo de aplicación de WordPress en GitHub.

El secreto contiene los siguientes campos:

entitlement-id	Identificador que representa el acuerdo del cliente para comprar y usar el software.
consumer-id	Identificador asociado al derecho que se envía a Google Service Control junto con los informes de uso.
reporting-key	La clave JSON de la cuenta de servicio de Google Cloud que se usa para autenticarse en Google Service Control.

Si tu producto proporciona un componente SaaS además de la aplicación, puedes hacer que ese componente SaaS compruebe periódicamente la validez de los IDs de derecho mediante el servicio de adquisición de Cloud Marketplace. Para acceder al servicio de Compras, ponte en contacto con tu ingeniero de partners.

Para obtener información sobre otros parámetros que se transfieren a la aplicación, consulte la sección Parámetros transferidos a su aplicación, que aparece más adelante en este artículo.

Requisitos para crear imágenes de contenedor

Tu aplicación consta de una o varias imágenes de contenedor de aplicaciones. Además, tu repositorio debe incluir un contenedor de implementación, que se usa cuando los clientes implementan la aplicación desde la interfaz de usuario de Cloud Marketplace.

Las imágenes de contenedor se suelen compilar con un Dockerfile y la herramienta de línea de comandos docker build. Te recomendamos que publiques el Dockerfile y las instrucciones de compilación del contenedor en el repositorio público de tu aplicación. Al publicarlas, los clientes pueden modificar o volver a crear las imágenes, lo que a veces es necesario para certificar imágenes en entornos de producción empresariales.

Si la imagen de tu aplicación depende de una imagen base, como Debian, o de una imagen de tiempo de ejecución de un lenguaje, como Python u OpenJDK, te recomendamos que utilices una de las imágenes de contenedor certificadas de Cloud Marketplace. De esta forma, te aseguras de que tu imagen base se actualice a tiempo, sobre todo en lo que respecta a los parches de seguridad.

Después de crear las imágenes de tu aplicación, envíalas al registro de staging que creaste en Artifact Registry o Container Registry cuando configuraste tu entorno.

Tu repositorio de Artifact Registry o Container Registry debe tener la siguiente estructura:

• La imagen principal de tu aplicación debe estar en la raíz del repositorio. Por ejemplo, si tu repositorio de Artifact Registry o Container Registry es gcr.io/exampleproject/exampleapp, la imagen de la aplicación debe estar en gcr.io/exampleproject/exampleapp.

• La imagen del contenedor de tu implementación debe estar en una carpeta llamada deployer. En el ejemplo anterior, la imagen de implementación debe estar en gcr.io/exampleproject/exampleapp/deployer.

• Si tu aplicación usa imágenes de contenedor adicionales, cada imagen adicional debe estar en su propia carpeta dentro de la imagen principal. Por ejemplo, si tu aplicación requiere una imagen proxy, añádela a gcr.io/exampleproject/exampleapp/proxy.

• Todas las imágenes de tu aplicación deben etiquetarse con la versión actual y el canal de lanzamiento. Por ejemplo, si vas a lanzar la versión 2.0.5 en el canal 2.0, todas las imágenes deben etiquetarse con 2.0 y 2.0.5. Consulta cómo organizar tus lanzamientos.

• Todas las imágenes de tu aplicación deben contener la siguiente anotación en su archivo de manifiesto de imagen:

  com.googleapis.cloudmarketplace.product.service.name=services/SERVICE_NAME
  

  Sustituye SERVICE_NAME por el nombre de tu servicio. Para encontrar el nombre de su servicio, consulte la tabla de productos de la página Resumen del Portal para productores. Para obtener más información sobre las anotaciones, consulta la documentación de la Open Container Initiative sobre las anotaciones en GitHub.

Por ejemplo, en la siguiente imagen se muestran los repositorios de Artifact Registry y Container Registry de la aplicación de Kubernetes Grafana Cluster. La pista de lanzamiento es 5.3 y la aplicación contiene la imagen de la aplicación principal, la imagen del desplegador en su propia carpeta y la imagen de Debian 9 en debian9. Todas las imágenes del repositorio están etiquetadas con la misma pista, 5.3, y la misma versión de esa pista, 5.3.4. También debe coincidir con el campo "Version" de la definición de recurso personalizado (CRD) del recurso Application tal como se declara en el implementador.

El repositorio está en gcr.io/cloud-marketplace/google/grafana.

Usa los identificadores de imagen de contenedor que hayas seleccionado anteriormente al elegir los identificadores de producto.

Para subir tus imágenes a Artifact Registry o Container Registry, etiquétalas con el nombre del registro y, a continuación, inserta la imagen con gcloud. Por ejemplo, usa los siguientes comandos para enviar las imágenes de example-pro:

docker build -t gcr.io/my-project/example-pro:4.0   # release track 4.0
docker tag gcr.io/my-project/example-pro:4.0 gcr.io/my-project/example-pro:4.0.3  # release version 4.0.3
docker push gcr.io/my-project/example-pro:4.0
docker push gcr.io/my-project/example-pro:4.0.3

Para obtener instrucciones detalladas sobre cómo etiquetar y enviar imágenes a tu registro, consulta la documentación correspondiente de Artifact Registry o Container Registry.

Requisitos del contenedor de implementación

El contenedor de implementación, o implementador, se usa cuando los clientes implementan tu producto desde Cloud Marketplace. La imagen del desplegador empaqueta la configuración de Kubernetes de tu aplicación y las herramientas de cliente, como kubectl o Helm, que envían la configuración a la API de Kubernetes. El implementador suele usar el mismo conjunto de comandos de línea de comandos que un usuario ejecutaría para implementar tu aplicación.

Para crear tu implementador, usa una de las imágenes base de los contenedores de implementación del directorio marketplace del repositorio de herramientas:

• Si usas kubectl para tu configuración, utiliza la imagen base de kubectl.
• Si utilizas un gráfico de Helm para la configuración, usa la imagen base de Helm.

Las imágenes base tienen utilidades integradas para tareas como asignar referencias de propietario, generar contraseñas y limpiar después de la implementación.

Para ver los pasos para crear tu imagen de implementación, consulta Crear el implementador de aplicaciones.

Parámetros enviados a tu aplicación

Tu contenedor de implementación debe declarar los parámetros que se deben recoger de los clientes cuando seleccionen tu aplicación. Estos parámetros se proporcionan al contenedor de implementación cuando los usuarios implementan la aplicación.

Para configurar estos parámetros, la imagen del contenedor de tu implementación debe incluir un esquema JSON en formato YAML en esta ruta: /data/schema.yaml.

Para saber cómo crear un schema.yaml, consulta Esquema de Deployer.

Solicitudes de clústeres de GPU

Si tu aplicación tiene necesidades específicas de GPU o requiere un uso intensivo de la GPU, puedes especificar el tipo y el número de GPUs del clúster mediante tu esquema de implementación. Si especificas tus necesidades de GPU, se inhabilitará la creación asistida de clústeres.

Tu aplicación puede solicitar una GPU de Nvidia genérica o una plataforma de Nvidia específica.

Requisitos del proceso de verificación

Las aplicaciones se ejecutan en nuestro sistema de verificación para asegurarnos de que:

• La instalación se realiza correctamente: se aplican todos los recursos y se espera a que estén en buen estado.
• Las pruebas de funcionalidad se superan: el implementador inicia el pod de prueba y observa su estado de salida. Cero significa que se ha completado correctamente y un valor distinto de cero significa que no se ha completado.
• La desinstalación se realiza correctamente: la aplicación y todos sus recursos se eliminan correctamente del clúster.

Para poder publicar una aplicación en Google Cloud Marketplace, debe obtener resultados satisfactorios.

Para obtener información sobre cómo empaquetar, ejecutar y verificar estas pruebas de funcionalidad, consulta la documentación sobre la integración de la verificación.

Requisitos de la guía del usuario

La guía del usuario debe incluir la siguiente información:

Descripción general

• Descripción general de la aplicación, que abarca las funciones básicas y las opciones de configuración. Esta sección también debe incluir un enlace al producto publicado en Cloud Marketplace.

Configuración única

• Configurar herramientas de cliente, como kubectl o Helm, según corresponda.
• Instalar la definición de recurso personalizado (CRD) de la aplicación para que tu clúster pueda gestionar el recurso de la aplicación.
• Si vendes una aplicación comercial, sigue los pasos para adquirir y desplegar un secreto de licencia desde Cloud Marketplace.

Instalación

• Comandos para implementar la aplicación.
• Transfiere los parámetros disponibles en la configuración de la interfaz de usuario.
• Fijar referencias de imágenes a resúmenes inmutables.

• Si añade campos de entrada personalizados al esquema del archivo de implementación, añada información sobre los valores esperados, si procede.

  Información sobre cómo añadir campos de entrada a tu archivo de implementación

Uso básico

• Conectarse a una consola de administración (si procede).
• Conectar una herramienta de cliente y ejecutar un comando de ejemplo (si procede).
• Modificar nombres de usuario y contraseñas.

• Habilitar el tráfico de entrada e instalar los certificados de Seguridad en la capa de transporte (TLS), si procede.

  Información sobre cómo habilitar el tráfico de entrada e instalar certificados TLS

Crear copias de seguridad y restaurar

• Creando una copia de seguridad del estado de la aplicación.
• Restaurando el estado de la aplicación a partir de una copia de seguridad.

Actualizaciones de imágenes

• Actualizar las imágenes de la aplicación para parches o actualizaciones menores.

Escalado

• Escalar la aplicación (si procede).

Eliminación

• Eliminando la aplicación.
• Limpiar los recursos que puedan quedar huérfanos intencionadamente, como los PersistentVolumeClaims.