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.