적절한 Nuget 패키지 관리자 선택 및 IIS에 설정하는 방법 – techsyncer

당신은 응용 프로그램이나 중요한 스크립트 세트를 구축하고 패키지화하고 배포해야 할 필요가 있습니다. NuGet 및 다양한 NuGet 패키지 관리자를 사용하면 더 이상 찾을 필요가 없습니다.

이 문서에서는 처음으로 다양한 NuGet 패키지 관리자를 설정하여 즉시 사용할 수 있도록하는 방법을 배우게 됩니다.

NuGet.Server 래퍼 설정

NuGet.Server를 처음부터 설정하는 것은 그리 복잡하지 않지만, Visual Studio와 IIS에 익숙하지 않은 사람에게는 시간이 걸릴 수 있습니다. 설정 및 업데이트 프로세스를 가속화하는 한 가지 방법은 래퍼를 사용하는 것입니다. 가장 인기있는 래퍼 중 하나인 nuget-server는 svenkle가 작성한 것으로, 그들의 Github 페이지에서 찾을 수 있습니다.

이 래퍼를 사용할 때 웹 서버를 수동으로 설치하는 대신 IIS Express를 사용하는 것이 가장 큰 차이점입니다. 차이점에 대해 자세히 알아보려면 Microsoft의 웹 사이트를 참조하십시오.

바닐라 NuGet.Server를 설정하는 것과 이 래퍼와 함께 설정하는 것 사이에는 두 가지 중요한 차이점이 있습니다:

웹 서버를 시작하기 위해 Windows 서비스를 생성해야합니다.
구성에는 IIS 관리자를 사용할 수 없습니다.

NuGet.Server를 설치하기 위해 래퍼를 사용하는 주요 단점은 래퍼가 업데이트될 때까지 버전을 쉽게 업데이트할 수 없다는 것입니다.

전제 조건

NuGet.Server 래퍼를 설정하는 방법을 배우려면 먼저 다음을 확인해야 합니다:

svenkle의 NuGet.Server 래퍼 설치 프로그램
Windows Server – 현재 지원되는 Windows Server 버전은 모두 작동하지만, 모든 스크린샷은 Windows Server 2019 Standard에서 촬영되었습니다.

웹 서버 서비스 설치

첫 번째 단계는 새로운 Windows 서비스를 생성하는 것입니다. 이 NuGet.Server 래퍼는 IIS를 사용하지 않으므로 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 파일은 <UnzipPath>\Host\Website 폴더에 위치해 있습니다. 이 배포의 주요 차이점은 기본 HTTP 포트 80 대신 포트 8080을 사용한다는 것입니다. 따라서 웹 URL을 사용하는 모든 위치에서 :8080을 추가해야합니다. 웹 페이지에 액세스할 때 예를 들어 http://localhost:8080/nuget이 됩니다.

모두 완료되었습니다. Visual Studio를 사용하는 것보다 훨씬 쉬웠습니다!

IIS에서 BaGet 설정하기

지금까지 스톡 버전의 NuGet.Server만 살펴보았지만 다른 다양한 버전도 많이 있습니다. 인기있는 NuGet 패키지 관리자 중 하나는 BaGet이라는 오픈 소스 프로젝트입니다.

BaGet을 설치하고 Windows Server에서 IIS에서 실행하는 방법을 알아보겠습니다.

사전 요구 사항

시작하기 전에 몇 가지 사전 요구 사항을 충족하는지 확인하십시오.

BaGet.zip – 이 프로젝트는 아직 미리 릴리스 상태이며 v0.1.77을 사용하고 있습니다.
.NET Core 런타임 및 호스팅 번들 – 이것은 나중을 위해 웹 서버에 다운로드되어 있어야합니다.
Windows Server – 현재 지원되는 Windows Server 버전 중 어떤 버전이든 작동합니다. 하지만 모든 스크린샷은 Windows Server 2019 Standard에서 촬영되었습니다.

웹 서버 사전 설치

아래 단계는 .NET Core가 설치된 Linux나 Docker 이미지에서 실행할 수 있지만, 이 지침은 Windows 서버에 BaGet을 설치하는 데 사용됩니다. 이렇게 하면 IIS를 사용하여 서버를 시작하고 중지할 수 있습니다.

IIS 설치

BaGet은 .NET Core에서 실행되므로 이전에 IIS를 설치한 NuGet.Server와는 달리 요구 사항이 적습니다. 기본 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와 비슷하게, NuGet 패키지 관리자 BaGet을 사용하려면 몇 가지 IIS 구성을 설정해야 합니다.

BaGet IIS 응용 프로그램 풀 생성

웹 서버에서 IIS 관리자를 열고 응용 프로그램 풀로 이동합니다. BaGet을 사용할 때는 .NET 관리 코드를 사용하지 않으므로 새로운 응용 프로그램 풀을 생성해야 합니다. 원하는 이름으로 지정할 수 있습니다. 아래에는 구성해야 하는 방법이 나와 있습니다.

