Información básica de Deployment Manager

Los siguientes componentes son los aspectos básicos de Deployment Manager.

Configuración

Una configuración describe todos los recursos que deseas para una sola implementación. Una configuración es un archivo escrito en la sintaxis YAML que enumera cada uno de los recursos que deseas crear y sus propiedades de recursos respectivas. Una configuración debe contener una sección resources: seguida de la lista de recursos para crear.

Cada recurso debe contener tres componentes:

  • name: una string definida por el usuario para identificar este recurso como, por ejemplo, my-vm, project-data-disk, the-test-network.
  • type: el tipo de recurso que se implementa como, por ejemplo, compute.v1.instance, compute.v1.disk. Los tipos de recursos de base se describen y enumeran en la documentación Tipos de recursos admitidos.
  • properties: los parámetros para este tipo de recurso. Deben coincidir con las propiedades del tipo como, por ejemplo, zone: asia-east1-a, boot: true.

Esta es una configuración de ejemplo:

resources:
- name: the-first-vm
  type: compute.v1.instance
  properties:
    zone: us-central1-a
    machineType: https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-a/machineTypes/f1-micro
    disks:
    - deviceName: boot
      type: PERSISTENT
      boot: true
      autoDelete: true
      initializeParams:
        sourceImage: https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/debian-7-wheezy-v20150423
    networkInterfaces:
    - network: https://www.googleapis.com/compute/v1/projects/myproject/global/networks/default
      accessConfigs:
      - name: External NAT
        type: ONE_TO_ONE_NAT

Plantillas

Una configuración puede contener plantillas, que son básicamente partes del archivo de configuración que se ha resumido en bloques de compilación individuales. Después de crear una plantilla, puedes volver a utilizarlas en todas las implementaciones según sea necesario. De manera similar, si necesitas volver a escribir configuraciones que comparten propiedades muy similares, puedes resumir las partes compartidas en plantillas. Las plantillas son mucho más flexibles que los archivos de configuración individuales y están diseñadas para admitir una portabilidad sencilla en todas las implementaciones.

Un plantilla es un archivo que se escribe en Python o Jinja2. El sistema Deployment Manager interpretará cada plantilla de manera recurrente y alineará los resultados con el archivo de configuración. Por lo tanto, la interpretación de cada plantilla debe resultar finalmente en la misma sintaxis YAML para los recursos como se definió anteriormente para el archivo de configuración.

Para crear una plantilla simple, lee Crear una plantilla básica.

Las configuraciones se describen como totalmente expandidas o no expandidas. Una configuración totalmente expandida describe todos los recursos y las propiedades de la implementación, lo que incluye cualquier contenido de los archivos de plantilla importados. Por ejemplo, deberás suministrar una configuración no expandida que utilice una plantilla como la que figura a continuación:

imports:
- path: vm_template.jinja

resources:
- name: vm-instance
  type: vm_template.jinja
  properties:
    zone: us-central1-a
    project: myproject

Una vez expandido, el archivo de configuración contendrá el contenido de todas las plantillas, de la siguiente manera:

resources:
- name: the-first-vm
  type: compute.v1.instance
  properties:
    zone: us-central1-a
    machineType: https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-a/machineTypes/f1-micro
    disks:
    - deviceName: boot
      type: PERSISTENT
      boot: true
      autoDelete: true
      initializeParams:
        sourceImage: https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/debian-7-wheezy-v20150423
        networkInterfaces:
        - network: https://www.googleapis.com/compute/v1/projects/myproject/global/networks/default
    accessConfigs:
    - name: External NAT
      type: ONE_TO_ONE_NAT

Recurso

Un recurso representa un recurso único de API. Este puede ser un recurso de API que proporcione un tipo de base administrado por Google o un recurso de API que suministre el proveedor de tipos. Por ejemplo, una instancia de Compute Engine es un recurso único, una instancia de Cloud SQL es un recurso único, y así sucesivamente.

Para especificar un recurso, proporciona un Tipo para esa instancia. Consulta la sección Tipos que figura a continuación para obtener más información sobre los tipos.

Tipos

Para crear un recurso en Deployment Manager, debes especificar un type. Un tipo puede representar un recurso de API único, conocido como tipo de base, o un conjunto de recursos, conocido como un tipo compuesto, que se creará como parte de la implementación.

Por ejemplo, para crear una instancia de VM de Compute Engine, especifica el tipo de base correspondiente, como en la configuración:

resources:
- name: the-first-vm
  type: compute.v1.instance # The type of resource to deploy
  ...

Deployment Manager ofrece una lista de tipos de base que mantiene Google y que puedes utilizar de inmediato. Puedes encontrar una lista de estos tipos en la documentación Propiedades y tipos de recursos admitidos.

Tipos de base y proveedores de tipos

Un tipo de base crea un recurso primitivo único. Por ejemplo, los tipos de base de Google incluyen compute.v1.instance, storage.v1.bucket y sqladmin.v1beta4.database. La API de Compute Engine V1, la API de Cloud Storage V1 y la API de Administrador de Cloud SQL v1beta4 correspondientes entregan estos tipos.

Una API de RESTful admite tipos de base que son compatibles con las operaciones de creación, lectura, actualización y eliminación (CRUD). También puedes crear tipos de base adicionales; para ello, agrega un proveedor de tipos si los tipos de Google por sí solos no satisfacen tus necesidades. La creación de un proveedor de tipos expone todos los recursos de una API como tipos de base que puedes utilizar. A fin de crear un proveedor de tipos, debes suministrar un documento del descriptor de API, que puede ser una especificación de OpenAPI o un Documento de Google Discovery, ajustar cualquier asignación de entrada necesaria para la API, y registrar el tipo con Deployment Manager. Una vez creado, tú y otros usuarios con acceso al proyecto pueden utilizar los tipos que proporciona el proveedor.

Cuando agregas un proveedor de tipos, todos los recursos que proporcionó la API y que son compatibles con una interfaz de RESTful, con operaciones de creación, lectura, actualización y eliminación (CRUD), se exponen como tipos que puedes usar en la implementación.

La creación de tu propio tipo es una situación avanzada y Google recomienda que lo hagas solo si estás muy familiarizado con la API que deseas integrar.

Para aprender a crear un proveedor de tipos, consulta Integrar con Deployment Manager.

Cuando llamas a un tipo de base en las plantillas o las configuraciones, utiliza una de las siguientes sintaxis según el tipo:

  • Para los tipos de base administrados por Google, utiliza:

    type: [API].[VERSION].[RESOURCE]
    

    Por ejemplo, compute.v1.instance.

  • Para los tipos de base que proporciona un proveedor de tipos, utiliza:

    type: [PROJECT_ID]/[TYPE_PROVIDER]:[COLLECTION]
    

    Donde [COLLECTION] es la ruta al recurso de la API que se implementará.

Tipos compuestos

Un tipo compuesto contiene una o más plantillas que están preconfiguradas para funcionar en conjunto. Estas plantillas finalmente se expanden a un conjunto de tipos de base cuando se implementan en una implementación. Los tipos compuestos son básicamente plantillas alojadas que puedes agregar a Deployment Manager. Puedes crear tipos compuestos para soluciones comunes a fin de que la solución sea fácilmente reutilizable o crear configuraciones complejas que puedes volver a utilizar en el futuro.

Por ejemplo, puedes crear un tipo compuesto que implemente un grupo de instancias administrado con balanceo de cargas de red. Un balanceador de cargas de red requiere varios recursos de Google Cloud Platform y cierta configuración entre recursos, por lo que puedes configurar estos recursos una vez y registrar el tipo con Deployment Manager. Después, tú y otros usuarios con acceso al proyecto pueden llamar a ese tipo y, a continuación, implementarlo en configuraciones futuras.

Para llamar a un tipo compuesto en la configuración, utiliza:

type: [PROJECT_ID]/composite:[TYPE_NAME]

Por ejemplo:

resources:
- name: my-composite-type
  type: myproject/composite:example-composite-type

Para aprender a crear un tipo compuesto, lee Agregar un tipo compuesto a Deployment Manager.

Manifiesto

Un manifiesto es un objeto de solo lectura que contiene la configuración original que proporcionaste, lo que incluye las plantillas importadas, así como la lista de recursos totalmente expandidos que creó Deployment Manager. Cada vez que actualizas una implementación, Deployment Manager genera un archivo de manifiesto nuevo para reflejar el estado nuevo de la implementación. A la hora de solucionar un problema con una implementación, es útil ver el manifiesto.

Para obtener más información, consulta Ver un manifiesto.

Implementación

Una implementación es una colección de recursos que se implementan y administran juntos mediante el uso de una configuración.

Para obtener más información, consulta Crear una implementación.

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Cloud Deployment Manager