웹사이트 검색

Upstart 이벤트 시스템: 정의 및 사용 방법


소개

초기화는 모든 스크립트 및 서비스의 작동을 제어하기 위해 Unix 기반 운영 체제의 핵심에 있는 중요한 절차입니다. 시작 및 종료의 중요한 지점에서 문제가 발생할 수 있고 최적의 성능을 보장하는 것이 최우선인 서버 환경에서 필수적입니다.

본질적으로 초기화는 다음과 같은 프로세스를 따릅니다.

  1. 서버 부팅
  2. 초기화 프로세스가 실행됩니다(보통 PID 1로)
  3. 미리 정의된 일련의 시작 작업이 순서대로 활성화됩니다.

초기화는 클라우드 서버가 정상적으로 부팅되고 종료될 수 있도록 하는 책임이 있습니다.

Unix 기반의 일부 배포판은 초기화를 위해 표준 초기화 프로세스를 사용합니다. 이 기사에서는 서버 운영을 강화할 수 있는 실용적이고 강력한 대체품인 Upstart에 대해 살펴보겠습니다.

고전적인 초기화에 어떤 문제가 있습니까?

기존의 초기화는 선형 프로세스를 따릅니다. 개별 작업은 시스템이 부팅될 때 미리 정의된 순서대로 로드됩니다. 이것은 특히 급변하는 상황에서 그다지 도움이 되지 않습니다. 그 이유를 이해하려면 예를 들어 스토리지 장치를 추가하여 서버 환경을 수정했다고 가정해 보십시오.

초기화 프로세스는 환경의 갑작스러운 변화를 고려할 수 없습니다. 즉, 추가 스토리지를 인식하려면 클라우드 서버를 다시 초기화해야 합니다. 일반적인 초기화 절차의 기능은 아니지만 즉각적인 감지가 필요합니다.

선형 순서로 부팅하는 것도 시간이 걸리므로 빠른 배포가 필수적인 클라우드 기반 환경에서 특히 불리합니다.

시스템이 로드된 후 작업 상태에 대해 걱정할 수도 있습니다. 불행히도 init은 부팅하거나 전원을 끌 때만 시퀀스와 관련이 있습니다.

동기 부팅 시퀀스는 더 이상 바람직하지 않습니다. 경직된 시스템은 어제의 시스템을 지원할 수 있지만 오늘날은 역동적입니다.

바로 이러한 문제에 대한 고급 기능 솔루션인 Upstart가 등장하는 곳입니다.

순서대로 미리 설정된 작업 목록 대신 실시간 이벤트를 기반으로 하는 이 대체 init 데몬은 작업의 시작 및 중지를 처리 하고 시스템이 실행되는 동안 이러한 프로세스를 모니터링합니다. – "전체 적용 범위\가 이를 설명하는 가장 좋은 방법입니다.

이 새로운 비동기식 처리는 엄격한 부팅 시퀀스의 필요성을 제거합니다. 실시간 처리는 개념화하기 어려울 수 있지만 Upstart는 작업 구조를 사용하여 가장 복잡한 시스템을 지원하고 모든 것을 확인할 수 있습니다.

업스타트 개요

처음부터 유연하게 설계된 Upstart 이벤트 시스템은 기존 초기화 시스템과 다른 다양한 개념을 활용합니다. 이 솔루션은 RHEL(Red Hat Enterprise Linux) 6, 구글의 크롬 OS, 우분투에 기본적으로 설치되지만, 최근 논의가 계속될지에 대한 혼란을 야기했다.

직업

Upstart의 세계에서 작업은 작업 프로세스이며 목적이 있는 태스크 작업과 백그라운드에서 실행될 수 있는 서비스 작업으로 나뉩니다. 관리 권한이 있는 사용자가 중지할 때까지 영원히 실행되는 프로세스인 추상 작업도 있습니다.

이벤트

