CI/CD для бессерверного интерфейса приложений в Azure

Azure Pipelines

Бессерверные вычисления абстрагируют серверы, инфраструктуры и операционные системы, позволяя разработчикам сосредоточиться на разработке приложений. Благодаря надежной CI/CD или непрерывной интеграции/непрерывной поставке таких приложений в пределах нескольких минут разработки компании могут поставлять полностью протестированные и интегрированные версии программного обеспечения. Они предоставляют основу современной среды DevOps.

Что означает CI/CD?

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

В этой статье рассматривается конвейер CI/CD для веб-интерфейсов реализации бессерверной ссылки. Этот конвейер разрабатывается с помощью служб Azure. На веб-интерфейсе демонстрируется современное веб-приложение с JavaScript на стороне клиента, многократно используемыми API-интерфейсами на стороне сервера и предварительно созданной разметкой, которая также называется Jamstack. Код можно найти в этом репозитории GitHub. В файле сведений содержатся инструкции по скачиванию, сборке и развертыванию приложения.

На указанной ниже схеме приведено описание конвейера CI/CD, используемого в этом образце интерфейса.

Конвейер CI/CD в бессерверном приложении с использованием служб Azure

В этой статье не рассматривается серверное развертывание.

Предварительные требования

Для работы с этим примером приложения убедитесь, что у вас есть следующее:

Учетная запись GitHub.
Учетная запись Azure. Если у вас нет указанного, вы можете попробовать бесплатную учетную запись Azure.
Организация Azure DevOps. Если у вас ее нет, вы можете испытать базовый план, который включает службы DevOps, такие как Azure Pipelines.

Использование системы управления версиями, подключенными к сети

Системы управления версиями отслеживают и контролируют изменения в исходном коде. Хранение исходного кода в системе управления версиями, подключенными к сети, позволяет нескольким группам разработчиков работать совместно. Его также проще поддерживать, чем традиционное локальное управление версиями. Эти подключенные системы можно легко интегрировать с ведущими службами CI/CD. Вы получаете возможность создавать и обслуживать исходный код в нескольких каталогах, а также файлы сборки и конфигурации, которые находятся в репозитории.

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

Автоматизация сборки и развертывания

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

Интеграция средств сборки

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

В примере подано приложение React, созданное с помощью Gatsby.js, которое является статическим генератором сайтов и интерфейсной платформой разработки. Эти средства можно запускать локально на этапах разработки и тестирования, а затем интегрировать с Azure Pipelines для окончательного развертывания.

В примере используется файл Gatsby gatsby-ssr.js для подготовки к просмотру и gatsby-config.js для конфигурации сайта. Gatsby преобразует все файлы JavaScript в подкаталоге pages папки src в файлы HTML. Дополнительные компоненты попадают в подкаталог components. В примере также используется подключаемый модуль gatsby-plugin-typescript, который позволяет использовать TypeScript для обеспечения безопасности типов, а не JavaScript.

Дополнительные сведения о настройке проекта Gatsby см. в официальной документации Gatsby.

Автоматизация сборок

Автоматизация процесса сборки сокращает количество ошибок пользователей, которые могут возникнуть во время исполнения процессов вручную. Файл azure-pipelines.yml содержит сценарий для автоматизации с двумя этапами. В файле сведений для этого проекта описаны шаги, необходимые для настройки конвейера автоматизации с помощью Azure Pipelines. В указанных ниже подразделах показано, как настроены этапы конвейера.

Этап сборки

Так как Azure Pipelines интегрирована с репозиторием GitHub, любые изменения в отслеживаемом каталоге main ветви запускают первый этап конвейера, этап сборки:

trigger:
  batch: true
  branches:
    include:
    - main
  paths:
    include:
    - src/ClientApp

В указанном ниже фрагменте кода показан запуск этапа сборки, который запускает контейнер Ubuntu для запуска этого этапа.

    stages:
    - stage: Build
      jobs:
      - job: WebsiteBuild
        displayName: Build Fabrikam Drone Status app
        pool:
          vmImage: 'Ubuntu-16.04'
        continueOnError: false
    steps:

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

Установка Node.js и настройка переменных среды,

Установка и запуск Gatsby.js, который строит статический веб-сайт:

    - script: |
        cd src/ClientApp
        npm install
        npx gatsby build
      displayName: 'gatsby build'

