2.2부 - Nginx를 설치하고 역방향 프록시 서버로 구성

아티클
03/21/2024

적용 대상: .NET Core 2.1, .NET Core 3.1, .NET 5

이 문서에서는 Nginx를 설치하고 역방향 프록시 서버로 구성하는 방법을 소개합니다.

필수 구성 요소

이 부분의 연습을 수행하려면 웹 애플리케이션을 만들고 /var 폴더에 배포하는 ASP.NET Core 하나 있어야 합니다.

이 부분의 목표

이전 부분에서는 .NET CLI 도구를 사용하여 ASP.NET Core 웹 애플리케이션을 만들었으며 애플리케이션은 /var 폴더에 배포됩니다. 또한 애플리케이션은 HTTP 요청에 대해 포트 5000에서 수신 대기하도록 구성되었으며 HTTPS 리디렉션이 제거되었습니다.

이 시점에서 클라이언트는 애플리케이션에 연결할 때 포트 번호를 제공해야 합니다(예: http://localhost:5000). 그러나 이는 원하는 동작이 아닙니다.

이 부분의 목표는 다음과 같습니다.

클라이언트는 포트 번호를 제공하지 않고도 탐색할 수 있어야 합니다. 예를 들어 클라이언트는 를 사용하여 http://localhost연결해야 합니다.
웹 애플리케이션이 어떤 이유로 중지되거나 컴퓨터가 다시 시작된 후 자동으로 시작되어야 합니다.

다음 섹션에서는 Nginx를 프록시 서버로 사용하여 포트 80에 대해 만들어진 HTTP 요청을 대신 .NET 애플리케이션으로 라우팅합니다. 또한 애플리케이션이 자동으로 시작되도록 구성합니다.

Nginx란?

Nginx 는 인기 있고 가볍고 빠른 웹 서버입니다. Linux와 Windows 모두에서 실행할 수 있으며 역방향 프록시 서버로 구성할 수 있습니다.

디먼이란?

Nginx는 디먼으로 실행됩니다. 디먼은 백그라운드에서 실행되는 서비스의 대체 용어입니다. Windows에서 실행되는 서비스와 마찬가지로 시작 중에 자동으로 시작하도록 디먼을 구성할 수 있습니다. 디먼으로 실행되도록 ASP.NET Core 애플리케이션을 구성합니다.

APT를 사용하여 Nginx 설치

Nginx 설치는 간단합니다. sudo apt install nginx 명령을 실행하여 Ubuntu 가상 머신에 프로그램을 설치합니다.

sudo 명령의 스크린샷.

설치가 완료되면 를 실행 whereis nginx 하여 프로그램이 설치된 위치를 검색합니다. 출력을 검사하여 Nginx 구성 파일이 있는 위치를 확인할 수 있습니다. 다음 스크린샷은 구성 파일이 /etc/nginx 폴더에 있음을 보여줍니다.

whereis 명령의 스크린샷

참고

Ubuntu 또는 Debian 이외의 배포를 실행하는 경우 공식 Nginx 설치 설명서에서 해당하는 패키지 관리자 설치 명령 또는 지침을 찾을 수 있습니다.

systemctl을 사용하여 서비스 관리

Nginx가 실행되고 있지 않으면 를 실행 sudo systemctl start nginx하여 명시적으로 시작할 수 있습니다. 이 연습에서는 Nginx에 대한 명령을 보여 주 systemctl 지만, 이러한 명령은 디먼으로 자동으로 시작되도록 웹 애플리케이션을 구성하는 데 사용됩니다.

설치가 완료되면 Nginx가 자동으로 시작되도록 이미 구성되어 있습니다. Nginx는 디먼으로 실행됩니다. systemctl을 사용하여 디먼의 상태 검사 수 있습니다.

명령은 systemctl 서비스의 상태 표시하거나 시작 및 중지와 같은 작업에 대해 "서비스"를 관리하는 데 사용됩니다. 사용 가능한 몇 가지 매개 변수는 시작, 중지, 다시 시작, 사용, 사용 안 함 및 상태. Nginx의 상태 검사 실행systemctl status nginx합니다.

systemctl 명령의 스크린샷

이 명령은 몇 가지 유용한 정보를 생성합니다. 이 스크린샷에서 active (running) 볼 수 있듯이 Nginx는 상태 있으며 Nginx instance 프로세스 ID는 8539입니다. 및 vendor preset: enabled 문도 확인 enabled 합니다. Enabled 는 컴퓨터가 다시 시작될 때 이 디먼이 시작되고 vendor preset: enabled Nginx가 설치될 때 기본적으로 사용하도록 설정되어 있음을 의미합니다. 따라서 Nginx는 서버가 시작될 때 자동으로 시작됩니다.

Nginx 설치 테스트

기본적으로 Nginx는 포트 80에서 수신 대기합니다. 실행 중이므로 localhost를 탐색할 때 Nginx의 기본 페이지에 액세스할 수 있어야 합니다. 를 사용하여 curl 를 실행 curl localhost하여 Nginx를 테스트합니다. 다음 스크린샷의 노란색 강조 표시된 텍스트는 Nginx 기본 웹 페이지를 보여줍니다. 따라서 Nginx가 실행 중입니다.

curl 명령의 스크린샷.

systemctl 명령 옵션

서비스 또는 디먼은 명령을 사용하여 systemctl 관리할 수 있습니다. 시작, 중지 또는 변경하려면 슈퍼 사용자 액세스가 필요합니다. 따라서 이러한 명령에 접두사를 추가 sudo 해야 합니다.

디먼 다시 시작

디먼을 수시로 다시 시작해야 할 수 있습니다. 디먼을 다시 시작하려면 를 실행 sudo systemctl restart <daemon_name>합니다. Nginx를 다시 시작하려면 를 실행 sudo systemctl restart nginx합니다. 이 명령을 실행하기 전과 후에 Nginx의 상태 검사 프로세스 ID의 변경 내용을 모니터링해야 합니다.

디먼 중지

디먼을 중지하려면 를 실행합니다 sudo systemctl stop <daemon_name>. Nginx를 중지하려면 를 실행한 다음, 를 다시 실행 sudo systemctl stop nginxsystemctl status nginx 하여 Nginx의 상태 검사. 이번에는 서비스가 비활성(데드)으로 표시되지만 여전히 사용하도록 설정됩니다. 즉, 서비스가 실행되고 있지는 않지만 서버를 다시 시작한 후 자동으로 시작됩니다.

중지 명령의 스크린샷.

참고

이 systemctl status 명령은 디먼에 대한 이전 로그 항목의 여러 줄도 표시합니다.

Nginx를 중지한 후 다시 실행 curl localhost 합니다.

참고

포트 80에서 들어오는 트래픽을 수신 대기하지 않으므로 연결이 거부됩니다.

BuggyAmb localhost의 스크린샷

디먼 사용 안 함

디먼을 사용하지 않도록 설정하는 것은 디먼을 중지하는 경우와 다릅니다. 비활성화된 디먼을 실행할 수 있지만 서버를 다시 시작한 후에는 자동으로 시작되지 않습니다. Nginx 디먼을 사용하지 않도록 설정하려면 를 실행sudo systemctl disable nginx한 다음 Nginx의 상태 검사.

사용 안 함 명령의 스크린샷

이 스크린샷은 Nginx가 실행되고 있지 않으며 사용하지 않도록 설정되어 있음을 보여줍니다. 즉, 다시 시작한 후 Nginx가 자동으로 시작되지 않습니다.

디먼 시작

디먼을 시작하려면 를 실행 sudo systemctl start <daemon_name>합니다. Nginx를 시작하려면 를 실행한 sudo systemctl start nginx다음 서비스의 상태 다시 검사.

시작 명령의 스크린샷.

이 스크린샷은 Nginx가 시작되었지만 여전히 사용하지 않도록 설정되어 있음을 보여줍니다. 서비스가 실행 중이지만 Nginx는 비활성화된 서비스이므로 다시 시작한 후 자동으로 시작되지 않습니다.

디먼 사용

서비스를 사용하도록 설정하면 다시 시작한 후 자동으로 시작됩니다. Nginx를 사용하도록 설정하려면 를 실행sudo systemctl enable nginx한 다음 Nginx의 상태 다시 검사.

사용 명령의 스크린샷.

이 스크린샷은 Nginx가 실행 중이며 서버를 다시 시작한 후 시작됨을 보여줍니다.

Nginx를 역방향 프록시로 구성하여 요청을 ASP.NET Core 애플리케이션으로 라우팅

이제 Nginx 서비스를 시작, 중지 및 다시 시작하는 방법을 알아보았으므로 포트 80에서 수행한 요청을 포트 5000에서 수신 대기 중인 ASP.NET Core 애플리케이션으로 라우팅하도록 Nginx를 역방향 프록시로 구성합니다.

필요한 구성은 다음과 같습니다. 일부 주요 부분이 강조 표시됩니다.

http {
  map $http_connection $connection_upgrade {
    "~*Upgrade" $http_connection;
    default keep-alive;
  }

  server {
    listen        80;
    server_name _;
    location / {
        proxy_pass         http://localhost:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection $connection_upgrade;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
  }
}

이 구성은 다음을 나타냅니다.

Nginx는 모든 요청(지시문: listen 80)에 대해 포트 80에서 수신 대기합니다.
Nginx는 요청을 로 라우팅합니다 http://localhost:5000 (지시문: proxy_pass http://localhost:5000).

참고

server_name _ 코드의 줄입니다. 이는 catch-all 지시문으로 사용됩니다. server_name 대한 자세한 내용은 공식 설명서를 참조하세요.

구성 변경 내용은 간단하게 표시됩니다. 이 코드를 사용하여 구성 파일의 server 지시문 섹션을 대체합니다. 그러나 구성 파일은 어디에 있나요?

올바른 Nginx 구성 파일 찾기

기본 Nginx 구성 파일은 입니다 /etc/nginx/nginx.conf. 구성을 검사하려면 명령을 사용하고 cat /etc/nginx/nginx.conf 서버 지시문을 검색합니다.

cat 명령의 스크린샷.

구성을 스크롤하여 서버 지시문을 찾습니다. 당신은 그것을 찾을 것으로 예상해야한다. 원하는 구성 변경 내용을 구성 파일 내부 어딘가에 배치할 수 있습니다. 그러나 이상적으로는 원래 구성 파일을 대체하지 않으려는 것이 좋습니다. 이는 서버가 올바르게 시작되지 않을 수 있는 구성 오류가 발생하지 않도록 하기 위한 것입니다. 섹션이 server 기본 구성 파일에 없습니다. 구성 파일을 계속 스크롤하면 몇 가지 include 지시문이 있음을 알 수 있습니다.

include 명령의 스크린샷.

포함 지시문을 사용하면 기본 구성 파일에 포함할 청크로 분할하여 구성을 보다 쉽게 관리할 수 있습니다. 기본 구성 파일을 간단하게 유지할 수 있으며 일부 특정 구성 파트를 다른 파일로 이동할 수 있습니다. 이 스크린샷의 강조 표시된 줄은 다음을 나타냅니다.

Nginx는 /etc/nginx/conf.d 디렉터리에 있는 각 .conf 파일에서 구성을 로드합니다.
Nginx는 /etc/nginx/sites-enabled 디렉터리에 있는 각 파일에서 구성을 로드합니다.

이러한 디렉터리를 검사하는 경우 /etc/nginx/conf.d에서 구성 파일을 찾을 수 없습니다. 그러나 /etc/nginx/sites-enabled에 하나의 파일이 있습니다.

conf 명령의 스크린샷

기본 구성 파일은 찾고 있는 구성을 호스트하는 주요 후보처럼 보입니다. 를 사용하여 /etc/nginx/sites-enabled/default 파일을 검사하는 경우 기본 서버 지시문이 다음 코드 내에 배치되는 것을 볼 수 있습니다.cat /etc/nginx/sites-enabled/default

기본 정보의 스크린샷.

따라서 구성을 변경하려면 /etc/nginx/sites-enabled/default 파일을 편집해야 합니다.

vi를 사용하여 구성 파일 편집

ASP.NET 파이프라인에서 HTTPS 리디렉션을 제거하기 위해 Startup.cs 파일을 편집할 때 파일을 편집하는 방법을 알아보았습니다. 이제 vi를 다시 사용하여 nginx 구성 파일을 변경합니다.

팁

항상 변경 중인 파일을 백업합니다. 편집 후 문제가 발생하면 해당 복사본을 사용하여 파일을 이전 상태로 복원할 수 있습니다. 이 경우 를 실행 cp /etc/nginx/sites-enabled/default ~/nginx-default-backup 하여 구성 파일을 홈 디렉터리에 복사합니다. 백업 파일 이름은 입니다 nginx-default-backup. 백업이 원본 파일과 동일한 디렉터리에서 만들어지지 않았습니다. Nginx는 해당 디렉터리의 모든 구성 파일을 로드하고 두 가지 버전의 서버 지시문을 로드하여 구성을 중단하지 않기 때문입니다.

다음 스크린샷과 같이 를 실행 sudo vi /etc/nginx/sites-enabled/default 하여 구성 파일을 편집하고 서버 지시문을 바꿉 있습니다.

vi 명령의 스크린샷.

vi를 사용하여 파일을 편집하기 위한 몇 가지 팁과 요령은 다음과 같습니다.

화살표 키를 사용하여 위아래로 스크롤할 수 있습니다.
편집 모드로 전환하려면 삽입 또는 I 키를 누릅니다. 편집 모드에 있는 동안 왼쪽 아래 모서리에 --INSERT-- 메시지가 표시됩니다.
편집 모드에서는 키보드를 사용하여 문자를 한 번에 하나씩 삭제할 수 있습니다.
편집 모드에서 복사 및 붙여넣기 작업은 대부분의 터미널과 함께 작동합니다. 따라서 이 문서의 콘텐츠를 복사하여 vi에 붙여넣을 수 있습니다.
편집 모드를 종료하려면 Esc 키를 누릅니다.
일반 모드에서 선을 더 쉽게 삭제할 수 있습니다. 일반 모드에서 삭제하려는 줄의 시작 부분으로 이동하여 dd를 입력합니다. dd 명령은 전체 줄을 삭제합니다. 5dd를 입력하여 한 번에 5개의 줄을 삭제할 수도 있습니다. 그러나 이 옵션은 추가 콘텐츠를 삭제하지 않도록 주의해서 사용해야 합니다.
Vim/Vi 문서에서 줄을 삭제하는 방법은 vi에서 여러 줄을 삭제하는 방법을 알아보는 좋은 방법입니다.
vi를 종료하고 변경 내용을 저장하려면 :wq!를 입력한 다음 Enter 키를 누릅니 다. 여기서 콜론(:)은 명령을 실행하고, 변경 내용을 쓰고, w 종료를 의미하며!, q 변경 내용을 재정의한다는 것을 의미합니다.
변경 내용을 저장하지 않고 종료하려면 :q!를 입력한 다음 Enter 키를 누릅니 다.

이제 변경 내용이 저장되고 이러한 변경 내용이 적용되려면 Nginx 서비스를 다시 시작해야 합니다. 서비스를 다시 시작하기 전에 명령을 실행 sudo nginx -t 하여 구성 파일을 테스트할 수 있습니다. 이 명령이 실행되면 Nginx는 구성 파일 구문을 확인한 다음 구성 파일에서 참조되는 파일을 열려고 시도합니다.

t 명령의 스크린샷.

여기에서 볼 수 있듯이 변경된 구성 파일이 올바른 것으로 보입니다.

변경 내용이 적용되도록 Nginx를 다시 시작해야 합니다.

sudo systemctl restart nginx

Nginx가 포트 80에 대해 수행되는 요청에 대해 역방향 프록시로 작동해야 하므로 다시 시작한 후 http://localhost에 대한 요청을 수행할 때 ASP.NET Core 애플리케이션의 응답이 표시됩니다.

변경 내용을 적용하려면 Nginx 서비스를 다시 시작한 다음 를 실행 curl localhost하여 localhost에 요청합니다. 그러나 이 명령은 실패합니다. 다음 단계는 를 실행 wget localhost한 다음 문제의 원본에 대한 몇 가지 힌트를 검색하는 것입니다.

wget 명령의 스크린샷

Nginx 프록시 문제 해결

이전 스크린샷에는 다음 정보가 표시됩니다.

Resolving localhost (localhost)... 127.0.0.1  
Connecting to localhost (localhost)|127.0.0.1|:80... connected.  
HTTP request sent, awaiting response... 502 Bad Gateway  
2020-12-27 21:15:53 ERROR 502: Bad Gateway.

첫 번째 줄과 두 번째 줄은 localhost를 resolve 소켓에 127.0.0.1:80 연결할 수 있음을 나타냅니다. 따라서 Nginx를 실행해야 합니다. 이를 확인하려면 명령을 실행할 systemctl status nginx 수 있습니다.

세 번째 줄은 문제의 원인을 나타냅니다. HTTP 502 잘못된 게이트웨이 오류 메시지가 표시됩니다. HTTP 502 잘못된 게이트웨이 는 프록시와 관련이 있습니다. 즉, 역방향 프록시가 백 엔드 애플리케이션에 연결할 수 없습니다. 이 경우 요청에 대해 포트 5000에서 실행되고 수신 대기해야 하는 ASP.NET Core 웹 애플리케이션입니다. 웹 애플리케이션도 실행 중인지 여부를 검사 합니다.

문제 해결을 시작하려면 이전과 동일한 netstat 명령을 실행합니다. 이번에는 grep를 사용하여 애플리케이션의 포트 5000을 필터링합니다. 그런 다음, 를 실행합니다 netstat -tlp | grep 5000.

netstat 명령의 스크린샷.

이 샘플 출력은 포트 5000에서 수신 대기하는 것이 없음을 나타냅니다. 따라서 이는 포트 5000 에서 수신 대기하는 프로세스를 찾을 수 있기 때문에 Nginx에서 발생하는 HTTP 502 응답의 원인입니다.

솔루션은 ASP.NET Core 애플리케이션을 시작하는 것입니다. 그러나 더 나아가기 전에 이 문제를 해결하기 위한 다른 방법을 검토할 수 있습니다. 단순히 몇 줄의 로그 콘텐츠를 보고 근본 원인을 찾는 것만큼 모든 문제를 쉽게 해결할 수 있는 것은 아닙니다. 경우에 따라 다른 시스템 및 애플리케이션 로그를 심층 분석해야 합니다.

Linux에서 ASP.NET Core 애플리케이션을 설정할 때 Nginx와 긴밀히 협력하기 때문에 문제 해결을 위해 Nginx 및 운영 체제에서 제공하는 로그 종류를 알아보는 것이 좋습니다.

Nginx 로그 확인

를 다시 실행 cat /etc/nginx/nginx.conf 한 다음 를 찾으 logging settings면 다음이 표시됩니다.

로그 정보의 스크린샷.

Nginx에는 액세스 로그 및 오류 로그라는 두 가지 종류의 로그가 있음을 보여 줍니다. / var/log/nginx/ 디렉터리에 저장됩니다.

액세스 로그는 IIS 로그 파일과 유사합니다. 콘텐츠를 빠르게 검사하면 다음 스크린샷과 유사하게 표시됩니다.

액세스 명령의 스크린샷.

액세스 로그에는 이미 알고 있는 HTTP 502 응답 상태 이외의 새 정보가 표시되지 않습니다. 를 실행 cat /var/log/nginx/error.log하여 오류 로그를 검사할 수도 있습니다. 이들은 문제의 원인에 대해 더 많은 것을 드러냅니다.

오류 정보의 스크린샷.

표시는 분명합니다. Nginx는 클라이언트에서 요청을 가져올 수 있지만 해당 포트에서 http://127.0.0.1:5000 실행되고 수신 대기해야 하는 ASP.NET Core 애플리케이션에서 서버에 연결할 upstream 수 없습니다.

해결 방법

이 문제를 해결하려면 ASP.NET Core 애플리케이션을 수동으로 시작합니다. 두 번째 터미널 세션을 사용하여 서버에 연결한 다음 이전과 같이 ASP.NET Core 애플리케이션을 실행합니다.

aspnet 정보의 스크린샷.

ASP.NET Core 애플리케이션이 실행되는 동안 다른 터미널 세션으로 전환하고 동일한 curl localhost 명령을 실행합니다. 이제 Nginx 뒤에서 실행되는 ASP.NET Core 애플리케이션에 액세스할 수 있습니다. 다음 스크린샷은 localhost에 요청을 했고, 요청이 Nginx에서 처리되고 백 엔드 애플리케이션으로 라우팅되었으며, ASP.NET Core 애플리케이션에서 응답을 받았다는 것을 보여줍니다.

curllocalhost 명령의 스크린샷

이제 Linux에서 실행되는 ASP.NET Core 애플리케이션에 대한 역방향 프록시로 작동하도록 Nginx를 구성했습니다.

그러나 다시 시작한 후 ASP.NET Core 애플리케이션이 시작되지 않으면 결과는 어떻게 되나요? 웹 애플리케이션이 충돌하고 실행되고 있지 않다는 것을 알 때까지 시작되지 않으면 어떻게 될까요? 프로세스 종료를 다시 시작할 때마다 ASP.NET Core 애플리케이션을 시작해야 하나요?

다음 단계

2.3부 - ASP.NET Core 애플리케이션이 자동으로 시작되도록 구성

타사 정보 고지 사항

이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.