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

  • Статья

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

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

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

Существует множество способов развертывания в Azure, включая портал Azure, CLI, API и многое другое. В этом руководстве мы будем использовать автоматизацию IaC и CI/CD. Этот подход отличается следующими преимуществами.

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

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

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

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

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

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

Архитектура

Architecture overview of using CI/CD to deploy Azure

Поток данных

  1. Создайте ветвь и проверка в необходимых изменениях кода IaC.
  2. Создайте запрос на вытягивание (PR) в GitHub после того, как вы будете готовы объединить изменения в вашей среде.
  3. Рабочий процесс GitHub Actions активируется для обеспечения того, чтобы код был хорошо отформатирован, внутренне согласован и создает безопасную инфраструктуру. Кроме того, анализ Terraform или Bicep будет выполняться для создания предварительной версии изменений, которые будут происходить в вашей среде 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 Подключение (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 Подключение (OIDC). Подробные инструкции см. в документации по Azure.

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

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

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

    • Задайте для параметра Entity Type значение Pull Request.
    • Branch Задайте Entity Type и используйте 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

Использование Bicep

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

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

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

  2. Bicep What-If / Deploy

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

Использование Terraform

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

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

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

  2. План Terraform / Apply

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

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

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