BaGet 웹사이트 생성

응용 프로그램 풀이 생성되었다면, 웹사이트를 생성하세요. BaGet은 비표준 HTTP 포트와 기본 앱 풀을 사용하므로 기본 웹 사이트(Default Web Site)에서 별도의 웹사이트를 생성하는 것이 가장 쉽습니다. 이를 위해 IIS 관리자에서 Sites 폴더를 마우스 오른쪽 버튼으로 클릭한 다음 웹 사이트 추가를 선택하세요.

아래는 BaGet을 구성해야 하는 설정입니다.

사이트를 구성한 후에는 자동으로 시작됩니다. 서버에서 http://localhost:5000/ 로 이동하여 확인할 수 있습니다.

BaGet 웹페이지에는 표준 NuGet.Server 웹페이지와 비교하여 더 많은 사용자 인터페이스가 있음을 알 수 있습니다. BaGet에서는 업로드된 패키지를 쉽게 검색할 수 있으며, NuGet 명령줄 옵션을 사용하는 대신 다양한 방법으로 업로드하는 명령을 제공합니다.

BaGet 웹 서버 사용자 정의

web.config 파일을 사용하여 NuGet.Server 서버를 사용자 정의할 수 있었다는 것을 기억하십시오. 그러나 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"
}

BaGet API 키

NuGet 서버를 무단 사용자로부터 패키지 게시 또는 삭제로부터 보호하기 위해 API 키를 설정해야 합니다. API 키 설정은 appsettings.json에도 있으므로, 거기에서 설정할 수 있습니다.

나는 NuGet 패키지를 관리하기 위해 PowerShell을 사용하고 있기 때문에 다시 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은 다양한 사용 옵션을 제공하지만, NuGet의 다른 영역에 특화된 BaGet 포크가 생성되었습니다. 가장 인기있는 포크 중 하나는 LiGet입니다. LiGet은 Linux를 우선적으로 고려하여 특별히 설계되었습니다.

LiGet은 BaGet의 원본 프로젝트에서 파생된 NuGet 패키지 관리자입니다. 개발자들이 이를 결정한 이유는 몇 가지가 있었지만, 주로 NuGet의 특정 기능에 집중하기 위해서였습니다. 그 중에서도 v3 피드 지원에 집중했습니다. v3 피드 지원은 PowerShell 사용 사례에는 영향을 주지 않습니다. 그러나 다른 사용 사례를 위해 NuGet 서버를 호스팅하려는 경우 추가 기능을 즐길 수 있습니다.

LiGet의 해시된 API 키

LiGet과 BaGet의 주요 차이점 중 하나는 평문 대신 해시된 API 키를 사용한다는 점입니다. 평문 키를 가진 사람이 NuGet.Server의 web.config 파일이나 BaGet의 appsettings.json 파일에 접근할 수 있다면 서버에 게시할 수 있습니다. 하지만 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 키를 잊어버리면 해시를 새로 생성하고 대체해야 한다는 점입니다. 해시는 되돌릴 수 없습니다.

IIS에서 ProGet 설정하기

지금까지 다루어진 모든 옵션은 무료이며 설정이 완료된 후에는 많은 이동 부품이 없습니다. 이는 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를 설정하고 있으므로 ProGet 설치 중 IIS 웹 서버 옵션을 선택합니다. IIS가 이미 설치되지 않은 경우 ProGet 설치 중에 설치가 처리됩니다.

나머지 옵션은 기본값으로 두십시오. 그렇지 않으면 ProGet 데이터베이스를 별도의 SQL 서버에 호스팅하려면 SQL 인스턴스를 지정해야 합니다. 만약 그렇게 하려면

SQL Server 옵션을 Install Inedo instance로 두면 SQL Express 서버가 설치됩니다.

설치가 완료되면 프롬프트에서 웹 사이트를 실행하면 아래 스크린샷과 같은 웹 페이지가 표시됩니다.

ProGet에 PSRepository 구성

이 시점에서 ProGet이 설치되었습니다. 이것은 매우 쉽습니다. NuGet 패키지와 작업하기 위해 PowerShell을 사용하기 때문에 이전에 수행한 것과 같이 PSRepository를 설정해야 합니다.

PSRepository를 설정하려면 Feeds 탭으로 이동하여 새로운 피드를 만듭니다. 피드의 이름은 원하는 대로 지정할 수 있습니다. 그런 다음 아래에 표시된 대로 Third-party package format 및 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 Keys를 선택하십시오. 여기에서 기존의 API 키를 볼 수 있으며 새로운 API 키를 생성할 수도 있습니다. 오픈 소스와 엔터프라이즈 ProGet 사이에는 즉시 주요한 차이점이 보입니다. ProGet에서는 여러 개의 API 키를 사용할 수 있습니다.

