Descripción general de App Lifecycle Manager

App Lifecycle Manager (antes conocido como entorno de ejecución de SaaS) te permite almacenar, alojar, administrar y supervisar aplicaciones de software como servicio (SaaS) en Google Cloud. App Lifecycle Manager administra las implementaciones de Terraform a gran escala, lo que te permite administrar tanto la aplicación de SaaS como la infraestructura en la que se ejecuta.

App Lifecycle Manager se puede usar de muchas maneras por una variedad de partes interesadas dentro de la canalización de SaaS. Si tu trabajo se identifica con alguno de estos roles, es posible que te interese usar App Lifecycle Manager:

  • Administradora de la plataforma
  • Desarrollador de aplicaciones
  • Arquitecto
  • Administrador de cumplimiento
  • Ingeniero de plataforma
  • Operaciones financieras

App Lifecycle Manager ofrece los siguientes beneficios:

  • Automatiza las tareas de administración de servicios (como la implementación, los lanzamientos y la administración de marcas de función) en todos tus usuarios de SaaS para simplificar la administración de servicios a gran escala.
  • Amplía tu observabilidad y control ajustando tus actualizaciones y lanzamientos en unidades configurables para administrar tu oferta de apps con precisión a gran escala.
  • Crea coherencia en tu ecosistema de Google Cloud administrando servicios en varios productos de Google Cloud , incluidos Google Cloud, Google Distributed Cloud, Facturación, Observabilidad y Resource Manager.
  • Usa una arquitectura flexible y con plantillas que promueva las actualizaciones y las implementaciones de grupos basadas en unidades para mejorar la eficiencia y la reutilización.

¿Cómo funciona App Lifecycle Manager?

App Lifecycle Manager implementa artefactos que definen tu oferta de app. Estos artefactos deben tener una configuración de Terraform. La implementación se organiza en unidades distintas que se pueden actualizar con versiones que contienen cambios en tu oferta a través de un lanzamiento configurable.

Para obtener más información sobre la nomenclatura de App Lifecycle Manager, consulta el Glosario.

Prepara tu carga de trabajo para App Lifecycle Manager

Antes de implementar tu oferta de app, te recomendamos que determines la disposición ideal de tu oferta de app dentro del ecosistema de App Lifecycle Manager.

Organiza las partes de tu oferta de app que se deben actualizar o modificar juntas en parámetros de configuración de Terraform distintos. Cuando planifiques tu oferta de app, usa tipos de unidades para cada agrupación de tu oferta de app.

Una vez que hayas definido la estructura ideal para tu carga de trabajo en App Lifecycle Manager, puedes crear tu oferta de app, los tipos de unidades y, luego, implementar tus unidades con un lanzamiento.

Para ver un ejemplo de la configuración de App Lifecycle Manager, consulta la guía de inicio rápido.

Usa plantillas compuestas con App Lifecycle Manager

Puedes usar plantillas compuestas a través de Application Design Center para definir la infraestructura de las ofertas de aplicaciones de App Lifecycle Manager.

Una vez que adjuntes una plantilla compuesta a tu oferta de app, App Lifecycle Manager completará los tipos de unidades definidos en tu plantilla. Esto te permite implementar unidades según la estructura y los recursos definidos en tu plantilla compuesta.

Puedes editar tus plantillas compuestas en App Design Center y ver los cambios reflejados en tus ofertas de apps de App Lifecycle Manager.

Para obtener más información sobre las plantillas compuestas, consulta la documentación de Diseña plantillas compuestas. Para obtener más información sobre cómo adjuntar plantillas compuestas a las ofertas de App Lifecycle Manager, consulta Modelar y empaquetar unidades de implementación.

Cuentas de servicio de App Lifecycle Manager

