Principes de base de Deployment Manager

Les éléments présentés ci-dessous sont les composants fondamentaux de Deployment Manager.

Configuration

Une configuration décrit toutes les ressources que vous souhaitez utiliser pour un déploiement unique. Il s'agit d'un fichier écrit en syntaxe YAML qui répertorie chacune des ressources que vous souhaitez créer, ainsi que les propriétés de chaque ressource. Une configuration doit comporter une section resources:, suivie de la liste des ressources à créer.

Chaque ressource doit contenir les trois éléments suivants :

  • name : une chaîne définie par l'utilisateur pour identifier cette ressource, par exemple my-vm, project-data-disk, the-test-network.
  • type : le type de la ressource déployée, par exemple compute.v1.instance, compute.v1.disk. Les types de ressources de base sont répertoriés et décrits dans la documentation Types de ressources acceptés.
  • properties : les paramètres de ce type de ressource. Ils doivent correspondre aux propriétés du type, par exemple zone: asia-east1-a, boot: true.

Voici un exemple de configuration :

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

Modèles

Une configuration peut contenir des modèles. Les modèles correspondent aux différentes parties d'un fichier de configuration qui a été décomposé en blocs de construction individuels. Une fois que vous avez créé un modèle, vous pouvez le réutiliser pour différents déploiements si cela est nécessaire. De même, si vous écrivez plusieurs configurations partageant des propriétés très similaires, vous pouvez extraire les parties communes à ces configurations dans des modèles pour gagner du temps. Les modèles sont beaucoup plus flexibles que les fichiers de configuration uniques. Ils facilitent la portabilité des informations de configuration entre différents déploiements.

Un fichier de modèle est écrit en Python ou en Jinja2. Le système Deployment Manager interprète chaque modèle de manière récursive et insère les résultats dans le fichier de configuration. Ainsi, l'interprétation de chaque modèle entraîne la même syntaxe YAML pour les ressources que celle définie ci-dessus pour le fichier de configuration lui-même.

Pour créer un modèle simple, consultez la page Créer un modèle de base.

Les configurations sont décrites sous une forme entièrement développée ou non développée. Une configuration entièrement développée décrit toutes les ressources et propriétés du déploiement, y compris tous les éléments contenus dans les fichiers de modèles importés. Vous pouvez par exemple décrire une configuration en utilisant un modèle sous une forme non développée, comme ceci :

imports:
- path: vm_template.jinja

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

Une fois développé, votre fichier de configuration afficherait le contenu de tous vos modèles, comme ceci :

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

Ressource

Une ressource représente une ressource d'API unique. Il peut s'agir d'une ressource d'API fournie par un type de base géré par Google ou d'une ressource d'API fournie par un fournisseur de type. Par exemple, une instance Compute Engine est une ressource unique, une instance Cloud SQL également, etc.

Pour spécifier une ressource, vous devez fournir un type pour cette ressource. Reportez-vous à la section Types ci-dessous pour plus d'informations sur les types.

Types

Pour créer une ressource dans Deployment Manager, vous devez spécifier un type. Un type peut représenter une ressource d'API unique (type de base), ou un ensemble de ressources (type composite). L'élément représenté sera créé dans le cadre de votre déploiement.

Par exemple, pour créer une instance de VM Compute Engine, vous devez spécifier le type de base correspondant, comme vous l'avez fait dans votre fichier de configuration :

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

Deployment Manager fournit un ensemble de types de base gérés par Google que vous pouvez utiliser immédiatement. Vous pouvez trouver la liste de ces types dans la documentation Types de ressources et propriétés pris en charge.

Types de base et fournisseurs de type

Un type de base crée une seule ressource primitive. Par exemple, les types de base gérés par Google sont compute.v1.instance, storage.v1.bucket et sqladmin.v1beta4.database, qui sont respectivement desservis par l'API Compute Engine V1, l'API Cloud Storage V1 et l'API Admin Cloud SQL v1beta4.

