Поделиться через

Развертывание в инфраструктуре Azure с помощью GitHub Actions

В этом руководстве мы рассмотрим, как использовать CI/CD и инфраструктуру как код (IaC) для развертывания в Azure с помощью GitHub Actions в автоматизированном и повторяемом режиме.

В этой статье представлен обзор архитектуры и представлено структурированное решение для разработки приложения в Azure, которое является масштабируемым, безопасным, устойчивым и высокодоступным. Чтобы просмотреть более реальные примеры облачных архитектур и идей решения, просмотрите архитектуры Azure.

Преимущества использования IaC и автоматизации для развертываний

Существует множество способов развертывания в Azure, включая портал Azure, ИНТЕРФЕЙС командной строки, API и многое другое. В этом руководстве мы будем использовать автоматизацию IaC и CI/CD. К преимуществам этого подхода относятся:

  • Декларативный: когда инфраструктура и процесс развертывания определены в коде, их можно версионировать и рецензировать, используя стандартный жизненный цикл разработки программного обеспечения. IaC также помогает предотвратить смещение конфигурации.

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

  • Безопасность: централизованно управляемые шаблоны можно ужесточить и утвердить в облачных операциях или группе безопасности, чтобы соответствовать внутренним стандартам.

  • Самообслуживание: Команды могут быть уполномочены развертывать собственную инфраструктуру, используя централизованно управляемые шаблоны.

  • Улучшенная производительность. Используя стандартные шаблоны, команды могут быстро подготавливать новые среды без необходимости беспокоиться обо всех деталях реализации.

Дополнительные сведения можно найти в разделе "Повторяемая инфраструктура" в Центре архитектуры Azure или в разделе "Что такое инфраструктура как код" в Центре ресурсов DevOps.

Architecture

Общие сведения об архитектуре использования CI/CD для развертывания Azure

Поток данных

  1. Создайте новую ветвь и проверьте необходимые изменения кода IaC.
  2. Создайте pull request (PR) в GitHub, как только будете готовы внести изменения в вашу среду.
  3. Рабочий процесс GitHub Actions активируется для обеспечения того, чтобы код был хорошо отформатирован, внутренне согласован и создает безопасную инфраструктуру. Кроме того, анализ Terraform Plan или Bicep what-if будет обрабатываться для создания предварительного просмотра изменений, которые произойдут в вашей среде Azure.
  4. После соответствующего рассмотрения pr-запрос можно объединить в основную ветвь.
  5. Другой рабочий процесс GitHub Actions активируется из основной ветви и выполняет изменения с помощью поставщика IaC.
  6. (эксклюзивно для Terraform) Регулярно запланированный рабочий процесс GitHub Action также должен выполняться для поиска любого смещения конфигурации в вашей среде и создания новой проблемы при обнаружении изменений.

Предпосылки

Используйте Bicep

  1. Создание сред GitHub

    Рабочие процессы используют среды и секреты GitHub для хранения информации об идентификации Azure и для настройки процесса утверждения развертываний. Создайте среду с именем production , следуя этим инструкциям. В production среде настройте правило защиты и добавьте всех необходимых утверждающих, которые должны подтвердить рабочие развертывания. Вы также можете ограничить среду исключительно вашей главной ветвью. Подробные инструкции можно найти здесь.

  2. Настройка идентификации Azure:

    Приложению Azure Active Directory требуется разрешение на развертывание в подписке Azure. Создайте одно приложение и предоставьте ему соответствующие разрешения на чтение и запись в подписке Azure. Затем настройте федеративные учетные данные, чтобы разрешить GitHub использовать удостоверение с помощью OpenID Connect (OIDC). Подробные инструкции см. в документации по Azure . Необходимо добавить три федеративных учетных данных:

    • Установите тип сущности на Environment и используйте имя среды production.
    • Установите тип сущности на Pull Request.
    • Установите тип сущности на Branch и используйте имя ветви main.

  3. Добавление секретов GitHub

    Замечание

    Хотя ни один из данных об удостоверениях Azure не содержит секретов или учетных данных, мы по-прежнему используем секреты GitHub как удобный способ параметризации информации о удостоверениях для каждой среды.

    Создайте следующие секреты в репозитории с помощью удостоверения Azure:

    • AZURE_CLIENT_ID : идентификатор приложения (клиента) регистрации приложения в Azure
    • AZURE_TENANT_ID : идентификатор клиента Azure Active Directory, в котором определена регистрация приложения.
    • AZURE_SUBSCRIPTION_ID : идентификатор подписки, в которой определена регистрация приложения.

    Инструкции по добавлению секретов в репозиторий см. здесь.