App Lifecycle Manager usa una combinación de cuentas de servicio administradas por Google y por el usuario:

  • Cuenta de servicio de App Lifecycle Manager (administrada por Google): Esta cuenta se crea automáticamente después de crear el primer recurso de oferta de la app. Google lo administra. Realiza acciones en tu nombre, como interactuar con otros servicios de Google Cloud durante el aprovisionamiento de unidades.

  • Cuenta de servicio de activación (administrada por el usuario): Tú creas y administras esta cuenta de servicio. App Lifecycle Manager (a través de Infrastructure Manager) usa esta cuenta para ejecutar tus parámetros de configuración de Terraform cuando aprovisiona o actualiza unidades. Esta cuenta actúa como la identidad para crear y administrar los recursos definidos en tu Terraform. Los permisos de la cuenta de servicio de activación están vinculados directamente a los recursos que administra tu configuración de Terraform.

    Puedes tener varias cuentas de servicio de activación. Te recomendamos que tengas una cuenta de servicio de activación para cada usuario.

  • Opcional: Cuenta de servicio de creación de artefactos (administrada por el usuario): Esta cuenta de servicio se usa para compilar y subir tu Terraform empaquetado en artefactos de OCI. A menudo, se trata de una cuenta de servicio de Cloud Build, pero puede ser cualquier cuenta de servicio con los permisos adecuados para tu oferta de app.

Cuenta de servicio de App Lifecycle Manager (administrada por Google)

La cuenta de servicio de App Lifecycle Manager es un agente de servicio administrado por Google que usa App Lifecycle Manager para realizar operaciones en tu proyecto.

Esta cuenta de servicio se aprovisiona de forma automática cuando creas tu primer recurso de App Lifecycle Manager. La cuenta de servicio de App Lifecycle Manager se crea con este formato:

  service-PROJECT_NUMBER@gcp-sa-saasservicemgmt.iam.gserviceaccount.com

Reemplaza lo siguiente:

  • PROJECT_NUMBER: Es el número de tu proyecto.

Cuenta de servicio de activación (administrada por el usuario)

La cuenta de servicio de activación es una cuenta de servicio administrada por el usuario que debes crear. App Lifecycle Manager (a través de Infra Manager) usa esta cuenta de servicio para ejecutar tus parámetros de configuración de Terraform. Es la identidad que crea, modifica y borra los recursos definidos en tu Terraform.

Eres responsable de crear esta cuenta de servicio dentro de tu proyecto o dentro de tu proyecto de usuario.

Variables de entrada de la cuenta de servicio de activación

Cuando creas una unidad, debes proporcionar la cuenta de servicio de activación como una variable de entrada de par clave-valor para la configuración de Terraform:

  • Nombre: actuation_sa
  • Tipo de variable: String

  • Valor de la variable: Dirección de correo electrónico de la cuenta de servicio de activación:

    my-actuation-sa@my-identifier.iam.gserviceaccount.com

Permisos necesarios

La cuenta de servicio de activación requiere permisos suficientes para administrar los recursos definidos en tu configuración de Terraform. Como mínimo, necesita lo siguiente:

  • roles/iam.serviceAccountTokenCreator: Permite que la cuenta de servicio genere tokens para la autenticación.
  • roles/config.admin: Otorga control total sobre los recursos de Infra Manager.
  • roles/storage.admin: Otorga control total de Cloud Storage.

La cuenta de servicio de actuación también necesita permisos para crear y administrar los recursos de Google Cloud específicos que usa tu aplicación.

Por ejemplo:

  • Si tu Terraform crea clústeres de Google Kubernetes Engine (GKE), la cuenta de servicio necesita roles de GKE adecuados (roles/container.admin, por ejemplo).
  • Si tu Terraform crea instancias de Compute Engine, la cuenta de servicio necesita el rol roles/compute.admin.
  • Si tu Terraform crea instancias de Cloud SQL, la cuenta de servicio necesita los roles de Cloud SQL adecuados (roles/cloudsql.admin, por ejemplo).

Consulta la documentación de cada recurso de Google Cloud que uses en tu Terraform para determinar los permisos necesarios. Otorga el privilegio mínimo necesario para que tu aplicación funcione.

Cuenta de servicio de creación de artefactos (administrada por el usuario)

La cuenta de servicio de creación de artefactos es una cuenta de servicio administrada por el usuario que creas para usar un sistema de compilación (como Cloud Build) para empaquetar y subir tus artefactos de Terraform a Artifact Registry.