그러나 이벤트는 작업 또는 다른 이벤트와 함께 특정 작업을 트리거하는 데 사용되는 신호 또는 "호출\입니다. 일반적인 형태의 이벤트는 프로세스 모니터링을 나타냅니다: 시작, 시작, 중지중지.

이벤트 방출

이벤트를 방송하는 과정을 \방출\이라고 합니다. 관리자가 initctl emit 명령을 실행하여 수동으로 이벤트를 내보낼 수도 있지만 일반적으로 프로세스 또는 작업 상태로 인해 발생합니다. > 명령은 Upstart와 관련된 수많은 작업을 탐색할 때 매우 유용합니다.

첫 번째 작업 구성 작성

Upstart는 Ubuntu에서 잘 작동하는 것으로 알려져 있으므로 시작하기 전에 Ubuntu 14.04 Droplet을 실행하십시오.

이제 준비가 되었으므로 작업 구성 파일이 유효하려면 세 가지 기본 원칙을 준수해야 한다는 점을 이해하는 것이 중요합니다.

  • 비어 있으면 안 됩니다(콘텐츠가 없는 파일).
  • 구문 오류가 없어야 합니다
  • 스탠자로 알려진 하나 이상의 명령 블록을 포함해야 합니다.

지금은 기본으로 유지합시다. 잠시 후 /etc/init 디렉토리에 testjob.conf라는 파일을 생성합니다. 이 경우 "초기화\는 "초기화\의 축약형으로 사용됩니다.

작업 구성 파일을 작성할 것임을 나타내는 .conf 파일 연결에 주목하십시오.

이 자습서의 목적을 위해 명령줄 텍스트 편집기 nano를 사용하는 것이 좋습니다. 이러한 명령 중 일부는 sudo와 함께 관리 권한이 필요할 수 있으므로 이 문서를 확인하여 적절한 사용자를 생성하십시오.

테스트 작업을 위한 새 구성 파일을 만들려면 다음을 실행합니다.

sudo nano /etc/init/testjob.conf

이제 목표를 간략히 설명하겠습니다. 우리는 이 작업이 로그 파일에 메시지와 현재 타임스탬프를 쓰기를 원합니다.

작업 스크립트의 목적과 작성자를 정의하는 데 도움이 되는 두 가지 기본 스탠자(descriptionauthor)가 있습니다. 파일의 첫 번째 행으로 다음을 작성하십시오.

description "A test job file for experimenting with Upstart"
author "Your Name"

이제 시스템 서비스와 프로세스가 이미 로드된 후에(충돌을 방지하기 위해) 이 작업이 수행되기를 원하므로 다음 행에 다음 이벤트가 통합됩니다.

start on runlevel [2345]

런레벨이 무엇인지 궁금하실 수 있습니다. 기본적으로 현재 시스템 구성을 나타내는 단일 값입니다. [2345]는 일반 Linux 액세스 및 네트워킹이 있는 모든 구성 상태를 나타내며 기본 테스트 예제에 이상적입니다.

그런 다음 실행 코드를 추가합니다. 이 줄은 exec로 시작하여 Bash 셸을 통해 다음 명령을 실행해야 함을 나타냅니다.

exec echo Test Job ran at  `date` >> /var/log/testjob.log

echo 명령은 백틱을 사용하여 date를 명령으로 실행한 다음 전체 메시지를 로그 파일에 씁니다. 백틱 없이 날짜라는 단어를 쓰면 명령 출력 대신 단어 자체가 인쇄됩니다.

이 파일을 저장하고 닫습니다.

작업을 수동으로 시작하여 이것이 작동하는지 확인할 수 있지만 먼저 구성 파일 구문을 확인하겠습니다.

init-checkconf /etc/init/testjob.conf

문제가 감지되면 이 명령은 특정 줄 번호와 문제를 나타냅니다. 그러나 테스트 작업에서는 다음과 같은 출력이 표시되어야 합니다.

File /etc/init/testjob.conf: syntax ok

이 명령은 Upstart 작업 및 웹 서버와 같은 기타 백그라운드 서비스를 제어하는 데 사용할 수 있습니다.

