얼마 전 잡지 페이지에서 우리는 UNIX 시스템용 Cfengine 원격 구성 관리 시스템을 살펴보았습니다. 이 시스템은 많은 네트워크 노드 구성 단계를 자동화하여 시스템 관리자의 업무를 크게 단순화합니다. 하지만 아무리 Cfengine이 편리하더라도 Puppet이라는 시스템에는 없는 단점이 많습니다.

UNIX 유형 운영 체제를 실행하는 수백 대의 시스템 기능을 유지 관리하는 시스템 관리자의 역할을 맡고 있다고 상상해 보십시오. 각각에는 구성, 주기적인 업데이트 및 모니터링이 필요하며 대부분 유사한 기능을 수행하는 것으로 가정됩니다.

3분의 2는 워크스테이션이고, 몇 개는 라우터이고, 나머지는 여러 웹 서버와 데이터 저장소입니다. 질문: 이 모든 사업을 관리하는 방법은 무엇입니까? 가장 간단한 대답은 SSH를 사용하여 각각에 연결하고 필요한 사항을 변경하는 것입니다. 그러나 이 방법에는 두 가지 문제점이 있다. 첫째, 노동집약적이다. 둘째, 관리자는 계속해서 많은 단조로운 작업을 수행해야 합니다. 예를 들어 모든 워크스테이션에서 OpenOffice.org를 업데이트하려면 동일한 명령을 수십 번 실행해야 합니다. 각 시스템 자체에 연결하고 미리 작성된 명령을 실행하는 여러 스크립트를 작성하여 이 문제를 방지할 수 있습니다. 그러나 여기서도 문제가 당신을 기다리고 있습니다.

각 작업에 맞게 스크립트를 지속적으로 수정해야 합니다. 스크립트는 운영 체제와 버전의 차이를 고려해야 하며 실행 중인 컴퓨터에 적용하기 전에 오랜 시간 동안 디버깅해야 합니다. 일반적으로, 실패하지 않습니다. 정답은 오픈 소스 시스템인 Cfengine과 Puppet이 가장 잘 알려진 대표적인 원격 구성 관리 시스템을 사용하는 것입니다. 이러한 시스템은 시스템 구성을 원하는 형식으로 가져오는 모든 책임을 지며, 관리자는 시스템의 최종 상태를 특수 언어로 설명하기만 하면 됩니다(예: OS에 설치해야 하는 패키지에 대한 설명, 어떤 명령을 실행해야 하는지 등을 구성 파일에 추가해야 합니다.) 그 후 모든 노드 자체는 서버로부터 필요한 상태에 대한 정보를 수신하고 시스템 자동 구성을 수행합니다. 이 메커니즘 덕분에 사람의 개입 없이 새 시스템을 완전히 구성할 수 있으며 상태 설명에 몇 줄만 추가하면 기존 시스템을 재구성할 수 있습니다.

인형?

우리는 이미 Cfengine 시스템에 대한 전체 기사를 다루었으므로 오늘은 이념적 계승자라고 할 수 있는 Puppet 시스템에 중점을 둘 것입니다. Puppet은 Cfengine의 한계에 지쳐서 처음부터 더 나은 버전을 만들기로 결정한 Luke Kanies가 개발했습니다. 이미 Cfenfine을 사용해 본 적이 있다면 아마도 Puppet이 더 편리하고 강력한 시스템이라는 것을 알게 될 것입니다. Puppet의 상태 언어는 더 높은 수준이고 유연하므로 관리자는 각 OS 유형에 대해 별도의 규칙을 작성하거나 사소한 작업을 수행하는 방법을 자세히 설명하는 것과 같은 작업에 대해 걱정할 필요가 없습니다. Puppet을 사용하면 마스터가 수행 방법 대신 수행하려는 작업에 집중할 수 있습니다. 예를 들어 시스템이 지원하는 OS에 특정 패키지를 설치하려면 문자 그대로 "이 프로그램을 설치하세요"라는 몇 줄만 작성하면 됩니다. " 설치에 필요한 명령을 설명하는 대신). Puppet은 간단한 Ruby 언어로 작성되어 특정 작업에 쉽게 적용하고 기능을 확장할 수 있습니다(유연한 플러그인 시스템 제공).

또한 기본적으로 한 사람을 중심으로 진행되는 Cfengine의 개발 모델과 달리 Puppet에는 코드를 개선하고 구성 예제를 공유하며 문서를 작성하는 열광적인 대규모 커뮤니티가 있습니다.

전반적으로 Puppet은 더욱 현대적이고 잘 설계된 시스템으로 보입니다. Cfengine과 마찬가지로 거의 모든 최신 UNIX 계열 운영 체제(MacOS X 포함)를 지원하며 Windows 기반의 Cygwin 환경에서도 실행할 수 있습니다. 종속성 목록에는 Ruby 인터프리터와 Factor 도구만 포함되어 있으므로 설치에 문제가 없어야 합니다(공평하게 말하면 Cfengine의 종속성 목록은 훨씬 더 짧습니다).

설치

Cfengne과 마찬가지로 Puppet은 제어 서버와 슬레이브 노드로 구성된 클라이언트-서버 시스템입니다. 서버는 노드의 최종 상태에 대한 설명(Puppet 용어로 매니페스트라고 함)을 저장하고 노드가 연결될 때까지 기다립니다. 30분마다(기본적으로) 클라이언트는 서버에 연결하여 서버로부터 최종 상태에 대한 설명을 수신하고 이를 현재 상태와 비교하고 해당 서버 및/또는 설명된 상태가 변경된 경우 시스템을 재구성한 다음 잠자리에 든다. 통신은 암호화된 채널을 통해 수행되므로 상태 설명 대체에 따른 공격은 제외됩니다(그러나 공격자가 서버를 장악하면 모든 노드가 그의 제어를 받게 됩니다).

Puppet은 모든 인기 배포판의 저장소에 포함되어 있으므로 설치가 어렵지 않습니다. 예를 들어 Debian/Ubuntu에서는 Puppet 클라이언트를 다음과 같이 설치할 수 있습니다.

$ sudo apt-get 설치 꼭두각시

그리고 서버는 다음과 같습니다.

$ sudo apt-get 설치 인형극 puppetmaster

클라이언트 및 서버 구성 파일은 /etc/puppet 디렉터리에 저장됩니다. 이 중 가장 중요한 것은 매니페스트가 포함된 /etc/puppet/manifests/site.pp 파일입니다.

상태에 대한 설명을 저장하며 서버에만 존재해야 합니다. 쉽게 디버깅할 수 있도록 간단한 구성을 추가해 보겠습니다.

