2 votes

Google Deployment Manager - Exemple de BigTable

J'ai essayé este exemple fourni dans le projet GitHub Google's Deployment Manager.

Cela fonctionne, mais je ne suis pas sûr de l'objectif de créer trois instances nommé instance_create , instance_update y instance_delete .

Par exemple, tiré du lien :

instance_create = {
      'name':
          'instance_create',
      'action':
          'gcp-types/bigtableadmin-v2:bigtableadmin.projects.instances.create',
      'properties': {
          'parent': project_path,
          'instanceId': instance_name,
          'clusters': copy.deepcopy(initial_cluster),
          'instance': context.properties['instance']
      },
      'metadata': {
          'runtimePolicy': ['CREATE']
      }
}

Quel est le but de `action` et `metadata`.`runtimePolicy` ? J'ai essayé de le trouver dans la documentation mais j'ai échoué lamentablement. Pourquoi y a-t-il trois instances de `BigTable` ?

1voto

Joan Grau Noël Points 2756

Vous avez raison, il manque dans la documentation les informations qui répondraient à vos questions concernant ces paramètres.

Cependant, il est utile de savoir ce qui se passe dans l'exemple de Depoyment Manager que vous avez cité.

Tout d'abord, c'est à la ligne suivante du fichier config.yaml que les choses se compliquent :

resources:
- name: my-bigtable
  type: bigtable.py

Cette ligne fera un appel à la fonction bigtable.py qui définit le type de ressources du déploiement en fonction de celles qui s'y trouvent, sous l'onglet GenerateConfig fonction. Voir comment cela se passe aquí .

Les ressources sont renvoyées sous forme de {'resources': resources} à la fin de celui-ci, étant la variable ressources une liste de modèles créé là-bas.

Ces modèles ont des identificateurs de nom différents, qui sont définis par l'attribut "name" tag. Ainsi, vous ne créez pas trois instances différentes portant le nom de instance_create , instance_update y instance_delete dans ce fichier, mais vous créez trois modèles avec ces noms, qui seront plus tard ajoutés au fichier resources et renvoyés ensuite dans le fichier config.yaml resources.type étiquette. Ces modèles seront ensuite construits et exécutés séquentiellement par le gestionnaire de déploiement, une fois la commande create utilisée. Notez qu'ils peuvent apparaître dans le désordre, ceci est dû au fait que ne pas utiliser de schéma .

Il est plus facile de voir cette structure dans une .yaml par exemple, construit avec jinja le modèle que vous avez posté serait :

resources:
- action: gcp-types/bigtableadmin-v2:bigtableadmin.projects.instances.create
  name: instance_create
  metadata:
    runtimePolicy:
    - CREATE
  properties:
    clusters:
      initial:
        defaultStorageType: HDD
        location: projects/<PROJECT_ID>/locations/<PROJECT_LOCATION>
        serveNodes: 4
    instance:
      displayName: My BigTable Instance.
      type: PRODUCTION
    instanceId: my-instance
    parent: projects/<PROJECT_ID>

Remarquez que les paramètres sous properties sont les dans le corps de la demande pour bigtableadmin.projects.instances.create. (ce qui revient à imbriquer un paramètres de l'objet cluster et un paramètres de l'objet d'instance ). Notez que l'InstanceId sous les propriétés est toujours le même, donc l'instance BigTable, sur laquelle les modèles font les appels, est toujours la même.

Le problème est que, non seulement l'exemple que vous avez lié crée plusieurs modèles à exécuter dans le même script, mais que le type de ressource pour chaque modèle est un appel à l'API BigTable .

Normalement, les ressources du modèle sont spécifiées avec l'option type mais comme vous appelez une ressource qui exécute directement un appel d'API (c'est-à-dire qu'au lieu de simplement spécifier gcp-types/bigtableadmin-v2 vous spécifiez bigtableadmin-v2:bigtableadmin.projects.instances.create ), le action est utilisée. Je n'ai pas trouvé cette différence d'utilisation documentée nulle part, mais elle doit être spécifiée ainsi. Vous saurez si vous appelez directement un "point de terminaison" d'API si la ressource se termine par create/update/delete.

Enfin, le j'ai enquêté dans mon côté, et le metadata.runtimePolicy est lié au fait que le type de ressource est un appel d'API (comme dans le point précédent). Encore une fois, je n'ai pas trouvé de documentation à ce sujet. Cependant, comme il s'agit d'une exigence, vous devrez toujours définir la valeur correcte dans ce champ. En gros, cela revient à avoir metadata.runtimePolicy à ces valeurs, en fonction du type d'appel d'API que vous effectuez :

create -> ['CREATE']

update -> ['UPDATE_ON_CHANGE']

delete -> ['DELETE']

Résumant :

  • Vous ne créez pas trois instances différentes, mais trois modèles différents, qui effectuent le travail sur la même instance BigTable.
  • Vous devez modifier la ressource type pour action si vous appelez un point de terminaison d'API (création/mise à jour/suppression), au lieu de simplement nommer l'API de base.
  • Le site metadata.runtimePolicy est nécessaire lors d'un appel vers l'un des points d'extrémité précédemment nommés.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X