블로그로 돌아가기

리눅스 서비스가 재부팅 또는 시스템 크래시 후 자동 시작되도록 구성하는 방법: 1부 (실용적인 예제)

리눅스 서비스가 재부팅 또는 시스템 크래시 후 자동 시작되도록 구성하는 방법: 1부 (실용적인 예제)

소개

컴퓨팅에서는 항상 계획대로만 진행되지는 않습니다. 종종 예기치 않은 시스템 다운으로 인해 시스템 관리자가 재부팅을 수행하고 개별 서비스를 다시 시작해야 하는 상황이 발생합니다. 시스템 다운이나 재부팅 후 애플리케이션이 실행되는 데 필요한 모든 서비스를 파악하고 다시 시작하는 것은 번거로운 일일 수 있습니다. 총 2부로 구성된 이 튜토리얼의 첫 번째 파트에서는 실질적인 예제를 통해 시스템 다운 또는 서버 재부팅 후 서비스가 자동으로 시작되도록 구성하는 방법을 보여드리겠습니다. 두 번째 파트에서는 이론적인 정보를 다룰 것입니다(첫 번째 파트에서 달성한 내용에 대한).

실습 예제로는 MySQL 데이터베이스 서비스를 사용할 것입니다. 하지만 동일한 원칙이 다음과 같이 완전한 서버를 구성하는 다른 프로세스에도 적용됩니다: Nginx, Apache, Redis 또는 기타 애플리케이션. 다음에서 제공하는 튜토리얼을 확인하실 수 있습니다: MySQL 설치 방법, NginxApache.

In Linux 배포판에는 실행 중인 배포판에 따라 세 가지 주요 초기화(init) 시스템이 있습니다. 일부 배포판에는 아래에 설명된 대로 두 개 이상의 init 시스템이 포함되어 있을 수 있습니다:

  • System V – 다음과 같은 이전 배포판에서 볼 수 있는 오래된 init 시스템입니다:
    • Ubuntu 9.04 및 이전 버전
    • CentOS 5 및 이전 버전
    • Debian 6 및 이전 버전
  • Upstart – 다음과 같은 이전 배포판에서 사용되었습니다:
    • CentOS 6
    • Ubuntu 9.10 ~ Ubuntu 14.10 및 Ubuntu 14.04
  • Systemd – 다음과 같은 최신 배포판에서 사용됩니다:
    • CentOS 7
    • Debian 7 및 8.
    • Ubuntu 15.04 및 최신 버전

배경

운영 체제, 특히 Linux 및 Unix 시스템에서는 백그라운드에서 프로세스와 서비스가 실행되는 것이 일반적입니다. 이러한 서비스는 운영 체제 소프트웨어와 함께 제공되었을 수 있습니다. 일부는 사용자가 설치한 애플리케이션과 함께 제공되었을 수도 있습니다.

운영 체제 서비스에는 다음이 포함됩니다:

  • sshd – 원격 연결을 허용하는 데몬입니다.
  • cupsd – 인쇄를 제어하는 데몬입니다.

설치된 애플리케이션 서비스에는 다음이 포함됩니다:

  • httpd/apache2 – Apache2 웹 서버와 함께 제공되는 서비스입니다.
  • nginx – Nginx 웹 서버와 함께 제공되는 서비스입니다.

웹 애플리케이션, 데이터베이스, 메일 서버 등에 액세스할 수 있도록 하려면 이러한 서비스가 지속적으로 실행되어야 합니다. 시스템 관리자이거나 호기심 많은 앱 개발자라면 이러한 서비스가 지속적으로 실행되도록 하고, 불행히도 시스템이 다운되는 경우 시스템이 재부팅된 후 자동으로 시작되도록 하고 싶을 것입니다. 이 실습 튜토리얼에서 바로 그 방법을 배우게 됩니다.

경고를 설정하고 Linux 배포판을 지속적으로 모니터링하는 것도 중요하지만, 서비스를 관리하는 init 시스템 덕분에 잘 구성하기만 하면 일부 Linux 서비스는 자체 복구(자가 치유)될 수 있습니다.