클래스 비밀번호(
파일("/etc/passwd":
소유자 => 루트,
그룹 => 루트,
모드 => 644,
}
}
노드 기본값(
비밀번호 포함
}

이 줄은 /etc/passwd 파일의 소유자가 루트여야 하고 해당 권한이 644로 설정된 조건을 설명합니다. 다음 섹션에서 매니페스트 파일 형식을 자세히 살펴보겠습니다. 두 번째로 중요한 파일은 /etc/puppet/puppet.conf입니다. 이는 서버와 클라이언트의 구성을 설정하므로 Puppet 네트워크에 구성된 모든 시스템에 있어야 합니다. Ubuntu에서 이 파일에는 최소한의 필수 설정과 대부분의 경우 충분한 설정이 포함되어 있습니다. 아래에는 설명이 제공됩니다.

# vi /etc/puppet/puppet.conf
# 표준 디렉터리 경로
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
# 팩터 도구 위치,
# OS에 대한 정보를 얻는 데 사용됩니다.
사실경로=$vardir/lib/facter
# 플러그인 동기화
# (서버에 설치된 플러그인 - 클라이언트에 복사됨)
플러그인동기화=true
# 템플릿이 포함된 카탈로그(아래에서 이에 대해 읽어보세요)
templatedir=$confdir/templates
# etckeeper와 동기화
# (누가 알겠는가, 이해할 것인가, 다른 사람들은 그것을 필요로 하지 않을 것이다)
prerun_command=/etc/puppet/etckeeper-commitpre
postrun_command=/etc/puppet/etckeeper-commitpost

구성 파일에는 다양한 옵션이 포함될 수 있으며 이에 대한 정보는 기본 구성을 생성하여 얻을 수 있습니다.

$ sudo puppetmasterd -genconfig > /etc/puppet/
puppetd.conf.default

기본 클라이언트 구성은 다른 명령을 사용하여 생성됩니다.

$ sudo puppet -genconfig > /etc/puppet/puppetd.conf.default

fileserver.conf 및 auth.conf 파일은 파일 서버("파일 서버" 섹션 참조) 및 인증을 구성하는 데 사용됩니다. 아직 만질 필요가 없습니다. 구성이 완료되면 Puppet 서버를 다시 시작해야 합니다.

$ sudo /etc/init.d/puppetmaster 재시작

그 후에 그는 고객 요청을 수락할 준비가 됩니다. 그러나 서명된 인증서가 없으면 어떤 클라이언트도 서버에서 매니페스트를 수신하고 시스템을 구성할 수 없습니다.

따라서 Puppet 클라이언트가 서명을 위해 서버에 인증서를 제출할 수 있도록 테스트 모드에서 Puppet 클라이언트를 실행해야 합니다(이 작업은 shmux 도구를 사용하여 모든 시스템에서 동시에 수행할 수 있습니다).

$ sudo puppetd -server puppet-server.com -verbose -test

서버로 돌아가서 서명할 준비가 된 인증서 목록을 받습니다.

$ sudo puppetca --list

목록에서 호스트를 선택하고 해당 인증서에 서명합니다.

$ sudo puppetca --sign nomad.grinder.com

아니면 모든 것을 한 번에 서명합니다.

$ sudo puppetca --sign --all

이제 전투 모드에서 클라이언트를 시작할 수 있습니다. 하지만 먼저 구성 파일에 Puppet 서버의 이름을 입력해야 합니다(기본적으로 이름은 단순히 puppet입니다).

$sudo su
# 에코 "" >> /etc/puppet/puppet.conf
# echo "server=puppet-server.com" >> /etc/puppet/puppet.conf
# 출구

클라이언트 시작:

$ sudo /etc/init.d/puppet 시작

상태 설명 언어

위에서 언급했듯이 Puppet은 운영 체제의 최종 상태를 설명하기 위해 자체 언어를 사용하며, 이를 통해 시스템 관리자는 원하는 상태를 달성하기 위해 OS 구성 요소를 어떤 형식으로 가져와야 하는지 지정합니다. 이것은 다소 복잡한 언어이지만 어떤 프로그래밍 언어보다 훨씬 간단합니다. bash 스크립팅 언어에 최소한 표면적으로 익숙하다면 Puppet 언어를 쉽게 이해할 수 있습니다. 언어의 핵심 요소는 OS 구성 요소 중 하나를 어떤 형식으로 변환해야 하는지 설명하는 데 사용되는 리소스입니다. 예를 들어 다음의 간단한 리소스는 /etc/passwd 파일의 원하는 상태를 설명합니다.

# vi /etc/puppet/manifests/site.pp
파일("/etc/passwd":
소유자 => "루트"
}

여기 파일은 리소스 유형입니다. 이 예와 같이 파일을 관리하는 리소스부터 패키지 및 서비스에 이르기까지 총 수십 개가 있습니다. /etc/passwd 줄은 리소스의 이름입니다.

파일 형식의 경우 이름은 파일 경로와 동일하지만 일부 다른 형식에서는 이름이 임의로 지정될 수 있습니다. owner => "root" 행은 소유자 속성을 루트로 설정하는 것을 설명합니다. 즉, 지정된 파일의 소유자는 관리자여야 함을 나타냅니다.

각 리소스 유형에는 수정에 사용할 수 있는 자체 속성 세트가 있으며, 모든 리소스에서 사용할 수 있는 특수 메타 속성도 있습니다. 리소스의 중요한 특성 중 하나는 해당 리소스에 연결하는 기능입니다. 이는 종속성 체인을 형성하는 데 사용될 수 있습니다. 다음 항목은 /etc/passwd 리소스에 종속되는 /etc/group 리소스를 생성합니다(종속성은 require 메타 속성을 사용하여 지정됩니다).

# vi /etc/puppet/manifests/site.pp
파일("/etc/그룹":
요구 => 파일["/etc/passwd"],
소유자 => "루트",
}

이는 /etc/passwd 리소스가 구성된 경우에만 /etc/group 리소스를 구성(설명된 형식으로 가져옴)할 수 있음을 의미합니다. 리소스는 클래스라는 리소스 컬렉션으로 그룹화될 수 있습니다. 이는 수행되는 작업의 의미와 유형이 유사한 자원을 하나의 추상 자원으로 결합하기 위해 필요합니다. 예를 들어 편의를 위해 nginx 웹 서버의 설치 ​​및 실행을 동일한 이름의 하나의 추상 리소스로 결합할 수 있습니다.

# vi /etc/puppet/manifests/site.pp
클래스 nginx(
package("nginx":
보장 => 설치됨
}
서비스("nginx":
보장 => 실행 중,
요구 => 패키지["nginx"],
}
}