Используйте Terraform

  1. Настройка расположения состояния Terraform

    Terraform использует файл состояния для хранения сведений о текущем состоянии управляемой инфраструктуры и связанной конфигурации. Этот файл необходимо сохранить между различными запусками рабочего процесса. Рекомендуется хранить этот файл в учетной записи хранения Azure или в другой аналогичной удаленной серверной части. Как правило, это хранилище будет подготовлено вручную или через отдельный рабочий процесс. Блок конфигурации серверной части Terraform нужно обновить с выбранным расположением хранилища (см. документацию здесь).

  2. Создание среды GitHub

    Рабочие процессы используют среды и секреты GitHub для хранения информации об удостоверениях Azure и настройки процесса одобрения для развертываний. Создайте среду с именем production , следуя этим инструкциям. На среде production настройте правило защиты и добавьте всех необходимых одобрителей, которые должны утвердить производственные развертывания. Вы также можете ограничить среду главной ветвью. Подробные инструкции можно найти здесь.

  3. Настройка идентификации Azure:

    Приложению Azure Active Directory требуется разрешение на развертывание в подписке Azure. Создайте отдельное приложение для read-only учетных записей и read/write предоставьте им соответствующие разрешения в подписке Azure. Кроме того, обеим ролям потребуется по крайней мере Reader and Data Access права доступа к учетной записи хранения, в которой находится состояние Terraform из шага 1. Затем настройте федеративные учетные данные, чтобы разрешить GitHub использовать удостоверение с помощью OpenID Connect (OIDC). Подробные инструкции см. в документации по Azure .

    read/write Для удостоверения создайте одну федеративную учетную запись следующим образом:

    • Установите Entity Type на Environment и используйте имя среды production.

    read-only Для удостоверения создайте два федеративных учетных данных следующим образом:

    • Задайте для параметра Entity Type значение Pull Request.
    • Установите Entity Type в Branch и используйте название ветки main.

  4. Добавьте секреты GitHub

    Замечание

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

    Создайте следующие секреты в репозитории с помощью идентификатора read-only.

    • AZURE_CLIENT_ID : идентификатор приложения (клиента) регистрации приложения в Azure
    • AZURE_TENANT_ID : идентификатор клиента Azure Active Directory, в котором определена регистрация приложения.
    • AZURE_SUBSCRIPTION_ID : идентификатор подписки, в которой определена регистрация приложения.

    Инструкции по добавлению секретов в репозиторий см. здесь.

    Создайте другой секрет в production среде с помощью read-write удостоверения:

    • AZURE_CLIENT_ID : идентификатор приложения (клиента) регистрации приложения в Azure

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

Развертывание с помощью GitHub Actions

Используйте Bicep

Существует два основных рабочего процесса, включенных в эталонную архитектуру:

  1. Модульные тесты Bicep

    Этот рабочий процесс выполняется при каждом коммите и состоит из набора модульных тестов для кода инфраструктуры. Он выполняет bicep build, чтобы скомпилировать bicep в шаблон ARM. Это гарантирует отсутствие ошибок форматирования. Затем он выполняет проверку , чтобы убедиться, что шаблон можно развернуть. Наконец, checkov, средство анализа статического кода с открытым исходным кодом для IaC, будет выполняться для обнаружения проблем безопасности и соответствия требованиям. Если репозиторий использует GitHub Advanced Security (GHAS), результаты будут отправлены в GitHub.

  2. Bicep What-If / Deploy

    Этот рабочий процесс выполняется при каждом запросе на слияние и каждом коммите в главной ветви. Шаг рабочего процесса what-if используется для понимания влияния изменений IaC на среду Azure путем запуска анализа what-if. Затем этот отчет присоединяется к PR для удобства проверки. Этап развертывания выполняется после анализа "что если", когда рабочий процесс активируется отправкой в основную ветку. На этом этапе вы развернете шаблон в Azure после завершения проверки вручную.

Используйте Terraform

Существует три основных рабочих процесса, включенных в эталонную архитектуру:

  1. Модульные тесты Terraform

    Этот рабочий процесс запускается на каждой фиксации и состоит из набора модульных тестов для кода инфраструктуры. Он запускает terraform fmt, чтобы убедиться, что код правильно форматируется и соответствует лучшим практикам terraform. Далее выполняется проверка terraform , чтобы убедиться, что код синтаксически правильный и внутренне согласованный. Наконец, checkov, средство анализа статического кода с открытым исходным кодом для IaC, будет выполняться для обнаружения проблем безопасности и соответствия требованиям. Если репозиторий использует GitHub Advanced Security (GHAS), результаты будут отправлены в GitHub.

  2. План Terraform / Применить

    Этот рабочий процесс выполняется для каждого pull request и каждого коммита в главной ветке. Этап планирования рабочего процесса используется для понимания влияния изменений IaC на среду Azure путем выполнения terraform plan. Затем этот отчет присоединяется к PR для простой проверки. Этап применения выполняется после плана, когда рабочий процесс активируется принудительной отправкой в основную ветвь. Этот этап обработает документ плана и применит изменения после окончательного утверждения, если в среде существуют какие-либо ожидающие изменения.

  3. Обнаружение смещения Terraform

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

  • Last updated on