Prácticas recomendadas para usar Deployment Manager

En esta página se describen las prácticas recomendadas para crear implementaciones con Google Cloud Deployment Manager. Esta página está dirigida a usuarios que conocen Deployment Manager. En ella no se explica cómo usar Deployment Manager.

Si no has usado nunca Deployment Manager, prueba la guía de inicio rápido.

Gestionar recursos

❑  
Una vez que hayas creado un recurso como parte de un despliegue, usa Deployment Manager si necesitas modificarlo. Si modificas un recurso sin usar Deployment Manager, por ejemplo, con la Google Cloud consolagcloud, es posible que se produzcan errores si intentas modificar el recurso en tu implementación original.

Si quieres quitar un recurso de una implementación sin eliminarlo, sigue estos pasos:

  1. En la configuración de la implementación, elimina la definición de ese recurso.
  2. Actualiza el despliegue y, en el comando `gcloud`, añade --delete-policy ABANDON. El recurso ya no estará asociado a la implementación y, a continuación, podrás modificarlo mediante la Google Cloud consola o gcloud.
❑  
Si tienes instancias de Compute Engine en tu implementación y quieres adjuntar discos persistentes a las instancias, define el disco por separado de la instancia para poder gestionarlo fácilmente. Por ejemplo, en la siguiente implementación, el disco example-disk se define por separado de la instancia example-instance. Para adjuntar el disco, la configuración tiene una referencia al disco: 
    resources:
    # instance
    - name: example-instance
      type: compute.v1.instance
      properties:
        disks:
          - type: PERSISTENT
            source:$(ref.example-disk.selfLink)
   # disk
   - name: example-disk
     type: compute.v1.disk
     properties:
       zone: us-central1-a
       sizeGb: 10
       type: ...
❑  

Si quieres crear y gestionar clústeres privados de Google Kubernetes Engine (GKE) con Deployment Manager, define las siguientes opciones privateClusterConfig y ipAllocationPolicy en tu implementación.

     privateClusterConfig:
        enablePrivateNodes: true
        enablePrivateEndpoint: true
        #  Configure the IP range for the hosted master network
        masterIpv4CidrBlock: IP_RANGE
      ipAllocationPolicy:
        useIpAliases: true
        createSubnetwork: true

Para consultar los requisitos y otras consideraciones a la hora de crear un clúster privado con GKE, consulta el artículo Configurar un clúster privado.

Incluir credenciales en tu implementación

❑  
Deployment Manager oculta algunos campos relacionados con las credenciales de las propiedades de las configuraciones YAML. Esta redacción se basa en la clave de la propiedad. En el siguiente ejemplo se muestra una de estas redacciones: 
    # Config provided to Deployment Manager
    resources:
    - name: example-resource
      type: gcp-types/service-v1:sample-type-with-password
      properties:
        zone: us-central1-a
        username: test-user
        password: hunter2

   # Config as surfaced by Deployment Manager
   resources:
    - name: example-resource
      type: gcp-types/service-v1:sample-type-with-password
      properties:
        zone: us-central1-a
        username: test-user
        password: (redacted)
❑  
Si incluyes la credencial en una plantilla de Jinja o Python para tu implementación, se ocultará en los archivos de configuración y diseño ampliados resultantes, pero seguirá visible en el archivo de importación original. Por este motivo, te recomendamos que coloques todas las credenciales que quieras mantener en secreto en tu archivo de configuración YAML de nivel superior. Puedes hacer referencia a ellas desde ahí usando propiedades de plantilla.
❑  
Las credenciales incluidas en un par clave-valor de un archivo YAML o una lista de elementos no se ocultarán, como en el siguiente ejemplo. Por este motivo, le recomendamos que no proporcione credenciales a Deployment Manager como pares clave-valor en archivos YAML o listas de elementos. 
    # Not a valid instance configuration, used solely for demonstration
    resources:
    - name: example-resource
      type: gcp-types/compute-v1:instances
      properties:
        zone: us-central1-a
        disks:
        - autoDelete: true
          boot: true
    # Will not be redacted
          password: hunter2

Plantillas de Build

