더북(TheBook)

다음 내용을 추가한다. 퍼펫 패키지를 설치하는 과정은 어렵지 않게 이해할수 있다.

#!/bin/bash

echo '192.168.122.1 losttemple.linuxmaster.com losttemple' >>
/etc/hosts

cd /home/administrator
mkdir .ssh
cd .ssh
wget http://192.168.122.1/authorized_keys
chmod 600 authorized_keys

cd /home/administrator
wget http://apt.puppetlabs.com/puppetlabs-release-trusty.deb
sudo dpkg -i puppetlabs-release-trusty.deb
sudo apt-get update
sudo apt-get install -y puppet

echo "[agent]" >> /etc/puppet/puppet.conf
echo "server=losttemple.linuxmaster.com" >> /etc/puppet/puppet.conf
echo "runinterval=60" >> /etc/puppet/puppet.conf

/bin/sed -i 's/START\=no/START\=yes/' '/etc/default/puppet'

퍼펫 설정 파일을 수정하는 부분에 설명이 필요하다. 일반적으로 echo “문자열” >> [파일이름] 행은 문자열을 해당 파일에 추가하는 명령이다. ‘puppet.conf’에 퍼펫 마스터 서버의 주소 정보와 runinterval 정보를 기록하게 된다.

퍼펫 에이전트를 자동으로 시작하기 위해 sed를 사용한다./etc/default/puppet의 START=no라는 문자열을 검색하고 이를 START=yes로 수정한다.

스크립트를 저장했으면 웹 브라우저를 실행해서 스크립트 내용이 제대로 변경되었는지 확인해야 한다.

echo "[agent]" >> /etc/puppet/puppet.conf
echo "server=losttemple.linuxmaster.com" >> /etc/puppet/puppet.conf
echo "runinterval=60" >> /etc/puppet/puppet.conf

/bin/sed -i 's/START\=no/START\=yes/' '/etc/default/puppet'

마지막으로 DHCP 서버, TFTP 서버, 웹 서버가 실행 중인지 확인하고 아직 실행 상태가 아니라면 서비스를 재시작한다. 웹 브라우저로 미리 설정 파일(preseed.cfg), 시스템 초기화 셸 스크립트 파일(initialscript.sh), 공개키 파일(authorized_keys)을 열어볼 수 있는지 확인한다. 준비가 끝나면 가상 시스템을 시작해서 설치를 시작한다(라고는 하지만, 사용자가 설치 과정에서 손댈 일은 없어야 한다). 설치 과정에서 DHCP 서버 설정 파일의 next-serverfilename 행은 다시 주석 처리하여 설치가 끝나고 다시 설치를 반복하는 실수가 벌어지지 않게 해야 한다.

shinjaehun@losttemple:~$ virsh start vm03
shinjaehun@losttemple:~$ virsh start vm04

가상 시스템 자동 설치가 끝났으면 puppet 인증 과정으로 넘어간다. 호스트에서 퍼펫 인증서 목록을 살펴보면 새로 추가한 시스템에 대한 인증 요청을 확인할 수 있다. 시스템 관리자가 퍼펫 에이전트를 직접 실행하지 않아도 된다!

shinjaehun@losttemple:~$ sudo puppet cert --list --all
...
  "vm03.linuxmaster.com"      (SHA256)
74:6E:C4:A0:71:5C:00:46:DE:2A:61:6C:F1:3A:CB:BD:7A:D9:52:9C:AC:3C:47:F2:ED:71:25:B6:26:30:49:3B

새로 추가한 시스템에 대한 인증을 허가( puppet cert sign)한다. 해당 시스템에 대한 인증서를 확인( puppet cert –list)할 수 있다.

shinjaehun@losttemple:~$ sudo puppet cert sign vm03.linuxmaster.com
shinjaehun@losttemple:~$ sudo puppet cert --list --all
...
+ "vm03.linuxmaster.com"      (SHA256)
9F:E4:82:09:D5:6D:E4:85:1F:A9:64:9F:9D:B0:49:2B:FD:13:C0:6E:41:C3:F7:7A:B3:F5:4B:3F:6E:DE:58:47

퍼펫 에이전트가 정보를 갱신하는 시간을 잠시 기다리는 동안 새로 추가한 시스템의 이름을 호스트의 /etc/hosts에 등록한다.