установка и запуск средства сжатия с именем brotliдля сжатия созданных файлов перед развертыванием:

    - script: |
        cd src/ClientApp/public
        sudo apt-get install brotli --install-suggests --no-install-recommends -q --assume-yes
        for f in $(find . -type f \( -iname '*.html' -o -iname '*.map' -o -iname '*.js' -o -iname '*.json' \)); do brotli $f -Z -j -f -v && mv ${f}.br $f; done
      displayName: 'enable compression at origin level'

Вычисление версии текущей сборки для управления кэшем,

Публикация файлов сборки для использования на этапе развертывания:

    - task: PublishPipelineArtifact@1
      inputs:
        targetPath: 'src/ClientApp/public'
        artifactName: 'drop'

Успешное завершение этапа сборки удаляет среду Ubuntu и запускает этап развертывания в конвейере.

Этап развертывания

Этап развертывания выполняется в новом контейнере Ubuntu:

    - stage: Deploy
      jobs:
      - deployment: WebsiteDeploy
        displayName: Deploy Fabrikam Drone Status app
        pool:
          vmImage: 'Ubuntu-16.04'
        environment: 'fabrikamdronestatus-prod'
        strategy:
          runOnce:
            deploy:
              steps:

Этот этап включает в себя различные задачи и сценарии развертывания для:

Скачайте артефакты сборки в контейнер (что происходит автоматически, как следствие использования PublishPipelineArtifact на этапе сборки),
запишите версию выпуска сборки и обновите ее в репозитории GitHub,
передайте файлы веб-сайта в Хранилище BLOB-объектов, в новой папке, соответствующей новой версии, и
измените CDN, чтобы она указывала на эту новую папку.

Последние два шага вместе реплицируют очистку кэша, так как старые папки больше не доступны для пограничных серверов CDN. В следующем фрагменте кода показано, как это достигается:

       - script: |
              az login --service-principal -u $(azureArmClientId) -p $(azureArmClientSecret) --tenant $(azureArmTenantId)
              # upload content to container versioned folder
              az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --content-encoding br --pattern "*.html" --content-type "text/html"
              az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --content-encoding br --pattern "*.js" --content-type "application/javascript"
              az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --content-encoding br --pattern "*.js.map" --content-type "application/octet-stream"
              az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --content-encoding br --pattern "*.json" --content-type "application/json"
              az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --pattern "*.txt" --content-type "text/plain"
              # target new version
              az cdn endpoint update --resource-group $(azureResourceGroup) --profile-name $(azureCdnName) --name $(azureCdnName) --origin-path '/$(releaseSemVer)'
              AZURE_CDN_ENDPOINT_HOSTNAME=$(az cdn endpoint show --resource-group $(azureResourceGroup) --name $(azureCdnName) --profile-name $(azureCdnName) --query hostName -o tsv)
              echo "Azure CDN endpoint host ${AZURE_CDN_ENDPOINT_HOSTNAME}"
              echo '##vso[task.setvariable variable=azureCndEndpointHost]'$AZURE_CDN_ENDPOINT_HOSTNAME
            displayName: 'upload to Azure Storage static website hosting and purge Azure CDN endpoint'

Атомарные развертывания

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

В примере конвейера CI/CD содержимое веб-сайта развертывается в Хранилище BLOB-объектов, которое выступает в качестве сервера-источника для Azure CDN. Если файлы обновляются в той же корневой папке в BLOB-объекте, веб-сайт будет обрабатываться непоследовательно. Эта проблема решается при передаче в новую папку с версиями, как показано в предыдущем разделе. Пользователи либо получают либо все, либо ничего с новой удачной сборки, так как CDN указывает на новую папку в качестве источника, только после успешного обновления всех файлов.

Развертывание с управлением версиями

Ниже указанны преимущества этого подхода.

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

Размещение и распространение с помощью облака

Сеть доставки содержимого (CDN) — это набор распределенных серверов, которые ускоряют доставку содержимого пользователям по обширному географическому региону. Каждый пользователь получает содержимое с ближайшего к нему сервера. CDN обращается к этому содержимому с сервера-источника и кэширует его на пограничных серверах в стратегических расположениях. В примере CI/CD в этой статье используется служба Azure CDN, указывающая на содержимое веб-сайта, размещенное в Хранилище BLOB-объектов Azure в качестве сервера-источника. Хранилище BLOB-объектов настроено для статического размещения веб-сайтов. Краткое руководство по использованию Azure CDN с Хранилищем BLOB-объектов Azure см. в статье Интеграция учетной записи хранения Azure с Azure CDN.

