블로그 | NGINX

튜토리얼: NGINX 및 NGINX Plus를 사용한 .NET Core 및 Kestrel 프록싱

NGINX-F5-수평-검정-유형-RGB의 일부
닉 샤드린 썸네일
닉 샤드린
2017년 2월 14일 게시

약 2년 전 Microsoft®는 Linux 및 Mac 시스템에서 .NET 애플리케이션을 기본적으로 개발하고 실행할 수 있는 프레임워크인 .NET Core를 발표했습니다. ASP.NET Core에는 내부 웹 서버 라이브러리인 Kestrel이 포함되어 있습니다.

Microsoft 웹사이트 와 GitHub 저장소 의 Kestrel 설명서에 나와 있듯이 일반적으로 Kestrel은 IIS나 NGINX와 같은 프로덕션 웹 서버 뒤에서 실행합니다. 이 튜토리얼에서는 NGINX와 NGINX Plus 뒤에서 Kestrel을 구현하는 방법을 설명합니다.

이 튜토리얼에서는 다음 방법을 배우게 됩니다.

설치 및 구성이 완료되면:

  • .NET Core 및 Kestrel:

    • 동적 애플리케이션 코드 실행
    • 로컬 IP 주소를 수신하고 HTTP 요청에 응답합니다.

  • NGINX 또는 NGINX Plus는 역방향 프록시 역할을 합니다.

    • IPv6 및 IPv4를 통한 HTTP/2 트래픽 허용
    • .NET 애플리케이션에 대한 SSL 오프로드를 제공합니다.
    • 정적 파일 제공
    • 접근 로그를 제공합니다
    • 캐싱을 추가합니다

  • NGINX 플러스:

    • 실시간 활동 모니터링 및 메트릭 제공
    • 활성 상태 검사를 통해 앱이 작동하는지 확인합니다.

.NET Core 애플리케이션 배포 아키텍처는 Node.js 또는 Go 애플리케이션의 배포 아키텍처와 유사합니다. NGINX는 .NET 앱에 트래픽 관리 기능을 제공하여 앱의 프로덕션 배포와 확장성을 간소화합니다. 동일한 머신이나 다른 머신에서 여러 .NET 애플리케이션을 실행할 수 있으며, NGINX 또는 NGINX Plus는 이러한 애플리케이션 간의 부하 분산과 지능형 트래픽 라우팅을 수행합니다.

지침

다음 지침에서는 .NET Core를 사용하여 "Hello World" 앱을 빠르게 빌드하고 Linux에서 실행하고 고급 트래픽 관리 기능이 있는 NGINX 또는 NGINX Plus 역방향 프록시 뒤에 배포하는 방법을 설명합니다.

  1. .NET Core, NGINX 및 NGINX Plus 설치
  2. “Hello World” 앱을 실행하세요
  3. Kestrel HTTP 서버 실행
  4. NGINX 또는 NGINX Plus를 구성하여 .NET 애플리케이션 역방향 프록시
  5. NGINX Plus 라이브 활동 모니터링 및 활성 상태 확인 구성

.NET Core, NGINX 및 NGINX Plus 설치

  1. Microsoft 웹사이트의 지침 에 따라 .NET Core를 설치합니다.

    우리의 예에서는 Ubuntu 16.04를 사용하고 있습니다. 다음 명령은 이 글을 쓸 당시에는 정확했지만, Kestrel은 아직 개발 중이기 때문에 변경될 수 있습니다. 필요에 따라 .NET Core 설명서를 참조하세요.

    $ sudo apt-get apt-transport-https 설치 $ sudo sh -c '에코 "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ xenial main" > /etc/apt/sources.list.d/dotnetdev.list" $ sudo apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893 $ sudo apt-get 업데이트 $ sudo apt-get dotnet-dev-1.0.0-preview2-003131 설치

  2. NGINX 설치:

    $ sudo apt-get nginx 설치

  3. 실시간 활동 모니터링이나 활성 상태 확인, 또는 둘 다를 원하시면 NGINX Plus를 설치하세요. NGINX Plus 관리자 가이드 의 지침을 참조하세요.

    1. ./project.json 파일을 편집하여 Kestrel을 프로젝트의 종속성으로 추가합니다.

      { "버전": "1.0.0-*", "buildOptions": { "debugType": "이식형", "emitEntryPoint": true }, "종속성": {}, "프레임워크": { "netcoreapp1.0": { "종속성": { "Microsoft.NETCore.App": { "유형": "플랫폼", "버전": "1.0.1" } , "Microsoft.AspNetCore.Server.Kestrel": "1.0.0" }, "가져오기": "dnxcore50" } } }

    2. 간단한 앱의 이 코드를 Program.cs 라는 새 파일에 복사합니다. 로컬 호스트의 포트 5000에서 Kestrel을 실행하여 현재 날짜와 시간을 반환합니다.

      using System;using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;

