이 시리즈의 Part 1에서는 SmallPayroll.ca 애플리케이션을 Amazon 클라우드로 마이그레이션했고 Part 2에서는 이 애플리케이션을 더 강력하게 만들었다. Part 3에서 살펴봤듯이 애플리케이션은 로드에 따라 자체적으로 서버를 추가 및 제거할 수 있다. 현재는 특정 시점에 활성 서버의 수 및 IP 주소를 예측할 수 없어 이러한 서버에 연결하는 것이 힘들 수 있다. 따라서 클라우드 환경은 기존의 데이터 센터와 다르다.

클라우드의 동적 특성 또한 애플리케이션 전개를 어렵게 만든다. 사용자의 서버 목록은 전개 사이에서 다른데 그렇다면 애플리케이션을 어떻게 업데이트하는가? 이 문제에 대해 서버에서 결함을 어떻게 모니터하는가?

일반적인 데이터 센터가 아님

"일반적인" 데이터 센터에서는 컴퓨터에 원하는 모든 이름을 지정하고 사용자에게 적합한 IP 주소를 해당 컴퓨터에 제공하고 원하는 경우 서버로 돌아가 서버가 여전히 해당 위치에 있는지 확인할 수 있다. 서버를 추적하기 위해 스프레드시트를 보관할 수도 있고 또는 소프트웨어를 사용할 수도 있고, 사용자의 머리나 텍스트 파일에 정보를 보관할 수도 있다. 구성의 일관성을 유지하기 위해 필요한 구성 관리를 가지고 있는가?

다수 함수에 대한 제어를 양도하기 때문에 클라우드 환경은 기존 데이터 센터와 상당히 다르다. IP 주소를 예측할 수도 없고 두 서버가 동일한 서브넷에 있을 것이라고 확신할 수도 없다. 자원의 자동 확장으로 진행하는 경우 새로운 노드가 실행되면 수동 구성에서 힘들게 수행한 작업이 모두 손실된다. 사용자에게 예측 가능한 이름을 가진 웹 서버가 20개 있다는 사실에 기반하는 스크립트는 클라우드에서 작동하지 않는다.

다행히도 약간의 훈련으로 이러한 문제점을 해결하고 실제 데이터 센터의 가동 시간을 개선할 수 있다.

IP 주소 지정 및 이름 지정하기

사용자들은 서버에 지정할 이름과 적절한 IP 주소 지정 스키마를 도출하는 방법을 걱정하면서 상당한 시간을 보내기 쉽다. Amazon EC2(Elastic Compute Cloud) 인스턴스는 무작위 IP 주소와 이 주소를 기반으로 하는 이름과 함께 제공된다. 확실하게 서버의 이름을 바꿀 수 있지만 이를 수행하려면 나머지 환경에 대한 지식이 필요하다. 예를 들어, 서버 이름을 webprd42로 지정하려면 실행한 마지막 서버가 webprd41이었음을 알고 있어야 한다.

더 나은 해결책은 이름 또는 IP 주소에 의존하지 않고 이러한 이름이 중요하지 않은 방식으로 소프트웨어를 빌드하는 것이다.

구성 관리

실제 환경에서는 일반적으로 서버에 대한 수동 구성 변경사항 작성을 제대로 수행할 수 있다. 서버가 자동으로 실행되는 경우에는 수동 변경사항이 적용되지 않는다. 각각의 변경 이후 AMI(Amazon Machine Image)를 다시 번들화할 수 있지만 이를 수행해도 이미 실행 중인 다른 서버에 대한 업데이트를 적용하는 문제가 해결되지 않는다. 다행히도 Puppet 및 Cfengine과 같은 탁월한 소프트웨어 패키지가 이러한 변경사항을 자동화할 수 있다(참고자료 참조).

