Выбор правильного менеджера пакетов Nuget и его настройка с IIS

Вы создали приложение или, возможно, даже набор важных скриптов и хотите его упаковать и развернуть. Не ищите дальше, чем NuGet и различные менеджеры пакетов NuGet, которые у вас есть на выбор.

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

Связано: Настройка сервера NuGet под Windows (полное руководство)

Настройка оболочки NuGet.Server

Хотя настройка NuGet.Server с нуля не слишком сложна, это может занять некоторое время для тех, кто впервые работает с Visual Studio и IIS. Способ ускорить процесс установки и обновления – использовать оболочку. Одной из самых популярных оболочек, называемой nuget-server, является та, написанная svenkle и доступная на их странице Github.

Одно из основных отличий использования этой оболочки вместо ручной установки веб-сервера состоит в том, что она использует IIS Express. Подробнее о различиях можно прочитать на веб-сайте Microsoft.

Существуют два важных отличия между настройкой обычного NuGet.Server и с использованием этой оболочки:

• вам необходимо создать службу Windows для запуска веб-сервера
• вы не можете использовать Менеджер IIS для настройки.

Основным недостатком использования обертки для установки NuGet.Server является то, что вы не можете легко обновить версию до тех пор, пока обертка не будет обновлена.

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

Если вы хотите узнать, как настроить эту обертку NuGet.Server, вам сначала нужно убедиться, что у вас есть следующее:

• Установщик обертки NuGet.Server от svenkle
• Windows Server – Любая поддерживаемая версия Windows Server будет работать, но все скриншоты были сделаны на Windows Server 2019 Standard

Установка службы веб-сервера

Первый шаг – создание новой службы Windows. Поскольку эта обертка NuGet.Server не использует IIS, вы не можете использовать его.

Скачайте файл NuGetServer.zip с страницы релизов и распакуйте его в выбранную вами директорию на веб-сервере. После распаковки создайте службу Windows, которая автоматически запустит веб-страницу при запуске сервера. Ниже вы найдете команду PowerShell, чтобы сделать это за вас.

New-Service -Name NuGetServer -BinaryPathName '<UnzipPath>\Svenkle.NuGetServer.Service.exe' -StartupType Automatic
Start-Service -Name NuGetServer

Настройка веб-сервера

Теперь, когда у вас установлен NuGet.Server из оболочки, и служба создана и запущена, пришло время настроить файл web.config. Вы можете внести те же изменения, которые вы бы внесли в файл web.config при ручном развертывании, если хотите.

Файл web.config находится в папке <Путь к распаковке>\Host\Website. Основное отличие этого развертывания заключается в том, что он использует порт 8080 вместо стандартного HTTP-порта 80. Это означает, что везде, где вы использовали веб-URL, вам нужно добавить :8080, например, при переходе на веб-страницу это будет http://localhost:8080/nuget.

Все готово. Это было намного проще, чем использование Visual Studio!

Настройка BaGet в IIS

Пока вы изучали только стандартные версии NuGet.Server, существует множество других доступных версий. Одним из популярных менеджеров пакетов NuGet является проект с открытым исходным кодом под названием BaGet.

Давайте посмотрим, что нужно сделать, чтобы установить и запустить BaGet на сервере Windows с помощью IIS.

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

Прежде чем начать, убедитесь, что у вас есть несколько предварительных требований.

• BaGet.zip – На момент написания этого руководства проект все еще находится в предварительной версии, и я использую v0.1.77
• .NET Core Runtime & Hosting Bundle – Это нужно будет загрузить и иметь на веб-сервере для последующего использования.
• Windows Server – Любая текущая поддерживаемая версия Windows Server будет работать, но все снимки экрана были сделаны на Windows Server 2019 Standard

Установка предварительных требований для веб-сервера

Хотя нижеследующие шаги могут быть выполнены на Linux с .NET Core или в Docker-образе, эти инструкции будут использоваться для установки BaGet на сервер Windows. Таким образом, вы сможете воспользоваться IIS для запуска и остановки вашего сервера.

Установите IIS

Поскольку BaGet работает на .NET Core, для этого не требуется так много требований, как для базового сервера NuGet, для которого вы установили IIS ранее. Вам нужен только веб-сервер IIS по умолчанию и менеджер IIS. Чтобы установить их, откройте сеанс PowerShell на вашем веб-сервере и выполните следующую команду:

Install-WindowsFeature Web-Server -IncludeManagementTools

Установите .NET Core