네임스페이스 ConsoleApplication
{
public class Program
{
public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseKestrel()
.Configure(app =>
{
app.Run(async (context) => await context.Response.WriteAsync("현재 날짜: " + DateTime.Now + "n"));
})
.Build();

host.Run();
}
}
}

    3. dotnet run 명령을 실행하여 .NET Core 서버를 시작합니다.

      $ dotnet run 프로젝트 앱(.NETCoreApp,Version=v1.0)은 입력이 수정되었기 때문에 컴파일됩니다. .NETCoreApp,Version=v1.0에 대한 앱을 컴파일하는 중 컴파일이 성공했습니다.
    0 경고 0 오류 경과 시간 00:00:01.9047678 안녕하세요!
호스팅 환경: 프로덕션 콘텐츠 루트 경로: /app/bin/Debug/netcoreapp1.0 현재 수신 대기 위치: http://localhost:5000 애플리케이션이 시작되었습니다. Ctrl+C를 눌러 종료하세요.

    4. curl 명령을 실행하여 연결 및 HTTP를 테스트합니다.

      $ curl -v localhost:5000 * localhost:5000/로 URL을 다시 작성했습니다. * 시도 중 ::1... * 로컬 호스트(::1) 포트 5000(#0)에 연결되었습니다. > GET / HTTP/1.1 > 호스트: localhost:5000 > 사용자 에이전트: curl/7.47.0 > 수락: */* > < HTTP/1.1 200 OK < 날짜: 화, 2017년 2월 14일 19:50:59 GMT < 전송 인코딩: 청크 < 서버: 케스트럴 < 현재 날짜: 02/14/17 12:50:59 PM * 호스트 localhost에 대한 연결 #0이 그대로 유지됨

    1. SSL 인증서를 설치하세요. 이를 얻는 방법은 여러 가지가 있습니다.

      • 잘 알려진 인증 기관(CA)에서 구매하세요
      • 회사 IT 그룹이나 CA에서 생성하도록 하세요.
      • 기존 IIS 서버에서 내보내기
      • Let's Encrypt 와 같은 무료 CA를 사용하세요
      • 자체 서명된 인증서를 직접 생성하세요

      SSL을 사용하여 샘플 .NET Core 앱을 빠르게 구축하기 위해 이 openssl 명령을 사용하여 자체 서명된 인증서와 관련 키를 생성합니다. 여기서는 NGINX의 표준 위치인 /etc/nginx 에 인증서와 키를 설치하지만 다른 위치를 선택할 수 있습니다.

      $ openssl req -x509 -subj /CN=localhost -days 365 -set_serial 2 -newkey rsa:4096 -keyout /etc/nginx/cert.key -nodes -out /etc/nginx/cert.pem 4096비트 RSA 개인 키 생성 .........++ ............................++ '/etc/nginx/cert.key'에 새 개인 키 쓰기 -----

    2. HTTP 가상 서버에 대한 기본 NGINX 및 NGINX Plus 구성 파일에서 역방향 프록시를 구성합니다.

      NGINX 및 NGINX Plus의 주요 구성 파일은 /etc/nginx/nginx.conf 입니다. 그러나 여러 NGINX 배포판(NGINX Plus 포함)은 주 파일에 실제 구성을 많이 두지 않고 대신 /etc/nginx 하위 디렉터리에 더 작고 기능별 파일을 만드는 관례를 따릅니다.

      • nginx.org 에서 제공하는 NGINX 오픈 소스 빌드와 NGINX Plus의 경우 디렉토리는 /etc/nginx/conf.d 이고, HTTP 가상 서버의 기본 파일은 default.conf 입니다.
      • Ubuntu와 함께 배포되는 NGINX 오픈 소스 빌드의 경우 디렉토리는 /etc/nginx/sites-enabled 이고, HTTP 가상 서버의 기본 파일은 default 입니다.

      이러한 디렉토리의 기능별 파일의 내용은 include 지시문과 함께 기본( nginx.conf ) 파일에 읽혀집니다. 예:

      /etc/nginx/conf.d/*.conf를 포함합니다. /etc/nginx/sites-enabled/*를 포함합니다.

      시스템의 HTTP 가상 서버에 대한 기본 구성 파일이 무엇인지 확실하지 않으면 /etc/nginx/nginx.conf 에서 관련 include 지침을 찾으세요.

      NGINX 또는 NGINX Plus를 역방향 프록시로 구성하려면 HTTP 가상 서버의 기본 구성 파일에 다음 세 가지 구성 블록을 추가합니다.

      • 첫 번째 서버 블록은 포트 80에서 HTTP 요청을 수락하고 이를 HTTPS 요청을 위한 가상 서버로 리디렉션합니다.

      • 두 번째 서버 블록은 포트 443에서 HTTPS 요청을 수락하고 이를 dotnet 이라고 하는 하나 이상의 업스트림(백엔드) 서버 그룹으로 프록시합니다. (1단계에서 /etc/nginx 가 아닌 다른 디렉토리에 자체 서명된 SSL 인증서를 설치한 경우 ssl_certificate 및 ssl_certificate_key 지시문에서 올바른 경로로 대체합니다.)

      • 업스트림 블록은 백엔드 서버의 dotnet 그룹을 정의합니다.

        Kestrel HTTP 서버 실행 에서 Kestrel을 localhost:5000 에 구성했는데, 이는 해당 포트에서 IPv4 및 IPv6 트래픽을 모두 수신한다는 의미입니다. (Kestrel을 단 하나의 프로토콜에 대해서만 구성하면 불안정성이 발생할 수 있으며 잠재적으로502 오류.) 마찬가지로 NGINX와 NGINX Plus는 localhost를 IPv4와 IPv6 주소(127.0.0.1 및 ::1)로 확인합니다. 단순화를 위해 여기서 우리는 업스트림 서버를 다음과 같이 식별합니다.127.0.0.1 localhost 대신 IPv4 트래픽만 수신합니다. IPv6를 포함한 고급 구성에 익숙하다면 localhost를 사용할 수 있습니다.

      서버 { 수신 80 기본 서버;
수신 [::]:80 기본 서버;
반환 301 https://$host$request_uri;
}

서버 {
수신 443 ssl http2 기본 서버;
수신 [::]:443 ssl http2 기본 서버;

ssl_certificate /etc/nginx/cert.pem;
ssl_certificate_key /etc/nginx/cert.key;

위치 / {
proxy_pass http://dotnet;
proxy_set_header 호스트 $host;
}
}

업스트림 dotnet {
존 dotnet 64k;
서버 127.0.0.1:5000;
}

    3. HTTPS를 통해 .NET Core 앱에 대한 연결을 테스트하려면 이 curl 명령을 실행하세요. (또한 브라우저를 Linux 서버로 지정할 수도 있습니다.)

      $ curl -kv https://localhost * https://localhost/로 URL을 다시 작성했습니다. * 시도 중 ::1... * 로컬호스트(::1) 포트 443(#0)에 연결되었습니다...[ 건너뜀 ]... < HTTP/1.1 200 OK < 서버: nginx/1.10.0(Ubuntu) < 날짜: 화, 14 2월 2017 20:22:07 GMT < 전송 인코딩: 청크 < 연결: keep-alive < 현재 날짜: 02/14/17 1:22:07 오후

      메모: 만약 당신이 보면 502Bad Gateway 오류는 NGINX 또는 NGINX Plus가 .NET 애플리케이션에 연결할 수 없다는 것을 의미합니다. 포트 5000에서 실행되고 응답을 처리하는지 확인하세요.

      nghttp2 패키지를 설치했다면 다음 nghttp 명령을 실행하여 HTTP/2를 통한 연결을 테스트할 수도 있습니다. 다음 예에서 주황색으로 강조된 줄을 찾아보세요. 꽤 긴 출력의 시작 부분 근처에 있습니다.

      $ nghttp -v https://localhost [ 0.000] 연결됨 협상된 프로토콜: h2 [ 0.009] SETTINGS 프레임 전송(niv=2) [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100] [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535] [ 0.009] PRIORITY 프레임 전송(dep_stream_id=0, weight=201, exclusive=0)
    • 응답 코드는 200좋아요
    • 앱 서버는 Kestrel이며 다른 소프트웨어가 아닙니다.
    • 응답 본문에는 "현재 날짜"라는 단어가 포함됩니다.
    • 앱은 1초의 시간 초과 기간 내에 응답합니다.

    4. “Hello World” 앱을 실행하세요

    선택한 부모 디렉토리에 "Hello World" 앱을 설치하고 초기화합니다.

    $ cd parent-dir-for-apps $ mkdir 앱 $ cd 앱 $ dotnet 복원

    앱이 작동하는지 확인하려면 dotnet run 명령을 실행하세요.

    Kestrel HTTP 서버 실행

    이 시점에서 .NET Core는 Linux에서 실행 중이며 Kestrel을 HTTP 서버로 사용하여 동적 데이터를 제공합니다.

    NGINX 또는 NGINX Plus를 구성하여 .NET 애플리케이션 역방향 프록시

    NGINX 또는 NGINX Plus를 .NET 애플리케이션의 역방향 프록시로 사용하면 SSL/TLS, HTTP/2 지원 및 .NET Core 애플리케이션이 실행되는 동일한 머신에서 빠른 애플리케이션 제공을 위한 여러 다른 기능으로 보안을 쉽게 구성할 수 있습니다. 다음 지침에서는 NGINX와 NGINX Plus가 이미 시스템에 설치되어 있다고 가정합니다. 그렇지 않은 경우 .NET Core, NGINX 및 NGINX Plus 설치를 참조하세요.

    NGINX Plus 라이브 활동 모니터링 및 활성 상태 확인 구성

    이 시점에서 .NET Core를 사용한 NGINX 또는 NGINX Plus의 기본 구성이 완료되었습니다. NGINX 또는 NGINX Plus는 .NET Core 앱에 대한 HTTP 처리, 수동 상태 검사, SSL/TLS를 통한 보안, HTTP/2 연결을 제공합니다.

    NGINX Plus를 설치했다면 라이브 활동 모니터링과 활성 상태 검사라는 두 가지 추가 기능을 구성할 수 있습니다.

    라이브 활동 모니터링 구성

    [편집자 - 이 섹션은 원래 여기에서 논의된 별도의 확장된 Status 모듈을 대체하고 더 이상 사용되지 않는 NGINX Plus API를 참조하도록 업데이트되었습니다.]

    HTTP 가상 서버의 기본 NGINX 구성 파일에 다음 서버 블록을 추가합니다. 통계 및 지표에 대한 액세스를 제한하는 것이 좋습니다. 여기서는 로컬 호스트와 로컬 네트워크에 있는 사용자에게만 액세스를 허용합니다.

    라이브 활동 모니터링에 대한 자세한 내용은 블로그의 3가지 간단한 단계로 NGINX Plus의 라이브 활동 모니터링 과 NGINX Plus 관리자 가이드를 참조하세요.

    server { listen 8080;
allow 127.0.0.1; # localhost가 통계에 액세스하도록 허용
allow 10.3.3.0/24; # 로컬 네트워크가 통계에 액세스하도록 허용
deny all; # 다른 곳에서 액세스 차단

root /usr/share/nginx/html;

location / {
return 302 /dashboard.html;
}

location /api {
api write=on;
}

location = /dashboard.html {
root /usr/share/nginx/html;
}

# 이전 대시보드로 요청 리디렉션
location = /status.html {
return 301 /dashboard.html;
}
}

    활성 상태 검사 구성

    활성 상태 검사를 통해 NGINX Plus가 올바르게 작동하는 애플리케이션에만 트래픽을 전송하도록 보장합니다. NGINX Plus가 앱에 주기적으로 보내는 HTTP 요청과 앱이 정상으로 간주되기 위해 반환해야 하는 응답 유형을 정의합니다.

    여기서는 앱의 응답이 다음 조건을 충족해야 합니다.

    HTTP 가상 서버의 기본 구성 파일에서 다음 위치 블록을 주 서버 블록( .NET 애플리케이션의 역방향 프록시를 위한 NGINX 또는 NGINX Plus 구성 의 2단계에서 정의한 HTTPS 트래픽 블록)에 추가합니다.

    위치 @healthcheck { proxy_pass http://dotnet;
proxy_set_header 호스트 localhost;
health_check match=currentdate;
proxy_connect_timeout 1초;
proxy_read_timeout 1초;
}

    또한 계층 구조에서 서버 및 업스트림 블록과 같은 수준에 다음 일치 블록을 추가합니다.

    match currentdate { status 200;
header Server = Kestrel;
body ~ "현재 날짜";
}

    내장된 라이브 활동 모니터링 대시보드의 업스트림 탭에서 백엔드 앱이 정상인지 확인할 수 있습니다(브라우저에서 //http:// nginx-plus-server-address :8080/을 입력하세요).

    NGINX Plus 라이브 활동 모니터링 대시보드는 NGINX가 프록시하는 백엔드 .NET 애플리케이션의 상태를 보고합니다.

    추가 NGINX 구성 옵션은 Microsoft 설명서를 참조하세요.

    결론

    ASP.NET, NGINX 및 NGINX Plus로 개발한 앱을 프로덕션에 바로 배포할 수 있도록 하면 역방향 프록시에 필요한 트래픽 관리 기능을 활용할 수 있습니다. NGINX와 NGINX Plus는 .NET Core 애플리케이션에 대한 HTTP 요청에 대한 보안, 확장성, 인증, 트래픽 제한 및 지능적 라우팅을 제공합니다.

    NGINX Plus를 직접 사용해보려면 오늘 무료 30일 체험판을 시작하거나 저희에게 연락해 사용 사례에 대해 논의해 보세요 .

F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."