API Keys 화면에서 API 키 생성을 클릭합니다. 여기서 피드 API의 상자를 선택하고 API 키 저장을 클릭합니다.

API 키가 생성되면 API 키 페이지로 돌아갑니다. 여기에서 보이는 API 키를 사용하여 패키지를 피드에 게시할 수 있습니다.

ProGet에서 패키지 검색하기

ProGet에는 피드의 모든 NuGet 패키지를 검색하고 다운로드 수, PowerShell 모듈의 이름, 패키지가 업로드된 피드 등과 같은 유사한 패키지 통계를 볼 수 있는 웹 페이지가 포함되어 있습니다. 아래에 표시된 패키지 페이지에서 확인할 수 있습니다.

또는 피드 페이지로 이동하여 해당 피드에 대한 패키지만 볼 수 있습니다. 거기서 개별 패키지까지 들어가서 패키지에 대한 통계 및 기타 세부 정보를 확인할 수 있습니다. 아래에 표시된 것과 같습니다.

ProGet 업데이트하기

기업용 제품을 사용하는 경우 일부 시간이 걸리는 관리 작업이 훨씬 빠릅니다. ProGet 업데이트가 좋은 예입니다.

최신 버전의 ProGet으로 업데이트하려면 웹 서버에서 Inedo 설치 관리자를 엽니다. 이것은 ProGet을 처음 설치했을 때 설치되었습니다. 아래에 표시된 업그레이드 버튼을 클릭하면 설치 관리자가 나머지 작업을 수행합니다.

NuGet 패키지 관리자 비교

이 글에서 다양한 NuGet 도구에 대해 많이 알게 되었습니다. 아직 시도해 볼 도구를 찾고 있다면 이 섹션에서 각 도구의 차이점을 살펴볼 수 있습니다.

BaGet 대 LiGet

LiGet은 BaGet의 분기 버전이므로 설정 프로세스를 포함하여 많은 유사한 점을 공유합니다. 사실, BaGet과 정확히 동일한 설정 절차를 따를 수 있습니다.

설치한 후에도 LiGet과 BaGet은 일부 기능을 공유하지만 다른 점도 있습니다.

Feature	BaGet	LiGet
Web Port	5000	9011
Source URL	/v3/index.json	/api/v3/index.json
NuGet Search API	v2	v3
API Key	Plain Text	SHA256 hash
Web Interface	Can see list of packages and commands to upload	No web interface

이러한 차이점 대부분은 PowerShell과의 사용에 영향을 미치지 않지만, 설정은 해시된 API 키를 사용하기 때문에 약간 변경됩니다.

BaGet과 LiGet은 모두 .NET Core로 구축되어 있어 Linux 운영 체제뿐만 아니라 Windows에서도 사용할 수 있습니다. 또한 Docker 이미지도 사용할 수 있으며, 이미 컨테이너 서비스를 사용하고 있다면 설정을 훨씬 빠르고 이식성 있게 만들 수 있습니다.

LiGet과 BaGet 사이의 몇 가지 차이점으로 인해 둘 중 어느 것이든 오픈 소스이고 컨테이너 친화적인 NuGet 서버의 훌륭한 옵션이 될 수 있습니다. 두 옵션 모두 Windows에서 NuGet 서버를 시작하면서 Linux 또는 Docker 이미지로 이동할 때 추가 작업이 거의 필요하지 않도록 해줍니다.

BaGet vs ProGet

일부 정도까지는 직접 구현하지 않고 쉬운 방법을 선택하려면 ProGet을 이용할 수도 있습니다. 그러나 단점도 있습니다. ProGet은 오픈 소스가 아니며 무료가 아닙니다. 그러나 설정 및 작업이 더 쉽습니다.

ProGet과 BaGet 사이에는 몇 가지 주요한 차이점이 있습니다.

Feature	ProGet	BaGet
Cost	ProGet Free: Free, ProGet Basic: $1995/yr, ProGet Enterprise: $9995+/year	Free
Platform	Windows	Windows, Linux, Docker
Database	SQL	Internal
Support	ProGet Free: Email and Slack support, ProGet Basic and Enterprise: Defined SLAs with Email, Slack and Phone support	Community based through GitHub issues

Inedo는 ProGet 버전 간의 기능 차이점을 자세히 설명하고 있습니다.

요약

이 기사에서는 다양한 NuGet 도구와 기술에 대해 많은 것을 배웠습니다. NuGet 서버를 사용할지 말지 결정하는 데 많은 도움이 될 지식을 얻었습니다.

각 NuGet 도구를 Windows와 함께 설정하는 방법과 각 도구의 많은 기능에 대해 배웠습니다.