Публикация ASP.NET Core приложения с помощью Azure Pipelines

Требования:

Windows Server 2019 c установленным IIS и .net core runtime.

Заходим в один из существующих проектов, если список проектов пуст создаем новый (в выбранной организации нажимаем «Новый проект», указываем имя, описание и видимость проекта).

Настройка Build Pipelines

  1. В меню слева выбрать пункт Pipelines.
  2. Выбираем где хранится код, в моем случае Azure Repos Git дальше нажимаем на имя репозитория. Из других доступных вариантов Bitbucket Cloud, GitHub, Other Git, Subversion.

3. Выбираем репозиторий и ждем пока анализируется репозиторий.

4. В списке конфигураций находим ASP.NET Core (Build and test ASP.NET Core projects targeting .NET Core). Появиться подготовленный шаблон azure-pipelines.yml. С следующим содержимым:

# ASP.NET Core
# Build and test ASP.NET Core projects targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core

trigger:
- main

pool:
  vmImage: ubuntu-latest

variables:
  buildConfiguration: 'Release'

steps:
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'

Все что начитается с # можно удалить, это комментарий с описанием. На работу pipeline не влияет.

Pipeline будет срабатывать каждый раз при изменении ветки «main». За это отвечает строка trigger c указанием – main. Триггер можно отключить:

trigger: none

Начнем править конфигурационный файл.

  • Так как я публикую на Windows сервер поменяем значение vmImage на ‘windows-2019’. Список доступных агентов можно посмотреть здесь.
pool:
  vmImage: "windows-2019"

Далее удаляем все что находится после steps. Вместо блока script, будем использовать встроенные задачи. Итак начнем по-порядку:

  • Задача, которая собирает проект. Для этого воспользуемся асистентом задач, который находится справа, по-умолчанию он скрыт. Открываем ассистент нажатием на «Show assistant», в списке задач найдем .NET Core.

Выбираем команду Build, в качестве Arguments добавляем строку «–configuration $(buildConfiguration)» и нажимаем Add. Мы явно указываем что для сборки нужно использовать конфигурацию «Release» взятую из названия переменной $(buildConfiguration).

В итоге добавяться следующие строки.

- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    arguments: '--configuration $(buildConfiguration)'
  • Задача, которая создаcт другие ресурсы, такие как зависимости проекта, файлы настроек приложения, статические файлы и выведет их все в каталог, готовый к развертыванию. Выбираем всю туже задачу .NET Core, теперь команду publish, arguments вставляем «–configuration $(buildConfiguration) –output $(Build.ArtifactStagingDirectory)», отмечаем чек-боксы Publish web projects, Zip published projects, Add project’s folter name to publish path. В итоге команда будет выглядеть так
  - task: DotNetCoreCLI@2
    inputs:
      command: 'publish'
      publishWebProjects: true

      arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'
  • Задача, которая сделает артефакт доступным в общем месте на Azure DevOps для использования в конвейере Releases. Для добавления этой команды в асистенте найдем «Publish PipeLine Artifacts» и укажем следующие параметры:
    • File or directory path, путь куда был опубликован проект. Был указан на предыдущем шаге: $(Build.ArtifactStagingDirectory)
    • Artifact name, может быть любым: NordAnorraClientServiceArtifact
    • Artifact publish location: Azure PipeLines
  - task: PublishPipelineArtifact@1
    inputs:
      targetPath: "$(Build.ArtifactStagingDirectory)"
      artifact: "NordAnorraClientServiceArtifact"

На этом конфигурация pipelines завершена. Сохраняем файл и проверяем что pipeline выполнился без ошибок и артефакт доступен для скачивания. Полная версия файла конфигурация приведена ниже:

trigger:
- main

pool:
  vmImage: "windows-2019"

variables:
  buildConfiguration: "Release"

steps:

  - task: DotNetCoreCLI@2
    inputs:
      command: "build"
      arguments: "--configuration $(buildConfiguration)"

  - task: DotNetCoreCLI@2
    inputs:
      command: "publish"
      publishWebProjects: true
      arguments: "--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)"

  - task: PublishPipelineArtifact@1
    inputs:
      targetPath: "$(Build.ArtifactStagingDirectory)"
      artifact: "NordAnorraClientServiceArtifact"

Настройка Release Pipelines

Цель Release pipelines – взять опубликованный артефакт из release pipelines и развернуть его на целевых серверах. Для этого необходимо зарегистрировать сервер или серверы в пуле развертывания и создать группы развертывания.
Прежде чем вы сможете создать пул развертывания, убедитесь, что ваша учетная запись имеет соответствующие разрешения. Если вы выполнили указанные действия, возможно, у вас есть разрешения, поскольку вы являетесь владельцем организации.

  1. Cоздание пула развертования
    • Нажием на лого Azuer DevOps
    • Выбираем Organizations Settings
    • В разделе Pipelines выбираем Deployments pools
    • Нажимаем New, указываем имя пула и связанные проекты и жмем Create

На этом этапе Azure DevOps создает сценарий регистрации. Вам нужно взять этот сценарий и запустить его на каждом из серверов, на которых вы хотите развернуть приложение.

  1. Регистрация сервера в пуле развертования
    • Зайдите в пул развертования, выберите Windows в «Type of target to register».
    • Отметьте чек-бокс «Use a personal access token in the script for authentication» и скопируйте скрипт, нажав на кнопку «Сopy Script to the clipboard»
    • Подключитесь к серверу, запустите PowerShell c правами администратора
    • Запустите скопированный скрипт в powerShell.
    • Дайте разрешение на разархивирования «Enter Perform an unzip for tasks for each step.«. Нужно ответить Y и Enter
    • Когда будет предложено указать учетную запись пользователя для использования на сервере, используйте значение по умолчанию. (Enter User account to use for the service (press enter for NT AUTHORITY\SYSTEM))

