Диспетчер развертывания Google - пример BigTable

Я пробовал rel="nofollow. > пример приведен в проекте Google Deployment Manager на GitHub.

Это работает, но я не уверен, какова цель создания трех instances с именами instance_create, instance_update и instance_delete.

Например, взято по ссылке:

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']
      }
}
What is the purpose of `action` and `metadata`.`runtimePolicy`? I have tried to find it in the documentation but failed miserably. Why there are three `BigTable` instances there?

google-cloud-platform google-deployment-manager google-cloud-bigtable
person Navarro    schedule 10.01.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вы правы, в документации отсутствует информация, которая бы ответила на ваши вопросы по этим параметрам.

Однако это помогает узнать, что происходит в примере Depoyment Manager, который вы связали.

Прежде всего, следующая строка в config.yaml - вот где все усложняется:

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

Эта строка будет вызывать файл bigtable.py python, который устанавливает тип ресурса развертывания, который находится в нем, в функции GenerateConfig. Узнайте, как это делается, здесь.

Ресурсы возвращаются как {'resources': resources} в конце, поскольку переменная ресурсов представляет собой список шаблоны, созданные там.

Эти шаблоны имеют разные идентификаторы имен, которые задаются тегом "name". Таким образом, вы не создаете в этом файле три разных экземпляра с именами instance_create, instance_update и instance_delete, но вы создаете три шаблона с этими именами, которые позже будут добавлены в список resources и позже возвращены в config.yaml resources.type ярлык. Затем эти шаблоны будут последовательно построены и выполнены менеджером развертывания после использования команды create. Обратите внимание, что они могут отображаться не по порядку, это связано с тем, что не используется схему.

Эту структуру легче увидеть в формате файла .yaml, например, созданного с помощью jinja, опубликованный вами шаблон будет выглядеть следующим образом:

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>

Обратите внимание, что параметры в properties - это поля в теле запроса к bigtableadmin.projects.instances.create (который содержит параметры объекта кластеров и параметры объекта экземпляра). Обратите внимание, что InstanceId в свойствах всегда один и тот же, поэтому экземпляр BigTable, для которого шаблоны выполняют вызовы, всегда один и тот же.

Дело в том, что не только связанный вами пример создает различные шаблоны для запуска в одном скрипте, но и тип ресурса для каждого шаблона - это вызов API BigTable.

Обычно ресурсы шаблона указываются с помощью тега type, но поскольку вы вызываете ресурс, который непосредственно выполняет вызов API (т.е. вместо того, чтобы просто указывать gcp-types/bigtableadmin-v2, вы указываете bigtableadmin-v2:bigtableadmin.projects.instances.create), используется тег action. Я нигде не обнаружил такой разницы в использовании, но ее нужно указать именно так. Вы узнаете, вызываете ли вы «конечную точку» API напрямую, если ресурс заканчивается на create / update / delete.

Наконец, я исследовал на своей стороне, и metadata.runtimePolicy привязан к тому факту, что тип ресурса - это вызов API (как в предыдущем пункте). Еще раз, я нигде не нашел этого документированного. Однако, поскольку это является обязательным требованием, вам всегда нужно будет указывать правильное значение в этом поле. По сути, это сводится к тому, чтобы установить metadata.runtimePolicy на эти значения, в зависимости от того, какой тип API-вызова вы выполняете:

create -> ['CREATE']

update -> ['UPDATE_ON_CHANGE']

delete -> ['DELETE']

Подведение итогов:

  • Вы создаете не три разных экземпляра, а три разных шаблона, которые работают с одним и тем же экземпляром BigTable.
  • Вам нужно изменить флаг ресурса type на action, если вы вызываете конечную точку API (создание / обновление / удаление), вместо того, чтобы просто именовать базовый API.
  • Значение metadata.runtimePolicy является обязательным при вызове одной из вышеупомянутых конечных точек.
person Joan Grau Noël    schedule 10.01.2019