127.0.0.    localhost
127.0.1.1   losttemple.linuxmaster.com   losttemple
192.168.122.11  vm01.linuxmaster.com          vm01
192.168.122.12  vm02.linuxmaster.com          vm02
192.168.122.13  vm03.linuxmaster.com          vm03
192.168.122.14  vm04.linuxmaster.com          vm04
...

새로 추가한 시스템에 SSH 접속을 시도해보자. 6장의 ‘공개키 인증 사용하기’에서 설정한대로 SSH 서버가 패스워드 대신 공개키 인증 방식으로 접속을 허용한다면 성공이다.

shinjaehun@losttemple:~$ ssh administrator@vm03.linuxmaster.com
...
shinjaehun@vm03:~$

이렇게 편리한 환경을 구축했는데도 불구하고 높으신 분들이 시스템 관리자의 휴가를 늘리는 데 망설이는 까닭은 아마도 시스템에 문제가 발생하는 비상 상황을 염려해서일 것이다. 쓰면 쓸수록 퍼펫의 막강함에 놀라고 있다. 그런데 만약 이 막강한 힘이 잘못 휘둘리게 되면 어떤 일이 벌어질까? 상상만해도 끔찍하다. 퍼펫으로 잘못된 매니페스트를 모든 노드에 적용해서 전체 시스템을 망칠 위험은 언제든 존재한다. 따라서 시스템 관리자는 puppet apply 명령으로 적용하기 직전까지 매니페스트를 신중하게 검토해야 한다.

사실 신중하게 검토하는 것만으로 부족하다. 시스템 관리자도 사람인 이상 실수는 피할 수 없기 마련 아닌가? 선배가 추천한 합리적인 대응 방법은 두 가지. 먼저 전체 시스템에 매니페스트를 적용하기 전에 테스트배드를 마련해서 철저한 검증을 거쳐야 한다. 이를테면 다음과 같이 작성한 ‘site.pp’ 파일에 위험해 보이는 danger_module 클래스를 전체 시스템에 적용하려고 한다면 모든 노드에 danger_module을 적용하기에 앞서 시스템 하나에만 적용해서 테스트해보고 결과를 확인하는 것이 좋다(여기에 나오는 danger_module 모듈은 구현하지 않은 가상의 모듈이기 때문에 실제 퍼펫에 반영하면 분명 오류가 발생할 것이다).

node 'vm01.linuxmaster.com' {
    include danger_module
}

node /^vm[0-9]+\.linuxmaster\.com$/ {
    include localmail
    include sshd
#   include danger_module
}

전체 시스템을 대상으로 해도 되겠다는 판단이 들 때만 다음과 같이 주석을 해제해서 puppet apply 명령으로 적용한다.

node ‘vm01.linuxmaster.com’ {
    include danger_module
}

node /^vm[0-9]+\.linuxmaster\.com$/ {
    include localmail
    include sshd
    include danger_module
}

그렇게 조심스럽게 했는데도 뭐가 잘못되었는지 결국 시스템마다 문제가 발생했다. 새로운 방식이 말을 듣지 않으니 다시 옛 방식으로 돌아가야 하는가? 야근에, 주말 근무에, 이 건물, 저 건물 돌아다니며 모든 시스템을 확인해서 문제를 해결해야 할까?

선배와 토론 끝에 내린 결론은 “아니올시다.” 문제가 생긴 시스템을 하나씩 손보느니 차라리 시스템을 재설치하고 필요한 설정을 자동으로 전개하는 편이 훨씬 빠르다. 자동 설치를 완료한 다음 문제가 발생하기 전 가장 최근에 수정한 매니페스트를 적용하고 다른 시스템에 백업해둔 내용을 복원하는 과정이 문제 해결의 열쇠다.

그럼 언제든 이전 버전으로 돌아갈 수 있도록 매니페스트를 수정할 때마다 버전을 달리해서 관리할 수 있고, 필요한 정보를 자동으로 백업해주는 네트워크를 이용한 표준화된 솔루션이 존재한다면 어떨까?

신간 소식 구독하기
뉴스레터에 가입하시고 이메일로 신간 소식을 받아 보세요.