Токен личного доступа – это то, как агент (сервер, на котором размещено приложение) безопасно взаимодействует с azure DevOps. Агент периодически обращается к запросам о работе. Когда задание попадает в очередь, агент загружает задание и выполняет его.


  ___                      ______ _            _ _
 / _ \                     | ___ (_)          | (_)
/ /_\ \_____   _ _ __ ___  | |_/ /_ _ __   ___| |_ _ __   ___  ___
|  _  |_  / | | | '__/ _ \ |  __/| | '_ \ / _ \ | | '_ \ / _ \/ __|
| | | |/ /| |_| | | |  __/ | |   | | |_) |  __/ | | | | |  __/\__ \
\_| |_/___|\__,_|_|  \___| \_|   |_| .__/ \___|_|_|_| |_|\___||___/
                                   | |
        agent v2.183.1             |_|          (commit b8617e6)


>> Connect:

Connecting to server ...

>> Register Agent:

Scanning for tool capabilities.
Connecting to the server.
Successfully added the agent
Testing agent connection.

Enter a valid value for Perform an unzip for tasks for each step..
Enter Perform an unzip for tasks for each step. (press enter for N) > Y
2021-03-16 18:11:39Z: Settings Saved.
Enter User account to use for the service (press enter for NT AUTHORITY\SYSTEM) >
Error reported in diagnostic logs. Please examine the log for more details.
    - C:\azagent\A1\_diag\Agent_20210316-180718-utc.log
Granting file permissions to 'NT AUTHORITY\SYSTEM'.
Service vstsagent.SucaSuc.NordAndorraServer.1F35B89 successfully installed
Service vstsagent.1F35B89 successfully set recovery option
Service vstsagent.1F35B89 successfully set to delayed auto start
Service vstsagent.1F35B89 successfully configured
Service vstsagent.1F35B89 started successfully

Процесс включает подключение к серверу и может занять некоторое время. После успешного завершения сценария вернитесь в Deployment pools в разделе Organizations settings. Вы должны увидеть статус, указывающий, что агент находится в сети, и один проект обращается к пулу.


Повторите вышеуказанные шаги, если у вас есть другие серверы, которые вы хотите добавить в пул.
Теперь, когда мы установили агенты на серверах развертывания, зарегистрировали серверы в пуле развертывания и создали группу развертывания из пула для использования в проекте. Давайте создадим pipeline release для развертывания артефакта в IIS.

  1. Создание Release pipeline
    • Нажмите на Releases в разделе Pipelines, далее New pipeline
    • В списке шаблонов выберите IIS website deployment и нажмите Apply
    • Ставим курсор на дефолтном имени New release pipeline и переименовываем в Nord Services pipelines.
    • В блоке артефактов нажмите на Add an artifact, выберите source type Build.
    • Далее выбираем проект, pipeline созданный ранее, версия Latest, alias оставляем как есть и нажимаем Add

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

  1. Настраиваем Deployment process
    • Переименовываем stage name в Deploy
    • Configuration type выбираем IIS WebSite, Action – Create Or Update
    • Website name указываем имя взятое из ISS Manager, в моем случае это ClientWebServices
    • Убираем checkbox Add binding, так как все уже настроено
  2. Настраваем IIS Deployment. Указываем Deployment group группу развертования созданную ранее. Все остальные опции оставляем как есть.
  3. Настраиваем IIS Web App Manage
    • Указываем правильный путь сайта в параметре Physical path
    • Physical path authentication оставляем Application User (Pass-through)
  4. Настраиваем
  5. Настраиваем IIS Web App Deploy
    • Нажимаем на «…» параметра Package or Folder и выбираем артефакт сгенерированный build pipelines
    • Отмечаем XML transformation, XML variable substitution при необходимости.
    • Отмечаем Remove Additional Files at Destination. Параметр на ваше усмотрение.
    • И последнее что хотелось бы расмотреть, так это замена переменных в JSON, а именно параметров appsettings.json. Так как файл настроек находится в корне добавляем относительный путь к файлу в параметр JSON variable substitution значение ./appsettings.json
    • Переходим в вкладку Variables и добавляем значения нужных переменных. Вложенные параметры указываем через точку. Например, DefaultConnection, в appsettings.json выглядит так, тогда имя переменной в pipeline должно быть Connections.DefaultConnection
  "ConnectionStrings": {
    "DefaultConnection": null
  },

Как оказалось JSON variable substitution задачи ISS Web App Deploy может заменять только строки, но что если в параметре appsettings.json нужно хранить массив. Например,

    "SupportedCultures": [
        "es-ES",
        "ca-ES"
    ],

Чтобы решить эту проблему нужно добавить задачу File Transform, перед ISS Web App Deploy.

  • Display Name указываете произвольное
  • Package or Folder выбираете файл артефакта, полученный от build pipelines.
  • File Format – JSON
  • Target files – ./appsettings.json

Сохраняем и создаем релиз. Ожидаем завершения публикации. На этом настройка Azure Pipelines завершена.

Заметки:

  • Включить debug логирования можно добавив в variables переменную system.debug со значением true
  • Параметр типа integer в appsettings.json после JSON substitution будет строкой, то есть 1 -> "1". Будьте внимательны. А вот задача File Transform сохраняет как число.

Ссылки:

Agent pools

Transform web.config

Create your first pipeline

Publish .NET apps with the .NET CLI

Build, test, and deploy .NET Core apps

Use predefined variables

Publish Pipeline Artifacts task

JSON variable substitution

JSON Variable Substitution in Multi-Stage YAML Azure Pipelin


Publicado

en

por

Etiquetas:

Comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *