Настройка непрерывного развертывания с помощью Chocolatey

  • Статья

Примечание.

Прежде чем включить конфигурацию состояния автоматизации, мы хотели бы знать, что более новая версия DSC теперь общедоступна, управляемая функцией Политика Azure именованной гостевой конфигурации. Служба гостевой конфигурации объединяет функции расширения DSC, служба автоматизации Azure конфигурации состояния и наиболее часто запрашиваемые функции из отзывов клиентов. Гостевая конфигурация также включает поддержку гибридных компьютеров через серверы с поддержкой Arc.

В среде DevOps существует множество средств, которые упрощают различные аспекты конвейера непрерывной интеграции. State Configuration службы автоматизации Azure — это долгожданная новая служба, которую могут использовать команды разработчиков DevOps.

Служба автоматизации Azure — это управляемая служба в Microsoft Azure, которая позволяет автоматизировать различные задачи с помощью модулей Runbook, узлов и общих ресурсов, таких как учетные данные, расписания и глобальные переменные. Служба State Configuration службы автоматизации Azure расширяет возможности автоматизации, которые теперь включают средства Desired State Configuration (DSC) PowerShell. Вот прекрасный обзор на эту тему.

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

Continuous Deployment for IaaS VMs

На высоком уровне

Эта схема включает немало действий, но, к счастью, их можно разбить на два основных процесса:

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

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

Обзор компонентов

Диспетчеры пакетов, такие как apt-get, хорошо известны среди разработчиков Linux и гораздо меньше — среди тех, кто работает с Windows. К таким диспетчерам пакетов относится Chocolatey, общие сведения о котором изложены в записи блога Скотта Хансельмана (Scott Hanselman). В двух словах, Chocolatey позволяет с помощью командной строки устанавливать пакеты из центрального репозитория в Windows. Вы можете создать собственный репозиторий и управлять им, а Chocolatey будет устанавливать пакеты из любого указанного вами количества репозиториев.

PowerShell DSC — это средство PowerShell, которое позволяет объявить конфигурацию, необходимую для компьютера. Например, если требуется установить Chocolatey, установить службы IIS, открыть порт 80 и установить версию 1.0.0 веб-сайта, Configuration Manager DSC (LCM) реализует эту конфигурацию. Опрашиваемый сервер DSC содержит хранилище конфигураций для компьютеров. Локальный диспетчер конфигураций на каждом компьютере периодически проверяет, совпадает ли его конфигурация с сохраненной конфигурацией. Он либо сообщает о состоянии, либо пытается привести компьютер в соответствие с сохраненной конфигурацией. Сохраненную конфигурацию на опрашивающем сервере можно изменить, чтобы привести компьютер или набор компьютеров в соответствие с измененной конфигурацией.

Ресурс DSC — это модуль кода, который имеет определенные возможности, такие как управление сетевыми подключениями, Active Directory или SQL Server. Ресурс DSC Chocolatey может получать доступ к серверу NuGet, загружать и устанавливать пакеты и т. д. Имеется также множество других ресурсов DSC, доступных в коллекции PowerShell. Эти модули устанавливаются на опрашиваемом сервере State Configuration службы автоматизации Azure, поэтому их можно использовать в ваших конфигурациях.

Шаблоны Resource Manager предоставляют декларативный способ создания инфраструктуры с помощью сетей, подсетей, сетевой безопасности и маршрутизации, подсистем балансировки нагрузки, сетевых карт, виртуальных машин и т. д. В этой статье сравнивается декларативная модель развертывания с помощью Resource Manager и принудительная модель развертывания управления службами Azure (ASM или классическая). Кроме того, в статье рассматриваются основные поставщики ресурсов: вычислительных, ресурсов хранилища и сетевых.

Одна из ключевых особенностей шаблона Resource Manager заключается в возможности установить на виртуальной машине расширение виртуальной машины во время подготовки. Расширение VM предоставляет определенные возможности, такие как выполнение пользовательского сценария, установка антивирусного программного обеспечения и выполнение сценария конфигурации DSC. Существует много других типов расширений VM.

Краткий обзор схемы

Если начинать сначала, вы пишете код, выполняете сборку и тестирование, а затем создаете пакет установки. Chocolatey может обрабатывать пакеты установки различных типов, например MSI, MSU и ZIP. Кроме того, в вашем распоряжении имеются все возможности PowerShell для фактической установки, если возможностей Chocolatey недостаточно. Поместите пакет в легкодоступное место, например в репозиторий пакетов. Он может располагаться где угодно. Например, в этом примере используется общая папка в учетной записи хранилища больших двоичных объектов Azure. Chocolatey работает непосредственно с серверами NuGet и некоторыми другими серверами в рамках управления метаданными пакета. Возможные варианты описаны в этой статье. В этом примере используется NuGet. Nuspec — это метаданные о пакетах. Сведения о Nuspec компилируются в NuPkg и хранятся на сервере NuGet. Когда конфигурация запрашивает пакет по имени и ссылается на сервер NuGet, ресурс DSC Chocolatey на виртуальной машине извлекает пакет и устанавливает его. Можно также запросить определенную версию пакета.

