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 que crear.

Cada recurso debe contener tres componentes:

  • name: una string definida por el usuario para identificar este recurso, como my-vm, project-data-disk, the-test-network.
  • type: el tipo de recurso que se implementa, como 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 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 archivo de plantilla se escribe en Python o Jinja2. El sistema de Deployment Manager interpretará cada plantilla de forma recursiva y, también, intercalará los resultados dentro del archivo de configuración. De esta forma, la interpretación de cada plantilla dará como resultado la misma sintaxis YAML para recursos que la definida antes para el archivo de configuración.

Para crear una plantilla simple, lee Crea 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 propiedad de Google incluyen compute.v1.instance, storage.v1.bucket y sqladmin.v1beta4.database, todos los cuales los entrega la API respectiva de Compute Engine V1, la API de Cloud Storage V1 y la API de administrador de Cloud SQL v1beta4.

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. Para crear un proveedor de tipos, debes proporcionar 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.

Crear un proveedor de tipos propio es una situación avanzada, y Google recomienda que solo lo hagas si estás muy familiarizado con la API que deseas integrar.

Para aprender a crear un proveedor de tipos, consulta Integra 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 proveedores de tipos administrados por Google (Beta), usa lo siguiente:

    type: gcp-types/[PROVIDER]:[RESOURCE]

    Puedes ver la lista de proveedores de tipos admitidos en la página Proveedores de tipos de Google Cloud admitidos.

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

    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 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 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