애플리케이션 변경사항을 전개하는 것은 별도로 살펴볼 만한 구성 관리의 또다른 측면이다. 일반 구성 관리 도구가 이 작업을 수행할 수 있지만 이 도구를 사용하여 애플리케이션 전개와 마이그레이션 및 구성 롤백 관리의 특정 단계를 재현하는 것은 어렵다. Rails 커뮤니티는 애플리케이션 전개 태스크를 처리하는 다른 도구(예: Capistrano)를 발표했다(참고자료 참조).

구성 관리를 두 가지 별도의 문제로 간주하는 것이 도움이 된다. 첫 번째는 소프트웨어 패키지의 설치에서부터 다양한 디먼의 구성에 이르기까지 서버를 관리하는 방법이다. 두 번째는 제어된 방식으로 소프트웨어의 새로운 버전을 전개하는 방법이다.

시스템 모니터링

서버가 수행하고 있는 작업에 대해 알고 있는 것이 중요하다. CPU, 디스크 자원, 메모리 및 네트워크는 모니터해야 하는 중요한 컴포넌트이다. 애플리케이션 자체를 포함하여 시스템에서 실행 중인 디먼에는 주시해야 할 기타 메트릭이 있을 수 있다. 예를 들어, 애플리케이션 응답 시간과 웹 서버 및 애플리케이션 서버에 대한 연결 수를 감시하면 문제가 발생하기 전에 경고 통보를 받을 수 있다.

서버를 모니터하고 결과를 그래프로 표시하는 데 사용할 수 있는 도구는 많이 있다. 문제는 새로운 서버가 온라인 상태가 될 때 이러한 서버를 어떻게 모니터하고 서버가 오프라인 상태가 될 때 모니터링을 어떻게 중지하는지에 있다.

클라우드 아키텍처에 적용된 패턴

Amazon EC2와 같은 동적 환경을 관리하는 방법을 살펴보면 세 가지 일반적인 패턴이 드러난다.

• 클라이언트 폴. 서버가 중앙 서버에서 자원을 쿼리한다. 이 패턴을 사용하는 모든 서버의 주소를 알 필요는 없지만 서버는 자체 스케줄에 따라 작동하므로 사용자는 클라이언트의 폴링 타이밍을 제어할 수 없다.
• 서버 푸시. 이 패턴은 먼저 클라우드 제공자의 API(Application Programming Interface)를 쿼리하여 현재 서버 목록을 찾은 후 중앙 서버가 각 서버에 접속하여 작업을 수행한다. 이 패턴은 속도가 느리고 이를 수행하려면 관리 도구가 환경의 동적 특성에 대해 이해해야 하지만 이 패턴은 업데이트를 동기화할 수 있는 장점이 있다.
• 클라이언트 등록. 각 서버가 온라인 상태가 되면 각 서버는 자신을 중앙 서버에 등록한다. 서버는 종료되기 전에 자체적으로 등록을 취소한다. 이 방법은 더 복잡하지만 클라우드 환경에서 클라우드 비인식 도구를 사용할 수 있다.

위로

구성 관리를 위한 클라이언트 폴링

이 패턴은 구현하기 쉽다. 클라이언트는 단순히 미리 결정된 스케줄에 따라 명령어에 대해 잘 알려진 서버를 폴링하면 된다. 클라이언트가 수행할 항목이 서버에 없는 경우 서버는 클라이언트에 이 내용을 알린다. 단점은 클라이언트가 서버를 폴링하는 경우에만 명령어가 실행될 수 있다는 것이다. 변경이 긴박한 경우 다음 폴링을 기다려야 한다.

폴링을 사용하는 탁월한 방법은 서버의 구성 관리이다. Reductive Labs의 Puppet 패키지는 유명한 구성 관리 도구이다. Puppetmaster라는 프로세스가 중앙 서버에서 실행된다. 클라이언트는 Puppet 디먼을 실행하고 이 디먼은 적절한 구성 매니페스트를 위해 Puppetmaster를 폴링한다. 이러한 구성 매니페스트는 "NTP 디먼이 설치되어 실행되도록 보장"하는 것과 같은 특정 컴포넌트의 원하는 종료 상태를 지정한다. Puppet은 이러한 매니페스트를 읽고 문제점을 정정한다.