❑  
Para definir tus plantillas más rápido, te recomendamos que empieces con las plantillas de ejemplo listas para producción del proyecto Cloud Foundation Toolkit.
❑  
Si tienes requisitos de infraestructura complejos, como la necesidad de crear varios entornos, consulta el tutorial y los ejemplos sobre cómo usar Deployment Manager a gran escala.
❑  
Usa Python para crear tus plantillas. Puedes usar Python o Jinja2 para crear plantillas. Es más fácil empezar a usar Jinja, pero Python es más flexible para las implementaciones complejas en las que puede haber muchos recursos distribuidos en varios entornos.
❑  
Estructura el archivo de configuración (el archivo YAML) de forma que solo use un tipo y utiliza una plantilla de nivel superior como ese tipo para llamar a todas las demás plantillas. Si adoptas esta práctica, te resultará más fácil convertir un conjunto de plantillas en un tipo compuesto.
❑  
Usa un archivo de esquema. Los esquemas definen un conjunto de reglas que debe seguir un archivo de configuración para usar una plantilla concreta. Si defines un esquema y animas a otros usuarios a revisar los requisitos definidos en un esquema, tus usuarios podrán saber fácilmente qué propiedades se pueden definir o son obligatorias para la plantilla correspondiente. De esta forma, los usuarios pueden usar la configuración sin tener que investigar los detalles de las plantillas. Como mínimo, define un archivo de esquema para la plantilla de nivel superior.
❑  
Usa propiedades de plantilla y salidas. Las propiedades y las salidas te permiten transferir variables como la zona, el tamaño de la máquina, el número de máquinas o el estado de la aplicación (prueba, producción o staging) a tus plantillas y recibir valores de salida, como la dirección IP y el selfLink de una instancia de VM. Las propiedades y las salidas permiten que tus plantillas sean flexibles para que se puedan reutilizar sin modificar las plantillas subyacentes.
❑  
Usa archivos de plantilla individuales que importes en tu archivo de configuración principal. De esta forma, podrá gestionar las configuraciones de una forma más sencilla.
❑  
Divide las configuraciones en unidades lógicas. Por ejemplo, crea configuraciones independientes para servicios con estado, como bases de datos y segmentos, y configuraciones para servicios más transitorios, como instancias de frontend.
❑  
Usa referencias. Las referencias se deben usar para los valores que no se definan hasta que se cree un recurso, como el selfLink, la dirección IP o el ID generado por el sistema de un recurso. Si no hay referencias, Deployment Manager crea todos los recursos en paralelo, por lo que no se garantiza que los recursos dependientes se creen en el orden correcto. Si usas referencias, se aplicará el orden en el que se crean los recursos.
❑  
Previsualiza tus implementaciones para evaluar cómo afectará a tu implementación la actualización. Deployment Manager no crea instancias de recursos reales cuando previsualizas una configuración, sino que amplía la configuración completa y crea recursos de "shell". De esta forma, puedes ver los cambios en tu implementación antes de confirmarlos.
❑  
Consulta los métodos de la API de un recurso concreto para saber qué implica llevar a cabo una actualización. Define políticas de actualización al actualizar un despliegue para controlar cómo aplica Deployment Manager cada actualización.
❑  
Usa etiquetas para tus recursos. Si los recursos que estás definiendo admiten etiquetas, úsalas para etiquetar tus recursos. Las etiquetas pueden ayudar a categorizar los recursos que pertenecen a diferentes implementaciones y también son una forma de distinguir en qué fase se encuentran los recursos, por ejemplo, si un recurso es compatible con un entorno de producción o de prueba.

Gestionar el tamaño de tus despliegues

Deployment Manager puede operar con un gran número de recursos, sujeto a límites de cuota. Si quieres reducir el tiempo que se tarda en crear, actualizar o eliminar tus implementaciones, puedes reducir el número de recursos de cada implementación.

❑  
Si un grupo de recursos no depende de ningún recurso fuera de ese grupo, puedes moverlo a una implementación independiente. Por ejemplo, si tu implementación contiene varias plantillas, puedes empaquetar cada una de ellas como una implementación independiente.
❑  
Elimina los recursos innecesarios de tu configuración. Si necesitas más recursos más adelante, puedes añadirlos a tu implementación en ese momento.
❑  
Si quiere, puede limitar sus implementaciones a 1000 recursos o menos.

Permisos

De forma predeterminada, Deployment Manager usa las credenciales de la cuenta de servicio de las APIs de Google para autenticarse en otras APIs. La cuenta de servicio de las APIs de Google se ha diseñado específicamente para ejecutar procesos internos de Google en tu nombre.

Si quiere dar acceso a otros usuarios a su proyecto de Deployment Manager, debe asignarles un rol de gestión de identidades y accesos que tenga los permisos adecuados para usar Deployment Manager. Hay varios roles de gestión de identidades y accesos predefinidos que puedes usar para determinar el nivel de acceso que tiene un usuario para llamar a Deployment Manager.