Linux 배포판에는 시스템 초기화를 구현하는 모드 작업이 있으며, 이를 런레벨(runlevels)이라고 합니다. 서비스가 자동으로 시작되려면 런레벨에 추가되어야 합니다. 모든 Linux 및 Unix 계열 시스템에는 아래에 나열된 네 가지 공통 런레벨이 있습니다.

  • 0 – 런레벨 0은 시스템 종료를 나타냅니다.
  • 1 – 런레벨 1은 단일 사용자, 복구 모드를 나타냅니다.
  • 2, 3, 4 – 이 런레벨은 시스템이 다중 사용자, 네트워크 사용 가능, 텍스트 모드로 부팅된 상태를 나타냅니다.
  • 5 – 런레벨 5는 다중 사용자, 네트워크 사용 가능, 그래픽 모드를 나타냅니다.
  • 6 – 런레벨 6은 시스템 재부팅을 나타냅니다.

본 튜토리얼에서 여러분은 앞서 설명한 세 가지 다른 init 모드인 System V, Upstart, Systemd를 사용하여 시스템이 재부팅될 때 Linux 서비스가 자동으로 시작되도록 구성하는 방법을 배우게 됩니다.

사전 요구 사항

이 실습 튜토리얼을 진행하려면 따라 할 수 있는 Linux VPS가 필요합니다. Cloudsigma의 무료 평가판 기간을 활용하여 서버를 구동하고 명령어를 테스트해 볼 수 있습니다. 다음의 Ubuntu 서버 설정 방법에 대한 단계별 튜토리얼.

이 튜토리얼에서 생성하는 서버는 순전히 실습을 따라 하기 위한 용도이므로, 많은 서비스가 중단될 수 있으므로 운영 서버에서 명령어를 실행해서는 안 됩니다.

필요한 배포판 중 일부는 다음과 같습니다:

  • Ubuntu 9.04 및 이전 버전, 또는 Debian 6 x64 (System V init 시스템을 시연하는 데 사용됨)
  • Ubuntu 14.04 x64 (Upstart를 시연하는 데 사용됨)
  • CentOS 7 x64 (systemd를 데모하는 데 사용됩니다).

sudo 권한이 있는 비루트(non-root) 사용자를 설정했는지 확인하십시오. 다음에서 당사의 sudoers 파일 구성에 대한 튜토리얼을 확인하실 수 있습니다.

System V 사용하기

이것은 다음과 같은 이전 Linux 배포판에서 사용되었던 가장 오래된 init 시스템입니다:

  • Debian 6 및 이전 버전
  • CentOS 5 및 이전 버전
  • Ubuntu 9.04 및 이전 버전

MySQL 및 Nginx와 같이 설치 가능한 대부분의 서버 애플리케이션에는 기본적으로 다음 디렉토리에 init 스크립트가 저장되어 제공됩니다: /etc/init.d 디렉토리. 이 스크립트를 사용하면 재부팅 후 애플리케이션을 시작할 수 있습니다. 그러나 시스템 충돌 후 자동으로 시작되도록 구성되어 있지 않을 수 있습니다.

System V 자동 시작 체크리스트

첫 번째 단계는 /etc/init.d/service 디렉토리에 작동 가능한 Bash init 스크립트가 있는지 확인하는 것입니다. 서비스를 활성화하려면, Debian 또는 Ubuntu 배포판에서는 update-rc.d 명령을 사용하고, CentOS 시스템에서는 chkconfig를 사용하십시오. 실제 서비스 이름으로 대체하십시오:

위 명령은 다음 디렉토리에 심볼릭 링크(symlink)를 생성합니다: /etc/rc2.d 디렉토리이며 아래 출력과 같이 보입니다. 자동으로 생성되므로 직접 생성하지 마십시오:

파일의 맨 아래에 /etc/inittab 아래의 일반적인 예와 같이 respawn 줄을 추가하십시오. 애플리케이션의 시작 스크립트에 대한 실제 경로로 바꾸는 것을 잊지 마십시오:

서비스를 중지하고 시작하려면 다음 명령을 입력하십시오:

다음으로, 서버를 재부팅합니다:

변경 사항을 테스트하는 방법은 무엇입니까?

서버를 재부팅한 후, 다음 명령을 사용하여 프로세스 번호를 검색하여 서비스가 실행 중인지 확인하십시오:

다음 명령을 사용하여 프로세스를 종료(kill)하십시오:

5분 후, 서비스가 정상적으로 실행 중인지 확인하십시오.