Ниже указанны некоторые стратегии, которые могут повысить производительность CDN.

Сжатие содержимого

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

Это можно сделать двумя способами.

"На лету" на пограничных серверах CDN. Это улучшает использование пропускной способности на значительный процент, делая веб-сайт значительно быстрее, чем без сжатия. Этот тип сжатия относительно несложно включить для Azure CDN. Так как он управляется CDN, средство сжатия нельзя выбрать или настроить. Используйте это сжатие, если производительность веб-сайта не является критической задачей.
Предварительное сжатие перед достижением CDN, либо на сервере-источнике, либо до достижения источника. Предварительное сжатие ускоряет время выполнения веб-сайта, так как оно выполняется до того, как CDN получит его. В примере конвейера CI/CD файлы, созданные на этапе развертывания, сжимаются с помощью brotli, как показано в указанном разделе сборки. Ниже указанны преимущества использования предварительного сжатия.
1. Вы можете использовать любое удобное средство сжатия, чтобы его настроить. Сети CDN могут иметь ограничения на используемые ими средства.
2. Некоторые сети CDN ограничивают размер файлов, которые можно сжать "на лету", что приведет к снижению производительности для больших файлов. При предварительном сжатии не устанавливается ограничение на размер файла.
3. Предварительное сжатие в конвейере развертывания приводит к уменьшению объема хранилища, необходимого в источнике.
4. Это быстрее и эффективнее, чем сжатие CDN.

Подробнее см. в статье Повышение производительности за счет сжатия файлов в Azure CDN.

Динамическое ускорение сайтов

Использование CDN оптимально для статического содержимого, которое можно безопасно кэшировать на пограничных серверах. Однако для динамических веб-сайтов требуется, чтобы сервер создавал содержимое на основе ответа пользователя. Этот тип содержимого не может кэшироваться на границе, что требует более подробного комплексного решения, которое может ускорить доставку содержимого. Динамическое ускорение сайтов по Azure CDN является одним из таких решений, которое значительно улучшает производительность динамических веб-страниц.

Этот пример включает динамическое ускорение сайта, как показано в этом разделе файла сведений.

Управление кэшем веб-сайта

Сети CDN используют кэширование для повышения производительности. Настройка и управление этим кэшем станет неотъемлемой частью конвейера развертывания. В документации Azure CDN показано несколько способов как это сделать. Вы можете задать правила кэширования на CDN, а также настроить срок жизни для содержимого на сервере-источнике. Статическое веб-содержимое может кэшироваться в течение длительного времени, так как оно может измениться слишком сильно со временем. Это снижает затраты на доступ к одному серверу-источнику для каждого запроса пользователя. Дополнительные сведения см. в статье Как выполняется кэширование.

Очистка кэша

CDN кэширует файлы веб-сайта на пограничных серверах до истечения их срока жизни. Они обновляются для нового запроса клиента, только после истечения срока жизни. Очистка кэша CDN необходима для того, чтобы каждый пользователь получил последние файлы веб-сайта, особенно если развертывание происходит в той же исходной папке CDN. Azure CDN позволяет очистить кэш с портала Azure.

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

CDN проверяет index.html по отношению к источнику для каждого нового экземпляра веб-сайта.
За исключением index.html и 404.html, все остальные файлы веб-сайта отправляются на отпечатки и кэшируются в течение года. Это основано на предположении, что ресурсы, такие как изображения и видео, не требуют частого изменения. Если эти файлы обновляются и перестраиваются, их имена обновляются с помощью нового GUID отпечатка. Это приводит к обновлению index.html с обновленной ссылкой на измененный файл ресурсов. Затем CDN извлекает обновленный index.html, а так как он не находит файл ресурсов ссылки в кэше, он также извлекает измененные файлы ресурсов.

Это гарантирует, что CDN всегда будет получать новые обновленные файлы и ему не нужно будет очищать кэш для новой сборки.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально она была написана следующими авторами.

Основной автор:

Дханашри Кширсагар | Старшее содержимое PM

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Дальнейшие действия

Теперь, когда вы понимаете основы, используйте этот файл сведений, чтобы настроить и выполнить конвейер CI/CD.
Просмотрите статью о рекомендациях по использованию сетей доставки содержимого (CDN)

Share via