В левой нижней части схемы упоминается шаблон Azure Resource Manager. В этом примере расширение виртуальной машины регистрирует виртуальную машину на опрашиваемом сервере State Configuration службы автоматизации Azure как узел. Конфигурация хранится на опрашиваемом сервере дважды: один раз в виде обычного текста и после компиляции в виде MOF-файла. На портале Azure MOF-файл указывается как "конфигурация узла", а не просто "конфигурация". Это связанный с узлом артефакт, сообщающий узлу его конфигурацию. Ниже объясняется, как назначить узлу конфигурацию узла.

Создание метаданных Nuspec, их компиляция и сохранение на сервере NuGet — несложная задача. Кроме того, вы уже управляете виртуальными машинами.

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

Начинать работу с шаблона Resource Manager необязательно. Существуют команды PowerShell, которые помогут вам зарегистрировать виртуальные машины на опрашиваемом сервере. Дополнительные сведения см. в статье Подключение компьютеров для управления с помощью State Configuration службы автоматизации Azure.

Сведения о примере использования

В начале примера в этой статье создается виртуальная машина с помощью универсального образа Windows Server 2012 R2 из коллекции Azure. Ее можно запустить из любого сохраненного образа, а затем настроить, используя конфигурацию DSC. Однако изменение конфигурации, встроенной в образ, требует гораздо больше усилий, чем динамическое обновление конфигурации с помощью DSC.

Для использования этого метода на виртуальных машинах не обязательно использовать шаблон Resource Manager и расширение VM. Кроме того, виртуальные машины, на которых должно выполняться непрерывное развертывание, не обязательно должны размещаться в Azure. На виртуальной машине достаточно установить Chocolatey и настроить локальный диспетчер конфигураций, чтобы указать для нее расположение опрашивающего сервера.

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

Полный исходный код для этого примера хранится в этом проекте Visual Studio на сайте GitHub.

Шаг 1. Настройка опрашивающего сервера и учетной записи службы автоматизации

В командной строке PowerShell с аутентификацией (Connect-AzAccount) выполните следующую команду (настройка опрашивающего сервера может занять несколько минут).

New-AzResourceGroup -Name MY-AUTOMATION-RG -Location MY-RG-LOCATION-IN-QUOTES
New-AzAutomationAccount -ResourceGroupName MY-AUTOMATION-RG -Location MY-RG-LOCATION-IN-QUOTES -Name MY-AUTOMATION-ACCOUNT

Вы можете поместить учетную запись службы автоматизации в любой из следующих регионов (также известных как расположения): восточная часть США 2, южная часть США, сша gov Вирджиния, Западная Европа, Юго-Восточная Азия, Восточная Япония, Центральная Индия и Австралия юго-восток, Центральная Канада, Северная Европа.

Шаг 2. Настройка расширений виртуальной машины в шаблон Resource Manager

Сведения о регистрации виртуальных машин (с помощью расширения VM PowerShell DSC) можно найти в этом кратком руководстве по шаблонам Azure. На этом шаге новая виртуальная машина регистрируется на опрашивающем сервере в списке узлов State Configuration. В рамках этой регистрации указывается конфигурация узла, применяемая к узлу. Эта конфигурация узла может пока отсутствовать на опрашивающем сервере, поэтому вполне нормально, что впервые она указывается на шаге 4. Однако на данном шаге 2 нужно принять решение об имени узла и имени конфигурации. В этом примере использования узел называется isvbox, а конфигурация — ISVBoxConfig. Поэтому имя конфигурации узла (указываемое в DeploymentTemplate.json) имеет значение ISVBoxConfig.isvbox.

Шаг 3. Добавление необходимых ресурсов DSC на вытягивающий сервер

Коллекция PowerShell содержит средства для установки ресурсов DSC в учетной записи службы автоматизации Azure. Перейдите к нужному ресурсу и нажмите кнопку "Развернуть в службе автоматизации Azure".

PowerShell Gallery example

Недавно на портал Azure добавлена возможность получать новые модули и обновлять имеющиеся. Щелкните ресурс учетной записи службы автоматизации, плитку "Ресурсы" и, наконец, плитку "Модули". Значок "Обзор коллекции" позволяет просмотреть список модулей в коллекции, перейти к подробным сведениям и в конечном итоге импортировать модуль в учетную запись службы автоматизации. Это отличный способ периодически обновлять модули. Кроме того, во время импорта проверяется наличие зависимостей от других модулей, чтобы обеспечить полную синхронизацию.