실제 서비스를 사용한 실용적인 System V 구성

다음 단계에서는 MySQL과 같은 실제 서버 애플리케이션을 사용해 보겠습니다. 귀하는 Debian 6 가상 머신에 액세스할 수 있어야 합니다. sudo 권한이 있는 계정으로 SSH 또는 Windows 데스크톱을 사용하는 경우 putty를 사용하여 연결하십시오.

1단계: MySQL 설치

MySQL을 설치하려면 다음 명령을 입력하십시오:

설치가 시작되면 root 비밀번호를 입력하라는 메시지가 표시됩니다. 그런 다음 원하는 비밀번호를 입력하고 확인하십시오. 설치가 완료될 때까지 기다린 후, 다음 명령을 입력하여 MySQL 보안 설정을 시작하십시오:

이전에 입력한 root 비밀번호를 묻는 메시지가 표시됩니다. 유지하려면 N을 누르십시오. 다음으로, 익명 사용자 제거, 원격 root 로그인 비활성화, 테스트 데이터베이스 제거에 대한 후속 프롬프트를 수락하려면 Y를 누르십시오. 마지막으로, 변경 사항이 자동으로 반영되도록 권한 테이블을 다시 로드하는 것을 수락하십시오.

이것으로 MySQL 설치가 완료되었습니다. 다음 명령을 입력하여 서비스가 실행 중인지 확인할 수 있습니다:

2단계: 재부팅 후 MySQL이 자동 시작되도록 구성

MySQL은 기본적으로 시스템 재부팅 후 시작되도록 구성되어 있습니다. 다음 디렉토리에서 MySQL 초기화 스크립트에 대한 심볼릭 링크를 찾을 수 있습니다: /etc/rc2.d 디렉토리. 이 심볼릭 링크는 수동으로 생성되지 않습니다. 서비스를 활성화 및 비활성화하려면 update-rc.d 명령을 사용할 수 있습니다.

디렉토리의 내용을 나열하려면 다음 명령을 입력하십시오:

MySQL init 스크립트에 대한 심볼릭 링크가 보이는지 확인하십시오:

The S는 중요합니다. 왜냐하면 볼 수 있는 한, S 서비스의 기본 런레벨 디렉터리 아래에 스크립트가 있으면, init 시스템은 서버가 부팅될 때 서비스를 시작합니다. 재부팅 후 MySQL이 자동 시작되는지 확인하려면 다음 명령어를 입력하여 시스템을 재부팅하십시오:

재부팅하는 동안 ssh 연결이 끊어집니다. 1~2분 정도 기다린 후 다시 연결하십시오. 다음 명령어를 실행하여 서비스가 실행 중인지 확인하십시오:

출력 결과에 서비스가 실행 중이라고 표시됩니다. 이는 재부팅 후 자동으로 시작되었음을 의미합니다. 자동으로 시작되도록 구성되지 않은 서비스의 경우 직접 구성해야 합니다.

MySQL 서비스를 비활성화하고 시스템을 재부팅하여 자동 시작되는지 테스트할 수 있습니다. Debian 및 Ubuntu 시스템에서는 update-rc.d 명령어를 사용하여 init 시스템에서 서비스를 추가하거나 제거할 수 있습니다. MySQL 서비스를 비활성화하려면 다음 명령어를 입력하십시오:

시스템을 재부팅하고 ssh를 사용하여 다시 연결하십시오. 다음 명령어를 사용하여 MySQL에 연결해 보십시오:

다음과 같은 MySQL 오류가 발생합니다:

그런 다음, 다음 명령어를 입력하여 서비스를 다시 활성화하십시오:

CentOS 배포판을 사용하는 경우 명령어는 다음과 같습니다:

처음에는 MySQL이 시작되지 않았으므로 시작해야 합니다. 다음 명령어를 입력하십시오:

3단계: 시스템 충돌 후 서비스(MySQL)가 자동 시작되도록 구성

System V는 충돌 후 프로세스를 자동으로 시작하지 않습니다. MySQL 프로세스 ID를 찾아 종료함으로써 시스템 충돌을 시뮬레이션할 수 있습니다. MySQL 프로세스 ID를 찾으려면 다음 명령어를 입력하십시오:

출력 결과에서 MySQL 프로세스를 찾습니다. MySQL을 실행하는 주요 프로세스는 mysqld_safe 및 mysqld입니다. 해당 프로세스 ID(숫자)를 기록하고 다음 명령어를 사용하여 종료하십시오:

다음 명령어를 사용하여 MySQL 서비스 상태를 확인하십시오:

출력 결과에 MySQL이 중지되었다고 표시됩니다. service start 명령어를 사용하여 수동으로 다시 시작할 수 있습니다. 하지만 우리는 자동 프로세스를 원합니다. 이러한 자동 동작을 구현하려면 /etc/inittab 파일을 편집해야 합니다. 이 파일은 System V init이 부팅할 때 가장 먼저 읽는 파일입니다. /etc/inittab 파일에는 프로세스가 충돌할 때 어떻게 동작해야 하는지에 대한 지침이 포함되어 있습니다. 올바르게 구성되면 충돌이 발생했을 때 시스템을 다시 시작합니다. 우리의 경우, MySQL이 해당 서비스 중 하나가 되도록 하려고 합니다.

The /etc/inittab 파일은 Linux 배포판에서 매우 중요합니다. 이 파일은 시스템의 재부팅 여부를 결정합니다. 명령어에 실수가 있으면 재부팅할 때 시스템이 시작되지 않을 수 있습니다. 앞서 언급했듯이, 운영 환경이 아닌 테스트 서버 환경에서만 이 명령어들을 시도해 보시길 바랍니다.

먼저 편집을 시작하기 전에 파일의 복사본을 만드십시오:

다음으로, nano를 사용하여 파일을 엽니다:

파일의 끝으로 스크롤하여 다음 코드 스니펫을 추가하십시오:

위 명령어는 시스템 충돌 후 mysql_safe 프로세스를 다시 시작합니다. 아래에 설명된 대로 콜론(:)으로 구분된 4개의 필드가 있습니다:

  • ms: 프로세스의 ID를 지정합니다.
  • 2345: 명령어가 적용되는 런레벨을 지정합니다. 이 경우: 런레벨 2, 3, 4, 5.
  • respawn: 동작을 지정합니다. 이 경우 프로세스를 재실행(respawn)하거나 다시 시작합니다.
  • /bin/sh /usr/bin/mysqld_safe: 마지막 부분은 프로세스를 정의합니다. 즉, 프로세스를 다시 시작하기 위해 실행되는 명령어입니다.

이제 Ctrl + O를 누르고 Enter를 입력하여 파일을 저장합니다. 그런 다음 Ctrl + X를 눌러 편집기를 닫습니다. 다음 명령어를 입력하여 서비스를 시작합니다:

서버를 재부팅한 다음, 앞서 설명한 명령어를 실행하여 프로세스 번호를 찾습니다. 그런 다음, 다음 명령어로 시작하여 프로세스를 종료합니다. ps -ef | grep mysql. 몇 분 동안 기다린 후 다음 명령어를 입력하여 MySQL의 상태를 확인합니다:

출력 결과에 MySQL 서비스가 실행 중이라고 표시되어야 하며, 이는 크래시 이후 성공적으로 재시작되었음을 의미합니다. 서버의 다른 서비스에 대해서도 동일한 과정을 수행할 수 있습니다.

Upstart를 사용하여 서비스 자동 시작하기

Upstart은(는) Ubuntu 6에서 처음 도입되었고 이후 Ubuntu 9.10에서 기본값이 된 또 다른 init 시스템입니다. RHEL 6 및 그 파생 버전, 그리고 Google의 Chrome OS도 Upstart init 시스템을 사용합니다. 이 섹션의 단계를 진행하려면 다음 배포판 중 하나를 실행하는 서버가 필요합니다:

  • Ubuntu 9.10부터 Ubuntu 14.10까지, 그리고 Ubuntu의 LTS 버전인 Ubuntu 14.04.
  • CentOS 6

재부팅 또는 시스템 크래시 발생 시 서버 서비스가 자동으로 시작되도록 Upstart 파일을 구성하는 방법을 살펴보겠습니다. Upstart는 /etc/init 디렉터리에 저장된 구성 파일을 사용하여 Linux 배포판의 서비스를 제어합니다. MySQL 및 Nginx와 같은 최신 버전의 서버 애플리케이션은 자체 init 스크립트를 /etc/init 디렉터리에 설치합니다. 따라서 사용자가 아무것도 하지 않아도 재부팅 후 및 시스템 크래시 후에 자동으로 시작됩니다.

