적용 대상: .NET 8 이상
이 문서에서는 Linux에서 ASP.NET Core 애플리케이션을 만들고 구성하는 방법을 소개합니다.
필수 조건
이 부분의 연습을 수행하려면 .NET SDK가 설치되어 있어야 합니다. SDK를 설치하려면 필요에 따라 1부의 설치 지침을 참조하세요.
이 부분의 목표
Linux에서 .NET CLI(명령줄 인터페이스)를 사용하여 ASP.NET Core 웹 애플리케이션을 만드는 방법과 /var 디렉터리에 애플리케이션을 게시하는 방법을 알아봅니다. 이러한 개념을 알아보면 파일 및 폴더 작업, 권한 있는 사용자로 명령 실행과 같은 몇 가지 기본 작업을 연습합니다. Linux에서 vi 텍스트 편집기를 사용하여 파일을 편집하는 방법도 알아봅니다.
.NET CLI
이 .NET CLI 설명서에 따르면 .NET CLI는 .NET 애플리케이션을 개발, 빌드, 실행 및 게시하기 위한 플랫폼 간 도구 체인입니다. .NET CLI는 .NET SDK와 함께 설치됩니다.
이러한 학습은 명령을 자주 사용합니다 dotnet . 이 명령은 강력하며 다음 두 가지 주요 함수가 있습니다.
- .NET 프로젝트에서 작업하기 위한 명령을 제공합니다. 예를 들어
dotnet build는 프로젝트를 빌드합니다. 각 명령은 자체 옵션과 인수를 정의합니다. 모든 명령은 명령을 사용하는 방법에 대한 간단한 설명을 인쇄하는 옵션을 지원--help합니다. - .NET 애플리케이션을 실행합니다.
이 dotnet new 명령을 사용하여 Linux에서 첫 번째 ASP.NET Core 프로젝트를 만듭니다. 이 명령은 프로젝트의 형식을 인수로 가져옵니다. 프로젝트 형식은 이 문서에 설명되어 있습니다. 매개 변수 없이 실행 dotnet new 하여 형식 목록을 표시할 수도 있습니다. 웹 관련 프로젝트 형식은 다음 스크린샷에서 노란색으로 강조 표시됩니다.
SDK를 사용하여 ASP.NET Core 웹 애플리케이션 만들기
.NET CLI를 사용하여 다음 명령을 사용하여 첫 번째 웹 애플리케이션을 만듭니다.
dotnet new <template_type> -n <project_name> -o <output_directory>
이러한 규칙은 다음을 사용할 dotnet new때 적용됩니다.
- 이 명령은 출력 디렉터리에 프로젝트 파일을 만듭니다. 세그먼트를
-o <output_directory>생략하면 프로젝트가 현재 디렉터리에 만들어집니다. 언제든지 스위치를-o사용할 수 있습니다. - 폴더가 없으면 명령에서 폴더를 만듭니다.
- 세그먼트를
-n <project_name>생략하면 프로젝트 이름이 디렉터리 이름과 동일합니다.
디렉터리 및 프로젝트 자체에 대한 창의적인 이름을 찾을 수 있습니다. 그러나 Linux는 대/소문자를 구분합니다. 이 연습에서는 보다 보수적인 AspNetCoreDemo 프로젝트 이름을 사용하고 디렉터리에 만듭니 firstwebapp 다.
프로젝트를 만들려면 다음 명령을 실행합니다.
dotnet new webapp -n AspNetCoreDemo -o firstwebapp
출력을 검사하여 디렉터리 및 프로젝트 이름을 확인합니다. 다음 스크린샷에는 출력 디렉터리의 콘텐츠도 나열됩니다. 이전에 Windows에서 ASP.NET Core 웹 애플리케이션을 만든 경우 디렉터리 구조에 대해 잘 알고 있어야 합니다.
첫 번째 애플리케이션을 만들었습니다. 다음 작업은 실행하는 것입니다. 디렉터리를 프로젝트 폴더로 변경하고 실행 dotnet run합니다.
참고 항목
이 스크린샷의 다음 항목은 다음과 같습니다.
- 웹 애플리케이션은 HTTPS 요청에 대해 포트 5001에서 수신 대기하고 HTTP 요청의 경우 포트 5000에서 수신 대기합니다.
- 콘텐츠 루트는 홈 디렉터리 아래에 있습니다.
홈 디렉터리에서 애플리케이션을 실행하지 않는 것이 좋습니다. 나중에 다른 디렉터리에 게시하지만 게시하기 전에 테스트해야 합니다. Ctrl+C를 눌러 애플리케이션을 중지할 수 있습니다. 그러나 지금은 계속 실행하고 기본 방법을 사용하여 Linux 가상 머신에 연결하여 새 터미널 세션을 엽니다. 이 예제에서는 PowerShell을 다시 사용합니다.
다른 터미널에서 웹 사이트 테스트
새 터미널 세션에서 애플리케이션이 포트 5000 및 5001에서 수신 대기하고 있는지 확인합니다. Linux에는 Windows와 동일한 netstat 명령이 있습니다. 스위치와 함께 실행 netstat 합니다 -tlp . 이 문서의 스위치에 netstat 익숙해지거나 실행 man netstat 하거나 info netstat실행하여 도움말 파일을 볼 수 있습니다.
다음은 두 번째 터미널 세션의 netstat -tlp 명령 출력입니다. AspNetCoreDemo 프로세스가 PID 781을 사용하여 실행 중이며 IPv4 및 IPv6 모두에 대해 포트 5000 및 5001에서 수신 대기 중임을 보여줍니다.
curl 및 wget을 사용하여 웹 사이트를 테스트할 수 있습니다. 두 명령 모두 대상 쪽에 대한 HTTP 호출을 수행하지만 다르게 동작합니다.
-
Curl는 단순히 명령줄 브라우저 도구입니다. 지정된 대상에 대한 HTTP 요청을 수행하고 HTTP 응답의 일반 출력만 표시합니다. 예를 들어 웹 애플리케이션에 대한 HTML 원본 태그를 보여 줍니다. -
Wget는 HTTP 다운로더입니다. HTTP 요청을 수행하고 지정된 리소스를 다운로드합니다. 예를 들어 wgethttp://server/file.zip은 file.ziphttp://server다운로드하여 현재 디렉터리에 저장합니다.
또한 이 wget 명령은 리디렉션 및 수신할 수 있는 오류 메시지와 같은 몇 가지 세부 정보도 보여줍니다. 따라서 필요할 때마다 HTTP 추적 도구의 기본 버전으로 사용할 수 있습니다.
차이점 curlwget에 대한 자세한 내용은 StackExchange 웹 페이지로 이동하세요.
이 교육 시리즈에서는 이전에 .NET을 설치하기 전에 Microsoft 서버에서 .deb 패키지 관리자 파일을 다운로드하는 데 사용 wget 했습니다.
실행 curl http://localhost하면 아무 것도 발생하지 않습니다. 이는 HTTP 응답이 없음을 의미합니다. 그런 다음, 사이트에 액세스하려고 할 때 더 많은 정보가 표시되는지 확인하기 위해 실행할 wget http://localhost 수 있습니다.
이것은 지금 일어나는 일입니다.
- HTTP 요청을 수행하고
http://localhost:5000성공적으로 연결합니다. 즉, 애플리케이션이 포트 5000에서 연결을 허용합니다. - 보안 HTTPS 위치를
https://localhost:5001가리키는 애플리케이션에서 HTTP 307 임시 리디렉션 응답을 받습니다. - Wget은 이 리디렉션을 따르고 새 요청을 수행할 수 있을 만큼 스마트합니다
https://localhost:5001. - 다시 연결합니다. 그러나
wgetSSL 인증서는 신뢰하지 않습니다. 따라서 연결이 실패합니다.
이 wget 명령은 스위치를 사용하여 --no-check-certificate 안전하지 않게 연결하여 이 문제를 해결하는 것이 좋습니다. 그러나 이 방법에는 이 학습의 범위를 벗어난 SSL 인증서 설정이 포함됩니다. 대신 http 요청을 HTTPS로 리디렉션하지 않도록 ASP.NET Core 애플리케이션을 구성할 수 있습니다. ASP.NET Core 애플리케이션 개발(또는 구성)에 익숙한 경우 Startup.cs 파일을 편집하여 리디렉션 구성을 제거합니다.
vi를 사용하여 파일 편집
Linux 배포판용 vi 텍스트 편집기를 사용하여 모든 종류의 일반 텍스트 파일을 편집할 수 있습니다. 이 학습에서 이를 사용하여 애플리케이션을 다시 구성합니다.
애플리케이션을 편집하려면 먼저 애플리케이션을 닫아야 합니다. 먼저 열린 터미널 세션을 닫습니다. 그런 다음 Ctrl+C를 눌러 애플리케이션을 종료합니다.
Startup.cs 파일을 편집하려면 다음 명령을 실행합니다.
vi ~/firstwebapp/Startup.cs
참고 항목
이 명령은 vi 편집기를 시작한 다음 파일을 로드합니다. ~(타일드) 바로 가기는 프로젝트를 만든 홈 디렉터리를 가리킵니다. 즉, 명령은 /home/YourName>/<firstwebapp/Startup.cs 가리킵니다.
I(삽입) 키를 눌러 편집 모드를 사용하도록 설정합니다. 이제 명령줄 아래쪽에 INSERT가 표시됩니다. 화살표 키를 사용하여 파일 내에서 탐색합니다. 다음 스크린샷과 app.UseHsTs()같이 시작 부분에 추가 // 하여 ; 및 app.UseHttpsRedirection(); 줄을 모두 주석으로 지정합니다.
편집 모드를 종료하려면 esc 키를 누르고 :wq!를 입력한 다음 Enter 키를 누릅니다. 콜론 문자(:)는 명령을 입력하고, 쓰기를 의미하고, w 종료를 의미하며!, q 강제로 쓰기를 한다는 것을 의미합니다.
Enter 키를 누르면 변경 내용이 저장됩니다. 를 실행 cat ~/firstwebapp/Startup.cs하여 변경 내용을 확인할 수 있습니다. 이 명령은 Startup.cs 파일의 내용을 표시합니다.
애플리케이션을 다시 시작합니다. 이렇게 하려면 현재 디렉터리를 디렉터리로 ~/firstwebapp 변경하고 다시 실행 dotnet run 합니다. 그런 다음 서버에 대한 다른 터미널 세션을 열고 명령을 다시 실행합니다 curl http://localhost:5000 . 이번에는 명령이 홈 페이지의 HTML 콘텐츠를 반환해야 합니다.
이제 Linux에서 첫 번째 ASP.NET Core Web App을 성공적으로 실행했습니다.
/var 디렉터리에 애플리케이션 배포
이 연습의 주요 목표는 연결 클라이언트가 포트 번호가 없는 호스트 이름만 사용하여 다른 컴퓨터에서 애플리케이션에 액세스할 수 있도록 역방향 프록시 뒤에 웹 애플리케이션을 호스트하는 것입니다. 이것이 실제 시나리오에서 발생할 것으로 예상되는 것입니다. 나중에 Nginx로 작업하여 이 작업을 완료합니다. 그러나 이렇게 하기 전에 /var 디렉터리에 애플리케이션을 게시합니다. 사용자의 홈 디렉터리에서 애플리케이션을 실행하지 않는 것이 좋습니다.
/var 디렉터리가 Apache 및 Nginx와 같은 다양한 애플리케이션의 콘텐츠 및 로그 파일을 저장하는 데 사용됩니다. 여기서는 새로 만든 웹 애플리케이션을 /var에 게시하여 이러한 연습을 수행합니다.
프로젝트 폴더로 변경한 다음 실행 dotnet publish 하여 게시 폴더를 만듭니다. 해당 폴더를 /var 디렉터리에 복사합니다.
스크린샷은 명령이 dotnet publish ~/firstwebapp/bin/Debug/net5.0/publish/ 폴더에 게시 파일을 만든 것을 보여줍니다. 그런 다음, 다음 명령을 사용하여 모든 파일을 /var/firstwebapp/ 폴더에 복사했습니다.
sudo cp -a ~/firstwebapp/bin/Debug/net5.0/publish/ /var/firstwebapp/
참고 항목
복사 명령 이전의 sudo 사용량을 확인합니다. 표준 사용자에게 /var 디렉터리에 대한 쓰기 권한이 없기 때문에 이를 사용합니다. 따라서 명령을 슈퍼 사용자로 실행해야 합니다.
게시된 폴더에서 애플리케이션을 실행하려면 다음 명령을 실행합니다.
dotnet /var/firstwebapp/AspNetCoreDemo.dll
원하는 경우 동일한 curl 명령과 wget 명령을 사용하여 이러한 테스트를 실행할 수 있습니다. 이는 애플리케이션이 HTTP 요청에 대해 포트 5000에서 계속 수신 대기하기 때문입니다.
프로세스 수명 및 다음 단계
애플리케이션에 지속적인 가동 시간이 필요한 경우 대화형 사용자 세션 내에서 .NET 애플리케이션을 실행하는 것은 다음과 같은 이유로 좋지 않습니다.
- 예를 들어 사용자가 PuTTY 또는 PowerShell SSH 클라이언트를 닫아 세션을 종료하거나 세션을 종료하는 경우 애플리케이션이 종료됩니다.
- 어떤 이유로 인해 프로세스가 종료되는 경우(예: 처리되지 않은 예외로 인해 프로세스가 충돌함) 프로세스가 자동으로 시작되지 않으며 수동으로 다시 시작해야 합니다.
- 서버를 다시 시작하면 애플리케이션이 자동으로 시작되지 않습니다.
다음 단계
2.2부 - Nginx를 설치하고 역방향 프록시 서버로 구성
웹 애플리케이션이 자동으로 시작되는지 확인합니다. 대신 포트 80에 대해 만들어진 HTTP 요청을 dotnet 애플리케이션으로 라우팅하는 역방향 프록시로 Nginx를 설치하고 구성합니다(클라이언트가 포트 번호를 제공하지 않고도 연결할 수 있도록).
타사 정보 고지 사항
이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.