En esta página se describen las prácticas recomendadas para crear implementaciones mediante Google Cloud Deployment Manager. Está diseñada para usuarios familiarizados con Deployment Manager, y no te enseñará a utilizar Deployment Manager.
Si acabas de empezar a usar Deployment Manager, te recomendamos que consultes la Guía de inicio rápido.
Administrar recursos
|
❑
Después de crear un recurso como parte de una implementación, usa Deployment Manger si necesitas modificarlo.
Si modificas un recurso sin usar Deployment Manager, como con la consola de Google Cloud o
gcloud, es posible que veas errores si intentas modificar el recurso en tu implementación original.
Si deseas quitar un recurso de una implementación sin borrar el recurso, sigue estos pasos:
|
|
❑
Si tienes instancias de Compute Engine en tu implementación y deseas agregar discos persistentes a las instancias, define el disco por separado de la instancia a fin de que puedas administrarlo 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 deseas crear y administrar clústeres privados de Google Kubernetes Engine (GKE) con Deployment Manager, configura las siguientes opciones
privateClusterConfig:
enablePrivateNodes: true
enablePrivateEndpoint: true
# Configure the IP range for the hosted master network
masterIpv4CidrBlock: IP_RANGE
ipAllocationPolicy:
useIpAliases: true
createSubnetwork: true
Para conocer los requisitos y las consideraciones adicionales cuando creas un clúster privado con GKE, lee Configura un clúster privado. |
Incluye credenciales en tu implementación
|
❑
Deployment Manager oculta algunos campos relacionados con las credenciales de las propiedades en tu configuración de YAML. Este ocultamiento se basa en la clave de la propiedad. En el siguiente ejemplo, se muestra un ocultamiento:
# 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, la credencial se oculta de los archivos resultantes de configuración y diseño expandidos, pero aún se pueden ver en el archivo de importación original. Por este motivo, te recomendamos que coloques todas las credenciales que pretendes mantener en secreto en tu configuración YAML de nivel superior. Puedes hacer referencia a ellas desde allí mediante las propiedades de plantilla.
|
|
❑
Cualquier credencial incluida en un par clave-valor dentro de un archivo YAML o una lista de elementos no se ocultará, como en el siguiente ejemplo. Te recomendamos que no proporciones credenciales a Deployment Manager como pares clave-valor en los archivos YAML o las listas de elementos por este motivo.
# 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
|
Compilar plantillas
|
❑
A fin de acelerar la definición de tus plantillas, considera comenzar con las plantillas de muestra listas para la producción del proyecto de Cloud Foundation Toolkit.
|
|
❑
Si tienes requisitos de infraestructura complejos, como la necesidad de crear varios entornos, lee el instructivo y las muestras para usar Deployment Manager a gran escala.
|
|
❑
Usa Python para compilar tus plantillas.
Puedes usar Python o Jinja2 para crear plantillas. Es más fácil comenzar con Jinja, pero Python es más flexible para implementaciones complejas en las que puedes tener muchos recursos divididos en múltiples entornos.
|
|
❑
Estructura tu archivo de configuración (el archivo YAML) de manera que solo use un tipo y una plantilla de nivel superior como ese tipo para llamar a las otras plantillas. Si adoptas esta práctica, es más sencillo transformar 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 utilizar una plantilla en particular. Cuando definen un esquema y buscan que otros revisen los requisitos definidos en un esquema, tus usuarios podrán entender fácilmente qué propiedades son configurables o cuáles se requieren para la plantilla en cuestión. Esto ayuda a que los usuarios utilicen 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 las propiedades de la plantilla y los resultados.
El uso de propiedades y resultados te permite pasar variables como la zona, el tamaño de la máquina, la cantidad de máquinas o el estado de la app (prueba, producción o etapa de pruebas) en tus plantillas y obtener valores de salida como la dirección IP y la
selfLink a una instancia de VM. Las propiedades y los resultados te permiten que tus plantillas sean flexibles para poder reutilizarlas sin modificaciones en las plantillas subyacentes.
|
|
❑
Usa archivos de plantillas individuales que importas en tu archivo de configuración principal. Esto te brindará una forma más manejable de trabajar con las configuraciones.
|
|
❑
Divide tus configuraciones en unidades lógicas. Por ejemplo, crea configuraciones separadas para cada servicio con estado, como bases de datos y depósitos, y configuraciones para servicios más transitorios, como instancias frontend.
|
|
❑
Usa references.
Las referencias deben usarse para valores no definidos hasta que se crea un recurso, como el
selfLink, la dirección IP o el ID generad por el sistema de un recurso. Sin referencias, Deployment Manager crea todos los recursos en paralelo, por lo que no hay garantía de que los recursos dependientes se creen en el orden correcto. El uso de referencias haría cumplir el orden en el que se crean los recursos.
|
|
❑
Obtén una vista previa de las implementaciones para evaluar cómo una actualización afectará tu implementación.
Deployment Manager no ejecuta los recursos reales cuando se efectúa la vista previa de la configuración, sino que expande la configuración total y crea recursos “shell” en su lugar. Esto te brinda la oportunidad de ver los cambios en tu implementación antes de comprometerte con ella.
|
|
❑
Verifica los métodos de la API del recurso para comprender lo que implica realizar una actualización. Establece políticas de actualización cuando actualices una implementación para controlar la forma en la que Deployment Manager aplica cada actualización.
|
|
❑
Usa etiquetas para tus recursos. Si los recursos que estás definiendo son compatibles con las etiquetas, úsalas para etiquetar tus recursos. Las etiquetas pueden servir para categorizar recursos que pertenecen a implementaciones diferentes y también son una forma de distinguir en qué etapa podría estar el recurso, por ejemplo, si un recurso es compatible con un entorno de producción o de prueba.
|
Administra el tamaño de las implementaciones
Deployment Manager puede operar en una gran cantidad de recursos, sujeto a los límites de cuota. Si deseas reducir la cantidad de tiempo que lleva crear, actualizar o borrar tus implementaciones, puedes reducir la cantidad de recursos dentro de cada implementación individual.
|
❑
Si un grupo de recursos no depende de ningún recurso fuera de ese grupo, puedes mover ese grupo de recursos a una implementación independiente. Por ejemplo, si tu implementación contiene varias plantillas, puedes empaquetar cada plantilla como una implementación independiente.
|
|
❑
Quita los recursos innecesarios de la configuración. Si necesitas más recursos más adelante, puedes agregar más recursos a tu implementación en ese momento.
|
|
❑
De manera opcional, limita tus implementaciones a 1,000 recursos o menos.
|
Permisos
De forma predeterminada, Deployment Manager utiliza las credenciales de la cuenta de servicio de las API de Google para autenticarse en otras API. La cuenta de servicio de las API de Google está diseñada específicamente para ejecutar procesos internos de Google en tu nombre.
Cuando deseas otorgar acceso a otros usuarios a tu proyecto de Deployment Manager, debes otorgarles una función IAM con los permisos correspondientes para usar Deployment Manager. Existen diferentes funciones IAM predefinidas que puedes usar a fin de determinar cuánto acceso tiene un usuario para llamar a Deployment Manager.
|
❑
Utiliza funciones de IAM a fin de restringir qué permisos se otorgan a los usuarios para usar Deployment Manager.
|
|
❑
Si deseas que los usuarios puedan acceder a los recursos que crea Deployment Manager, otórgales las funciones que necesitan para usar los recursos, pero no les otorgues los permisos a fin de implementar los recursos directamente.
|
|
❑
La concesión de la función de propietario a un principal le permitirá modificar la política de IAM. Por lo tanto, otorga la función de propietario solo si el principal tiene un propósito legítimo para administrar la política de IAM, ya que tu política contiene datos de control de acceso confidenciales. Tener un conjunto mínimo de usuarios administrados simplificará cualquier auditoría que tengas que hacer.
|
|
❑
Deployment Manager usa la cuenta de servicio de las API de Google a fin de crear y administrar tus recursos. Si usas Deployment Manager para administrar recursos críticos, como funciones personalizados de IAM, debes asignar funciones adicionales de IAM a la cuenta de servicio predeterminada de las API de Google. Por ejemplo, si deseas usar Deployment Manager a fin de crear y administrar funciones IAM personalizadas, debes agregar la función Administrador de funciones a la cuenta de servicio de las API de Google.
Para obtener una descripción general de la cuenta de servicio de las API de Google, consulta Cuentas de servicios administradas por Google. Si deseas conocer los pasos a fin de asignar funciones a la cuenta de servicio, consulta Asigna funciones a las cuentas de servicio. |
Automatización
Considera la opción de automatizar la creación de proyectos, así como la de recursos contenidos dentro de proyectos. Esto te permite adoptar un enfoque de infraestructura como código para el aprovisionamiento de proyectos. Este enfoque brinda muchos beneficios, como la capacidad de realizar las siguientes acciones:
- Permitir el cumplimiento de requisitos corporativos a la hora de proporcionar proyectos a los equipos que necesitan acceso a los recursos de Google Cloud
- Proporcionar diferentes entornos de proyecto predefinidos que pueden aprovisionarse rápido y fácilmente.
- Utilizar el control de versiones para administrar la configuración de tu proyecto base.
- Confiar en que estás implementando configuraciones de proyectos reproducibles y coherentes.
- Incorporar la creación de proyectos como parte de un proceso de aprovisionamiento automatizado.
|
❑
Automatiza la creación de proyectos con las plantillas disponibles en GitHub como punto de partida.
|
Integración continua (IC)/Implementación continua (CD)
Usa Deployment Manager como parte de tu canalización de IC/CD.
|
❑
No uses una canalización de IC/CD para crear y borrar proyectos completos de prueba y control de calidad.
|
|
❑
Usa Deployment Manager a fin de crear las partes con estado de la configuración de proyecto y de red y para implementarlas fuera del proceso de IC/CD como parte de la configuración inicial. Una vez que la etapa de prueba termine, puedes quitar las implementaciones que contengan solo recursos sin estado que se implementaron como parte de la canalización.
|
|
❑
Como parte del proceso de IC/CD, usa una configuración diferente a fin de implementar recursos en tus proyectos de prueba y control de calidad. Una vez terminada la etapa de pruebas, puedes usar Deployment Manager a fin de quitar los recursos de tus proyectos de prueba y control de calidad.
|
| Implementaciones de prueba. Con la capacidad de incorporar aprovisionamiento de recursos como parte de la canalización de IC/CD, Deployment Manager te permite tratar la configuración de tu proyecto como un código que puedes probar y reproducir copias coherentes del entorno de producción actual o el entorno actual con cambios aplicados a fin de realizar pruebas de confianza. |
|
❑
Usa el control de versiones. Usar un sistema de control de versiones como parte del proceso de desarrollo para tus implementaciones te permite realizar las siguientes acciones:
|