여기서 package 리소스 유형은 시스템에 nginx 패키지를 설치하는 데 사용되며, service는 동일한 이름의 서비스를 시작하는 데 사용됩니다. require를 사용하면 패키지가 성공적으로 설치된 경우에만 시스템이 서비스를 시작하도록 강제합니다. 수업의 편리함은 다음에 따라 수업이 포함될 수도 있다는 것입니다.

# vi /etc/puppet/manifests/site.pp
service("오징어":
보장 => 실행 중,
요구 => 클래스["nginx"],
}

실제 OOP 언어와 마찬가지로 클래스는 서로 상속하고 속성을 재정의할 수 있습니다.

# vi /etc/puppet/manifests/site.pp
클래스 비밀번호(
파일("/etc/passwd":
소유자 => "루트",
그룹 => "루트",
}
}
passwd-bsd 클래스는 passwd를 상속합니다(
파일["/etc/passwd"] ( 그룹 => "휠" )
}

여기서 passwd-bsd 클래스는 /etc/passwd 리소스의 그룹 속성을 재정의하기 위해 passwd에서 상속됩니다(BSD 시스템에서 /etc/passwd는 휠 그룹에 속하므로 해당 시스템에 대해 별도의 클래스를 만들었습니다). 나중에 조건을 사용하여 대체 속성 값을 선택하는 보다 정확하고 명확한 방법을 살펴보겠습니다.

변수는 모든 프로그래밍 언어의 필수 구성 요소 중 하나이며 Puppet에도 변수가 있습니다. 변수는 $ 기호로 시작하고 숫자, 문자열 또는 부울 값(true, false)을 포함할 수 있습니다.

$want_apache = 사실
$apache_version = "2.2.14"

Puppet의 가장 강력한 변수 관련 기능 중 하나는 팩터 머신 정보 도구와의 통합입니다. 이 유틸리티는 Puppet이 동일한 이름의 변수로 변환되는 키-값 쌍의 형태로 모든 시스템별 정보를 반환합니다. Puppet 언어의 조건부 지침과 함께 시스템 속성에 따라 리소스 속성을 변경하는 데 사용할 수 있습니다.

예를 들어 위에서 설명한 passwd 클래스는 OS 유형에 따라 속성을 자동으로 선택하도록 쉽게 다시 작성할 수 있습니다(클래스 자체는 필요하지 않음).

# vi /etc/puppet/manifests/site.pp
파일("/etc/passwd":
소유자 => "루트",
그룹 => $kernel ? (
리눅스 => "루트",
FreeBSD => "휠",
},
}

이 매니페스트 조각이 분석되는 OS에 따라 그룹 속성 값은 루트 또는 휠이 됩니다. 조건 연산자 외에도 Puppet 언어는 변수 값에 따라 특정 리소스를 생성하는 데 사용할 수 있는 사례 선택 연산자도 지원합니다.

# vi /etc/puppet/manifests/site.pp
$운영체제(
redhat: (service("httpd": verify => 실행 중))
데비안: (service("apache": verify => running))
기본값: ( 서비스( "apache2": 보장 =>
달리기))
}

이 코드는 운영 체제에 따라 서비스 유형 리소스의 다양한 변형을 정의합니다(서비스 이름은 Linux 배포판마다 다를 수 있으므로 Puppet이 실행해야 하는 서비스는 각 배포판에 대해 개별적으로 지정해야 합니다).