Esta cuenta de servicio es independiente de las cuentas de servicio de App Lifecycle Manager y de activación, y compila tu código de Terraform y envía el artefacto resultante a Artifact Registry. A menudo, esta es la cuenta de servicio de Cloud Build.

Creación manual de artefactos

Si compilas y subes tus artefactos de Terraform de forma manual (por ejemplo, con Docker build y Docker push directamente), no necesitas una cuenta de servicio de creación de artefactos independiente.

En su lugar, debes autenticarte con tus propias credenciales o una cuenta de servicio con los permisos necesarios de Artifact Registry.

Permisos necesarios

Si usas Cloud Build, la cuenta de servicio de Cloud Build suele necesitar los siguientes roles:

  • roles/artifactregistry.writer: Para enviar artefactos a Artifact Registry.
  • roles/artifactregistry.repoAdmin: Para administrar el repositorio de Artifact Registry.
  • roles/storage.admin: Para administrar los buckets de Cloud Storage.
  • roles/developerconnect.admin: Permisos para usar Developer Connect.
  • roles/developerconnect.readTokenAccessor: Permisos para obtener el token de lectura de Developer Connect.
  • roles/logging.logWriter: Permisos para escribir registros.
  • Si implementas tu configuración de Terraform con Developer Connect: roles/cloudbuild.builds.builder: Para ejecutar compilaciones.
  • Cualquier otro permiso que requiera tu proceso de compilación (por ejemplo, acceso a repositorios de código fuente).

Estrategias de lanzamiento

App Lifecycle Manager emplea varias estrategias de lanzamiento para administrar cómo se actualizan las unidades en tu oferta de app. Estas estrategias de lanzamiento siguen el enfoque deGoogle Cloudpara el cambio aplicando enfoques coherentes al lanzamiento de cambios en tu oferta de apps.

Usa estrategias de lanzamiento para minimizar los impactos negativos en los clientes y aislar los problemas en dominios con fallas lógicos y físicos individuales. Define tus estrategias de lanzamiento creando un tipo de lanzamiento que especifique una de las siguientes estrategias de lanzamiento:

  • Una ubicación a la vez (simple): Se actualiza una ubicación a la vez, sin espera entre ubicaciones. Las unidades se seleccionan de forma arbitraria dentro de una ubicación, con un máximo del 5% de las unidades de la ubicación actualizadas en un momento determinado.

    Esta estrategia se recomienda para entornos de desarrollo y situaciones de emergencia.

  • Todo al mismo tiempo (simple): Todas las ubicaciones comienzan a actualizarse al mismo tiempo.

    Esta estrategia se recomienda para entornos de desarrollo y situaciones de emergencia.

  • Progresiva (gradual): En cada ubicación, las unidades se actualizan en lotes estáticos basados en porcentajes (por ejemplo, 1%, 10%, 20%, 30%, ~40%) con tiempos de prueba entre lotes. En todas las ubicaciones, el lanzamiento progresa con un aumento exponencial en la cantidad de ubicaciones simultáneas (por ejemplo, una ubicación, luego dos, luego cuatro) con tiempos de prueba (18 horas, por ejemplo) entre las olas. Las unidades dentro de una ubicación se seleccionan al azar.

    Esta estrategia está diseñada para lanzamientos seguros y predecibles en varias ubicaciones. Se comienza con una presencia reducida y se realiza una expansión gradual a medida que aumenta la confianza. Esta estrategia se recomienda en entornos de producción con más de una ubicación.

  • Progresiva (ubicación única): Las unidades se actualizan en lotes estáticos basados en porcentajes (por ejemplo, 1%, 10%, 20%, 30%, ~40%) con tiempos de prueba más largos (18 horas, por ejemplo) entre lotes para permitir un tiempo amplio para la detección de problemas y limitar el impacto adverso de los cambios de lanzamiento.

    Esta estrategia está diseñada para ofertas de apps que operan en una sola ubicación, en la que se prioriza la seguridad y la precaución. Recomendamos esta estrategia en entornos de producción con una ubicación.