Upstart 자동 시작 체크리스트

서비스가 자동으로 시작되도록 구성되어 있는지 확인하기 위한 몇 가지 참조 구성은 다음과 같습니다.

  • 서비스의 init 스크립트가 다음 디렉터리에 있는지 확인합니다: /etc/init/service_name.conf service_name은(는) 해당 특정 서비스의 실제 이름입니다. /etc/init/service_name.conf 파일에서 다음 두 줄을 확인해야 합니다:
    • 다음과 같은 내용을 포함하는 줄: start on runlevel [2345]. 이는 시스템 재부팅 시 서비스가 시작됨을 나타냅니다.
    • 다음과 같은 내용을 포함하는 줄: respawn. 이는 시스템 크래시 후 서비스가 다시 생성/재시작됨을 나타냅니다.
  • 디렉터리에 서비스 재정의(override) 파일이 없는지 확인합니다: /etc/init/service_name.override. 귀하 또는 다른 시스템 관리자가 이전에 생성한 경우가 아니라면 말입니다.
  • 다음 명령어를 입력하여 서비스를 중지하고 시작합니다:
  • 시스템을 재부팅하고 몇 분 후에 다시 연결합니다. 이제 제대로 작동하는지 테스트를 실행해 보겠습니다.
  • 재부팅 후 서비스가 정상적으로 실행 중인지 확인합니다. 다음 명령어를 입력하여 프로세스 번호를 검색하되, service_name을 테스트 중인 서비스의 실제 이름으로 바꿉니다:
  • 프로세스 번호를 확인했으면 다음 명령어를 입력하여 프로세스를 종료합니다:
  • 몇 초 동안 기다린 후 프로세스가 다시 실행 중인지 확인합니다.

실제 서비스를 사용한 실용적인 Upstart 구성

다음 섹션에서는 실제 서비스에 Upstart를 사용하는 방법을 보여드리겠습니다. MySQL을 서비스로 사용하는 Ubuntu 14.04 가상 머신 서버에서 테스트를 실행할 것입니다. Windows를 사용하는 경우 ssh 또는 putty를 사용하여 Ubuntu 14.04 테스트 서버에 연결합니다. 일반적인 경우와 마찬가지로 sudo 권한이 있는 non-root 사용자를 사용해야 합니다. 로그인한 후 단계를 시작할 수 있습니다:

1단계: MySQL 설치

새 소프트웨어를 설치하기 전에 항상 패키지를 업데이트해야 합니다:

이제 다음 명령어를 입력하여 MySQL 서버를 설치합니다:

프롬프트가 표시되면 root 비밀번호를 생성합니다. 설치가 완료될 때까지 기다린 후 다음 명령어를 실행하여 MySQL 설치 보안 설정을 시작합니다:

이전 섹션에서 했던 것처럼 프롬프트의 안내를 따르세요. 그런 다음, 변경 사항이 즉시 적용되도록 권한(privileges)을 플러시(flush)합니다.

2단계: 시스템 재부팅 후 서비스(MySQL)가 자동 시작되도록 구성하기

MySQL은 재부팅 후 자동으로 시작되도록 설정되어 있습니다. 여기서는 사용자 정의 애플리케이션도 재부팅 후 자동으로 시작되도록 구성하는 방법을 배우기 위해 MySQL의 설정 파일만 살펴보는 것입니다. MySQL 서비스는 설치 후 자동으로 시작되었습니다. 하지만 다음 명령어를 입력하여 실행 중인지 확인해 보겠습니다:

MySQL 서비스가 실행 중임을 나타내는 다음과 같은 출력이 표시되어야 합니다:

서버를 재부팅하고 다시 로그인합니다. 다시 다음 명령어를 입력하여 실행 중인지 테스트합니다:

