Политики обрабатываются в соответствии с определением политики. В частности, если к одному развертыванию применимы несколько политик, область и уровень применения определяют, какая из них будет действовать.

Эта статья содержит общие сведения об обработке политик, а также дополнительную информацию о типах политик.

Ранжирование политик с учетом уровня организации и типа применения

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

Схема порядка ранжирования для обработки политик

Чтобы оценить политики, система сначала идентифицирует и ранжирует их.

  1. Имеются ли какие-либо жесткие политики на уровне организации или проекта? Если существуют жесткие и нежесткие политики, то учитываются только жесткие политики и выполняется их ранжирование. Если есть только нежесткие политики, то ранжироваться будут только они.
  2. Ранжирование всех жестких или всех нежестких политик упорядочивается по области, при этом организационные политики имеют более высокий ранг, чем политики проекта.
  3. Окончательная отличительная характеристика — дата создания, причем более старая дата имеет более высокий ранг, чем более новая.

Обработка политик с учетом уровня организации и типа применения

Политики оцениваются, ранжируются и при необходимости объединяются для создания единой эффективной политики. Эффективная политика дает необходимые результаты, но не всегда является той или иной именованной политикой.

Этот раздел включает следующие примеры.

  • Политики аренды
  • Политики действий по регулярному обслуживанию

Просмотрите следующие примеры политик аренды.

Пример ранжирования политик аренды.

После определения политик, которые нужно учитывать и ранжировать, выполняется оценка политик, чтобы выявить порядок объединения.

  • Политика с наивысшим рангом становится базовой. Политика второго уровня применяется в дополнение к ней и т. д.
  • Если политика несовместима с предыдущими политиками, она не рассматривается. Например, если значения выше, чем в предыдущих политиках.
  • Любая отклоненная политика игнорируется. Чтобы увидеть, какая политика применяется, выберите Содержимое и политики > Политики > Применение, выберите развертывание и просмотрите примечания к решению.
Пример обработки и объединения ранжированных политик.

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

В этом примере процесс слияния исключает политику 2 из рассмотрения, так как ее значения выше, чем у политики 1.

Затем политика 3 оценивается по сравнению с политикой 1. Значения аренды и общей аренды в политике 3 меньше, чем в политике 1, поэтому эти значения, а также период отсрочки становятся частью действующей политики.

Просмотрите следующие примеры политик действий по регулярному обслуживанию.

Пример ранжирования политик действий по регулярному обслуживанию.

После определения политик, которые нужно учитывать и ранжировать, выполняется оценка политик, чтобы выявить порядок объединения.

  • Политика с наивысшим рангом становится базовой. Политика второго уровня применяется в дополнение к ней и т. д.
  • Если политика применяется с помощью предшествующих политик, например политики 3, она исключается из рассмотрения.
  • Любая отклоненная политика игнорируется. Чтобы увидеть, какая политика применяется, выберите Содержимое и политики > Политики > Применение, выберите развертывание и просмотрите примечания к решению.

Примечания о целях управления политиками аренды

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

В ходе анализа способа реализации политик рассмотрите следующие сценарии.

  • Цели и примеры применения политик аренды
  • Цели и примеры применения политик регулярного обслуживания
Табл. 1. Цели и примеры применения политик аренды
Цель управления Пример конфигурации Особенности
Осмысленная политика по умолчанию на уровне организации, которая не препятствует влиянию значений политик на уровне проекта на применяемые значения.

Политика организации = нежесткая

  • Период отсрочки: 10
  • Аренда: 100
  • Общий срок действия аренды: 100

Политика 1 проекта 1 = нежесткая

  • Аренда: 20
  • Общий срок действия аренды: 50

Политика 1 проекта 2 = нежесткая

  • Аренда: 10
  • Общий срок действия аренды: 30

Участник проекта 1 запрашивает элемент каталога.

Проект 2 не рассматривается, так как он не применяется к развертываниям проекта 1.

Объединенная действующая политика:

  • Период отсрочки: 10
  • Аренда: 20
  • Общий срок действия аренды: 50
Всегда используется по умолчанию для политики на уровне организации.

Политика организации = жесткая

  • Период отсрочки: 10
  • Аренда: 100
  • Общий срок действия аренды: 100

Политика 1 проекта 1 = нежесткая

  • Аренда: 20
  • Общий срок действия аренды: 50

Участник проекта 1 запрашивает элемент каталога.

Политика 1 проекта 1 не рассматривается, так как жесткий проект на уровне организации имеет более высокий ранг, а нежесткая политика не рассматривается.

Действующая политика:

  • Период отсрочки: 10
  • Аренда: 100
  • Общий срок действия аренды: 100