변수 값이 이전 옵션과 일치하지 않는 경우 기본 옵션이 사용됩니다. 이전에 설명한 파일, 패키지 및 서비스 리소스 유형 외에도 Puppet은 타사 개발자가 만든 리소스 유형을 포함하여 수많은 다른 리소스 유형을 지원합니다. 예제, 지원되는 속성 및 기능을 포함한 자세한 설명은 공식 문서(http://docs.puppetlabs.com/references/stable/type.html)에서 확인할 수 있습니다. 다음은 가장 많이 사용되는 목록과 간략한 설명입니다.

인기 있는 Puppet 리소스 유형

• cron - 크론 작업 관리
• exec - 스크립트 및 명령 실행
• 파일 - 파일 관리
• filebucket - 파일 백업
• 그룹 - 그룹 관리
• 호스트 - /etc/hosts 파일의 항목을 관리합니다.
• 인터페이스 - 네트워크 인터페이스 구성
• mount - 파일 시스템 마운트
• 알림 - Puppet 로그 파일에 메시지를 보냅니다.
• 패키지 - 패키지 관리
• 서비스 - 서비스 관리
• sshkey - SSH 키 관리
• tidy - 조건에 따라 파일 삭제
• 사용자 - 사용자 관리
• zones - Solaris 영역 관리

리소스 다음으로 Puppet 언어에서 두 번째로 중요한 요소는 노드입니다. 관리자의 도움을 받아 관리자는 특정 리소스와 클래스를 어떤 시스템에 적용해야 하는지 설명할 수 있습니다. 즉, Puppet 네트워크에 참여하는 각 머신에 대한 개별 구성을 지정하는 방법입니다. 노드의 가장 간단한 예는 "설치" 섹션의 기사 시작 부분에 나와 있습니다.

# vi /etc/puppet/manifests/site.pp
노드 기본값(
비밀번호 포함
}

이는 passwd 리소스/클래스를 포함하는 기본 노드의 정의입니다. default라는 이름은 "다른 모든 노드"를 의미하므로 위에 정의된 passwd 리소스/클래스가 각 노드에 구성됩니다. 여기에는 편의상 include 키워드가 사용되었습니다. 실제로 모든 클래스와 리소스는 노드 설명에서 직접 설명할 수 있지만 권장되지는 않습니다. 기본값 외에도 노드 이름에 시스템의 네트워크 이름(노드에 설명된 모든 리소스는 이 시스템에서만 구성됨) 또는 임의의 이름(이 노드는 다른 노드에서 상속될 수 있음)을 지정할 수 있습니다. . 이 모든 것이 클래스 및 리소스와 함께 어떻게 작동하는지 이해하기 위해 두 개의 네트워크 시스템(웹 서버 및 NTP 서버)을 구성하는 데 사용되는 미리 만들어진 Puppet 매니페스트의 예를 살펴보겠습니다.

# vi /etc/puppet/manifests/site.pp
# SSH 서버 설치 및 실행
클래스 sshd (
패키지( openssh-server: 확인 => 설치됨)
서비스(sshd:
이름 => $operatingsystem ? (
페도라 => "sshd",
데비안 => "ssh",
기본값 => "sshd",
},
활성화 => 사실,
보장 => 실행 중,
}
}
# 아파치 설치 및 실행
클래스 httpd(
패키지(httpd: 확인 => 설치됨)
서비스(httpd:
활성화 => 사실,
보장 => 실행 중,
}
}
# NTP 서버 설치 및 시작
클래스 ntpd(
패키지(ntp-server: 확인 => 설치됨)
서비스 (
ntp 서버:
활성화 => 사실,
보장 => 실행 중,
}
}
# 다른 모든 노드의 상위 노드로만 사용되는 기본 노드
노드 베이스(
sshd 포함
}
# 웹서버가 위치할 노드
node web.server.com은 기본(
httpd 포함
}
# NTP 서버 노드
노드 ntp.server.com은 기본(
ntpd 포함
}

겉으로는 단순해 보이는 이 구성은 꽤 많은 일을 합니다. web.server.com의 머신에 Apache를 설치하여 실행하고 NTP 서버를 머신에 설치하여 실행합니다. ntp.server.com. 또한 두 시스템 모두 SSH 서버를 설치합니다. 이 구성은 한 명의 관리자에게도 적합하지 않습니다. 서버를 올바르게 구성하고, 기본 Puppet 서버에서 새로운 구성 및 기타 파일을 받는 방법을 가르치려면 심각하게 개선되어야 합니다.

하지만 퍼핏의 위력은 확실히 드러납니다. 간단한 구성을 사용하여 기계가 필요한 소프트웨어를 자체적으로 설치 및 실행하고 작동 순서대로 유지하도록 만들었습니다(서버가 충돌하면 Puppet 자체가 재구성되어 시스템을 필요한 상태로 전환합니다).

파일 서버

추가 파일을 시스템에 복사하지 않으면 많은 원격 관리 작업을 해결할 수 없습니다. 이는 사전 준비된 구성, Apache용 웹 페이지, 공식 저장소에 없는 패키지 등이 될 수 있습니다. 이러한 파일을 원격 호스트로 쉽게 전송하기 위해 Puppet에는 파일 서버가 포함되어 있습니다.

파일 서버 설정은 /etc/puppet/fileserver.conf 파일에 저장됩니다. Puppet이 특정 디렉토리의 내용을 클라이언트에게 제공하도록 하려면 여기에 몇 줄을 입력해야 합니다.

# vi /etc/puppet/fileserver.conf
경로 = /var/puppet/files
*.server.com 허용

이 두 줄은 /var/puppet/files 디렉토리가 server.com 도메인의 모든 호스트에 액세스 가능해야 함을 나타냅니다. 또한 허용된 시스템의 전체 도메인 이름이나 해당 IP 주소를 지정할 수 있으며, 거부 지시문을 사용하여 원하지 않는 것을 차단할 수도 있습니다. 그런 다음 해당 디렉터리의 모든 파일을 파일 리소스를 사용하여 클라이언트로 이동할 수 있습니다. 예를 들어:

# vi /etc/puppet/manifests/site.pp
파일("/etc/httpd/conf/httpd.conf":
소스 => "puppet://httpd/httpd.conf",
모드 => 644,
}

서버의 /var/puppet/files/httpd 디렉터리에 있는 httpd.conf 파일은 리소스 이름에 지정된 경로를 따라 대상 시스템에 복사됩니다.

결론

이 문서에서는 Puppet 기능의 아주 작은 부분을 다루었습니다. 사실 이것은 책의 페이지에서만 완전히 설명할 수 있는 복잡한 시스템입니다. 동시에 Puppet은 구성 및 유지 관리가 매우 쉽습니다. 특히 웹에서 구성에 대한 많은 예를 찾을 수 있기 때문입니다.

정보

• Puppet은 HTTP 프로토콜을 사용하므로 웹 서버에서 실행되어 성능을 향상시킬 수 있습니다.
• Puppet을 사용하면 단일 로컬 시스템을 자동 구성하고 유지 관리할 수 있습니다.
• Puppet, 네트워크 OS 설치(pxe-install) 및 자체 구축 설치 이미지를 결합하면 단 하나의 명령으로 배포할 수 있는 완전히 자체 구성되는 머신 네트워크를 생성할 수 있습니다.
• Google, Fedora Project, Stanford University, Red Hat, Siemens IT Solution 및 SugarCRM과 같은 많은 대기업이 업무에 Puppet을 사용합니다.

연결

• http://docs.puppetlabs.com - Puppet 문서
• http://docs.puppetlabs.com/guides/언어_tutorial.html - Puppet 언어에 대한 전체 설명
• http://docs.puppetlabs.com/references/stable/type.html - 리소스 유형

Puppet을 사용하여 가상 서버 관리

1부: Puppet 설치 및 구성

콘텐츠 시리즈:

가상화 도구나 클라우드 서비스를 활용해 서버 환경을 구성하는 과정에서 개별 서버의 수가 급격히 늘어나고 있다. 새 서버를 생성할 때마다 적절한 소프트웨어를 설치하고 구성해야 합니다. 또한 서버 구성을 동기화하려면 셸 스크립트 작성과 같은 추가 노력이 필요합니다. 껍데기.

Puppet 소프트웨어를 사용하면 몇 가지 명령만으로 어려움 없이 빠르게 새 서버를 만들고 설정을 구성할 수 있습니다. 또한 Puppet은 생성된 서버의 구성을 주기적으로 동기화합니다.

이 프로그램은 일반적으로 대규모 서버 구조(예: 사용자가 많은 데이터 센터 또는 웹 서비스)를 관리하는 데 사용되지만 여러 서버(예: 로컬 네트워크)를 유지 관리하는 데에도 사용할 수 있습니다. 소규모 사무실 또는 홈 네트워크).

인형의 역사

Puppet 프로젝트는 Puppet Labs에서 개발되었으며 오픈 소스 소프트웨어로 배포됩니다. 이 프로그램은 유연한 모듈식 구조를 가지고 있습니다. 현재 Puppet용으로 200개 이상의 확장 모듈이 작성되었습니다.

Puppet은 개발 회사뿐만 아니라 매우 활동적인 사용자 커뮤니티에서도 지원됩니다.

업무용 Puppet 설치 및 준비

Puppet의 기능은 클라이언트-서버 체계에 따라 구성됩니다. 각 클라이언트는 정기적으로 마스터 관리 서버(또는 여러 서버)와 통신하고 해당 구성을 동기화합니다. 기본적으로 이러한 통신 세션은 30분마다 발생합니다. 따라서 Puppet의 정상적인 작동을 보장하려면 설치된 서버가 두 개 이상 필요합니다. 하나는 마스터 서버로 작동하고 다른 하나는 하위 서버로 작동합니다. 즉, 이 컨텍스트에서 다음을 수행할 수 있습니다. 그들을 클라이언트라고 불러라."