출력 결과는 MySQL이 실행 중임을 나타내며, 이는 재부팅 후 자동으로 시작되었음을 의미합니다. 이 경우에는 아무것도 변경할 필요가 없습니다. 그러나 다른 애플리케이션의 경우 이 동작이 다를 수 있습니다. Upstart 초기화 시스템이 재부팅 후 MySQL을 자동 시작해야 한다는 것을 어떻게 아는지 궁금할 수 있습니다. MySQL은 Upstart 시작 구성 파일을 다음 위치에 설치합니다: /etc/init/mysql.conf. Upstart 파일은 셸 스크립트가 아니라 pre-start 및 post-start 이벤트에 대한 스크립트 블록이 포함된 텍스트 파일입니다. 이 블록은 MySQLd 프로세스가 시작 중이거나 이미 시작되었을 때 실행할 작업을 Upstart 시스템에 지시합니다.

nano로 편집기에서 파일을 열려면 다음 명령어를 입력하세요:

파일의 출력은 다음과 같을 수 있습니다:

보시다시피, start 블록은 MySQL이 런레벨 2,3,4,5에서 시작하고 0,1,6에서는 시작하지 않도록 지시합니다. 애플리케이션에 대한 Upstart 구성을 정의하는 경우 이 섹션에서 정의하게 됩니다. respawn 블록은 크래시(충돌)가 발생한 후 Upstart가 수행할 작업을 지시합니다. 이에 대해서는 다음 섹션에서 설명할 예정이므로 nano 편집기에서 파일을 열어 두세요.

3단계: 크래시 후 서비스(MySQL)가 자동 시작되도록 구성하기

The respawn 지시어는 /etc/init/mysql.conf 파일에서 크래시 발생 후 MySQL 서비스를 재시작하도록 Upstart에 지시합니다.

respawn limit 지시어는 초 단위로 지정된 간격 내에서 크래시가 발생한 MySQL 서비스를 재시작하려고 시도해야 하는 횟수를 Upstart에 지시합니다. 첫 번째 인수 (2)는 시도 횟수를 나타냅니다. 두 번째 인수 (5)는 초 단위의 간격을 나타냅니다. 크래시 발생 후 Upstart가 임계값 내에 MySQL 서비스를 다시 시작(respawn)하지 못하면 서비스는 중지된 상태로 유지됩니다. 이 동작은 지속적으로 크래시가 발생하는 서비스를 계속 재시작하려고 시도하여 시스템 안정성에 영향을 주는 것을 방지하도록 설계되었습니다. 이제 변경 사항을 저장하지 않고 편집기를 닫으셔도 됩니다.

크래시 발생 후 MySQL이 자동으로 다시 시작되는지 테스트해 보겠습니다. 다음 명령어를 입력하여 MySQL 서비스의 상태를 확인하고 프로세스 번호를 가져옵니다:

출력은 다음과 같아야 합니다. 나중에 사용할 것이므로 프로세스 번호를 기록해 두세요:

다음으로, 프로세스를 강제 종료하는 다음 명령어를 입력합니다. 이는 크래시를 에뮬레이트합니다. 이전 명령어에서 얻은 프로세스 번호로 대체하세요:

다음 명령어를 입력하여 MySQL의 상태를 다시 확인합니다:

다시 실행 중이어야 하지만, 아마도 다른 프로세스 번호일 것입니다:

이것은 다음 파일에 있는 respawn 지시어 때문에 발생합니다: /etc/init/mysql.conf 파일입니다. 이 파일은 시스템 장애가 발생하더라도 MySQL이 자동으로 시작되도록 보장합니다. 따라서 MySQL 데이터베이스에 의존하는 애플리케이션이 예상대로 계속 작동합니다.

Systemd를 사용하여 서비스 자동 시작하기

Systemd은(는) 대부분의 최신 Linux 배포판에서 볼 수 있는 초기화 시스템입니다. 사용자가 새로운 VPS를 구동할 때 주로 사용하게 될 것입니다. 이 시스템은 Fedora에서 처음 도입되었습니다. RHEL 7 및 CentOS 7과 같은 파생 버전과 함께 제공됩니다. Ubuntu 15.04부터는 Systemd가 기본적으로 탑재되어 있습니다. Systemd는 System V 초기화 스크립트 및 명령과 하위 호환됩니다. 따라서 모든 System V 서비스는 Systemd에서 작동해야 합니다. System V 및 Upstart에서 사용되는 대부분의 명령은 Systemd와 작동하도록 수정되었습니다.