Затем установите пакет .NET Core на веб-сервере. Для этого запустите ранее загруженный исполняемый файл .exe. Вы можете оставить все параметры установки по умолчанию.

Пакет .NET Core должен быть установлен после установки IIS. Если это не произошло в правильном порядке, вам придется повторно запустить установщик пакета .NET Core и выбрать режим восстановления, чтобы добавить недостающие требования для веб-приложения.

Теперь, когда у вас есть готовые компоненты веб-сервера, разархивируйте ранее загруженный файл BaGet.zip и поместите его в папку C:\inetpub\wwwroot на вашем веб-сервере.

Настройка приложения веб-сервера

Аналогично NuGet.Server, вам необходимо настроить несколько компонентов IIS, чтобы запустить менеджер пакетов NuGet BaGet.

Создание пула приложений BaGet IIS

Откройте Менеджер IIS на веб-сервере и перейдите к Пулам приложений. Создайте новый пул приложений для BaGet, так как он не будет использовать управляемый код .NET. Вы можете назвать его, как хотите. Ниже показано, как это должно выглядеть.

Создание веб-сайта BaGet

После создания пула приложений создайте веб-сайт. Поскольку BeGet использует нестандартный HTTP-порт и нестандартный пул приложений, самым простым будет создание отдельного веб-сайта из Веб-сайта по умолчанию. Для этого щелкните правой кнопкой мыши на папке Сайты в Менеджере IIS и выберите Добавить веб-сайт.

Ниже приведены настройки, которые вам нужно настроить для BaGet.

После настройки сайта он должен автоматически запуститься. Вы можете посмотреть его, перейдя по адресу http://localhost:5000/ с вашего сервера.

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

Настройка веб-сервера BaGet

Вспомните, что вы могли настроить свой сервер NuGet.Server, используя файл web.config. Но менеджер пакетов NuGet BaGet не использует файл web.config. Вместо этого, поскольку BaGet также может использоваться в Linux, разработчики выбрали более кросс-платформенный формат с файлом JSON под названием appsettings.json. Он расположен в папке C:\inetpub\wwwroot\BaGet.

Обратите внимание, что, поскольку BaGet использует .NET Core для кросс-платформенного функционала, все пути используют прямые слеши.

Например, если вы хотите иметь путь к вашему пакету в C:\Packages на вашем сервере, вам нужно будет иметь то, что показано ниже в файле appsettings.json.

"Storage": {
    "Type": "FileSystem",
    "Path": "C://Packages"
}

Ключ API BaGet

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

Поскольку я использую PowerShell для управления моими пакетами NuGet, я снова могу зарегистрировать PSRepository. Для BaGet перейдите на созданную вами веб-страницу. Веб-страница предоставит вам команду для выполнения в вашей сессии PowerShell. Например:

Register-PSRepository -Name "BaGet" -SourceLocation "http://<WebServer>:5000/v3/index.json" -PublishLocation "http://<WebServer>:5000/api/v2/package" -InstallationPolicy "Trusted"

Понимание форков BaGet (LiGet)

Хотя BaGet предоставляет много вариантов использования, были созданы другие форки BaGet, которые специализируются в других областях NuGet. Один из самых популярных форков – LiGet. LiGet отличается тем, что ориентирован на использование в Linux в первую очередь.

LiGet – это менеджер пакетов NuGet, созданный на основе оригинального проекта BaGet. Разработчики приняли решение сделать это по нескольким причинам, но в основном для того, чтобы сосредоточиться на некоторых конкретных возможностях NuGet, включая поддержку в3-канала. Поддержка в3-канала не влияет на использование PowerShell. Однако, если вы собираетесь использовать сервер NuGet для других целей, вам может понравиться дополнительный функционал.

Хешированный API-ключ LiGet

Одно из основных отличий LiGet от BaGet – это использование хешированного API-ключа вместо обычного текста. При наличии обычного текстового ключа кто-то, кто имеет доступ к файлу web.config на сервере NuGet.Server или appsettings.json на сервере BaGet, может опубликовать пакеты на сервере. Этого не может произойти с LiGet.

Чтобы запустить LiGet, вам потребуется создать хешированный API-ключ и поместить его в файл appsettings.json в папке C:\inetpub\wwwroot\LiGet.

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

([System.Security.Cryptography.HashAlgorithm]::Create('SHA256').ComputeHash([System.Text.Encoding]::UTF8.GetBytes(<apikey>)) | 
Foreach-Object { $_.ToString('x2')}) -join ''

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

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