배포판에 Puppet이 함께 제공되거나 gem install puppet facter를 사용하여 Puppet을 신속하게 설치할 수 있다. 하지만 Puppet은 문제를 복잡하게 하는 보안 시스템을 구현한다. 클라이언트가 Puppetmaster와 대화하려면 서명된 키가 있어야 한다. 연결되는 클라이언트를 위해 자동으로 키에 서명하도록 Puppetmaster에 지시할 수 있지만 이를 수행하면 임의의 사용자가 구성 파일을 다운로드할 수 있다. 대안은 Puppetmaster를 무시하고 메니페스트를 직접 분배한 후 Puppet 도구를 로컬로 실행하는 것이다.

클라이언트가 Puppet 매니페스트를 실행하게 하는 이벤트의 시퀀스는 다음과 같다.

1. 서버로부터 업데이트된 매니페스트 사본 및 연관된 파일을 다운로드한다.
2. 매니페스트에 대해 Puppet을 실행한다.

1단계를 위해 선택하는 도구는 변경된 파일만 다운로드하는 rsync이다. 2단계를 위해서는 puppet 명령(Puppet 설치의 일부)이 매니페스트를 실행한다. 이 접근 방식에는 두 가지 주의사항이 있다.

• 서버는 클라이언트의 SSH(Secure Shell) 공용 키를 승인해야 한다. 이 키는 AMI에서 분배될 수 있다.
• 매니페스트에서 지정하는 모든 구성 파일은 매니페스트와 함께 복사해야 한다. 기본 제공 Puppet 파일 서버에는 인증서도 필요하므로 이 파일 전송 메소드는 사용할 수 없다.

샘플 매니페스트를 사용하면 클라이언트가 올바른 네트워크 시간 프로토콜 구성을 가진다. 여기에는 소프트웨어가 설치되고 구성 파일이 수정되고 디먼이 실행되도록 하는 것이 포함된다. 목록 1에서는 최상위 레벨 매니페스트를 보여 준다.

	
import "classes/*"

node default {
  include ntpclient
}

목록 1에서는 먼저 classes 디렉토리에 있는 모든 파일을 가져오며 각 파일에는 단일 컴포넌트에 대한 정보가 들어 있다. 모든 노드에는 목록 2에 정의된 ntpclient 클래스가 포함된다.

	
class ntpclient {
  package {
    ntp:
      ensure => installed
  }
  service {
    ntpd:
      ensure => true,
      enable => true,
      subscribe => [ Package [ntp], File["ntp.conf"] ],
  }
  file {
    "ntp.conf":
      mode => 644,
      owner => root,
      group => root,
      path => "/etc/ntp.conf",
      source => "/var/puppetstage/files/etc/ntp.conf",
      before => Service["ntpd"]
  }
}

Puppet 언어에 대한 자세한 검토는 이 기사의 범위를 벗어나지만 상위 레벨에서 목록 2는 ntp라는 패키지, ntpd라는 서비스 및 /etc에 있는 ntp.conf라는 파일로 구성되는 ntpclient라는 클래스를 정의한다. ntp 패키지가 설치되지 않은 경우 Puppet에서는 yum 또는 apt-get과 같은 적절한 도구를 사용하여 이를 설치한다. 서비스가 실행되고 있지 않으며 시작 스크립트에 있는 경우 서비스는 고정된다. ntp.conf 파일이 /var/puppetstage/files/etc에 있는 사본과 다른 경우에는 해당 파일이 업데이트된다. before 및 subscribe 행은 구성이 변경되는 경우 디먼이 다시 시작되도록 한다.