Systemd를 사용하면 MySQL 및 Nginx와 같은 대부분의 서버 애플리케이션이 재부팅 또는 종료 후 사용자가 아무것도 변경하지 않아도 자동으로 시작됩니다. 사용자 정의 앱의 경우 서비스를 자동으로 재시작하려면 자체 init 스크립트를 생성해야 합니다.

Systemd에 대한 자세한 내용은 다음을 참조하십시오: Systemctl로 Systemd 서비스 및 유닛을 관리하는 방법에 대한 튜토리얼.

Systemd 자동 시작 체크리스트

서비스가 Systemd로 자동으로 시작되도록 구성되었는지 확인하기 위한 몇 가지 참조 구성은 다음과 같습니다.

  • 서비스에는 다음 위치에 작동하는 Systemd init 스크립트가 있어야 합니다: /etc/systemd/system/multi-user.target.wants/serviceName.service. ServiceName은 구성 중인 서비스의 실제 이름입니다.
  • 서비스를 활성화하는 명령은 다음과 같습니다:
  • 이 명령은 /etc/systemd/system/multi-user.target.wants/ 디렉토리에 다음과 유사한 심볼릭 링크를 생성합니다:
  • 해당 심볼릭 링크가 제자리에 있으면 부팅 후 자동 재시작이 활성화됩니다.
  • 변경 사항을 활성화하려면 다음 명령을 사용하여 시스템 데몬을 다시 로드한 다음 서비스를 다시 로드하십시오:
  • 재부팅 후 구성이 서비스를 시작하는지 테스트하려면 시스템을 재부팅할 수 있습니다:
  • 시스템이 재부팅되면 다음 명령을 사용하여 프로세스 번호를 검색합니다:
  • 프로세스 번호를 기록하고 다음 명령을 사용하여 종료합니다:
  • 몇 초 동안 기다린 후 서비스를 다시 검색하여 백업되었는지 확인합니다.

실제 서비스를 사용한 실용적인 Systemd 구성

이 섹션에서는 Ubuntu 20.04 가상 머신에서 MySQL 서비스를 구성해 보겠습니다.

Step 1: Connect to your Virtual Private Server (Ubuntu 20.04 or CentOS 7 x64)

VPS에 로그인하거나 Cloudsigma 패널에서 생성한 후, Windows를 사용하는 경우 ssh 또는 putty를 사용하여 연결합니다. 이 튜토리얼 섹션에서는 Ubuntu 20.04 서버를 사용하고 있습니다. 동일한 명령이 CentOS 7에도 적용될 수 있습니다. sudo 권한이 있는 비루트(non-root) 사용자를 사용해야 합니다.

Step 2: Install MySQL (the service we are configuring)

먼저 시스템을 업데이트합니다:

그런 다음, 다음 명령을 사용하여 MySQL 서버를 설치할 수 있습니다:

다음으로, 다음 명령을 실행하여 MySQL 보안 설정을 시작합니다:

스크립트에서 VALIDATE PASSWORD 구성 요소를 설정할지, 아니면 아무 키나 눌러 구성 요소를 활성화하지 않고 진행할지 묻습니다. 다음 링크를 통해 다음에 대해 자세히 알아보십시오: MySQL 비밀번호 검증 구성 요소.

1을 눌러 활성화한 다음, 1을 눌러 중간 레벨을 선택합니다. 대문자, 소문자, 특수 문자, 숫자가 조합된 강력한 비밀번호를 입력하세요. 비밀번호를 확인하고 입력한 비밀번호를 root 비밀번호로 사용할 것인지 묻는 프롬프트에 동의합니다. 나머지 다른 프롬프트의 경우, 이전 섹션에서 했던 것처럼 y를 눌러 수락합니다. 마지막으로 MySQL의 권한을 플러시하여 변경 사항을 다시 로드합니다.

3단계: 재부팅 후 MySQL 자동 시작 구성

MySQL은 재부팅 후 시작되도록 구성되어 있으므로 변경할 필요가 없습니다. 하지만 MySQL 구성 파일을 사용하여 사용자 정의 파일을 구성하는 방법을 배울 수 있습니다.

먼저, 부팅 시 MySQL 서비스가 시작되도록 구성되었는지 확인합니다. 다음 명령을 입력합니다(CentOS에서는 MySQL 서비스 이름이 mysqld임에 유의하세요).

출력 결과는 다음과 같습니다:

CS screenshot

다음으로, 다음 명령을 입력하여 VPS를 재부팅합니다:

ssh를 사용하여 다시 연결하고 다음 명령을 입력하여 MySQL 서비스의 상태를 확인합니다:

아래 스크린샷과 유사한 출력을 얻어야 합니다:

System Crash 3

MySQL 서비스를 비활성화하려면 다음 명령을 입력합니다:

출력 결과는 Systemd에서 MySQL 서비스에 대한 심볼릭 링크가 제거되었음을 나타냅니다:

screenshot it 4

다음 명령을 입력하여 Systemd 초기화 시스템에서 서비스가 활성화되어 있는지 테스트할 수 있습니다:

출력 결과에 비활성화됨(disabled)으로 표시됩니다. 시스템을 재부팅하면 부팅 시 MySQL이 시작되지 않습니다:

disabled screenshot

다음 명령을 입력하여 서비스를 활성화합니다:

출력 결과는 Systemd 초기화에 생성된 MySQL 서비스에 대한 심볼릭 링크를 보여줍니다:

screenshot 5

재부팅하면 MySQL 서비스가 자동으로 시작됩니다.

4단계: 크래시 후 MySQL 자동 시작 구성

MySQL은 크래시 후 자동으로 재시작되도록 구성되어 있습니다. Systemd에서 이 구성이 어떻게 구현되는지 살펴보겠습니다. Systemd는 구성을 위해 유닛 파일을 사용합니다. 다음 명령을 입력하여 nano에서 mysql.service 구성 파일을 엽니다:

출력 결과는 다음과 같습니다:

System Crash 2

우리가 관심 있는 부분은 Restart 지시어입니다. 정의된 대로, 실패가 발생하면 MySQL이 재시작됩니다. Restart 지시어는 Upstart의 Respawn 지시어와 마찬가지로 Systemd에서 발생해야 할 작업을 정의합니다.

모든 서비스에 이 지시어가 있는 것은 아닙니다. 크래시 후 서비스가 재시작되도록 하려면 항상 Restart 지시어를 서비스 구성 유닛 파일의 [Service] 블록 아래에 추가할 수 있습니다. 만약 [Service] 헤더가 존재하지 않는다면 추가하세요. 이제 Ctrl + X를 눌러 편집기를 종료합니다.

크래시를 에뮬레이트하려면 다음 명령을 입력하여 MySQL 프로세스 ID를 찾습니다:

상태 확인 명령은 프로세스 ID를 표시하며, 이 예시에서는 3555입니다:

System Crash 1

다음 명령을 입력하여 프로세스를 종료합니다. 이 부분을 서버에서 얻은 프로세스 ID로 바꾸세요:

다음 명령을 입력하여 상태를 확인합니다:

출력 결과는 MySQL이 실행 중이지만 새로운 프로세스 ID를 가지고 있음을 보여줍니다. 이는 크래시 후 자동으로 재시작되었음을 의미합니다:

screenshot 8

결론

이 튜토리얼에서는 Linux 배포판의 세 가지 초기화 시스템인 System V, Upstart, Systemd를 소개해 드렸습니다. 재부팅 또는 시스템 크래시 후 지속적으로 실행되는 서비스가 자동으로 시작되도록 이러한 초기화 시스템 중 하나를 사용하여 구성하는 방법을 배웠습니다. 이는 서비스를 구성해야 할 때 시작점 역할을 할 것입니다. 이 시리즈의 1부는 주로 실습 위주의 실용적인 튜토리얼이었습니다. 그 두 번째 파트는 더 이론적이며 첫 번째 파트에서 진행한 내용에 대한 더 자세한 세부 정보를 다룹니다.. 두 번째 파트에서도 사용하게 되므로 아직 테스트 서버를 삭제하지 마세요.

즐거운 컴퓨팅 되세요!

 

author

Manpreet Singh

작성자 · CloudSigma

Preslav Dobrev는 CloudSigma의 크리에이티브 디자이너로서, 전통적이고 혁신적인 마케팅 채널을 활용하여 일관된 비즈니스 정체성을 구축하는 데 중점을 두고 있습니다. 그는 영향력 있는 브랜드 내러티브를 창출하기 위해 예술적 비전과 전략적 마케팅을 결합하는 데 능숙합니다.

댓글

아직 댓글이 없습니다. 첫 번째로 작성해 보세요.