난이도 : 중급 Martin C. Brown, Freelance Writer and Consultant
2004 년 9 월 14 일 한 가지 유형의 시스템을 위한 오픈 소스 애플리케이션을 구현할 때 고려해야 할 점이 많다. 하물며 호환되지 않는 머신 간 분산될 애플리케이션을 구현한다면? 약간의 훈련과 커스텀 스크립트를 사용하면 이 과정을 단순화 할 수 있다. 이 글에서는 애플리케이션들을(과도하게 커스터마이징 된 애플리케이션 포함) 구현하여 분산하는 구조를 만드는 방법과 가능한 한 쉽게, 수동 또는 자동으로, 많은 머신들 간 애플리케이션들을 분산시키는 간단한 방법을 설명한다.
나는 언제나 바이너리나 RPM 배포판을 사용하기 보다는 애플리케이션들을 시스템에 자가구현 했다. RPM을 믿지 못해서가 아니라 많은 시스템들에 커스터마이징 된 환경을 사용하기 때문이다. 디버깅을 바꾸거나 줄여야 할 때도 있을 수 있고, 특정 확장, 모듈 또는 다른 옵션이 필요할 때가 있다. 가끔은 완전히 다른 디렉토리 구조를 만들 때도 있다.
더욱 복잡한 건 Linux™, BSD, OS X, 다양한 사용 UNIX® 배포판을 포함한 오픈 소스 프로젝트를 사용하는 광범위한 플랫폼에서 작업한다는 것이다. 이들 중 어떤 것은 단 하나의 머신을 사용하지만 다른 것은 각종 유형의 10개, 20개 또는 50개 머신을 사용한다. 새로운 소프트웨어가 출시될 때 각 머신을 직접 업데이트 하는 것은 대단한 작업이다. 커스터마이징을 무시하면 실제 구현과 설치 과정은 일반적으로 쉽다. (Listing 1):
Listing 1. 구현과 설치 과정
$ bunzip2 -c latest-release.tar.bz|tar xf -
$ cd latest-release
$ ./configure
$ make
$ make install
|
특별한 교육 없이, 수 백 개의 머신에 직접 수행할 수 있었다. 최신 버전을 섭렵하고 테스트를 목적으로 특정 패키지의 베타와 알파 릴리스로 작업하면서 내가 마치 전문가가 된 듯한 생각을 했다.
몇 년 전, 다음의 간단한 규칙을 따르고 이 프로세스에 구조를 추가하여 프로세스를 뚜렷하게 단순화하기로 결정했다.:
- 각 OS용 디렉토리 만들기
- 각 OS 디렉토리 안에 소프트웨어 패키지를 위한 디렉토리 만들기
- 각 릴리스용 디렉토리 만들기
- 각 OS를 위해 한번만 구현하기
- 각 머신에 여러 번 전개하기
네트워크를 통해 공유할 수 있는 모든 소프트웨어에 맞는 구조를 구현하여 시작할 수 있다.
중앙 구현 디렉토리 만들기
첫 번째 단계는 NFS를 통해 공유할 디렉토리를 만드는 것이다. NFS는 디렉토리가 구현되는 동안 애플리케이션을 저장하는데 사용될 것이다. 일단 구현되면 소스 디렉토리부터 설정 파일까지, 그리고 시스템에 필요한 기타 컴포넌트들을 저장할 때 이 디렉토리를 사용할 수 있다. 핵심은 NFS이다. 시스템이 작동하게 하려면 네트워크 상의 모든 머신에서 중앙 구현 디렉토리에 액세스할 수 있어야 한다.
상위 레벨 구조 만들기
첫 번째 단계는 네트워크에서 지원하고자 하는 각 OS을 위한 상위 레벨 구조를 만드는 것이다. 각 디렉토리는 특정 OS, 아키텍쳐, (중대한 변경일 경우) 버전 넘버의 특성에 맞춰져야 한다. 이러한 디렉토리들은 자신의 네트워크상의 머신과 맞아야 한다. 내 네트워크상에 다양한 머신들이 있기 때문에 나의 상위 레벨 디렉토리 구조는 매우 확장성이 있다. (Listing 2):
Listing 2. 내 구현 환경의 OS 레벨 디렉토리
total 58
drwxrwxrwx 2 root other 512 Jul 25 12:01 aix/
drwxrwxrwx 2 root other 512 Jul 25 13:14 darwin-ppc/
drwxrwxrwx 2 root other 512 Jul 25 13:14 darwin-x86/
drwxrwxrwx 2 root other 512 Jul 25 12:02 freebsd-x86/
drwxrwxrwx 2 root other 512 Jul 25 13:14 freedbsd-sparc/
drwxrwxrwx 3 root other 1024 Mar 9 2003 incoming/
drwxrwxrwx 2 root other 512 Jul 25 12:02 linux-debian-x86/
drwxrwxrwx 2 root other 512 Jul 25 12:02 linux-fedora-1-x86/
drwxrwxrwx 2 root other 512 Jul 25 12:02 linux-fedora-2-x86/
drwxrwxrwx 11 root other 512 Apr 13 16:56 linux-redhat-9.0-x86/
drwxr-xr-x 3 root root 8192 Feb 6 2002 lost+found/
drwxrwxrwx 13 root other 512 Jun 15 15:02 macosx/
drwxrwxrwx 2 root other 512 Jul 25 12:02 netbsd-x86/
drwxrwxrwx 2 root other 512 Jul 25 12:02 openbsd/
lrwxrwxrwx 1 root other 12 Jul 25 13:13 solaris -> solaris8-x86/
drwxrwxrwx 2 root other 512 Jul 25 13:13 solaris8-sparc/
drwxrwxrwx 32 root other 1024 Jul 25 13:12 solaris8-x86/
drwxrwxrwx 2 root other 512 Jul 25 13:13 solaris9-sparc/
drwxrwxrwx 2 root other 512 Jul 25 13:13 solaris9-x86/
|
너무 많다고 걱정하지 말라. 이 OS 디렉토리들은 각 OS 개정판을 위한 관련 애플리케이션 디렉토리들을 저장하는데 사용될 것이다. 애플리케이션 구현의 커스터마이징은 각 디렉토리에서 개별적으로 다루어질 것이다.
/export/build로서 반출된 구현 디렉토리를 위해 개별 파일 시스템을 사용했다. 이 파일 시스템은 충분한 공간이 있다. 구현 디렉토리의 경우, 설정, OS, 애플리케이션의 구현 버전 등에 맞추기 위해서는 충분한 공간이 필요하다. 예를 들어, 컴파일된 Perl v5.9.0은 90 MB를 차지한다. Apache는 27 MB를 차지한다.
애플리케이션 구조 만들기
각 OS 디렉토리 내에 설치하고자 하는 애플리케이션을 위한 추가 디렉토리를 만들어야 한다. 각 OS 스팩에 맞춰야 하고 실제로 필요한 애플리케이션 디렉토리만 만들어야 한다. 예를 들어, Fedora 머신에는 Perl을 설치해야 하지만 다른 머신에는 안그래도 된다. Listing 3은 레이아웃이다:
Listing 3. OS 디렉토리 내의 애플리케이션 디렉토리들
drwxrwxrwx 4 mc staff 512 May 12 12:30 apache/
drwxrwxrwx 4 root other 512 Apr 16 2003 assassin/
drwxrwxrwx 3 501 other 512 Jun 11 10:11 bind/
drwxrwxrwx 3 root other 512 Jul 24 15:37 ccache/
drwxrwxrwx 5 root other 512 Jun 21 17:12 clamav/
drwxrwxrwx 6 root other 512 Jul 25 15:28 cpan/
drwxrwxrwx 4 root other 512 Jul 25 12:35 cpanplus/
drwxrwxrwx 4 root other 512 Sep 6 2003 cyrus/
drwxrwxrwx 3 root other 512 Jun 6 16:29 dhcp/
drwxrwxrwx 3 root other 512 Apr 11 15:42 distcc/
drwxrwxrwx 3 root other 512 May 11 10:39 eggdrop/
drwxrwxrwx 3 root other 512 Apr 9 05:50 ethereal/
drwxrwxrwx 5 root other 512 Jun 8 19:12 gawk/
drwxrwxrwx 2 root other 512 May 15 08:19 gcc/
drwxrwxrwx 4 root other 512 Jul 28 2003 ircd/
drwxrwxrwx 4 root other 512 Apr 9 05:44 libpcap/
drwxrwxrwx 5 root other 512 Jul 25 13:22 mysql/
drwxrwxrwx 3 root other 512 Mar 25 13:07 nmap/
drwxrwxrwx 3 root other 512 Nov 21 2003 ogsi-lite/
drwxrwxrwx 6 root other 512 Jul 25 13:33 perl/
drwxrwxrwx 3 root other 512 Aug 19 2003 php/
drwxrwxrwx 6 root other 512 Mar 5 15:09 ppro/
drwxrwxrwx 3 root other 512 May 15 09:02 python/
drwxrwxrwx 4 root other 512 Apr 22 06:06 razor/
drwxrwxrwx 3 root other 512 Aug 24 2003 razorsdk/
drwxrwxrwx 4 root other 512 Dec 4 2003 sendmail/
drwxrwxrwx 3 root other 512 May 23 09:37 ssh/
drwxrwxrwx 4 root other 512 May 11 10:25 tcl/
drwxrwxrwx 3 root other 512 Dec 22 2003 tcpwrappers/
drwxrwxrwx 6 root other 512 Apr 24 07:13 xmltv/
|
이들 각 디렉토리 내부에, 애플리케이션과 구현의 구성 및 설정 방법에 따라 두 가지 구조 중 하나를 만들어야 한다. 여러분이 만드는 각 디렉토리는 활성 애플리케이션을 저장하는데 사용될 것이다. 두 가지 방법으로 구성할 수 있는데 하나는 버전 별 디렉토리 이고 다른 하나는 직접적인 애플리케이션 디렉토리이다:
- 버전 별 디렉토리: 애플리케이션의 각 버전 별 하나의 추가적인 디렉토리 레벨. 각 버전 별 다른 많은 구현 설정을 만들 곳에 유용하다. 예를 들어, perl-5.9.0/debug-build 또는 perl-5.9.0/std-build>를 만들 수 있다.
- 직접적인 애플리케이션 디렉토리: 이 디렉토리의 하위 디렉토리는 원래의 tarball에서 만들어진 디렉토리이다. 기존 OS에 대해 모든 머신들에 같은 설정을 사용한다면 작동한다.
애플리케이션의 구현과 전개 방법에 따라, 둘 중 하나 또는 두 가지 모두 사용할 수 있다. 다만 각 경우의 구조를 반드시 이해해야 한다. 전개를 시작하면서 디렉토리 레이아웃을 알아야 하기 때문이다. 예를 들어, Apache의 경우 디버깅을 위한 다른 설정을 저장하기 위해 각 버전 별 세 개 또는 네 개의 디렉토리를 가지고 있었고 개발, 스테이징, 제품 버전 별 설치 디렉토리도 갖추고 있었다. 레이아웃은 다음과 같다. (Listing 4):
Listing 4. 다른 활성 설정을 지원하는 Apache 레이아웃
./httpd-2.0.46
./httpd-2.0.46/staging-build
./httpd-2.0.46/devel-build
./httpd-2.0.46/prod-build
./httpd-2.0.49
./httpd-2.0.49/staging-build
./httpd-2.0.49/devel-build
|
devel-build 디렉토리에는 원래 tarball의 압축을 풀 때 만들어지는 것과 같은 디렉토리를 포함하고 있다. 비교해 보면, Listing 5는 표준 구현의 모든 Perl 버전을 갖고 있는 개발 머신 상의 Perl 레이아웃을 보여주고 있다. 보다 간단해진 구조이다.
Listing 5. 직접적인 버전 애플리케이션 디렉토리
./perl/
./perl/perl-5.8.2
./perl/perl-5.8.3
./perl/perl-5.8.5
./perl/perl-5.9.0
|
디렉토리를 알맞은 자리에 배치하면 각 OS와 설정에 맞춰 애플리케이션 구현을 시작할 수 있다. 애플리케이션/설정이 일단 구현되면 OS들에 이들 각각을 전개하는 것은 비교적 쉽고 단순하다.
개별 구현 설정하기
다른 애플리케이션들과 다른 설정들을 지원하는 문제들 중 하나는 설정이 어떤 애플리케이션과 상황을 위한 것인지 잊기 쉽다는 점이다. 예를 들어, Apache를 구현할 때, 대안 개발 디렉토리와 지원하고자 하는 모듈과 컴포넌트 리스트를 지정한다. 처음에는 잘되었다. 하지만 세 달 후에 다시 그 프로세스로 돌아가서 특정한 설정 부분을 기억하는 것은 거의 악몽이었다. 최신 버전으로 새로운 구현을 하기로 결정했다.
이것을 해결하기 위해, 나는 설정에 일반적으로 사용하는 라인을 저장하고 있는 한 줄의 스크립트와 함께 만든 디렉토리 구조를 사용한다. 예를 들어, 내 Apache 스테이징 서버에 다음과 같은 스크립트를 사용한다. (Listing 6):
Listing 6. Apache 스테이징 서버용 스크립트
./configure --enable-so --enable-mods-shared=most --prefix=/export/httpd2/staging
|
이 라인을 스크립트에 배치하고, 적절한 이름을 정하고, 이것을 애플리케이션용 디렉토리 안에 둔다. 다시, 버전에 근거하여(설정 시스템이 변경된 애플리케이션의 경우 매우 중요함. 예를 들어, Apache 1.3.x 에서 Apache 2.x으로 변경된 경우) 또는 일반적인 애플리케이션 디렉토리에 근거하여 이를 수행한다. 예를 들어, 이 파일 이름을 apache/staging-config라고 지어 어떤 버전에서라도 사용할 수 있고 Apache 스테이징 서버를 설정하는 구현 디렉토리에서 사용할 수 있음을 설명한다.
기존 OS, 애플리케이션, 설정을 위한 설정과 구현을 실제로 수행하기 위해 다음과 같이 한다:
Listing 7. 설정과 구현
$ cd redhat-linux-9.0/apache/httpd-2.0.46/staging-build
$ ../../staging-config
$ make
|
설치 자동화
컴파일 되고 설치 준비가 된 애플리케이션 버전이 있다면 네트워크 상의 다양한 머신에 이 애플리케이션을 배포 및 설치하는 것은 쉽다. 각 머신에 개별적으로 설정/구현 프로세스를 실행할 필요가 없다. 머신이 같다면 말이다. 실행해야 할 것은 make install뿐이다.
각 머신에 설치하고자 하는 애플리케이션 리스트를 포함하고 있는 각 OS 시스템 디렉토리에 파일을 만들어서 시스템 레벨 별로 이를 자동화한다. 어떤 경우, 다양한 설치 유형을 관리하기 위해 수 많은 다른 파일들을 만들어야 한다. 다음 파일은 애플리케이션 구현 디렉토리 리스트이다. (Listing 8):
Listing 8. OS 애플리케이션 선택
perl/perl-5.9.0
python/Python-2.3
ccache/ccache-2.3
distcc/distcc-2.13
|
이 파일들은 Listing 9의 스크립트로 처리된다. 보이는 그대로이다. 나열된 각 디렉토리를 실행하고 make install을 실행한다.
Listing 9. 자동 설치 스크립트
#!/bin/sh
os=$1
src=$2
currentdir=`pwd`
basedir=/export/build
if [ -z "$os" ]
then
echo "No operating system definition specified"
exit 1
fi
if [ -z "$src" ]
then
echo "No application definition specified"
exit 1
fi
cd $basedir
if [ -r "$basedir/$os/$src" ]
then
for dir in `cat $os/$src`
do
cd $basedir/$os/$dir
make install
done
else
echo "No application definition specified"
exit 1
fi
|
머신에 특정 애플리케이션을 설치하려면 이 스크립트를 실행하고 OS 폴더와 애플리케이션 선택 파일들을 제공한다. (Listing 10):
Listing 10. 머신에 특정 애플리케이션 세트 설치하기
$ appinstall.sh solaris8-x86 standard
|
이 스크립트와 신중하게 만들어진 디렉토리 구조가 나머지를 수행한다.
요약
애플리케이션의 설치와 배포에 이 방법을 사용하려면 설정에 시간도 걸리고 익숙해져야 한다. 하지만 일단 실행하면 거의 모든 것이 자동이다. 사실, 어떤 애플리케이션을 설치할 수 있는지에 대한 정보와 함께 파일을 배치하기 때문에, 크론 잡 으로서 스크립트를 실행하여 네트워크 상에서 머신을 자동으로 업데이트 할 때 같은 시스템을 사용할 수 있다. 나는 일주일에 한 번 실행하지만 여러분은 한 달에 한 번만 실행해도 된다. 99%의 인스톨러의 경우 현재 버전과 설치되는 버전이 같다면 문제 없다. 모든 인스톨러가 하는 일은 이전에 사용되던 파일의 동일한 카피를 겹쳐 쓰는 것이다.
무엇보다도, 자동 메소드를 사용한다면 모든 머신을 업데이트하는 것은 애플리케이션 선택 파일을 최신 버전의 구현 디렉토리와 함께 업데이트 하는 경우이다. 최신 설치는 머신이 알아서 정해진 업데이트를 하는 동안 설치한다. 팬시 스크립트나 rsync, ssh, rsh가 필요 없다. 필요에 맞게 애플리케이션을 설정 및 커스터마이징 하고 다른 머신들이 다양한 애플리케이션 세트를 사용할 수 있도록 한다.
시작할 때 말했지만, 여러분이 해야 할 일은 약간의 훈련일 것이다. 디스크 공간이 많으면 더 좋다.
참고자료
필자소개  | | Martin C. Brown은 크로스 플랫폼 통합 분야의 IT Director이다. HP와 Oracle의 사이트를 만들었으며 Foodware.net의 기술 디렉터이다. 현재 프리랜스 작가와 컨설턴트, MC로 활동하고있다. |
기사에 대한 평가
| 