기본 명령 구문은 다음과 같습니다.

sudo service <servicename> <control>

이 구문은 다음 기본 컨트롤과 함께 작동합니다.

  • 다시 시작: 중지한 다음 서비스를 시작합니다.
  • 시작: 서비스가 실행 중이 아닌 경우 서비스를 시작합니다.
  • 중지: 실행 중인 서비스를 중지합니다.
  • 상태: 서비스 상태를 표시합니다.

테스트 작업을 수동으로 시작하려고 하므로 명령은 다음과 같아야 합니다.

sudo service testjob start

이제 다음 명령을 실행하여 testjob.log 파일을 확인합니다.

cat /var/log/testjob.log

이 명령은 파일을 쉘로 읽습니다. 아래와 비슷한 한 줄이 표시됩니다.

Test Job ran at Fri Aug 1 08:43:05 BST 2014

이는 테스트 작업이 설정되고 사용할 준비가 되었음을 나타냅니다.

Droplet을 재부팅한 다음 로그인하고 로그 파일을 다시 읽으십시오.

cat /var/log/testjob.log

Upstart 작업으로 실행되었음을 확인하기 위해 이후 타임스탬프를 표시하는 두 번째 줄이 로그에 표시되어야 합니다.

Test Job ran at Fri Aug 1 08:44:23 BST 2014

이는 Upstart로 할 수 있는 작업의 일부에 불과합니다. 나중에 자세한 예를 다루겠지만 지금은 작업 상태 및 이벤트에 대한 설명으로 넘어가겠습니다.

작업 상태 및 이벤트

시스템 작업은 /etc/init/ 디렉토리에 있고 사용자 작업은 사용자 고유의 초기화 디렉토리인 ~/.init/에 있습니다.

사용자 작업은 사용자 자신의 세션에서 실행되므로 세션 작업이라고도 합니다. 이들은 시스템 전체에서 실행되지 않으며 PID 1 지정에 있지 않습니다. 테스트 작업을 위해 시스템이 부팅될 때 로드할 수 있도록 /etc/init를 사용했습니다.

작업 유형에 관계없이 작업은 항상 구성 파일(.conf)에 정의되며 파일 이름은 관련된 서비스나 작업을 나타내야 합니다.

이러한 각 작업에는 시작 또는 중지라는 목표가 있습니다. 이 두 목표 사이에는 목표와 관련하여 작업의 현재 작업을 정의하는 일련의 작업 상태가 있습니다. 중요한 상태는 다음과 같습니다.

  • waiting: 초기 처리 상태
  • 시작: 작업이 시작되려는 위치
  • pre-start: 사전 시작 섹션이 로드되는 위치
  • spawned: 스크립트 섹션이 실행될 위치
  • 시작 후: 시작 후 작업이 수행되는 위치
  • 실행 중: 작업이 완전히 작동하는 위치
  • 사전 정지: 사전 정지 작업이 이루어지는 곳
  • 중지: 작업이 중지되는 위치
  • killed: 작업이 중지된 위치
  • 사후 정지: 사후 정지 작업이 수행되는 곳 - 청소를 위해

시작 후 상태 이후 작업은 실행 중으로 정의됩니다. 사전 중지가 트리거될 때까지 계속 실행되며 작업이 중지될 준비가 된 다음 작업이 종료되고 중지 후 정리 절차가 수행됩니다(정의된 경우).

이 명령을 사용하여 Upstart 시스템 로그(/var/log/upstart/ 디렉토리에 있음)의 우선 순위를 debug로 설정하여 작업이 상태 간에 어떻게 전환되는지 볼 수 있습니다. :

sudo initctl log-priority debug

상태는 이벤트가 아니며 이벤트는 상태가 아님을 기억하십시오. 네 가지 이벤트(시작, 시작, 중지 및 중지)는 Upstart에서 발생하지만 작업 상태는 작업 수명 단계 사이의 전환을 정의합니다.

