Note
Пользовательские правила защиты развертывания в настоящее время находятся в beta и подвергаются изменению.
Сведения о правилах защиты пользовательских развертываний
Вы можете включить собственные правила защиты для шлюза развертываний с помощью сторонних служб. Например, можно использовать такие службы, как Datadog, Honeycomb и ServiceNow, чтобы предоставить автоматические утверждения для развертываний в GitHub.
Пользовательские правила защиты развертывания основаны на GitHub Apps и выполняются на основе веб-перехватчиков и обратных вызовов. Утверждение или отклонение задания рабочего процесса основано на использовании deployment_protection_rule
веб-перехватчика. Дополнительные сведения см. в разделе "События и полезные данные веб-перехватчика" и "Утверждение или отклонение развертываний".
После создания настраиваемого правила защиты развертывания и его установки в репозитории настраиваемое правило защиты развертывания будет автоматически доступно для всех сред в репозитории.
Использование пользовательских правил защиты развертывания для утверждения или отклонения развертываний
Развертывания в среде могут быть утверждены или отклонены на основе условий, определенных в любой внешней службе, такой как утвержденный билет в системе УПРАВЛЕНИЯ ИТ-службами (ITSM), уязвимый результат сканирования на зависимости или стабильные метрики работоспособности облачного ресурса. Решение об утверждении или отклонении развертываний осуществляется по усмотрению интеграции стороннего приложения и условий, которые вы определяете в них. Ниже приведены несколько вариантов использования, для которых можно создать правило защиты развертывания.
- ITSM & Security Operations: вы можете проверить готовность службы, проверяя качество, безопасность и соответствие процессам, которые проверяют готовность к развертыванию.
- Системы наблюдения: вы можете проконсультироваться с системами мониторинга или наблюдаемости (системы управления производительностью активов и агрегатами журналов, системами проверки работоспособности облачных ресурсов и т. д.) для проверки готовности к безопасности и развертыванию.
- Средства качества кода и тестирования: вы можете проверить наличие автоматических тестов на сборках CI, которые необходимо развернуть в среде.
Кроме того, можно написать собственные правила защиты для любого из приведенных выше вариантов использования или определить любую пользовательскую логику для безопасного утверждения или отклонения развертываний из предварительной среды в рабочие среды.
Создание настраиваемого правила защиты развертывания с помощью GitHub Apps
-
Создайте GitHub App. Дополнительные сведения см. в разделе «Регистрация приложения GitHub». Настройте GitHub App следующим образом.
- При необходимости в текстовом поле URL-адреса обратного вызова в разделе "Идентификация и авторизация пользователей" введите URL-адрес обратного вызова. Дополнительные сведения см. в разделе «Сведения о URL-адресе обратного вызова авторизации пользователя».
- В разделе "Разрешения" выберите разрешения репозитория.
- Справа от пункта "Действия", щелкните раскрывающееся меню и выберите Access: Только для чтения.
- Справа от пункта "Развертывания", щелкните раскрывающееся меню и выберите Access: Чтение и запись.
- В разделе "Подписка на события" выберите правило защиты развертывания.
-
Установите настраиваемое правило защиты развертывания в репозиториях и включите его для использования. Дополнительные сведения см. в разделе «Настройка пользовательских правил защиты развертывания».
Утверждение или отклонение развертываний
Когда рабочий процесс достигнет задания, ссылающегося на среду с включенным пользовательским правилом защиты развертывания, GitHub отправляет POST
запрос на URL-адрес, который настроен, содержащий deployment_protection_rule
полезные данные. Вы можете написать правило защиты развертывания, чтобы автоматически отправлять запросы REST API, утверждающие или отклоняющие развертывание на основе полезных deployment_protection_rule
данных. Настройте запросы REST API следующим образом.
-
Проверьте входящий
POST
запрос. Дополнительные сведения см. в разделе «Проверка доставки веб-перехватчика». -
Используйте веб-маркер JSON для проверки подлинности в виде GitHub App. Дополнительные сведения см. в разделе «Проверка подлинности в качестве приложения GitHub».
-
Используя идентификатор установки из полезных
deployment_protection_rule
данных веб-перехватчика, создайте маркер установки. Дополнительные сведения см. в разделе «Сведения о проверке подлинности с помощью приложения GitHub».curl --request POST \ --url "http(s)://HOSTNAME/api/v3/app/installations/INSTALLATION_ID/ACCESS_TOKENS" \ --header "Accept: application/vnd.github+json" \ --header "Authorization: Bearer {jwt}" \ --header "Content-Type: application/json" \ --data \ '{ \ "repository_ids": [321], \ "permissions": { \ "deployments": "write" \ } \ }'
-
При необходимости, чтобы добавить отчет о состоянии, не выполняя никаких других действий в GitHub, отправьте
POST
запрос/repos/OWNER/REPO/actions/runs/RUN_ID/deployment_protection_rule
в . В тексте запроса опуститеstate
элемент . Дополнительные сведения см. в разделе «Конечные точки REST API для выполнения рабочих процессов». Отчет о состоянии можно опубликовать в одном развертывании до 10 раз. Отчеты о состоянии поддерживают форматирование Markdown и могут содержать до 1024 символов. -
Чтобы утвердить или отклонить запрос, отправьте
POST
запрос/repos/OWNER/REPO/actions/runs/RUN_ID/deployment_protection_rule
в . В тексте запроса задайтеstate
для свойства значениеapproved
илиrejected
. Дополнительные сведения см. в разделе «Конечные точки REST API для выполнения рабочих процессов». -
При необходимости запросите состояние утверждения рабочего процесса, отправив
GET
запрос/repos/OWNER/REPOSITORY_ID/actions/runs/RUN_ID/approvals
в . Дополнительные сведения см. в разделе «Конечные точки REST API для выполнения рабочих процессов». -
При необходимости просмотрите развертывание на GitHub. Дополнительные сведения см. в разделе «Проверка развертываний».