В Cloud Assembly с помощью тегов возможностей можно определить возможности развертывания для компонентов инфраструктуры. Вместе с ограничениями они служат основой для организации размещения в vRealize Automation.

Теги возможностей можно создавать в вычислительных ресурсах, облачных зонах, образах и картах образов, а также в сетях и профилях сетей. Страницы для создания этих ресурсов содержат параметры для создания тегов возможностей. Кроме того, для создания тегов возможностей в Cloud Assembly можно использовать страницу «Управление тегами». Теги возможностей в облачных зонах и профилях сети влияют на все ресурсы в этих зонах или профилях. Теги возможностей в хранилище или сетевых компонентах влияют только на те компоненты, к которым они применяются.

Как правило, теги возможностей могут определять такие характеристики, как расположение вычислительного ресурса, тип адаптера сети или уровень ресурса хранилища. Кроме того, они могут определять расположение или тип среды, а также любые другие вопросы, касающиеся бизнеса. Как и в общей стратегии тегирования, теги возможностей необходимо организовать логически с учетом бизнес-потребностей.

Cloud Assembly сопоставляет в ходе развертывания теги возможностей в облачных зонах с ограничениями в облачных шаблонах. Таким образом, при создании и использовании тегов возможностей необходимо предусматривать и планировать создание соответствующих ограничений облачных шаблонов, чтобы сопоставление выполнялось.

Например, в разделе, посвященном облачным зонам, в примере инфраструктуры WordPress из документации описано создание тегов dev и test для облачных зон OurCo-AWS-US-East и OurCo AWS-US-West. В данном учебнике эти теги указывают, что зона OurCo-AWS-US-East — это среда разработки, а зона OurCo-AWS-US_West — среда тестирования. Если создать аналогичные теги ограничений в облачных шаблонах, такие теги возможностей позволяют направлять развертывания в нужные среды.

Наследование тегов

Cloud Assembly использует наследование тегов, чтобы теги в облачных учетных записях выборочно переносились в другой связанный ресурс. В частности, если создать теги в облачной учетной записи, они также появятся во всех профилях хранилища и вычислительных ресурсах, которые связаны с этой облачной учетной записью.

Примечание: Поведение при распространении тегов не применяется к профилям хранилища. vRealize Automation не будет автоматически выбирать ограничение для профилей хранилища, поэтому пользователи должны вручную добавить требуемый тег ограничения, чтобы он был выбран и применен к профилям хранилища.

Следующий пример демонстрирует, как работает наследование тегов.

Вычислительные ресурсы

  • Кластер 1 с тегом cluster-1
  • Кластер 2 с тегом cluster-2
  • Кластер 3 с тегом cluster-3
Vm resoruce:
  properties:
    constraints:
      - tag: 'cluster-01'

Профили хранилища

  • Профиль 1 для кластера хранилища данных 1 с тегом storage-01
  • Профиль 2 для кластера хранилища данных 2 с тегом storage-02
  • Профиль 3 для кластера хранилища данных 3 с тегом storage-03
vm-resource:
  properties:
    storage:
      constraints:
        - tag: 'storage-01'

Учетная запись облачной службы

Облачная учетная запись vSphere со всеми тремя тегами: cluster-1, cluster-2 и cluster-3

При консолидации тегов в профилях хранилища и вычислительных ресурсах служба Cloud Assembly также учитывает теги уровня облачной учетной записи. Таким образом, действующими тегами во всех профилях хранилища и вычислительных системах являются cluster-1, cluster-2 и cluster-3. Поэтому, когда какой-либо из этих тегов предоставляется, как показано в предыдущем примере, все профили хранилища и вычислительные ресурсы могут быть размещены в любом из вычислительных узлов.

Любой тег должен применяться только на уровне облачной учетной записи, если он подходит для всех подчиненных ресурсов вычисления и хранения. Это поможет избежать неожиданных результатов и лишних тегов.