이제 서비스 작업을 작성하여 첫 번째 구성의 요소를 통합하는 보다 집중적인 예제로 이동할 준비가 되었습니다. 기본 테스트 구성 실행에서 프로덕션 준비 스크립트로 전환하는 방법을 보여줍니다.

심층 예제: 서비스 작업

서론에서 간략하게 다룬 서비스 작업에는 백그라운드에서 프로세스를 실행할 수 있도록 하는 스크립팅 구성 파일이 포함됩니다. 처음부터 기본 Node.js 서버를 설정할 것입니다.

Node에 익숙하지 않다면 본질적으로 "서버 측 및 네트워킹 응용 프로그램을 위한 교차 플랫폼 환경\(Wikipedia)입니다.

Node.js는 Ubuntu 14.04에 기본적으로 설치되지는 않지만 매우 가벼운 패키지입니다. 시작하려면 클라우드 서버에 설치하십시오.

sudo apt-get install nodejs

이제 서비스 작업을 시작하겠습니다. nodetest.conf라는 /etc/init에 새 작업 구성 파일을 만듭니다. 목적을 참조하여 파일 이름을 지정하는 것이 중요하므로 이 서비스 작업이 Node.js 테스트용임을 알 수 있습니다.

sudo nano /etc/init/nodetest.conf

사전에 Upstart 구성을 이해하는 것이 중요하므로 이 예제의 뒷부분에서 노드 애플리케이션 자체를 다룰 것입니다.

먼저 첫 번째 것들. 작업 설명과 작성자 줄을 입력하여 구성을 정의하는 것으로 시작합니다.

description "Service for a test node.js server"
author      "Your Name"

우리는 이 노드 기반 서버 응용 프로그램이 서버가 가동되어 실행 중일 때 시작되고 정상적으로 종료되었을 때 중지되기를 원합니다. 이 때문에 두 조건을 모두 지정해야 합니다.

start on filesystem or runlevel [2345]
stop on shutdown

이전의 런레벨 기준을 기억하십니까? filesystem 이벤트와 결합하면 서버가 정상적으로 실행 중일 때 작업이 로드됩니다.

이것이 기본이지만 이제 더 복잡해집니다. 앞에서 언급한 스탠자를 사용할 것입니다.

이것은 서버 애플리케이션이므로 작업 구성에 로깅 요소를 통합할 것입니다. 노드 애플리케이션이 시작되고 중지될 때 기록하기를 원하기 때문에 세 가지 다른 스탠자를 사용하여 script, pre-start script 서비스 작업을 구분할 것입니다. >사전 중지 스크립트.

이 소리가 익숙하다고 생각한다면 절대적으로 옳습니다. 사전 시작 및 사전 중지는 작업 상태이지만 스탠자에서도 작동합니다. 이것이 의미하는 바는 작업이 있는 상태에 따라 다른 명령을 실행할 수 있다는 것입니다.

그러나 작성할 첫 번째 스탠자는 작업 스크립트 자체입니다. 노드 백그라운드 서버의 프로세스 ID를 얻은 다음 애플리케이션 스크립트를 실행합니다. 스탠자 내 명령 들여쓰기에 유의하십시오. 이는 구문상 올바른 형식 지정에 필수적입니다.

script

	export HOME="/srv"
	echo $$ > /var/run/nodetest.pid
	exec /usr/bin/nodejs /srv/nodetest.js

end script

노드에는 홈 디렉토리 변수를 설정해야 하므로 /srv가 스탠자의 첫 번째 줄에 내보내지는 이유입니다. 다음으로 $$는 사용 가능한 프로세스 ID를 가져오고 작업에 대한 PID 파일을 만드는 데 사용됩니다. 준비가 되면 나중에 작성할 Node.js 애플리케이션이 로드됩니다.

이제 간단한 애플리케이션 로깅에 사용될 pre-startpre-stop에 집중할 시간입니다. 시작 또는 중지 메시지와 함께 날짜가 작업의 로그 파일에 추가됩니다.