다른 서버를 마스터 관리 서버로 관리할 호스트에 Puppet을 설치하려면 목록 1에 표시된 명령을 실행해야 합니다. 이러한 명령은 루트로 실행됩니다. 뿌리.

목록 1. 기본 명령 및 제어 서버에 puppet-server 패키지 설치

# yum -y install puppet-server # chkconfig puppetmaster on # service puppetmaster start

목록 2에 표시된 대로 슬레이브 서버용 패키지가 클라이언트 호스트에 설치됩니다(명령은 수퍼유저로도 실행됩니다). 뿌리).

목록 2. 클라이언트 호스트에 puppet 패키지 설치

# yum -y install puppet # chkconfig puppet on # 서비스 꼭두각시 시작

주 제어 서버의 호스트가 방화벽으로 보호되고 클라이언트 호스트가 이 방화벽을 기준으로 "외부"에 있는 경우(예: 로컬 네트워크의 컴퓨터) 주 서버에서 TCP 포트를 열어야 합니다. 숫자 8140 그리고 가능하다면 클라이언트 호스트에서만 사용할 수 있도록 하세요. 모든 작업이 하나의 컴퓨터(localhost)에서 수행되는 경우 방화벽을 조작할 필요가 없습니다.

퍼펫 기본 사항

Puppet 관점에서 모든 구성은 리소스( 자원)은 제어 환경의 주요 구조 구성 요소라고 할 수 있습니다. 리소스는 파일, 서버 서비스, 소프트웨어 패키지 등이 될 수 있습니다. 또한 리소스는 단일 셸 명령 호출일 수도 있습니다. 예를 들어, 목록 3에 설명된 유형의 리소스 파일소유자가 다음과 같은 모든 사람에게 알려진 /etc/passwd 파일을 나타냅니다. 뿌리.

목록 3. 리소스 설명 - /etc/passwd 파일

파일("/etc/passwd": 소유자 => 루트, 모드 => 644, )

리소스는 특정 특성에 따라 그룹화될 수 있습니다. 예를 들어 모든 파일에는 소유자가 있고 파일 시스템의 특정 주소(경로)에 위치하며 각 사용자는 로그인 이름, 개인 식별자(UID) 및 그룹 식별자( GID). 이러한 특성에 따라 자원의 유형이 형성됩니다. 또한 리소스 유형의 가장 중요한 특성은 사소한 구현 세부 사항에 관계없이 일반적으로 모든 운영 체제에서 동일합니다. 즉, 리소스에 대한 설명은 특정 운영 체제의 구현에서 완전히 추상화될 수 있습니다.

위의 전제조건을 바탕으로 자원 추상화 계층이 구성되었습니다. RAL) 인형극 프로그램. RAL은 리소스를 유형( 종류), 상위 수준 모델인 공급자( 공급자)는 하위 수준의 플랫폼별 리소스 구현을 나타냅니다. 이 RAL 조직을 사용하면 거의 모든 시스템에 적용할 수 있는 방식으로 리소스 설명을 작성할 수 있습니다.

RAL 동기화 주기

Puppet은 RAL을 사용하여 시스템 리소스의 상태를 읽고 수정합니다. 선언적 모니터링 및 제어 시스템인 Puppet은 리소스가 어떤 상태에 있어야 하는지에 대한 정보를 획득하여 작업 주기를 시작합니다. 리소스 동기화는 RAL을 사용하여 현재 상태를 쿼리하고 이를 원하는 상태와 비교하며 차이점이 발견되면 필요한 변경을 수행합니다.

리소스 설명 구조

위에서 언급했듯이 Puppet에서 모든 리소스는 특정 유형의 인스턴스입니다( 리소스 유형), 설명 자체가 시작됩니다. 리소스는 이름( 제목), 여는 중괄호 뒤에 작은따옴표로 작성되고 그 뒤에 콜론 문자가 옵니다. 다음으로, 유형 속성은 새 줄( 속성), 일부 속성은 모든 유형에 공통적이지만 다른 속성은 이 특정 유형의 리소스에 고유합니다. 각 속성에는 값( 값), 따라서 해당 값이 있는 속성 레코드는 일반적인 형식을 갖습니다. 속성 => 값.

Puppet 리소스 설명 언어의 구문에 대한 일반적인 아이디어는 가장 간단한 사례인 "사용자" 유형의 리소스에 대한 설명( 사용자).

목록 4. 사용자 예제를 사용한 Puppet 리소스 설명 언어 구문

사용자( "alex": verify => 현재, uid => "501", gid => "admin", shell => "/bin/bash", home => "/home/alex", preparehome => true, )

각 속성 정의 줄은 쉼표로 끝나며 닫는 중괄호는 리소스 정의가 완료되었음을 나타냅니다.

목록 5에 표시된 다음 구성은 패키지를 설치합니다. openssh-서버, 서비스 이용을 허용합니다 SSHD기본값을 선택하고 검사를 실행하여 서비스가 실제로 활성화되어 실행되고 있는지 확인하세요.

목록 5. 리소스 설명 - sshd 서비스(설치, 실행, 확인)

패키지( "openssh-server": 확인 => 설치됨, ) 서비스( "sshd": 활성화 => true, 확인 => 실행 중, 요구 => 패키지["openssh-server"], )

이제 위 구성을 적절한 서버에 적용해야 합니다. Puppet 패키지에는 기본적으로 특수 리소스 구성 파일이 포함되어 있습니다. site.pp, 이는 디렉토리에 있습니다. /etc/puppet/매니페스트. 리소스 구성 매개변수가 그다지 복잡하지 않은 경우 이 파일에 수동으로 추가할 수 있습니다. 예를 들어 위의 목록 3과 4의 내용입니다.

필요한 모든 프로그램을 설치 및 활성화하고 구성 파일을 생성한 후에는 모든 슬레이브 서버(클라이언트)를 주 제어 서버에 등록하고 등록의 진위 여부를 확인하는 것이 필수입니다( 징후), 즉 일종의 인증을 받는 것입니다. 슬레이브 서버에서는 다음 명령으로 등록이 수행됩니다(수퍼유저 권한도 필요함). 뿌리):

puppetd --test --waitforcert 30 --서버 MASTER_SERVER_ADDRESS

대신에 MASTER_SERVER_ADDRESS주 제어 서버의 실제 주소를 지정해야 합니다.