서버는 매니페스트 및 파일을 /var/puppetdist에 저장하고 클라이언트는 해당 트리를 /var/puppetstage에 복사한다. 디렉토리 트리의 아웃라인이 목록 3에 표시되어 있다.

	
/var/puppetdist/
|-- files
|   `-- etc
|       `-- ntp.conf
`-- manifests
    |-- classes
    |   `-- ntp.conf
    `-- site.pp

마지막으로 목록 4에서는 파일을 동기화하고 클라이언트에서 매니페스트를 실행한다.

	
#!/bin/bash
/usr/bin/rsync -avz puppetserver:/var/puppetdist/ /var/puppetstage/ --delete
/usr/bin/puppet /var/puppetstage/manifests/site.pp

이 코드는 cron으로부터 주기적으로 실행되는 경우 매니페스트에서 변경사항을 선택하여 클라우드 서버에 적용한다. 어떻게든 서버의 구성이 변경되면 Puppet에서는 서버를 다시 준수 상태로 돌리는 단계를 수행한다.

위로

애플리케이션 업데이트 적용하기

서버의 구성 업데이트에는 서버 간 동기화가 필요한 경우가 거의 없다. 패키지를 업그레이드해야 하는 경우에는 일반적으로 30분 창이면 충분하다. 하지만 사용자는 애플리케이션 업데이트를 위해 변경사항을 한 번에 롤아웃하고 타이밍을 제어하길 원한다. 이를 위해 적합한 유명한 도구가 Capistrano이다. 사용자는 Capistrano의 도메인 특정 언어를 사용하는 스크립트를 작성하고 다양한 태스크를 실행한다. 목록 5에서는 애플리케이션을 알려진 서버 세트에 푸시하는 최소 Capistrano 스크립트를 보여 준다.

	
set :application, "payroll"
set :repository,  "https://svn.smallpayroll.ca/svn/app/trunk/"
set :user, 'payroll'
set :home, '/home/payroll'
set :deploy_to, "#{home}"
set :rails_env, "production"

role :db, "174.129.174.213", :primary => true
role :web, "174.129.174.213", "184.73.3.169"

목록 5에 있는 대부분의 행은 Capistrano의 기본 동작을 변경하는 변수를 설정하며 이는 SSH를 사용하여 모든 서버에 액세스하고 소스 코드 관리 도구를 사용하여 애플리케이션의 사본을 체크아웃하기 위한 것이다. 마지막 두 행은 사용 중인 서버(특히 데이터베이스 및 웹 서버)를 정의한다. 이러한 역할은 Capistrano에 알려져 있으며 자체 목적을 위해 확장될 수 있다.

목록 5의 문제점은 서버를 사전정의해야 한다는 것이다. 하지만 Capistrano가 런타임 시 AWS(Amazon Web Services) API를 사용하여 서버 목록을 판별하게 할 수 있다. 먼저 다음을 실행한다.

gem install amazon-ec2

이를 실행하여 API를 구현하는 라이브러리를 설치한다. 그런 다음 목록 6과 같이 Capistrano 레서피(deploy.rb)를 수정한다.

	
# Put this at the beginning of your deploy.rb
require 'AWS'

# Change your role :web definition to this
role(:web) { my_instances }

# This goes at the bottom of the recipe
def my_instances
  @ec2 = AWS::EC2::Base.new(  :access_key_id => ENV['AWS_ACCESS_KEY_ID'],
                              :secret_access_key => ENV['AWS_SECRET_ACCESS_KEY'])
  servers = @ec2.describe_instances.reservationSet.item.collect do |itemgroup|
    itemgroup.instancesSet.item.collect {|item| item.ipAddress}
  end
  servers.flatten
end

목록 6에서는 웹 역할을 정적 정의에서 my_instances 함수로부터 리턴된 동적 서버 목록으로 변경한다. 이 함수는 Amazon EC2 API DescribeInstances 호출을 사용하여 서버 목록을 리턴한다. API는 동일한 예약 ID 아래에서 함께 실행된 인스턴스를 그룹화하는 형식으로 데이터를 리턴한다. 외부 collect 루프는 이러한 예약 그룹을 반복하고 내부 collect 루프는 각 제한 그룹 내에 포함된 서버를 반복한다. 결과는 배열의 배열이 발생하며 이 배열은 서버 IP 주소의 단일 차원 배열로 변환되어 다시 호출자에게 전달된다.

Capistrano가 동적 서버 목록에서 작동하는 방법을 제공한 것은 다행이다. 이러한 연결 고리가 제공되지 않았다면 또다른 접근 방식을 이용해야 했을 것이다.

위로

관리 서버에 등록하기

동적 서버 목록의 사용을 쉽게 허용하지 않는 애플리케이션의 경우에는 클라우드 서버 자체가 다른 애플리케이션에 등록되도록 하여 문제를 해결할 수 있다. 이 프로세스는 일반적으로 다음 두 가지 양식 중 하나를 사용한다.

• 클라우드 서버는 또다른 서버에 연결하여 스크립트를 실행하며 이를 통해 관리 애플리케이션이 직접 업데이트된다.
• 클라우드 서버는 다른 스크립트가 구성 파일을 다시 빌드할 공통 위치(예: Amazon S3(Simple Storage Service))에 일부 메타 데이터가 포함된 파일을 놓는다.

직접 업데이트

Cacti는 스크립트 또는 SNMP(Simple Network Management Protocol)를 통해 다양한 메트릭을 그래프로 표시하고 이러한 그래프를 대시보드 또는 메타 그래프로 결합할 수 있는 유명한 성능 관리 도구이다(참고자료 참조). Cacti에 대한 제한은 명령행 스크립트를 통하거나 Cacti 웹 인터페이스 내에서 관리에 적합하게 서버를 구성해야 한다는 것이다. 이 예제에서 클라우드 서버는 Cacti 서버에 다시 연결하여 자신을 구성한다.

Cacti는 템플리트의 시스템을 기반으로 하여 그래프에 대한 대량 변경을 훨씬 더 쉽게 만든다. 하지만 모든 명령행 도구는 템플리트 ID에 대해 작동하므로 먼저 사용할 ID를 파악해야 한다. 목록 7에서는 일부 데이터 요소를 미리 채우는 호스트 템플리트를 찾는 방법을 보여 준다.

	
$ php -q /var/lib/cacti/cli/add_device.php --list-host-templates
Valid Host Templates: (id, name)
0       None
1       Generic SNMP-enabled Host
3       ucd/net SNMP Host
4       Karlnet Wireless Bridge
5       Cisco Router
6       Netware 4/5 Server
7       Windows 2000/XP Host
8       Local Linux Machine

템플리트 번호 3은 대부분의 Linux® 배포판과 함께 사용할 수 있는 Net-SNMP 디먼을 실행 중인 호스트를 위한 것이다. 더 일반적인 버전 대신 이 특정 디먼을 사용하면 일부 Linux 특정 카운터를 쉽게 모니터할 수 있다.

사용자가 호스트 템플리트 3을 사용한다는 것을 알고 있으므로 사용 가능한 그래프 목록이 목록 8에 표시된다.

	
$ php -q /var/lib/cacti/cli/add_graphs.php --list-graph-templates --host-template-id=3
Known Graph Templates:(id, name)
4       ucd/net - CPU Usage
11      ucd/net - Load Average
13      ucd/net - Memory Usage

목록 8에 있는 세 가지 그래프는 기본 Cacti 배포판과 함께 제공되는 그래프이다. 더 많은 수를 추가하거나 --host-template-id 옵션을 사용하지 않거나 인터넷의 소스에서 그래프를 가져올 수 있다.

목록 9에서는 새로운 디바이스를 추가한 후 CPU 그래프를 추가하는 방법을 보여 준다.

	
$ php -q /var/lib/cacti/cli/add_device.php --description="EC2-1.2.3.4" \
  --ip=1.2.3.4 --template=3
Adding EC2-1.2.3.4 (1.2.3.4) as "ucd/net SNMP Host" using SNMP v1 with community "public"
Success - new device-id: (5)
php -q /var/lib/cacti/cli/add_graphs.php --host-id=5 --graph-type=cg \
  --graph-template-id=4
Graph Added - graph-id: (6) - data-source-ids: (11, 12, 13)

목록 9에서는 먼저 IP 주소가 1.2.3.4인 호스트를 추가한다. 리턴되는 디바이스 ID는 5이며 이는 CPU 사용량에 대한 그래프를 추가한다(그래프 유형 cg 및 템플리트 4). 결과는 그래프의 ID와 현재 모니터 중인 다양한 데이터 소스의 ID이다.

이제 매우 편리하게 목록 9에 있는 프로시저를 스크립트화할 수 있다. 목록 10에서는 이러한 스크립트를 보여 준다.

	
#!/bin/bash

IP=$1

# Add a new device and parse the output to only return the id
DEVICEID=`php -q /var/lib/cacti/cli/add_device.php --description="EC2-$IP" \
  --ip=$IP --template=3 | grep device-id | sed 's/[^0-9]//g'`
# CPU graph
php -q /var/lib/cacti/cli/add_graphs.php --host-id=$DEVICEID --graph-type=cg \
    --graph-template-id=4

스크립트에 대한 첫 번째 매개변수는 $IP라는 변수에 저장된다. add_device.php 스크립트는 이 IP 주소를 사용하여 실행되며 grep 명령을 사용하여 ID가 포함된 행만 출력되도록 필터링된다. 이 출력은 숫자만 출력하는 sed 스크립트에 피드된다. 이 값은 $DEVICEID라는 변수에 저장된다.

디바이스 ID가 저장되면 그래프를 추가하는 것이 add_graphs.php 스크립트를 호출하는 것만큼 단순해진다. CPU 그래프가 가장 단순한 경우이며 일부 다른 유형의 그래프에는 더 많은 매개변수가 필요하다.

add_to_cacti.sh 스크립트가 Cacti 서버에 있으면 클라우드 서버가 이를 실행하기만 하면 된다. 목록 11에서는 스크립트 호출 방법을 보여 준다.

	
#!/bin/bash

MYIP=`/usr/bin/curl -s http://169.254.169.254/2007-01-19/meta-data/public-ipv4`
ssh cacti@cacti.example.com "/usr/local/bin/add_to_cacti.sh $MYIP"