❑  
Usa roles de gestión de identidades y accesos para restringir los permisos que se conceden a los usuarios para usar Deployment Manager.
❑  
Si quiere que los usuarios puedan acceder a los recursos creados por Deployment Manager, concédales los roles que necesiten para usar los recursos, pero no les conceda permisos para implementar recursos directamente.
❑  
Si asignas el rol propietario a un principal, podrá modificar la política de gestión de identidades y accesos. Por lo tanto, solo debes asignar el rol de propietario si la entidad tiene un propósito legítimo para gestionar la política de gestión de identidades y accesos, ya que tu política contiene datos sensibles de control de acceso. Si solo un número mínimo de usuarios gestiona la cuenta, se simplificarán las auditorías que tengas que realizar.
❑  
Deployment Manager usa la cuenta de servicio de las APIs de Google para crear y gestionar tus recursos. Si usas Deployment Manager para gestionar recursos críticos, como roles de gestión de identidades y accesos personalizados, debes asignar roles de gestión de identidades y accesos adicionales a la cuenta de servicio predeterminada de las APIs de Google. Por ejemplo, si quieres usar Deployment Manager para crear y gestionar roles de gestión de identidades y accesos personalizados, debes añadir el rol Administrador de roles a la cuenta de servicio de las APIs de Google.

Para obtener una descripción general de la cuenta de servicio de las APIs de Google, consulta el artículo Cuentas de servicio gestionadas por Google.

Para ver los pasos para asignar roles a una cuenta de servicio, consulta el artículo sobre cómo conceder roles a cuentas de servicio.

Automatización

También puedes automatizar la creación de proyectos y de los recursos que contienen. De esta forma, puedes adoptar un enfoque de infraestructura como código para el aprovisionamiento de proyectos. Este enfoque ofrece muchas ventajas, como las siguientes:

  • Permite que se cumplan los requisitos de la empresa al proporcionar proyectos a los equipos que necesitan acceder a los recursos. Google Cloud
  • Proporciona una serie de entornos de proyectos predefinidos que se pueden aprovisionar de forma rápida y sencilla.
  • Usa el control de versiones para gestionar la configuración de tu proyecto base.
  • Ten la certeza de que estás implementando configuraciones de proyectos reproducibles y coherentes.
  • Incorpora la creación de proyectos como parte de un proceso de aprovisionamiento automatizado.
❑  
Automatiza la creación de proyectos usando las plantillas disponibles en GitHub como punto de partida.

Integración continua (CI) y despliegue continuo (CD)

Usa Deployment Manager como parte de tu flujo de procesamiento de CI/CD.

❑  
No uses un flujo de procesamiento de CI/CD para crear y eliminar proyectos de prueba y de control de calidad completos.
  • Puedes destruir instancias de VM o recursos que puedan generar costes adicionales, pero te recomendamos que conserves los recursos reutilizables que puedan tardar en recrearse, ya que eliminarlos podría afectar negativamente al tiempo que se tarda en completar tus pipelines de compilación. No se aplican costes por configurar redes, subredes ni reglas de cortafuegos.
  • Ten en cuenta que, si eliminas un proyecto, seguirá formando parte de tu cuota de proyectos durante unos días hasta que se elimine por completo. Esto también significa que no puedes volver a usar el nombre del proyecto.
  • Deployment Manager te permite eliminar fácilmente recursos de un proyecto para que no alcances las cuotas de recursos.
❑  
Usa Deployment Manager para crear las partes con estado del proyecto y la configuración de red, e implementa estos elementos fuera del proceso de integración continua y entrega continua como parte de la configuración inicial. Una vez finalizadas las pruebas, puedes eliminar las implementaciones que solo contengan recursos sin estado que se hayan implementado como parte de la canalización.
❑  
Como parte del proceso de integración y entrega continuas, usa una configuración independiente para desplegar recursos en tus proyectos de prueba y de control de calidad. Una vez que hayas terminado las pruebas, puedes usar Deployment Manager para eliminar los recursos de tus proyectos de prueba y de control de calidad.
Implementaciones de prueba. Gracias a la posibilidad de incorporar el aprovisionamiento de recursos como parte de un flujo de procesamiento de CI/CD, Deployment Manager te permite tratar la configuración de tu proyecto como código que puedes probar fácilmente y reproducir copias coherentes del entorno de producción actual o del entorno actual con los cambios aplicados para hacer pruebas con confianza.
❑  
Usa el control de versiones. Usar un sistema de control de versiones como parte del proceso de desarrollo de tus implementaciones te permite hacer lo siguiente:
  • Volver a una configuración anterior que funcionaba correctamente.
  • Proporcionar un registro de auditoría de los cambios.
  • Usar la configuración como parte de un sistema de implementación continua.