필요한 클라이언트가 모두 등록되면 목록 6에 표시된 명령이 주 제어 서버에서 실행됩니다.

목록 6. 마스터 제어 서버에 등록된 클라이언트 인증하기

puppetca --list # 등록된 클라이언트의 주소 목록을 표시합니다. puppetca --sign CLIENT_SERVER_ADDRESS # CLIENT_SERVER_ADDRESS 대신 실제 클라이언트 주소를 지정합니다. # 각 클라이언트 주소에 대해 명령이 반복됩니다.

등록 및 인증이 완료되면 Puppet은 위에서 설명한 리소스 구성을 등록된 클라이언트에 자동으로 적용합니다.

# 실제 서버 주소도 여기에 기록됩니다. server = MASTER_SERVER_ADDRESS

이제 Puppet이 완전히 구성되어 작동합니다. 슬레이브 서버의 리소스 구성 자동 동기화는 30분마다 수행됩니다. 다음 명령을 실행하여 프로세스를 볼 수 있습니다.

tail -f /var/log/messages

결론

이번 글에서는 주 제어 서버와 클라이언트 서버에서 Puppet을 설정하고 구성하는 과정과 그 상태를 모니터링하는 과정을 살펴보았습니다. 이 시리즈의 다음 기사에서는 표준 시스템 관리자 작업을 수행하기 위한 Puppet 구성의 예를 살펴보겠습니다.

Puppet을 보다 효과적으로 사용하려면 모듈과 매니페스트가 구축되는 방식을 이해해야 합니다. 이 튜토리얼에서는 Ubuntu 14.04 서버에서 LAMP 스택을 설정하여 이러한 Puppet 구성 요소가 작동하는 방식을 안내합니다.

요구사항

• Puppet 설치(마스터 및 에이전트) 이에 대해 더 자세히 -.
• Puppet 에이전트 노드를 제공하기 위해 하나 이상의 Ubuntu 14.04 가상 서버를 생성하는 기능.

꼭두각시 코드 기본 사항

자원

퍼펫 코드는 주로 리소스로 구성됩니다. 리소스는 시스템 상태를 설명하고 필요한 변경 사항을 결정하는 코드 조각입니다. 예를 들어:

user("미첼":
보장하다 => 현재,
uid => "1000",
gid => "1000",
쉘 => "/bin/bash",
집 => "/집/미첼"
}

리소스 선언의 형식은 다음과 같습니다.

resources_type("자원_이름"
속성 => 값
...
}

모든 Puppet 리소스 유형을 보려면 다음 명령을 실행하십시오.

꼭두각시 자원 --유형

이 가이드에서는 리소스 유형에 대해 자세히 알아봅니다.

선언문

매니페스트는 오케스트레이션 스크립트입니다. .pp 확장자를 가진 Puppet 프로그램을 매니페스트라고 합니다. 기본 Puppet 매니페스트는 /etc/puppet/manifests/site.pp입니다.

클래스

일반 프로그래밍 언어와 마찬가지로 클래스는 오케스트레이션의 일부를 구성하고 재사용하는 일을 담당합니다.

클래스 정의 내에는 클래스 작동 방식을 설명하는 코드 블록이 있습니다. 클래스를 정의하면 이를 매니페스트에서 사용할 수 있습니다.

클래스 정의의 형식은 다음과 같습니다.

클래스 예제_클래스(
...
암호
...
}

이 코드는 example_class 클래스를 정의합니다. Puppet 코드는 중괄호 안에 표시됩니다.

클래스 선언은 코드에서 특정 클래스가 호출되는 위치입니다. 클래스 선언을 통해 Puppet은 코드를 처리합니다.

클래스 선언은 일반적일 수 있으며 리소스 유형에 따라 달라질 수 있습니다.

정규 클래스 선언은 include 키워드를 사용하여 코드에 추가됩니다.

example_class 포함

리소스 유형으로 선언되면 클래스는 리소스 형식으로 선언됩니다.

클래스("예제_클래스":)

이 선언을 사용하면 클래스 속성의 기본값을 재정의하는 클래스 매개변수를 코드에 추가할 수 있습니다. 예를 들어:

노드 "host2"(
class ("apache": ) # 아파치 모듈을 사용합니다
apache::vhost ( "example.com": # 가상 호스트 리소스 정의
포트 => "80",
docroot => "/var/www/html"
}
}

모듈

모듈은 오케스트레이션의 개별 부분을 쉽게 공유하고 재사용할 수 있도록 사전 정의된 방식으로 구성된 매니페스트 및 기타 파일의 그룹입니다. 모듈은 코드를 여러 매니페스트로 분리하는 데 사용할 수 있으므로 Puppet 코드를 구성하는 데 도움이 됩니다.

Puppet 모듈은 /etc/puppet/modules 디렉터리에 저장됩니다.

선언문 작성

Ubuntu 서버에 LAMP 스택을 설치하는 예제를 사용하여 Puppet 매니페스트, 모듈 및 클래스 작성을 연습할 수 있습니다(결과는 ).

따라서 Ubuntu 14.04 서버를 조정하고 여기에 LAMP 스택을 설치하려면 다음 작업을 위한 리소스가 필요합니다.

• apache2 패키지를 설치합니다.
• apache2 서비스를 시작합니다.
• MySQL 서버 패키지 mysql-server를 설치합니다.
• mysql 서비스를 시작합니다.
• php5 패키지 설치
• PHP 테스트 스크립트 info.php를 생성합니다.
• 각 패키지를 설치하기 전에 적절한 색인을 업데이트하십시오.

아래에는 이러한 LAMP 스택 설정을 달성하는 데 사용할 수 있는 Puppet 코드의 세 가지 예가 나와 있습니다.

첫 번째 예에서는 하나의 파일에 기본 매니페스트를 작성하는 방법을 설명합니다. 두 번째 예제는 이전에 작성된 매니페스트를 기반으로 클래스와 모듈을 어셈블하고 사용하는 데 도움이 됩니다. 세 번째 예에서는 사전 구축된 공개 모듈을 사용하여 LAMP 스택을 설치하는 방법을 보여줍니다.

메모: 테스트를 위해서는 새로운 가상 서버를 사용하는 것이 좋습니다.

예 1: 하나의 매니페스트를 사용하여 LAMP 설치

Puppet 매니페스트는 에이전트 노드에 작성된 다음 puppet Apply 명령을 사용하여 실행할 수 있습니다(이 작업을 수행하기 위해 마스터 및 에이전트 설정이 필요하지 않음).

이 섹션에서는 다음 유형의 리소스 선언을 사용하는 매니페스트를 작성하는 방법을 배웁니다.