Les types de base sont pris en charge par une API RESTful gérant les opérations CRUD (création, lecture, mise à jour et suppression). Vous pouvez également créer des types de base supplémentaires en ajoutant un fournisseur de type si les types appartenant à Google ne répondent pas à vos besoins. La création d'un fournisseur de types expose toutes les ressources d'une API en tant que types de base que vous pouvez utiliser. Pour créer un fournisseur de type, vous devez d'abord fournir un document descripteur d'API. Il peut s'agir d'une spécification OpenAPI ou d'un document Google Discovery. Vous devez ensuite ajuster tous les mappages d'entrées nécessaires pour l'API, puis enregistrer le type avec Deployment Manager. Une fois que le fournisseur est créé, toutes les personnes ayant accès à votre projet peuvent utiliser les types générés par celui-ci.

Lorsque vous ajoutez un fournisseur de type, toutes les ressources fournies par l'API et prises en charge par une interface RESTful gérant les opérations CRUD (création, lecture, mise à jour et suppression) sont exposées en tant que types que vous pouvez utiliser dans votre déploiement.

La création de votre propre fournisseur de types constitue un scénario avancé. Nous vous recommandons de ne le faire que si vous maîtrisez parfaitement l'API que vous souhaitez intégrer.

Pour apprendre à créer un fournisseur de types, consultez la page Intégrer une API à Deployment Manager.

Selon le type de base que vous souhaitez appeler dans vos modèles ou configurations, vous devez utiliser l'une des syntaxes suivantes.

  • Pour les types de base gérés par Google, utilisez :

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

    Par exemple, compute.v1.instance.

  • Pour les fournisseurs de types gérés par Google (version bêta), utilisez :

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

    Pour obtenir la liste des fournisseurs de types compatibles, consultez la page Fournisseurs de types Google Cloud compatibles.

  • Pour les types de base fournis par un fournisseur de types, utilisez :

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

    Où [COLLECTION] est le chemin d'accès à la ressource d'API à déployer.

Types composites

Un type composite contient un modèle ou plusieurs modèles préconfigurés pour fonctionner ensemble. Lorsqu'ils sont utilisés dans le cadre d'un déploiement, ces modèles peuvent être étendus à un ensemble de types de base. Les types composites sont essentiellement des modèles hébergés que vous pouvez ajouter à Deployment Manager. Vous pouvez créer des types composites pour des solutions courantes afin de pouvoir réutiliser ces solutions facilement, ou encore créer des configurations complexes que vous pourrez réutiliser ultérieurement.

Par exemple, vous pouvez créer un type composite qui déploie un groupe d'instances gérées avec équilibrage de la charge réseau. Un équilibreur de charge réseau nécessite plusieurs ressources Google Cloud et une certaine configuration entre les ressources. Vous pouvez donc définir ces ressources une seule fois dans une configuration et enregistrer le type auprès de Deployment Manager. Suite à cela, toutes les personnes ayant accès à votre projet pourront appeler ce type et le déployer dans leurs configurations.

Pour appeler un type composite dans votre configuration, utilisez la syntaxe suivante :

type: [PROJECT_ID]/composite:[TYPE_NAME]

Exemple :

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

Pour savoir comment créer un type composite, reportez-vous à la rubrique Ajouter un type composite à Deployment Manager.

Fichier manifeste

Un fichier manifeste est un objet en lecture seule qui contient la configuration d'origine que vous avez fournie (y compris les modèles importés), ainsi que la liste de ressources entièrement développée créée par Deployment Manager. Chaque fois que vous mettez à jour un déploiement, Deployment Manager génère un nouveau fichier manifeste pour refléter le nouvel état du déploiement. Il peut être utile de consulter le fichier manifeste lorsque vous tentez de résoudre un problème rencontré avec un déploiement.

Pour plus d'informations, reportez-vous à la rubrique Consulter un fichier manifeste.

Déploiement

Un déploiement est une collection de ressources qui sont déployées et gérées ensemble par le biais d'une configuration.

Pour plus d'informations, consultez la rubrique Créer un déploiement.

Étapes suivantes