목록 11에서는 먼저 Amazon EC2 메타 데이터 서버를 호출하여 공용 IP 주소를 리턴한 후 Cacti 서버에서 원격으로 명령을 실행한다.

위로

결론

이 일련의 기사에서는 단일 서버에서 AWS 클라우드로의 애플리케이션 마이그레이션에 대해 살펴봤다. 새로운 서버의 실행에서 로드 밸런서에 이르기까지 Amazon EC2 오퍼링을 활용하기 위한 개선이 점점 많이 진행되었다. 이 마지막 기사에서는 동적 클라우드 환경 관리에 대해 살펴보고 사용할 수 있는 일부 패턴을 제공했다.

클라우드 자원을 사용하기 위한 초기 비용이 많지 않다는 것을 고려하면 실제로 마이그레이션을 수행해 봐야 한다. 클라우드를 사용하는 프로덕션에서 애플리케이션을 실행하지 않도록 결정하는 경우에도 클라우드에서 수행될 수 있는 사항에 대해 많이 알게 되고 시스템 관리 스킬을 개선할 수도 있을 것이다.

참고자료

교육

• LPI exam 301 prep, Topic 306: Capacity planning(developerWorks, 2008년 4월)에서는 시스템을 모니터하고 결과를 측정하는 방법에 대해 자세히 설명한다.
  
  
• Scott Patten이 저술한 The S3 Cookbook은 Amazon S3를 Ruby와 함께 사용하는 방법에 대해 설명하는 Leanpub에서 제공하는 PDF이다. 이 책에서는 약 60가지 문제점에 대해 살펴보고 코드를 사용하여 이러한 문제점을 해결하는 방법에 대해 설명한다.
  
  
• developerWorks의 Cloud Computing 영역에서 클라우드용 애플리케이션을 개발하고 배치하는 데 필요한 자원을 얻을 수 있으며 최신 클라우드 개발 정보도 확인할 수 있다.
  
  
• Linux에서는 수백 개의 기술자료 목록과 함께, Linux 개발자와 관리자를 위한 다양한 다운로드, 토론 포럼 및 다른 참고자료를 찾을 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트를 통해 다양한 IBM 제품 및 IT 산업 주제에 대한 최신 정보를 얻을 수 있다.
  
  
• 무료 developerWorks Live! briefing을 통해 최신 IBM 제품 및 도구에 대한 정보뿐만 아니라 IT 업계의 최신 경향까지도 빠르게 확인할 수 있다.
  
  
• developerWorks on-demand demos에서는 입문자를 위한 제품 설치 및 설정부터 숙련된 개발자를 위한 고급 기능까지 망라된 다양한 데모를 제공한다.
  
  
• Twitter의 developerWorks를 팔로우(follow)하거나 developerWorks에 대한 Linux 트윗(tweet)의 피드를 구독하자.
  
  