Существует также ручной подход, используемый только один раз для каждого ресурса, если потом вы не будете его обновлять. Дополнительные сведения о разработке модулей интеграции PowerShell см. в статье Разработка модулей интеграции для службы автоматизации Azure.

Примечание.

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

  1. Установите Windows Management Framework 5 (не требуется для Windows 10).

  2. Установка модуля интеграции.

    Install-Module -Name MODULE-NAME`    <—grabs the module from the PowerShell Gallery

  3. Скопируйте папку модуля из расположения c:\Program Files\WindowsPowerShell\Modules\MODULE-NAME во временную папку.

  4. Удалите примеры и документацию из основной папки.

  5. Упакуйте основную папку, присвоив ZIP-файлу такое же имя, как у папки.

  6. Поместите ZIP-файл в легкодоступное расположение HTTP, например хранилище BLOB-объектов в учетной записи службы хранилища Azure.

  7. Выполните следующую команду.

    New-AzAutomationModule `
  -ResourceGroupName MY-AUTOMATION-RG -AutomationAccountName MY-AUTOMATION-ACCOUNT `
  -Name MODULE-NAME -ContentLinkUri 'https://STORAGE-URI/CONTAINERNAME/MODULE-NAME.zip'

Приведенный здесь пример выполняет эти действия для cChoco и xNetworking.

Шаг 4. Добавление конфигурации узла на сервер извлечения

В первоначальном импорте конфигурации на опрашивающий сервер и ее компиляции нет ничего особенного. Все последующие операции импорта и компиляции с этой конфигурацией выполняются аналогичным образом. Каждый раз, когда вам нужно обновить пакет и передать его в рабочую среду, перед этим шагом проверяйте правильность файла конфигурации (в том числе обновление версии пакета). Вот файл конфигурации ISVBoxConfig.ps1:

Configuration ISVBoxConfig
{
    Import-DscResource -ModuleName cChoco
    Import-DscResource -ModuleName xNetworking

    Node 'isvbox' {

        cChocoInstaller installChoco
        {
            InstallDir = 'C:\choco'
        }

        WindowsFeature installIIS
        {
            Ensure = 'Present'
            Name   = 'Web-Server'
        }

        xFirewall WebFirewallRule
        {
            Direction    = 'Inbound'
            Name         = 'Web-Server-TCP-In'
            DisplayName  = 'Web Server (TCP-In)'
            Description  = 'IIS allow incoming web site traffic.'
            Enabled       = 'True'
            Action       = 'Allow'
            Protocol     = 'TCP'
            LocalPort    = '80'
            Ensure       = 'Present'
        }

        cChocoPackageInstaller trivialWeb
        {
            Name      = 'trivialweb'
            Version   = '1.0.0'
            Source    = 'MY-NUGET-V2-SERVER-ADDRESS'
            DependsOn = '[cChocoInstaller]installChoco','[WindowsFeature]installIIS'
        }
    }
}

Ниже приведен скрипт New-ConfigurationScript.ps1 (измененный для использования модуля Az):

Import-AzAutomationDscConfiguration `
    -ResourceGroupName MY-AUTOMATION-RG -AutomationAccountName MY-AUTOMATION-ACCOUNT `
    -SourcePath C:\temp\AzureAutomationDsc\ISVBoxConfig.ps1 `
    -Published -Force

$jobData = Start-AzAutomationDscCompilationJob `
    -ResourceGroupName MY-AUTOMATION-RG -AutomationAccountName MY-AUTOMATION-ACCOUNT `
    -ConfigurationName ISVBoxConfig

$compilationJobId = $jobData.Id

Get-AzAutomationDscCompilationJob `
    -ResourceGroupName MY-AUTOMATION-RG -AutomationAccountName MY-AUTOMATION-ACCOUNT `
    -Id $compilationJobId

В результате этих действий на опрашиваемом сервере будет создана новая конфигурация узла с именем ISVBoxConfig.isvbox. Имя конфигурации узла строится как configurationName.nodeName.

Шаг 5. Создание и обслуживание метаданных пакета

Для описания каждого пакета, который помещается в репозиторий пакетов, необходимы метаданные Nuspec. Их следует компилировать и хранить на сервере NuGet. Этот процесс описан здесь.

В качестве сервера NuGet можно использовать сайт MyGet.org. Вы можете приобрести эту службу, но существует бесплатный начальный номер SKU. На сайте NuGet вы найдете инструкции по установке сервера NuGet для закрытых пакетов.

Шаг 6. Связать все вместе

Каждый раз, когда версия проходит контроль качества и утверждается для развертывания, создается пакет, а nuspec и nupkg обновляются и развертываются на сервере NuGet. Чтобы обеспечить согласованность с новым номером версии, необходимо обновить конфигурацию (шаг 4). Ее необходимо отправить на опрашиваемый сервер и скомпилировать.

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

Следующие шаги