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

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

0 голосов
/ 10 января 2019

Я пытался этот пример, предоставленный в проекте 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']
      }
}
Какова цель `action` и` metadata``runtimePolicy`? Я пытался найти его в документации, но с треском провалился. Почему там три экземпляра BigTable?

1 Ответ

0 голосов
/ 10 января 2019

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

Тем не менее, это помогает узнать, что происходит в приведенном вами примере с менеджером депозитов.

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

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

Эта строка будет вызывать файл Python bigtable.py, который устанавливает тип ресурса развертывания для того, который находится в нем, в функции 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, для которого шаблоны выполняют вызовы, всегда один и тот же.

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

Обычно ресурсы шаблона указываются с помощью тега 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 является обязательным при выполнении вызова к одной из вышеупомянутых конечных точек.
...