Все политики определены на уровне проекта, политики по умолчанию на уровне организации отсутствуют.

Политика 1 проекта 1 = нежесткая

  • Период отсрочки: 10
  • Аренда: 100
  • Общий срок действия аренды: 100

Политика 2 проекта 1 = нежесткая

  • Аренда: 20

Участник проекта 1 запрашивает элемент каталога.

Они обе являются нежесткими политиками и используются для проекта 1. Значения будут объединены.

Действующая политика:

  • Период отсрочки: 10
  • Аренда: 20
  • Общий срок действия аренды: 100

В этих примерах используются политики действий по регулярному обслуживанию.

Табл. 2. Цели и примеры применения политик регулярного обслуживания
Цель управления Пример конфигурации Особенности
Осмысленная политика по умолчанию на уровне организации, которая не препятствует влиянию значений политик на уровне проекта на применяемые значения.
Политика организации = нежесткая
  • Действия: Deployment.*
Политика 1 проекта 1 = нежесткая
  • Действия: Cloud.vSphere.Machine.*
Политика 1 проекта 2 = нежесткая
  • Действия: Cloud.Azure.Machine.*

Участник проекта 1 запрашивает элемент каталога.

Проект 2 не рассматривается, так как он не применяется к развертываниям проекта 1.

Объединенная действующая политика:
  • Действие: {Deployment.* ,Cloud.vSphere.Machine.*}
Всегда используется по умолчанию для политики на уровне организации.
Политика организации = жесткая
  • Действие: Deployment.*
Политика 1 проекта 1 = нежесткая
  • Действие: Cloud.vSphere.Machine.*

Участник проекта 1 запрашивает элемент каталога.

Политика 1 проекта 1 не рассматривается, так как жесткий проект на уровне организации имеет более высокий ранг, а нежесткая политика не рассматривается.

Действующая политика:
  • Действие: {Deployment.* }
Все политики определены на уровне проекта, политики по умолчанию на уровне организации отсутствуют.
Политика 1 проекта 1 = нежесткая
  • Действия: Deployment.ChangeLease
Политика 2 проекта 1 = нежесткая
  • Действие: Deployment.Delete

Участник проекта 1 запрашивает элемент каталога.

Они обе являются нежесткими политиками и используются для проекта 1. Значения будут объединены.

Действующая политика:
  • Действие: {Deployment.ChangeLease , Deployment.Delete}

Цели и примеры применения политик утверждения

Оценка политики подтверждения выполняется согласно этому процессу.

  1. Отправляется запрос на развертывание или действие по регулярному обслуживанию.
  2. Служба утверждения запрашивает политики, применимые к проекту, в рамках которого инициирован запрос элемента каталога или изменение развернутого элемента.
  3. Возвращаются все применимые политики на уровне проекта и организации.
  4. Политики утверждения фильтруются на основе критериев развертывания. Критерии развертывания применяются к развертываниям и действиям по регулярному обслуживанию.
  5. Если соответствующие политики не найдены, утверждение не требуется и процесс развертывания продолжается.
  6. Если соответствующие политики найдены, например AP1, AP2, APn, то элемент утверждения создается следующим образом.
    • Применяемые политики = AP1, AP2, APn.
    • Утверждающие = совокупность утверждающих по всем применяемым политикам.
    • Автоматическое истечение срока действия = отклонить, если политика имеет значение отклонения; в противном случае утвердить.
    • Срок действия = минимальный срок действия любой из применяемых политик (в днях).

В следующей таблице приведен пример с несколькими политиками. Процесс их обработки описан в таблице ниже.

Политика Пример конфигурации
AP1

Область = организация

Автоматическое истечение срока действия = утвердить

Срок действия = 7 дн.

AP2

Область = проект 1

Автоматическое истечение срока действия = утвердить

Срок действия = 3 дн.

AP3

Область = проект 1

Автоматическое истечение срока действия = отклонить

Срок действия = 4 дн.

AP4

Область = проект 2

Автоматическое истечение срока действия = утвердить

Срок действия = 5 дн.

С учетом указанных политик и примеров конфигураций далее объясняется, как обрабатывается запрос проекта 1.

  1. При оценке области возвращаются значения AP1, AP2 и AP3. AP4 не указывается, так как это политика проекта 2.
  2. При условии что AP1, AP2 и AP3 удовлетворяют критериям развертывания и действия, элемент утверждения будет включать в себя следующие значения.
    • Утверждающие = все или все утверждающие из политик AP1, AP2 и AP3.
    • Автоматическое истечение срока действия = отклонить. AP3 имеет более строгие требования.
    • Срок действия = 3 дн. AP2 предусматривает наименьшее значение.