Настройка ProGet на IIS

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

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

Для установки ProGet вам понадобятся некоторые общие предварительные требования, с которыми вы, вероятно, уже знакомы, но с дополнительным вариантом использования SQL-базы данных.

• Windows Server – Подойдет любая поддерживаемая версия Windows Server, но все снимки экрана были сделаны на Windows Server 2019 Standard
• Установщик ProGet – Версия ProGet, которую я использую, – 5.2.9.
• SQL-экземпляр – Это необязательно, так как ProGet имеет опцию установки SQL Express из установщика, хотя для начальной загрузки требуется подключение вашего сервера к Интернету

Установка ProGet

Запустите установщик ProGet с вашего веб-сервера. Поскольку вы настраиваете IIS, выберите опцию веб-сервер IIS при установке ProGet. Если у вас еще не установлен IIS, он будет установлен во время установки ProGet.

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

Если оставить параметр SQL Server как Установить экземпляр Inedo, он установит для вас сервер SQL Express.

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

Настройка PSRepository в ProGet

На этом этапе ProGet установлен. Это довольно просто. Поскольку мы используем PowerShell для работы с пакетами NuGet, нам нужно настроить PSRepository, как мы делали ранее.

Для настройки ProGet для PSRepository перейдите на вкладку Feeds и создайте новую ленту. Вы можете дать ленте любое имя. Затем выберите Формат пакета сторонних поставщиков и PowerShell, как показано ниже.

После создания ленты вернитесь на вкладку Feeds, выберите вашу новую ленту, и она покажет URL-адрес, используемый для публикации. Это то, что вам нужно будет запустить в PowerShell на устройстве для публикации или загрузки из этого PSRepository.

Ниже показано, что было показано на приведенном выше примере:

Register-PSRepository -Name ProGet -SourceLocation http://<WebServer>:8624/nuget/PSRepository/ -PublishLocation http://<WebServer>:8624/nuget/PSRepository/ -InstallationPolicy Trusted

Добавление ключа API

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

На экране Ключи API нажмите Создать ключ API. Здесь установите флажок для API каналов и нажмите Сохранить ключ API.

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

Поиск пакетов с помощью ProGet

ProGet также включает веб-страницу, которая позволяет вам искать все пакеты NuGet в канале, видеть количество их загрузок, имя модулей PowerShell, в который был загружен пакет, и другую подобную информацию о пакетах на странице Пакеты, как показано ниже.

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

Обновление ProGet

Одна из приятных особенностей использования продукта, предназначенного для предприятий, заключается в том, что некоторые более трудоемкие административные задачи выполняются намного быстрее. Примером такого является обновление ProGet.

Чтобы обновить ProGet до последней версии, просто откройте программу-установщик Inedo на вашем веб-сервере. Она была установлена вместе с ProGet. Нажмите кнопку Обновить, как показано ниже, и установщик сделает всё остальное за вас.

Сравнение менеджеров пакетов NuGet

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

BaGet против LiGet

Поскольку LiGet является копией BaGet, они имеют много общих черт, включая большую часть процесса установки. Фактически, вы можете следовать точно такой же процедуре установки, как для BaGet.

После установки LiGet и BaGet действительно имеют некоторые общие функции, но отличаются друг от друга.

Хотя большинство этих различий не влияют на использование с PowerShell, процесс установки немного изменяется из-за использования хешированного ключа API.

И BaGet, и LiGet созданы на базе .NET Core, что делает их кросс-платформенными и пригодными для использования в операционных системах Linux, а также Windows. Оба также имеют доступные образы Docker, которые, если вы уже используете контейнерный сервис, могут существенно ускорить и упростить процесс установки.

С учетом небольших различий между LiGet и BaGet, любой из них – отличный выбор для открытого сервера NuGet, совместимого с контейнерами. Оба варианта позволяют начать работу с сервером NuGet на Windows и затем перейти на Linux или образ Docker в будущем, не прилагая особых усилий.

BaGet против ProGet

Если вы предпочитаете не заниматься созданием своего собственного сервера, всегда есть вариант использовать ProGet. Однако есть и недостатки. ProGet не является открытым исходным кодом и не является бесплатным. Но он более прост в установке и использовании.

Есть несколько основных различий между ProGet и BaGet.

Inedo также предоставляет сравнение всех различий в функциональности между версиями ProGet.

Вывод

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

Вы узнали, как настроить каждый инструмент NuGet для работы с Windows, и мы рассмотрели множество возможностей каждого инструмента.