다음을 통해 공유

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

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

이 문서에서는 서버가 다시 시작된 후 애플리케이션이 자동으로 시작되도록 ASP.NET Core 애플리케이션을 구성하는 방법을 소개합니다.

필수 조건

이 부분의 연습을 수행하려면 ASP.NET Core 웹 애플리케이션을 설치하고 Linux에 배포해야 합니다.

또한 Nginx 웹 서버를 역방향 프록시로 구성하여 포트 80에서 백 엔드 ASP.NET Core 애플리케이션으로 요청을 라우팅해야 합니다.

이 부분의 목표

이 시리즈의 이전 부분에서는 Nginx를 역방향 프록시로 구성하는 방법과 HTTP 502 프록시 오류를 해결하는 방법을 보여 줬습니다. HTTP 502 응답 코드의 원인은 Nginx가 트래픽을 전달하려고 할 때 백 엔드 ASP.NET Core 애플리케이션이 실행되지 않았기 때문에 발생합니다.

이 문제는 ASP.NET Core 애플리케이션을 수동으로 실행하여 일시적으로 해결되었습니다. 하지만 애플리케이션이 충돌하면 어떻게 될까요? 아니면 서버를 다시 시작해야 할까요? 매번 ASP.NET Core 애플리케이션을 수동으로 다시 시작하는 것은 실용적인 솔루션이 아닙니다. 따라서 이 섹션에서는 작동이 중단된 후 애플리케이션을 시작하도록 Linux를 구성합니다.

지금까지 Nginx와 ASP.NET Core가 함께 작동하도록 구성했습니다. Nginx는 포트 80에서 수신 대기하고 포트 5000에서 수신 대기하는 ASP.NET Core 애플리케이션에 요청을 라우팅합니다. Nginx는 자동으로 시작되지만 ASP.NET Core 애플리케이션은 서버를 다시 시작할 때마다 수동으로 시작해야 합니다. 그렇지 않으면 ASP.NET Core 애플리케이션이 정상적으로 종료되거나 충돌합니다.

IIS를 프록시로 사용하여 ASP.NET Core를 실행하는 경우 IIS ASP.NET CORE 모듈(ANCM)이 프로세스 관리를 처리하고 ASP.NET Core 프로세스가 자동으로 시작됩니다. 또 다른 옵션은 컴퓨터가 시작되는 즉시 자동 시작 기능을 구성할 수 있도록 Windows에서 ASP.NET Core를 서비스로 실행하는 것입니다.

ASP.NET Core 애플리케이션에 대한 서비스 파일 만들기

이 systemctl 명령은 "서비스" 또는 "디먼"을 관리하는 데 사용됩니다. 디먼은 Windows 서비스의 개념과 유사합니다. 이러한 서비스는 시스템이 시작될 때 자동으로 다시 시작할 수 있습니다.

서비스 파일이란?

Linux에는 프로세스가 종료되면 디먼의 동작을 제어하는 데 사용되는 ".service" 확장명이 있는 단위 구성 파일도 있습니다. 서비스 파일, 단위 파일 및 서비스 단위 파일이라고도 합니다.

이러한 서비스 파일은 다음 디렉터리 중 하나에 있습니다.

  • /usr/lib/systemd/: 다운로드한 애플리케이션에 대한 서비스 파일을 저장합니다.
  • /etc/systemd/system/: 시스템 관리자가 만든 서비스 파일을 저장합니다.

Nginx 서비스 파일을 검사합니다. 패키지 관리자를 통해 설치됩니다. 구성 파일은 /usr/lib/systemd/system/ 폴더에 있어야 합니다. 명령을 실행하면 systemctl status nginx 서비스 파일의 위치도 표시됩니다.

systemctl status nginx 명령의 스크린샷

Nginx 서비스 파일의 모양입니다.

cat 명령의 스크린샷.

ASP.NET Core 애플리케이션에 대한 샘플 서비스 파일

다음 예제 단위 파일 콘텐츠는 Nginx를 사용하는 Linux의 Host ASP.NET Core에서 가져옵니다.

[Unit]
Description=Example .NET Web API App running on Ubuntu

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

이 콘텐츠의 몇 가지 주요 측면은 다음과 같습니다.

  • WorkingDirectory 는 애플리케이션을 게시하는 디렉터리입니다.
  • ExecStart 는 애플리케이션을 시작하는 실제 명령입니다.
  • Restart=always 은 자체 설명입니다. 이 프로세스는 수동으로 또는 크래시로 인해 어떤 이유로 중지되는 경우 항상 시작됩니다.
  • RestartSec=10 은 자체 설명이기도 하다. 프로세스가 중지된 후 10초가 경과한 후에 시작됩니다.
  • SyslogIdentifier 가 중요합니다. "시스템 로그 식별자"를 의미합니다. 디먼에 대한 정보는 시스템 로그의 이 이름 아래에 기록됩니다. 이 식별자를 사용하여 프로세스의 PID를 찾을 수도 있습니다.
  • User 는 서비스를 관리하는 사용자입니다. 시스템에 존재하고 애플리케이션 파일의 적절한 소유권을 가져야 합니다.
  • 서비스 파일에서 원하는 수의 환경 변수를 설정할 수 있습니다.

참고 항목

사용자는 www-data 시스템의 특수 사용자입니다. 이 계정을 사용할 수 있습니다. Linux에서 사용자 권한을 연습하기 위한 새 사용자를 만듭니다. 그러나 다른 Linux 사용자를 만들지 않으려면 사용하는 www-data 것이 좋습니다.