Para obtener más información sobre cómo crear tipos de lanzamiento, consulta Crea un tipo de lanzamiento.

Regionalización de App Lifecycle Manager

Los recursos de oferta de app definen dónde pueden residir tus unidades de App Lifecycle Manager y cómo se administran tus lanzamientos. Cuando creas una oferta de app, las regiones que seleccionas sirven como fuente única de información para las regiones admitidas de tu oferta de app. Las regiones que selecciones son las regiones disponibles que definiste para tu oferta de app.

Cuando usas App Lifecycle Manager a través de la consola de Google Cloud , App Lifecycle Manager automatiza la replicación de los recursos que defines en tu oferta de app en todas las regiones. Esto garantiza la coherencia y la disponibilidad de tus recursos de App Lifecycle Manager en todas las regiones disponibles que definiste en tu oferta de app.

App Lifecycle Manager replica estos recursos:

  • Oferta de la app (Saas)
  • Tipo de unidad (UnitKind)
  • Versión (Release)

Usa global como región

Por lo general, no se recomienda incluir global como una región dentro de tu oferta de app para los destinos de implementación. App Lifecycle Manager usa la región global para propagar los lanzamientos regionales. Los lanzamientos regionales no se pueden ejecutar en la región global.

Regionalización del lanzamiento

Las ubicaciones admitidas para los lanzamientos se determinan según las regiones de nivel superior definidas en las regiones disponibles de tu oferta de app.

Los lanzamientos leen la lista de regiones disponibles de la oferta de la app asociada.

Replicación de recursos

App Lifecycle Manager controla la creación y las actualizaciones de recursos en todas las regiones disponibles de tu oferta de app.

Cuando actualizas las regiones disponibles de tu oferta de App, el App Lifecycle Manager controla la replicación:

  • Ubicaciones agregadas: Los recursos se replican en las ubicaciones recién agregadas.
  • Ubicaciones con copias antiguas: Se actualiza el contenido.

Ubicaciones de Artifact Registry y Developer Connect

Las ubicaciones de tu repositorio de Artifact Registry y de la instancia de Developer Connect tienen requisitos específicos:

  • La región de tu repositorio de Artifact Registry y la instancia de Developer Connect pueden ser cualquier región de Google Cloud válida. No es necesario que se incluyan en las regiones disponibles de tu oferta de app.

  • La región de tu repositorio de Artifact Registry debe coincidir con la región de tu instancia de Developer Connect.

    Esto requiere la presencia de recursos de tipo oferta, versión y unidad de la app en todas las regiones definidas en tu oferta de la app, aunque Artifact Registry y Developer Connect residan en una sola región (potencialmente diferente).

  • Las unidades solo se pueden crear en las regiones especificadas en tu oferta de app.

Ejemplo de configuración de regiones de App Lifecycle Manager

Proporcionamos este ejemplo para demostrar cómo funciona la regionalización cuando se usa App Lifecycle Manager con la replicación de recursos administrados.

Por ejemplo, si quisieras implementar tu oferta de app en us-central1 y europe-west4, mientras alojas tu repositorio de Artifact Registry y la instancia de Developer Connect en us-east1, la infraestructura de regiones de App Lifecycle Manager sería algo como lo siguiente:

  • Regiones disponibles para la oferta de apps: ['us-central1', 'europe-west4']
  • Región del repositorio de Artifact Registry: us-east1
  • Región de la instancia de Developer Connect: us-east1
  • Recursos de tipo de unidad y de versión: App Lifecycle Manager administra la creación y las actualizaciones de estos recursos en las regiones global, us-central1 y europe-west4.
  • Unidades: Las unidades se pueden crear en us-central1 o europe-west4.

Esta configuración te permite administrar tus implementaciones en dos regiones y, al mismo tiempo, mantener la administración de artefactos centralizada en una tercera región distinta con replicación automatizada de recursos. Debes considerar cuidadosamente tus requisitos de latencia, cumplimiento y residencia de datos cuando selecciones las regiones.

¿Qué sigue?