• exec: 명령을 실행합니다.
• 패키지: 패키지를 설치합니다.
• 서비스: 서비스 관리.
• 파일: 파일 관리.

매니페스트 만들기

새 매니페스트를 만듭니다.

sudo vi /etc/puppet/manifests/lamp.pp

필요한 리소스를 선언하려면 다음 코드를 추가하세요.

# "apt-get update" 명령을 실행합니다
exec("apt-update": # 리소스 exec "apt-update"
command => "/usr/bin/apt-get update" # 이 리소스가 실행할 명령
}
# apache2 패키지 설치
패키지("아파치2":
require => Exec["apt-update"], # 패키지를 설치하기 전에 "apt-update"를 요청합니다.
=> 설치되었는지 확인하세요.
}
# apache2 서비스를 시작합니다
서비스("아파치2":
보장 => 실행 중,
}
# mysql-서버를 설치한다
package("mysql-서버":
require => Exec["apt-update"], # 재설치하여 "apt-update" 요청
=> 설치되었는지 확인하세요.
}
# mysql 서비스를 시작한다
서비스("mysql":
보장 => 실행 중,
}
# php5 패키지 설치
패키지("php5":
require => Exec["apt-update"], # 설치 전에 "apt-update"를 요청합니다
=> 설치되었는지 확인하세요.
}
# info.php 서비스를 시작합니다
파일("/var/www/html/info.php":
보장 => 파일,
내용 => "", # phpinfo 코드
require => Package["apache2"], # "apache2" 패키지 요청
}

매니페스트 적용

새 매니페스트를 사용하려면 다음 명령을 입력하세요.

sudo puppet 적용 --테스트

환경 상태의 모든 변화를 표시하는 방대한 결과가 표시됩니다. 출력에 오류가 없으면 브라우저에서 외부 IP 주소 또는 도메인 이름을 열 수 있어야 합니다. 스택 정보가 포함된 PHP 테스트 페이지가 화면에 나타납니다. 이는 Apache와 PHP가 작동하고 있음을 의미합니다.

이제 Puppet을 사용하여 LAMP 스택이 서버에 설치되었습니다.

이는 에이전트에서 실행될 수 있으므로 매우 간단한 매니페스트입니다. Puppet 마스터가 없으면 다른 에이전트 노드는 이 매니페스트를 사용할 수 없습니다.

Puppet 마스터 서버는 30분마다 서버 상태 변경을 확인합니다.

예시 2: 모듈을 사용하여 LAMP 스택 설치

이제 이전 섹션에서 작성한 LAMP 매니페스트를 기반으로 간단한 모듈을 만들어 보십시오.

모듈을 만들려면 모듈 디렉터리에 새 디렉터리를 만듭니다(이름은 모듈 이름과 일치해야 합니다). 이 디렉터리에는 매니페스트 디렉터리와 init.pp 파일이 포함되어야 합니다. init.pp 파일은 Puppet 클래스를 지정합니다(해당 이름은 모듈 이름과도 일치해야 함).

모듈 생성

Puppet 마스터 서버로 이동하여 모듈에 대한 디렉터리 구조를 만듭니다.

CD /etc/puppet/모듈
sudo mkdir -p 램프/매니페스트

편집기에서 init.pp 파일을 만들고 엽니다.

sudo vi 램프/manifests/init.pp

램프 클래스를 파일에 삽입합니다.

수업 램프(
}

섹션 1의 매니페스트 내용을 복사하여 램프 클래스 블록에 붙여넣습니다. 이제 램프 클래스 정의가 생겼습니다. 다른 매니페스트에서는 이 클래스를 모듈로 사용할 수 있습니다.

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

기본 매니페스트에서 모듈 사용

이제 기본 매니페스트를 구성하고 램프 모듈을 사용하여 서버에 LAMP 스택을 설치할 수 있습니다.

Puppet 마스터 서버에서 다음 파일을 편집합니다.

sudo vi /etc/puppet/manifests/site.pp

현재 파일이 비어 있을 가능성이 높습니다. 다음 줄을 추가합니다.

노드 기본값( )
노드 "램프-1"(
}

메모: lamp-1을 스택을 설치할 Puppet 에이전트의 호스트 이름으로 바꿉니다.

노드 블록을 사용하면 일부 노드에만 적용되는 Puppet 코드를 지정할 수 있습니다.

기본 블록은 개별 블록이 없는 모든 에이전트 노드에 적용됩니다(비워두기). lamp-1 블록은 lamp-1 에이전트 노드에 적용됩니다.

램프 모듈을 사용하는 이 블록에 다음 줄을 추가합니다.

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

이제 Puppet 에이전트 노드는 마스터 서버에서 설정을 다운로드하고 LAMP 스택을 설치할 수 있습니다. 지금 바로 변경하려면 에이전트에서 다음 명령을 실행하세요.

sudo puppet 에이전트 --테스트

모듈은 Puppet 코드를 재사용하는 가장 편리한 방법입니다. 또한 모듈은 코드를 논리적으로 구성하는 데 도움이 됩니다.

예시 3: 공용 모듈을 사용하여 LAMP 설치

MySQL 모듈도 비슷한 방식으로 사용됩니다. 노드 블록에 다음 줄을 추가합니다.

class("mysql::서버":
root_password => "비밀번호",
}

MySQL 모듈 매개변수를 전달할 수도 있습니다.

info.php를 원하는 위치에 복사할 리소스를 추가합니다. 소스 매개변수를 사용하세요. 노드 블록에 다음 줄을 추가합니다.

file("info.php": # 리소스 파일 이름
path => "/var/www/html/info.php", # 대상 경로
보장 => 파일,
require => Class["apache"], # 사용할 아파치 클래스
source => "puppet:///modules/apache/info.php", # 파일을 복사할 위치
}

이 클래스 선언은 콘텐츠 대신 source 매개변수를 사용합니다. 이 옵션은 파일의 내용을 사용할 뿐만 아니라 복사도 합니다.

Puppet은 puppet:///modules/apache/info.php 파일을 /etc/puppet/modules/apache/files/info.php에 복사합니다.

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

info.php 파일을 생성합니다.

sudo sh -c "에코""> /etc/puppet/modules/apache/files/info.php"

이제 Puppet 에이전트 노드는 마스터 서버에서 설정을 다운로드하고 LAMP 스택을 설치할 수 있습니다. 지금 에이전트 환경을 변경하려면 이 노드에서 명령을 실행하세요.

sudo puppet 에이전트 --테스트