ASP.NET Core 애플리케이션에 대한 서비스 파일 만들기

서비스 파일을 만들고 편집하는 데 사용합니다 vi . 서비스 파일은 /etc/systemd/system/ 폴더로 이동합니다. 이 시리즈에서는 첫 번째 애플리케이션 을 /var/firstwebapp/ 폴더에 게시했습니다. 따라서 WorkingDirectory는 이 폴더를 가리킵니다.

최종 구성 파일은 다음과 같습니다.

[Unit]
Description=My very first ASP.NET Core applications running on Ubuntu

[Service]
WorkingDirectory=/var/firstwebapp/
ExecStart=/usr/bin/dotnet /var/firstwebapp/AspNetCoreDemo.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=myfirstapp-identifier
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Development
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

sudo vi /etc/systemd/system/myfirstwebapp.service 를 실행하고, 최종 구성을 붙여넣고, 파일을 저장합니다.

sudo 명령의 스크린샷.

그러면 ASP.NET Core 웹 애플리케이션이 디먼으로 실행되는 데 필요한 구성이 완료됩니다.

이제 웹 애플리케이션이 서비스로 구성되었으므로 실행 systemctl status myfirstwebapp.service하여 상태를 확인할 수 있습니다. 다음 스크린샷에서 볼 수 있듯이 애플리케이션이 비활성화되고(시스템이 다시 시작된 후 자동으로 시작되지 않음) 현재 실행되고 있지 않습니다.

systemctl status 명령의 스크린샷

서비스를 시작하려면 명령을 실행한 sudo systemctl start myfirstwebapp.service 다음 상태를 다시 확인합니다. 이번에는 서비스가 실행되고 프로세스 ID가 옆에 나열되어야 합니다. 명령 출력에는 새로 만든 서비스에 대한 시스템 로그의 마지막 몇 줄도 표시되며 서비스가 수신 대기 중 http://localhost:5000임을 보여 줍니다.

sudo systemctl start 명령의 스크린샷.

웹 애플리케이션이 예기치 않게 중지되면 10초 후에 자동으로 다시 시작됩니다.

마지막 단계는 서비스가 실행 중이지만 사용하도록 설정되지 않은 것입니다. "사용"은 서버가 시작된 후 자동으로 시작됨을 의미합니다. 원하는 최종 구성입니다. 다음 명령을 실행하여 서비스가 사용하도록 설정되어 있는지 확인합니다.

sudo systemctl enable myfirstwebapp.service

sudo systemctl enable 명령의 스크린샷.

서버를 다시 시작하거나 프로세스가 종료된 후 자동으로 시작되도록 구성했으므로 ASP.NET Core 애플리케이션의 중요 시점입니다.

ASP.NET Core 애플리케이션이 자동으로 다시 시작되는지 테스트

다음 부분으로 진행하기 전에 모든 것이 예상대로 작동하는지 확인합니다. 현재 구성은 다음과 같습니다.

  • Nginx는 자동으로 실행되며 포트 80에서 전송된 요청을 수신 대기합니다.
  • Nginx는 역방향 프록시로 구성되며 요청을 ASP.NET Core 애플리케이션으로 라우팅합니다. 애플리케이션이 포트 5000에서 수신 대기하고 있습니다.
  • ASP.NET Core 애플리케이션은 서버가 다시 시작되거나 프로세스가 중지되거나 충돌하는 경우 자동으로 시작되도록 구성됩니다.

따라서 ASP.NET Core 서비스가 중지되면 10초 후에 다시 시작해야 합니다. 이 동작을 테스트하려면 프로세스를 강제로 중지합니다. 10초 안에 다시 시작될 것으로 예상할 수 있습니다.

참고 항목

ASP.NET Core 애플리케이션의 현재 프로세스 ID입니다. 여기에 표시된 시도의 프로세스 ID는 프로세스가 종료되기 전의 5084입니다. ASP.net Core 애플리케이션에 대한 프로세스 ID를 찾으려면 명령을 실행합니다 systemctl status myfirstwebapp.service .

프로세스를 강제로 중지하려면 다음 명령을 실행합니다.

sudo kill -9 <PID>

참고 항목

9 신호 유형은 다음과 같습니다. 신호 명령에 9 따라 man SIGKILL(kill 신호)입니다. 이 항목에 대해 자세히 알아보려면 "종료 및 신호" 명령을 사용하여 man 도움말 페이지를 열 수 있습니다.

systemctl status myfirstwebapp.service 명령 바로 다음에 kill 명령을 실행하고 약 10초 동안 기다린 다음 동일한 명령을 다시 실행합니다.

kill 명령의 스크린샷.

이 스크린샷에서는 다음 정보를 볼 수 있습니다.

  • 종료되기 전에 ASP.NET Core 프로세스의 프로세스 ID는 5084입니다.
  • 서비스 상태는 PID 5084를 사용하는 프로세스가 종료되었으며 자동 다시 시작이 구성되었기 때문에 다시 활성화되고 있음을 나타냅니다.
  • 몇 초 후 새 프로세스(PID 5181)가 시작되었습니다.

사용하여 curl localhost사이트에 액세스하려는 경우 ASP.NET Core 애플리케이션이 여전히 응답하는 것을 볼 수 있습니다.

다음 단계

2.3.1부 - [선택 사항] Linux의 ASP.NET Core 애플리케이션이 다른 사용자 아래에서 자동으로 시작되도록 구성합니다.

  • Last updated on