제품 및 기술 얻기

• 이제 Amazon S3 내에 여러 개의 AMI가 있으므로 오래된 AMI를 정리하고 싶을 것이다. Amazon S3 File Manager는 여러 독립형 애플리케이션 또는 브라우저 플러그인의 기능과 견줄 만한 웹 기반 파일 관리자이다. AMI를 삭제한 경우에는 ec2-deregister를 실행하는 것도 잊지 말기 바란다.
  
  
• Capistrano는 Rake와 비슷하게 작동하는 유명한 전개 패키지이다.
  
  
• Cfengine은 UNIX®를 위한 가장 유명한 구성 관리 도구이다. Cfengine은 경량이며 많은 수의 시스템에서 작동할 수 있다.
  
  
• Cacti는 RRDTool 주위에 빌드된 네트워크 그래프 도구이다. 상상할 수 있는 거의 모든 항목을 그래프로 표시할 수 있다. 이 도구가 데이터 센터에 있는 경우에는 다른 사용자가 이미 플러그인을 작성했을 가능성이 높다.
  
  
• Puppet은 Ruby로 작성된 구성 관리 도구이며 Cfengine의 일부 제한사항을 극복하기 위해 빌드되었다. 적절한 시작 지점을 찾는 경우에는 저자가 재미있게 읽은 James Turnbull이 저술한 Pulling Strings with Puppet(Apress, 2008)을 추천한다.
  
  
• 자신에게 가장한 적합한 방법으로 IBM 제품을 평가해 보자. 평가판 제품을 다운로드하거나, 온라인으로 제품을 사용해 보거나, 클라우드 환경에서 제품을 사용하거나, SOA Sandbox에서 SOA(Service Oriented Architecture)를 효과적으로 구현하는 방법을 배울 수 있다.
  
  

토론

• developerWorks community에 참여한다. 개발자가 운영하고 있는 블로그, 포럼, 그룹 및 위키를 살펴보면서 다른 developerWorks 사용자와 의견을 나눌 수 있다.
  
  

필자소개

Sean Walberg は 1994年以来、学界、企業、およびインターネット・サービス・プロバイダー環境で Linux および UNIX システムに取り組んできました。この数年の間は、システム管理に関する広範な著作活動を行っています。

아티클 순위

의견

위로

목차

• 일반적인 데이터 센터가 아님
• 구성 관리를 위한 클라이언트 폴링
• 애플리케이션 업데이트 적용하기
• 관리 서버에 등록하기
• 결론
• 참고자료
• 필자소개
• 의견