pre-start script
	echo "[`date`] Node Test Starting" >> /var/log/nodetest.log
end script

사전 중지 스탠자에는 서버를 종료하는 절차의 일부로 PID 파일을 제거하는 다른 줄이 포함되어 있습니다(사전 중지가 수행하는 작업).

pre-stop script
	rm /var/run/nodetest.pid
	echo "[`date`] Node Test Stopping" >> /var/log/nodetest.log
end script

전체 Upstart 작업 구성이 정렬되었습니다. 참조를 위해 전체 내용이 다시 있습니다.

description "Test node.js server"
author      "Your Name"

start on filesystem or runlevel [2345]
stop on shutdown

script

	export HOME="/srv"
	echo $$ > /var/run/nodetest.pid
	exec /usr/bin/nodejs /srv/nodetest.js

end script

pre-start script
	echo "[`date`] Node Test Starting" >> /var/log/nodetest.log
end script

pre-stop script
	rm /var/run/nodetest.pid
	echo "[`date`] Node Test Stopping" >> /var/log/nodetest.log
end script

파일을 저장하고 닫습니다.

exec 줄에 표시된 대로 Node.js 스크립트는 서버에서 실행되므로 원하는 위치(/srv/ 이 예에서는 가 사용됨):

sudo nano /srv/nodetest.js

이것은 Upstart 튜토리얼이므로 Node.js 코드를 검토하는 데 너무 오래 걸리지는 않지만 이 스크립트가 수행할 작업에 대한 요약은 다음과 같습니다.

  • 노드의 HTTP 모듈 필요 및 로드
  • HTTP 웹 서버 만들기
  • 헤더에 상태 200(OK) 응답 제공
  • \Hello World를 출력으로 작성
  • 포트 8888에서 수신

시간을 절약하기 위해 직접 복사할 수 있는 Node 애플리케이션을 실행하는 데 필요한 코드는 다음과 같습니다.

var http = require("http");

http.createServer(function(request, response) {
	response.writeHead(200, {"Content-Type": "text/plain"});
	response.write("Hello World");
	response.end();
}).listen(8888);

Node.js 파일을 저장한 후 마지막으로 확인할 사항은 Upstart 작업 구문이 유효한지 여부입니다. 평소와 같이 구성 확인 명령을 실행하면 출력으로 확인을 받아야 합니다.

init-checkconf /etc/init/nodetest.conf 

File nodetest.conf: syntax ok

작업 구성이 있고 구문을 확인했으며 Node.js 코드를 저장했습니다. 모든 것이 준비되었으므로 Droplet을 재부팅한 다음 http://IP:8888 또는 관련 도메인을 방문하세요.

창의 왼쪽 상단에 "Hello World\가 표시되면 Upstart 서비스 작업이 완료된 것입니다!

상태 기반 로깅을 확인하려면 사전 정의된 로그 파일을 읽으십시오. 타임스탬프가 있는 Starting 줄이 표시되어야 합니다. 서버를 종료하거나 서비스 작업을 수동으로 중지하면 로그에 Stopping 줄이 기록되며 원하는 경우 확인할 수도 있습니다.

cat /var/log/nodetest.log

[Sun Aug 17 08:08:34 EDT 2014] Node Test Starting
[Sun Aug 17 08:13:03 EDT 2014] Node Test Stopping

다음과 같은 구문을 사용하여 이 서비스 및 기타 유사한 Upstart 작업에 대해 표준 시작, 중지, 다시 시작 등의 명령을 실행할 수 있습니다.

sudo service nodetest restart

결론

이 튜토리얼은 Upstart Event System의 겉핥기만 합니다. 기존 초기화에 대한 배경을 읽고 오픈 소스 Upstart 솔루션이 더 강력한 선택인 이유를 알아보고 자신의 작업을 작성하기 시작했습니다. 기본 사항을 알았으니 가능성은 무한합니다.

Upstart 공식 웹사이트의 로고, 저작권 원본 디자이너/Canonical Ltd.