이 명령은 현재 노드에 대한 모든 업데이트를 다운로드하고 해당 노드에 스택을 설치합니다. Apache와 PHP가 작동하는지 확인하려면 브라우저에서 노드의 IP 주소 또는 도메인을 엽니다.

http://lamp_1_public_IP/info.php

결론

이제 Puppet 모듈 및 매니페스트 작업에 대한 기본 지식을 갖추었습니다. 간단한 매니페스트와 모듈을 직접 만들어 보세요.

Puppet은 애플리케이션 구성 파일을 관리하는 데 적합합니다.

태그: ,

관리하는 서버 수가 10개 미만이면 중앙 집중식 관리에 대해 생각하는 사람이 거의 없으며 이것이 필요하지 않을 수도 있습니다. 수십 대의 서버가 있는 경우 중앙 집중식 소프트웨어 및 구성 관리는 매우 유용합니다. 수백, 수천 개의 서버가 있는 경우 이는 매우 중요합니다. 예를 들어 Chef, CFEngine 등과 같은 종류의 프로그램이 많이 있습니다. 이 게시물에서는 후자에 대해 논의하겠습니다.

Puppet은 이러한 종류의 최고의 솔루션 중 하나로 간주됩니다. Google, Citrix 및 Red Hat과 같은 회사에서 사용됩니다. 이는 Ruby 프로그래밍 언어로 작성된 클라이언트-서버 애플리케이션으로, 두 가지 버전으로 배포됩니다.

• Puppet 오픈 소스 - 완전 무료 버전
• Puppet Enterprise - 최대 10개의 서버까지 무료이며 이후에는 라이선스가 필요합니다.

대부분의 최신 배포판 패키지에 포함되어 있는 Puppet Open Source 서버 및 에이전트 설치를 고려해 보겠습니다. 다음으로 Ubuntu 12.04 Precise Pangolin에 대해 이야기하겠습니다.

Puppet의 백엔드는 다음과 같습니다. 꼭두각시 인형, 거기에서 설치를 시작하겠습니다.

:~# apt-get 설치 puppetmaster

이제 클라이언트는 다음과 같습니다.

:~# apt-get 설치 꼭두각시

클라이언트 구성 파일에서 /etc/puppet/puppet.conf다음 섹션을 추가하여 서버에 대해 설명해야 합니다.

서버=puppet.local 보고서=true 플러그인동기화=false

초기 단계에서는 플러그인 동기화를 끄는 것이 좋습니다.

인증서 요청을 생성하도록 Puppet 클라이언트를 실행해 보겠습니다.

:~# puppetd --verbose --test info: linux.local에 대한 새 SSL 키 생성 info: ca에 대한 인증서 캐싱 info: linux.local에 대한 새 SSL 인증서 요청 생성 info: 인증서 요청 지문(md5): E5: EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51 종료 중입니다. 인증서를 찾을 수 없으며 waitforcert가 비활성화되었습니다.

서버에서 인증서 요청이 수신되었는지 확인하고, 수신된 경우 인증서를 발급해야 합니다.

:~# puppetca --list "linux.local" (E5:EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51) :~# puppetca - -sign linux.local 공지: linux.local에 대한 서명된 인증서 요청 공지: "/var/lib/puppet/ssl/ca/requests/linux.local.pem"에서 Puppet::SSL::CertificateRequest linux.local 파일 제거

클라이언트에서 이전 단계를 반복합니다.

:~# puppetd --verbose --test 정보: linux.local에 대한 인증서 캐싱 정보: 플러그인 정보 검색 중: ca에 대한 인증서_revocation_list 캐싱 정보: linux.local에 대한 카탈로그 캐싱 정보: 구성 버전 "1356278451" 적용 정보: 상태 파일 생성 / var/lib/puppet/state/state.yaml 공지: 0.02초 만에 카탈로그 실행 완료

좋습니다. 모든 것이 작동합니다. 첫 번째 선언문 작성으로 넘어 갑시다. 매니페스트 또는 구성은 특별한 선언적 언어로 설명됩니다. 우리는 즉시 좋은 것들에 익숙해지고, 모듈식 구조와 클래스를 사용할 것입니다. 예를 들어 파일을 최신 상태로 유지하는 모듈을 작성해 보겠습니다. /etc/호스트우리의 모든 서버에서.

Puppet이 모듈을 찾는 위치를 확인해 보겠습니다.

:~# puppet apply --configprint modulepath /etc/puppet/modules:/usr/share/puppet/modules

모듈용 디렉터리 생성

:~# cd /etc/puppet/modules :~# mkdir 호스트; CD 호스트; mkdir이 나타납니다. CD 매니페스트

기본 모듈 파일이라고도 하는 첫 번째 매니페스트를 호출해야 합니다. init.pp

클래스 호스트( # puppet.local 호스트( "puppet.local": verify => "present", target => "/etc/hosts", ip => "192.168.0.1", host_aliases => "puppet", ) # linux.local 호스트 ( "linux.local": verify => "present", target => "/etc/hosts", ip => "192.168.0.2", host_aliases => "linux", ) )

기본적으로 Puppet은 파일을 찾습니다. /etc/puppet/manifests/site.pp구성을 로드하려면 다음 형식으로 가져오세요.

노드 기본값(호스트 포함)

서버에서 매니페스트를 확인하는 중:

:~# puppet apply --verbose /etc/puppet/manifests/site.pp info: 구성 버전 "1356281036" 적용 중 알림: /Stage//Host/ensure: 생성됨 정보: FileBucket 추가(md5)notice: /Stage// 호스트/확인: 생성 알림: 0.03초 만에 카탈로그 실행 완료

클라이언트에서:

:~# ll /etc/hosts rw-r--r-- 1 루트 루트 290 Dec 16 19:10 /etc/hosts :~# puppetd --verbose --test 정보: linux.local에 대한 캐싱 카탈로그 정보: 적용 중 구성 버전 "1356283380" 정보: FileBucket 추가(md5)알림: /Stage/Hosts/Host/ensure: 생성됨 알림: /Stage/Hosts/Host/ensure: 생성됨 알림: 0.04초 만에 카탈로그 실행 완료 :~# ll /etc /hosts -rw-r--r-- 1 루트 루트 551 12월 23일 20:43 /etc/hosts

모든 것이 제대로 작동하는지 확인한 후 서비스가 시작되도록 허용합니다. /etc/default/puppet변화:

# 부팅 시 꼭두각시를 시작하시겠습니까? 시작=예

서비스 시작

:~# 서비스 인형 시작

Puppet은 구성 변경을 위해 30분마다 puppetmaster 서버를 폴링하고 필요한 경우 그에 따라 시스템을 조정합니다.