cfpuppet서버 클래스

• 배포 사용자 = "deploypuppet" - 구성 업데이트를 자동으로 배포하기 위한 사용자 이름
• 배포 사용자_auth_keys = undef - $deployuser에 대한 키 목록
• repo_url = undef - 저장소 URI(예: ssh://user@host/repo 또는 file:///some/path)
• puppetserver = true - 이 노드에 Puppet 서버 구성 요소를 설치할지 여부
• puppetdb = true - 이 노드에 PuppetDB 구성 요소를 설치할지 여부
• puppetdb_port = 8081 - PuppetDB용 포트
• setup_postgresql = true - 이 노드에 PostgreSQL 구성 요소를 설치할지 여부(PuppetDB 설치가 활성화된 경우에만)
• service_face = "any" - 들어오는 연결을 수락하기 위한 cfnetwork::iface 리소스의 이름
• puppetserver_mem = auto - Puppet 서버용 RAM(MB)(최소 192MB)
• puppetdb_mem = auto - PuppetDB용 RAM(MB)(최소 192MB)
• postgresql_mem = auto - PostgreSQL용 RAM(MB)(최소 128MB)

클래스 cfpuppetserver::puppetdb

• postgresql_host = "localhost" - 데이터베이스 주소
• postgresql_listen = $postgresql_host - 값은 listening_addresses PostgreSQL 지시문으로 직접 이동됩니다.
• postgresql_port = 5432 - 데이터베이스 포트
• postgresql_user = "puppetdb" - 데이터베이스의 PuppetDB 사용자
• postgresql_pass = "puppetdb" - 데이터베이스에 있는 PuppetDB 사용자의 비밀번호
• postgresql_ssl = false - Puppet PKI 인증서를 기반으로 연결 암호화를 활성화합니다.

클래스 cfpuppetserver::puppetserver

• autosign = false - DMZ를 제외하고 전투 환경에서는 사용하면 안 됩니다. 테스트 자동화 전용으로 존재합니다.
• global_hiera_config = "cfpuppetserver/hiera.yaml" - Puppet 캐논에 따른 기본 Hiera 구성 파일의 경로(첫 번째 구성 요소는 모듈 이름이고 나머지는 모듈의 files/ 폴더 아래 경로입니다)

사이트 개발을 위해 일부 자금을 돕고 이체할 수 있습니다.

다수의 Unix 시스템을 관리하는 것은 편리하다고 할 수 없습니다. 하나의 매개변수를 변경하려면 관리자가 각 시스템에 접속해야 하며 스크립트는 부분적으로만 도움이 될 수 있으며 모든 상황에 도움이 될 수는 없습니다.

Windows 네트워크 관리자가 여전히 더 유리한 위치에 있다는 점을 인식해야 합니다. 그룹 정책 설정을 변경하는 것만으로도 충분하며, 잠시 후 최근에 설치된 운영 체제를 포함하여 네트워크의 모든 컴퓨터는 혁신에 대해 "학습"하게 됩니다. 유닉스 개발의 오랜 기간을 되돌아보면 이와 같은 것이 결코 성공하지 못했다는 것을 알게 될 것입니다. 초기 설치에 도움이 되는 kickstart와 같은 솔루션이 있습니다. 운영 체제그러나 추가 개선에는 상당한 노력이 필요합니다. BladeLogic 및 OpsWare와 같은 상용 솔루션은 설정 자동화 문제를 부분적으로만 해결합니다. 주요 장점은 가용성입니다. GUI, 대규모 조직에서만 구입할 수 있습니다. 물론 무료 솔루션을 제공하는 프로젝트도 있지만, 존재하는 동안 대규모 커뮤니티를 만들 수는 없었습니다. 예를 들어, Cfengine은 Linux 외에도 *BSD, Windows 및 Mac OS X에서 사용할 수 있지만 관리자들 사이에서는 그다지 인기가 없습니다. 이는 구성 생성이 상대적으로 복잡하기 때문일 수 있습니다. 작업을 설명할 때 각 특정 시스템의 기능을 고려해야 하며 명령을 실행할 때 작업 순서를 수동으로 제어해야 합니다. 즉, 관리자는 일부 시스템의 경우 다른 시스템의 경우 adduser, 다른 시스템의 경우 useradd를 작성하고 다른 시스템의 파일 위치 등을 고려해야 한다는 점을 기억해야 합니다. 이로 인해 명령을 작성하는 과정이 엄청나게 복잡해지며, 즉석에서 올바른 구성을 생성하는 것이 매우 어렵고 생성된 구성을 잠시 후에 읽는 것이 거의 불가능합니다. GPL 라이센스에도 불구하고 Cfengine은 실제로 모든 변경 사항을 제어하는 ​​1인 프로젝트이며 열린 사회를 구축하는 데 별로 관심이 없습니다. 결과적으로 cfengine의 기능은 개발자에게는 상당히 만족스럽지만 다른 관리자에게는 오히려 골칫거리가 됩니다. cfengine을 개선하기 위해 타사 개발자가 다양한 추가 기능을 만들었으나 이로 인해 상황이 악화되는 경우가 많았습니다. cfengine용 여러 모듈의 작성자인 Luke Kanies는 결국 유사한 도구를 개발하기로 결정했지만 cfengine의 많은 단점은 없었습니다.

인형의 특징

cfengine과 마찬가지로 Puppet은 선언적, 즉 구현을 위한 작업 및 라이브러리를 설명하기 위한 필수 언어를 사용하는 클라이언트-서버 시스템입니다. 클라이언트는 주기적으로(기본적으로 30분) 중앙 서버에 연결하여 최신 구성을 받습니다. 수신된 설정이 시스템 상태와 일치하지 않으면 실행되며, 필요한 경우 수행된 작업에 대한 보고서가 서버로 전송됩니다. 서버는 메시지를 syslog나 파일에 저장하고 RRD 그래프를 생성하여 지정된 이메일로 보낼 수 있습니다. 추가 트랜잭션 및 리소스 추상화 계층은 기존 설정 및 애플리케이션과의 최대 호환성을 제공하므로 세부 명령 및 파일 형식의 구현 및 설명 차이에 대해 걱정하지 않고 시스템 개체에 집중할 수 있습니다. 관리자는 객체 유형으로만 작업하고 Puppet은 나머지를 처리합니다. 따라서 패키지 유형은 약 17개의 패키지 시스템을 알고 있으며 필요한 시스템은 배포판이나 시스템 버전에 대한 정보를 기반으로 자동으로 인식되지만 필요한 경우 패키지 관리자를 강제로 실행할 수 있습니다.

다른 시스템에서 사용할 수 없는 스크립트와는 달리, 타사 관리자가 작성한 Puppet 구성은 대부분 다른 네트워크에서 문제 없이 작동합니다. 꼭두각시 요리책에서 [ http://www.reitivelabs.com/trac/puppet/tags/puppet%2Crecipe] 이미 36개의 기성 레시피가 있습니다. Puppet은 현재 Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo 및 MySQL, LDAP와 같은 운영 체제 및 서비스를 공식적으로 지원합니다.

꼭두각시 언어

앞으로 나아가려면 먼저 언어의 기본 요소와 기능을 이해해야 합니다. 언어는 다음 중 하나입니다. 강점인형. 이를 통해 관리자가 관리할 리소스와 조치를 설명합니다. 대부분의 유사한 솔루션과 달리 Puppet을 사용하면 언어를 통해 이기종 환경의 모든 시스템에 있는 모든 유사한 리소스에 대한 액세스를 단순화할 수 있습니다. 리소스 설명은 일반적으로 이름, 유형 및 속성으로 구성됩니다. 예를 들어, /etc/passwd 파일을 가리키고 해당 속성을 설정해 보겠습니다.

파일("/etc/passwd":

소유자 => 루트,

그룹 => 루트,

이제 서버에 연결된 클라이언트는 /etc/passwd 파일을 복사하고 지정된 속성을 설치합니다. 하나의 규칙에 여러 리소스를 정의하고 세미콜론을 사용하여 구분할 수 있습니다. 서버에서 사용하는 구성 파일이 클라이언트 구성 파일과 다르거나 전혀 사용되지 않는 경우 어떻게 해야 하나요? 예를 들어 다음과 같은 경우에 이러한 상황이 발생할 수 있습니다. VPN 설정사이. 이 경우 source 지시문을 사용하여 파일을 가리킬 수 있습니다. 여기에는 평소와 같이 다른 파일의 경로를 지정하는 두 가지 옵션이 있으며, 파일과 퍼펫이라는 두 가지 URI 프로토콜도 지원됩니다. 첫 번째 경우에는 외부 링크에 대한 링크입니다. NFS 서버, 두 번째 옵션에서는 리소스를 내보내는 NFS와 유사한 서비스가 Puppet 서버에서 시작됩니다. 후자의 경우 기본 경로는 puppet 루트 디렉터리(/etc/puppet)에 상대적입니다. 즉, puppet://server.domain.com/config/sshd_config 링크는 /etc/puppet/config/sshd_config 파일에 해당합니다. filebucket 지시문을 사용하여 이 디렉터리를 재정의할 수 있지만 /etc/puppet/fileserver.conf 파일에서 동일한 이름의 섹션을 사용하는 것이 더 정확합니다. 이 경우 특정 주소에서만 서비스 접근을 제한할 수 있습니다. 예를 들어 config 섹션을 설명하겠습니다.

경로 /var/puppet/config

*.domain.com 허용

192.168.0.* 허용

192.168.1.0/24 허용

*.wireless.domain.com 거부

그런 다음 리소스를 설명할 때 이 섹션을 참조합니다.

소스 => "puppet://server.domain.com/config/sshd_config"

콜론 앞에는 리소스 이름이 있습니다. 가장 간단한 경우에는 별칭이나 변수를 이름으로 지정할 수 있습니다. 별칭은 alias 지시문을 사용하여 설정됩니다. 파일의 전체 경로입니다. 더 복잡한 구성에서는

파일("/etc/passwd":

별칭 => 비밀번호

별칭을 만드는 또 다른 옵션은 다른 운영 체제를 처리해야 할 때 유용합니다. 예를 들어 sshd_config 파일을 설명하는 리소스를 생성해 보겠습니다.

파일(sshdconfig:

이름 => $operatingsystem ? (

솔라리스 => "/usr/local/etc/ssh/sshd_config",

기본값 => "/etc/ssh/sshd_config"

이 예에서 우리는 선택에 직면해 있습니다. Solaris용 파일은 별도로 지정되며, 다른 모든 파일의 경우 /etc/ssh/sshd_config 파일이 선택됩니다. 이제 이 리소스는 sshdconfig로 액세스할 수 있으며, 운영 체제에 따라 원하는 경로가 선택됩니다. 예를 들어, sshd 데몬이 실행 중이고 수신된 경우 새로운 파일, 서비스를 다시 시작해야 합니다.

보장 => 사실,

구독 => 파일

변수는 사용자 데이터를 작업할 때 자주 사용됩니다. 예를 들어, 사용자 홈 디렉터리의 위치를 ​​설명합니다.

$홈루트 = "/홈"

이제 특정 사용자의 파일에 다음과 같이 액세스할 수 있습니다.

$(홈루트)/$name

$name 매개변수는 사용자의 계정 이름으로 채워집니다. 어떤 경우에는 일부 유형에 대한 기본값을 정의하는 것이 편리합니다. 예를 들어, exec 유형의 경우 실행 파일을 찾아야 하는 디렉터리를 나타내는 경우가 많습니다.

Exec(경로 => "/usr/bin:/bin:/usr/sbin:/sbin")

여러 개의 중첩된 파일과 디렉터리를 가리켜야 하는 경우 recurse 매개변수를 사용할 수 있습니다.

파일("/etc/apache2/conf.d":

소스 => “puppet:// puppet://server.domain.com/config/apache/conf.d”,

재귀 => "참"

여러 리소스를 클래스나 정의로 결합할 수 있습니다. 클래스는 시스템이나 서비스에 대한 완전한 설명이며 별도로 사용됩니다.

"/etc/passwd": 소유자 => 루트, 그룹 => 루트, 모드 => 644;

"/etc/shadow": 소유자 => 루트, 그룹 => 루트, 모드 => 440

객체지향 언어와 마찬가지로 클래스도 재정의될 수 있습니다. 예를 들어, FreeBSD에서 이러한 파일의 그룹 소유자는 휠입니다. 따라서 리소스를 완전히 다시 작성하지 않기 위해 Linux 클래스를 상속할 새 클래스 freebsd를 생성해 보겠습니다.

freebsd 클래스는 Linux(

파일[“/etc/passwd”] ( 그룹 => 휠 );

파일[“/etc/shadow”] ( 그룹 => 휠 )

편의를 위해 모든 클래스를 별도의 파일에 배치할 수 있으며, 이는 include 지시문을 사용하여 연결할 수 있습니다. 정의는 여러 매개변수를 인수로 사용할 수 있지만 상속을 지원하지 않으며 재사용 가능한 객체를 설명해야 할 때 사용됩니다. 예를 들어 사용자의 홈 디렉터리와 새 계정을 만드는 데 필요한 명령을 정의해 보겠습니다.

user_homedir 정의($group, $fullname, $ingroups)(

사용자("$이름":

보장하다 => 현재,

코멘트 => "$fullname",

gid => "$그룹",

그룹 => $ingroups,

멤버십 => 최소,

쉘 => "/bin/bash",

집 => "/집/$이름",

필요 => 그룹[$group],

exec("$name 홈디렉터리":

명령 => “/bin/cp -R /etc/skel /home/$name; /bin/chown -R $name:$group /home/$name",

생성 => "/home/$name",

필요 => 사용자[$name],

이제 새로운 것을 만들려면 계정 user_homedir에 문의하세요.

user_homedir("sergej":

그룹 => "sergej",

전체 이름 => “Sergej Jaremchuk”,

그룹 내 => ["미디어", "관리자]

클래스와 같이 상속을 지원하는 노드에 대한 설명이 별도로 있습니다. 클라이언트가 Puppet 서버에 연결되면 해당 노드 섹션을 검색하여 이 컴퓨터에만 해당되는 설정을 제공합니다. 다른 모든 시스템을 설명하려면 노드 기본값을 사용할 수 있습니다. 모든 유형에 대한 설명은 "유형 참조" 문서에 나와 있으며, 최소한 Puppet 언어의 모든 기능을 이해하려면 반드시 읽어야 합니다. 다양한 방식특정 조건이 충족되는 경우(예: 구성 파일 변경)를 포함하여 지정된 명령을 실행하고, cron 작업, 사용자 자격 증명 및 그룹, 컴퓨터, 리소스 마운트, 서비스 시작 및 중지, 패키지 설치, 업데이트 및 제거, 작업 ~와 함께 SSH 키, Solaris 영역 등. 이것은 apt를 사용하여 배포판의 패키지 목록을 매일 2시간에서 4시간 사이에 업데이트하는 것이 얼마나 쉬운지입니다.

일정(매일:

기간 => 매일,

범위 =>

exec("/usr/bin/apt-get 업데이트":

일정 => 매일

해당 기간 동안의 업데이트는 각 시스템에서 한 번만 수행되며, 그 후에는 작업이 완료된 것으로 간주되어 클라이언트 컴퓨터에서 삭제됩니다. Puppet 언어는 조건, 함수, 배열, 주석 등과 같은 다른 친숙한 구조를 지원합니다.

꼭두각시 설치

Puppet에는 OpenSSL 지원 및 XMLRPC 라이브러리와 Faster 라이브러리가 포함된 Ruby(>= 1.8.1)가 필요합니다. http://reitivelabs.com/projects/facter]. 테스트 설치에 사용된 Ubuntu 7.04 저장소에는 강아지 패키지가 이미 포함되어 있습니다.

$ sudo apt-cache 검색 인형

puppet — 네트워크의 중앙 집중식 구성 관리

puppetmaster - 중앙 집중식 구성 관리 제어 데몬

설치 중에 필요한 모든 종속성 패키지(factor libopenssl-ruby libxmlrpc-ruby)가 설치됩니다.

$ sudo apt-get 설치 꼭두각시 puppetmaster

명령을 사용하여 Ruby 라이브러리의 가용성을 확인할 수 있습니다.

$ ruby ​​​​-ropenssl -e "puts:yep"

~$ ruby ​​​​-rxmlrpc/client -e "puts:yep"

오류가 수신되지 않으면 필요한 모든 것이 이미 포함되어 있는 것입니다. 원하는 시스템 구성을 설명하는 파일을 Puppet 용어로 매니페스트라고 합니다. 시작되면 데몬은 /etc/puppet/manifests/site.pp 파일을 읽으려고 시도하며 파일이 없으면 경고 메시지를 표시합니다. 테스트할 때 데몬이 오프라인 모드에서 작동하도록 지시할 수 있습니다. 이 경우 매니페스트가 필요하지 않습니다.

$ sudo /usr/bin/puppetmasterd --nonodes

필요한 경우 클래스 설명 등을 사용하여 다른 파일을 site.pp에 연결할 수 있습니다. 테스트 실행의 경우 이 파일에 가장 간단한 지침을 입력할 수 있습니다.

파일("/etc/sudoers":

소유자 => 루트,

그룹 => 루트,

서버와 클라이언트 모두에 대한 모든 구성 파일은 /etc/puppet에 있습니다. 위에서 설명한 fileserver.conf 파일은 선택 사항이며 Puppet이 파일 서버로도 작동하는 경우에만 사용됩니다. Ubuntu에서 이 파일은 /etc/puppet/files 하위 디렉터리를 내보냅니다. ssl 하위 디렉터리에는 클라이언트 연결 시 암호화에 사용되는 인증서와 키가 포함되어 있습니다. puppetmasterd를 처음 시작할 때 키가 자동으로 생성되며, 명령을 사용하여 수동으로 생성할 수 있습니다.

$ sudo /usr/bin/ puppetmasterd --mkusers.

puppetd.conf와 puppetmasterd.conf 파일은 유사합니다. 이는 클라이언트 시스템 및 서버의 데몬 작동에 대한 일부 매개변수를 나타냅니다. 클라이언트 파일은 puppetmasterd가 실행 중인 컴퓨터를 가리키는 서버 매개변수가 있는 경우에만 다릅니다.

서버 = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# 서버에 보고서를 보냅니다

모든 것을 수동으로 입력하지 않으려면 puppetd 자체를 사용하여 템플릿을 만들 수 있습니다.

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

마찬가지로 서버에서 site.pp를 만들 수 있습니다.

$ puppetd --genmanifest > /etc/puppet/manifests/site.pp

또 다른 파일인 tagmail.conf를 사용하면 보고서를 보낼 이메일 주소를 지정할 수 있습니다. 가장 간단한 경우에는 한 줄을 사용할 수 있습니다.

모두: [이메일 보호됨]

클라이언트가 서버에 연결하는 데 구성 파일이 충분하지 않습니다. 이렇게 하려면 인증서에도 서명해야 합니다. 먼저 클라이언트 시스템의 새 컴퓨터에 대해 서버에 알리려면 다음 명령을 입력하십시오.

$ sudo puppetd --server grinder.com --waitforcert 60 --test

정보: 인증서 요청 중

경고: 이 SSL 세션에서는 피어 인증서가 확인되지 않습니다.

주의사항: 인증서를 받지 못했습니다.

다른 줄이 반환되면 서버의 작동을 확인해야 합니다.

$ ps 보조 | 그렙 인형

꼭두각시 5779 0.0 1.4 27764 15404 ? Ssl 21:49 0:00 ruby ​​​​/usr/sbin/puppetmasterd

방화벽은 포트 8140에서의 연결을 허용해야 합니다.

서버에서는 서명이 필요한 인증서 목록을 받습니다.

$ sudo puppetca --list

nomad.grinder.com

그리고 클라이언트 인증서에 서명합니다.

$ sudo puppetca – nomad.grinder.com 서명

이제 클라이언트는 자유롭게 서버에 연결하여 설정을 받을 수 있습니다.

불행하게도 기사 내에서 Puppet의 모든 기능을 보여주는 것은 불가능합니다. 그러나 보시다시피 이는 다수의 시스템을 동시에 관리하는 데 따른 대부분의 문제를 해결할 수 있는 기능적이고 유연한 도구입니다. 업무 라인에 여러 시스템을 설정해야 하는 경우. 그리고 가장 중요한 것은 이 프로젝트가 작지만 지속적으로 성장하는 커뮤니티를 모으는 데 성공했다는 것입니다. 그러므로 좋은 아이디어가 죽거나 옆으로 치워지는 일이 없기를 바라자.

인형할 수 있는 크로스 플랫폼 구조입니다. 시스템 관리자코드를 사용하여 일반적인 작업을 수행합니다. 이 코드를 사용하면 새 프로그램 설치부터 파일 권한 확인, 사용자 계정 업데이트까지 다양한 작업을 수행할 수 있습니다. 인형시스템의 초기 설치뿐만 아니라 시스템의 전체 수명주기 동안 우수한 성능을 발휘합니다. 대부분의 경우에 인형클라이언트/서버 구성에 사용됩니다.

이 섹션에서는 설치 및 구성을 보여줍니다. 인형클라이언트/서버 구성에서. 이 간단한 예에서는 설치 방법을 보여줍니다. 아파치사용하여 인형.

설치

설치용 인형터미널에 입력:

Sudo apt-get install puppetmaster

클라이언트 컴퓨터에서 다음을 입력합니다.

Sudo apt-get 설치 꼭두각시

설정

꼭두각시를 설정하기 전에 항목을 추가할 수 있습니다. DNS CNAME을 위한 puppet.example.com, 어디 example.com- 이것은 귀하의 도메인입니다. 기본 클라이언트 인형 puppet.example.com의 DNS를 puppet 서버 이름으로 확인하세요( 퍼펫 마스터). DNS 사용에 대한 자세한 내용은 도메인 이름 서비스를 참조하세요.

DNS를 사용하지 않으려면 서버와 클라이언트의 /etc/hosts 파일에 항목을 추가할 수 있습니다. 예를 들어, /etc/hosts 파일에서 인형서버 추가:

127.0.0.1 localhost.localdomain localhost 꼭두각시 192.168.1.17 meercat02.example.com meercat02

매 인형클라이언트에서 서버에 대한 항목을 추가합니다.

192.168.1.16 meercat.example.com meercat 인형

IP 주소를 교체하고 도메인 이름예제에서 서버와 클라이언트의 현재 주소와 이름까지.

이제 다음을 위한 몇 가지 리소스를 설정해 보겠습니다. 아파치2. 파일 만들기 /etc/puppet/manifests/site.pp다음을 포함합니다:

패키지( "apache2": verify => 설치됨 ) 서비스( "apache2": verify => true, 활성화 => true, require => 패키지["apache2"] )

노드 "meercat02.example.com"(apache2 포함)

바꾸다 meercat02.example.com현재 이름으로 인형고객.

이 간단한 작업의 마지막 단계 인형서버가 서비스를 다시 시작하는 것입니다.

Sudo /etc/init.d/puppetmaster 재시작

지금 인형모든 것이 서버에 구성되어 있으며 이제 클라이언트를 구성할 차례입니다.

먼저 서비스를 구성해 보겠습니다. 인형에이전트를 실행합니다. /etc/default/puppet을 편집하여 값을 바꿉니다. 시작~에 예:

Sudo /etc/init.d/puppet start

다시 돌아가자 인형서버에서 다음 명령을 사용하여 클라이언트 인증서에 서명합니다.

Sudo puppetca --sign meercat02.example.com

확인하다 /var/log/syslog구성 오류가 있는 경우. 모든 것이 잘 되었다면 패키지 아파치2해당 종속성은 다음 위치에 설치됩니다. 인형고객.

이 예는 매우 간단하며 많은 기능과 이점을 보여주지 않습니다. 인형. 을 위한 추가 정보바라보다

세르게이 야렘추크

Puppet을 사용한 UNIX 시스템의 중앙 집중식 구성

다수의 UNIX 시스템을 관리하는 것은 편리하다고 할 수 없습니다. 하나의 매개변수를 변경하려면 관리자가 각 시스템에 접속해야 하며 스크립트는 부분적으로만 도움이 될 수 있으며 모든 상황에 도움이 될 수는 없습니다.

Windows 네트워크 관리자가 여전히 더 유리한 위치에 있다는 점을 인식해야 합니다. 그룹 정책 설정을 변경하는 것만으로도 충분하며, 얼마 후 최근에 설치된 운영 체제를 포함하여 네트워크의 모든 컴퓨터는 혁신에 대해 "학습"하게 됩니다. UNIX 개발의 오랜 기간을 되돌아보면 이와 같은 것이 결코 성공하지 못했다는 것을 알 수 있습니다. 운영 체제의 초기 설치에 도움이 되는 킥스타트와 같은 솔루션이 있지만 추가 개발에는 상당한 노력이 필요합니다. BladeLogic 및 OpsWare와 같은 상용 솔루션은 설정 자동화 문제를 부분적으로만 해결합니다. 주요 장점은 그래픽 인터페이스가 있다는 점이며 대규모 조직에서만 구매할 여유가 있습니다. 물론 무료 솔루션을 제공하는 프로젝트도 있지만, 존재하는 내내 대규모 커뮤니티를 만들 수는 없었습니다. 예를 들어 Cfengine은 관리자들 사이에서 그다지 인기가 없지만 Linux 외에도 *BSD, Windows 및 Mac OS X에서 사용할 수 있습니다. 이는 구성 생성이 상대적으로 복잡하기 때문일 수 있습니다. 작업을 설명할 때는 각 특정 시스템의 특성을 고려하고 명령을 실행할 때 작업 순서를 수동으로 제어해야 합니다. 즉, 관리자는 일부 시스템의 경우 adduser를 작성해야 하고 다른 시스템의 경우 useradd를 작성해야 하며 다른 시스템의 파일 위치를 고려해야 한다는 점을 기억해야 합니다. 이로 인해 명령을 작성하는 과정이 엄청나게 복잡해지며, 즉석에서 올바른 구성을 생성하는 것이 매우 어렵고 생성된 구성을 잠시 후에 읽는 것이 거의 불가능합니다. GPL 라이센스에도 불구하고 Cfengine은 본질적으로 모든 변경 사항을 제어하는 ​​1인 프로젝트이며 열린 사회를 구축하는 데 별로 관심이 없습니다. 결과적으로 Cfengine의 기능은 개발자에게는 상당히 만족스럽지만 다른 관리자에게는 오히려 골치 아픈 일이 됩니다. Cfengine을 개선하기 위해 제3자 개발자가 다양한 추가 기능을 만들었으나 이로 인해 상황이 악화되는 경우가 많았습니다. Cfengine용 여러 모듈의 작성자인 Luke Kanies는 결국 유사한 도구를 개발하기로 결정했지만 Cfengine의 많은 단점은 없었습니다.

인형의 특징

Cfengine과 마찬가지로 Puppet은 선언적 언어를 사용하여 작업을 설명하고 라이브러리를 구현하는 클라이언트-서버 시스템입니다. 클라이언트는 주기적으로(기본적으로 30분마다) 중앙 서버에 연결하여 최신 구성을 받습니다. 수신된 설정이 시스템 상태와 일치하지 않으면 실행되며, 필요한 경우 수행된 작업에 대한 보고서가 서버로 전송됩니다. 메시지 서버는 이를 syslog나 파일에 저장하고 RRD 그래프를 생성하여 지정된 이메일로 보낼 수 있습니다. 추가 트랜잭션 및 리소스 추상화 계층은 기존 설정 및 애플리케이션과의 최대 호환성을 제공하므로 세부 명령 및 파일 형식에 대한 구현 및 설명의 차이에 대해 걱정하지 않고 시스템 개체에 집중할 수 있습니다. 관리자는 객체 유형으로만 작업하고 Puppet은 나머지를 처리합니다. 따라서 패키지 유형은 약 17개의 패키지 시스템을 알고 있으며, 배포판이나 시스템의 버전 ​​정보를 기반으로 필요한 시스템을 자동으로 인식하며, 필요한 경우 패키지 관리자를 강제로 설정할 수 있습니다.

다른 시스템에서는 사용이 불가능한 경우가 많은 스크립트와 달리, 타사 관리자가 작성한 Puppet 구성은 대부분 다른 네트워크에서 문제 없이 작동합니다. Puppet CookBook에는 이미 36가지의 기성 레시피가 있습니다. Puppet은 현재 Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo 및 MySQL, LDAP와 같은 운영 체제 및 서비스를 공식적으로 지원합니다.

꼭두각시 언어

앞으로 나아가려면 먼저 언어의 기본 요소와 기능을 이해해야 합니다. 언어는 Puppet의 강점 중 하나입니다. 관리자가 관리할 리소스와 수행할 작업에 대해 설명합니다. 대부분의 유사한 솔루션과 달리 Puppet을 사용하면 언어를 통해 이기종 환경의 모든 시스템에 있는 모든 유사한 리소스에 대한 액세스를 단순화할 수 있습니다. 리소스 설명은 일반적으로 이름, 유형 및 속성으로 구성됩니다. 예를 들어, /etc/passwd 파일을 가리키고 해당 속성을 설정해 보겠습니다.

파일("/etc/passwd":

소유자 => 루트,

그룹 => 루트,

모드 => 644,

이제 서버에 연결하는 클라이언트는 /etc/passwd 파일을 복사하고 지정된 속성을 설정합니다. 하나의 규칙에 여러 리소스를 정의하고 세미콜론을 사용하여 구분할 수 있습니다. 하지만 서버에서 사용되는 구성 파일이 클라이언트 구성 파일과 다르거나 전혀 사용되지 않는 경우에는 어떻게 될까요? 예를 들어 VPN 연결을 설정할 때 이러한 상황이 발생할 수 있습니다. 이 경우 source 지시문을 사용하여 파일을 가리켜야 합니다. 여기에는 두 가지 옵션이 있습니다. 평소와 같이 다른 파일에 대한 경로를 지정할 수 있고 지원되는 두 가지 URI 프로토콜인 파일과 퍼펫을 사용할 수도 있습니다. 첫 번째 경우에는 외부 NFS 서버에 대한 링크가 사용되며, 두 번째 옵션에서는 리소스를 내보내는 Puppet 서버에서 NFS와 유사한 서비스가 시작됩니다. 후자의 경우 기본 경로는 puppet 루트 디렉터리(/etc/puppet)에 상대적입니다. 즉, puppet://server.domain.com/config/sshd_config 링크는 /etc/puppet/config/sshd_config 파일에 해당합니다. filebucket 지시문을 사용하여 이 디렉터리를 재정의할 수 있지만 /etc/puppet/fileserver.conf 파일에서 동일한 이름의 섹션을 사용하는 것이 더 정확합니다. 이 경우 특정 주소로만 서비스 접근을 제한할 수 있습니다. 예를 들어 구성 섹션을 설명하겠습니다.

경로 /var/puppet/config

*.domain.com 허용

127.0.0.1 허용

192.168.0.* 허용

192.168.1.0/24 허용

*.wireless.domain.com 거부

그런 다음 리소스를 설명할 때 이 섹션을 참조합니다.

소스 => "puppet://server.domain.com/config/sshd_config"

콜론 앞에는 리소스 이름이 있습니다. 가장 간단한 경우에는 파일의 전체 경로를 이름으로 지정할 수 있습니다. 보다 복잡한 구성에서는 별칭이나 변수를 사용하는 것이 더 좋습니다. 별칭은 alias 지시문을 사용하여 설정됩니다.

파일("/etc/passwd":

별칭 => passwd

별칭을 만드는 또 다른 옵션은 다른 운영 체제를 처리해야 할 때 유용합니다. 예를 들어 sshd_config 파일을 설명하는 리소스를 생성해 보겠습니다.

파일(sshdconfig:

이름 => $operatingsystem ? (

솔라리스 => "/usr/local/etc/ssh/sshd_config",

기본값 => "/etc/ssh/sshd_config"

이 예에서 우리는 선택에 직면해 있습니다. Solaris용 파일은 별도로 지정되며, 다른 모든 파일의 경우 /etc/ssh/sshd_config 파일이 선택됩니다. 이제 이 리소스는 sshdconfig로 액세스할 수 있으며, 운영 체제에 따라 원하는 경로가 선택됩니다. 예를 들어, sshd 데몬이 실행 중이고 새 파일이 수신되면 서비스를 다시 시작해야 함을 나타냅니다.

서비스(sshd:

=> true인지 확인하세요.

구독 => 파일

변수는 사용자 데이터를 작업할 때 자주 사용됩니다. 예를 들어, 사용자 홈 디렉터리의 위치를 ​​설명합니다.

$홈루트 = "/홈"

이제 다음과 같이 특정 사용자의 파일에 액세스할 수 있습니다.

$(홈루트)/$name

$name 매개변수는 사용자의 계정 이름으로 채워집니다. 어떤 경우에는 일부 유형에 대한 기본값을 정의하는 것이 편리합니다. 예를 들어, exec 유형의 경우 실행 파일을 찾아야 하는 디렉터리를 지정하는 것이 매우 일반적입니다.

실행( 경로 => "/usr/bin:/bin:/usr/sbin:/sbin" )

여러 개의 중첩된 파일과 디렉터리를 가리켜야 하는 경우 recurse 매개변수를 사용할 수 있습니다.

파일("/etc/apache2/conf.d":

출처 => "puppet:// puppet://server.domain.com/config/apache/conf.d",

재귀 => "참"

여러 리소스를 클래스나 정의로 결합할 수 있습니다. 클래스는 시스템이나 서비스에 대한 완전한 설명이며 별도로 사용됩니다.

클래스 리눅스 (

파일(

"/etc/passwd": 소유자 => 루트, 그룹 => 루트, 모드 => 644;

"/etc/shadow": 소유자 => 루트, 그룹 => 루트, 모드 => 440

객체지향 언어와 마찬가지로 클래스도 재정의될 수 있습니다. 예를 들어, FreeBSD에서 이러한 파일의 그룹 소유자는 휠입니다. 따라서 리소스를 완전히 다시 작성하지 않기 위해 Linux 클래스를 상속할 새 클래스 freebsd를 생성해 보겠습니다.

freebsd 클래스는 Linux(

파일["/etc/passwd"] ( 그룹 => 휠 );

파일["/etc/shadow"] ( 그룹 => 휠 )

편의를 위해 모든 클래스를 별도의 파일에 배치할 수 있으며, 이는 include 지시어를 사용하여 포함해야 합니다. 정의는 여러 매개변수를 인수로 사용할 수 있지만 상속을 지원하지 않으며 재사용 가능한 객체를 설명해야 할 때 사용됩니다. 예를 들어, 사용자의 홈 디렉터리와 새 계정을 만드는 데 필요한 명령을 정의해 보겠습니다.

user_homedir 정의($group, $fullname, $ingroups)(

사용자("$이름":

보장 => 존재,

댓글 => "$fullname",

기드 => "$그룹",

그룹 => $ingroups,

회원 => 최소,

쉘 => "/bin/bash",

집 => "/집/$이름",

필요 => 그룹[$group],

Exec("$name 홈디렉터리":

명령 => "/bin/cp -R /etc/skel /home/$name; /bin/chown -R $name:$group /home/$name",

생성 => "/home/$name",

필요 => 사용자[$name],

이제 새 계정을 만들려면 user_homedir에 문의하세요.

user_homedir("sergej":

그룹 => "sergej",

전체 이름 => "Sergej Jaremchuk",

그룹 내 => ["미디어", " 관리자]

클래스뿐만 아니라 상속을 지원하는 노드에 대한 별도의 설명이 있습니다. 클라이언트가 Puppet 서버에 연결되면 해당 노드 섹션을 검색하여 이 컴퓨터에만 해당되는 설정을 제공합니다. 다른 모든 시스템을 설명하려면 노드 기본값을 사용할 수 있습니다. 모든 유형에 대한 설명은 "유형 참조" 문서에 나와 있으며, 최소한 Puppet 언어의 모든 기능을 이해하려면 반드시 읽어야 합니다. 다양한 유형을 사용하면 특정 조건이 충족되는 경우(예: 구성 파일 변경), cron 작업, 사용자 자격 증명 및 그룹, 컴퓨터, 리소스 마운트, 서비스 시작 및 중지, 패키지 설치, 업데이트 및 제거를 포함하여 지정된 명령을 실행할 수 있습니다. , SSH 키, Solaris 영역 등을 사용하여 작업합니다. 이것은 apt를 사용하여 배포판의 패키지 목록이 매일 2~4시간 사이에 업데이트되도록 쉽게 강제할 수 있는 방법입니다.

일정(매일:

기간 => 매일,

범위 =>

exec("/usr/bin/apt-get 업데이트":

일정 => 매일

해당 기간 동안의 업데이트는 각 시스템에서 한 번만 수행되며, 그 후에는 작업이 완료된 것으로 간주되어 클라이언트 컴퓨터에서 삭제됩니다. Puppet 언어는 조건, 함수, 배열, 주석 등과 같은 다른 친숙한 구조를 지원합니다.

꼭두각시 설치

Puppet에는 OpenSSL 지원 및 XMLRPC 라이브러리와 Faster 라이브러리가 포함된 Ruby(버전 1.8.1 이상)가 필요합니다. 테스트 설치에 사용된 Ubuntu 7.04 저장소에는 강아지 패키지가 이미 포함되어 있습니다.

$ sudo apt-cache 검색 인형

~$ ruby ​​​​-rxmlrpc/client -e "puts:yep"

오류가 수신되지 않으면 필요한 모든 것이 이미 포함되어 있는 것입니다. 원하는 시스템 구성을 설명하는 파일을 Puppet 용어로 매니페스트라고 합니다. 시작되면 데몬은 /etc/puppet/manifests/site.pp 파일을 읽으려고 시도하며 파일이 없으면 경고 메시지를 표시합니다. 테스트할 때 데몬이 매니페스트가 필요하지 않은 독립형 모드에서 작동하도록 지시할 수 있습니다.

$ sudo /usr/bin/puppetmasterd --nonodes

필요한 경우 클래스 설명 등을 사용하여 다른 파일을 site.pp에 연결할 수 있습니다. 테스트 실행의 경우 이 파일에 가장 간단한 지침을 입력할 수 있습니다.

클래스 sudo (

파일("/etc/sudoers":

소유자 => 루트,

그룹 => 루트,

모드 => 440,

노드 기본값(

sudo 포함

서버와 클라이언트 모두의 모든 구성 파일은 /etc/puppet에 있습니다. 이미 설명한 fileserver.conf 파일은 선택 사항이며 Puppet이 파일 서버로도 작동하는 경우에만 사용됩니다. Ubuntu에서 이 파일은 /etc/puppet/files 하위 디렉터리를 내보냅니다. ssl 하위 디렉터리에는 클라이언트 연결 시 암호화에 사용되는 인증서와 키가 포함되어 있습니다. puppetmasterd를 처음 시작할 때 키가 자동으로 생성됩니다. 다음 명령을 사용하여 수동으로 생성할 수 있습니다.

$ sudo /usr/bin/puppetmasterd --mkusers

puppetd.conf와 puppetmasterd.conf 파일은 유사합니다. 이는 클라이언트 시스템 및 서버의 데몬 작동에 대한 일부 매개변수를 나타냅니다. 클라이언트 파일은 puppetmasterd가 실행 중인 컴퓨터를 가리키는 server 매개 변수가 있는 경우에만 다릅니다.

서버 = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# 서버에 보고서를 보냅니다

신고 = 사실

모든 것을 수동으로 입력하지 않으려면 puppetd 자체를 사용하여 템플릿을 만들 수 있습니다.

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

마찬가지로 서버에서 site.pp를 만들 수 있습니다.

$ puppetd --genmanifest > /etc/puppet/manifests/site.pp

또 다른 파일인 tagmail.conf를 사용하면 보고서를 보낼 이메일 주소를 지정할 수 있습니다. 가장 간단한 경우에는 다음 한 줄을 사용할 수 있습니다.

모두: [이메일 보호됨]

클라이언트가 서버에 연결하는 데 구성 파일이 충분하지 않습니다. 이렇게 하려면 인증서에도 서명해야 합니다.

먼저 서버에 새 컴퓨터에 대해 알리려면 클라이언트 시스템에 다음 명령을 입력합니다.

$ sudo puppetd --server grinder.com --waitforcert 60 –test

방화벽은 포트 8140에서의 연결을 허용해야 합니다.

서버에서는 서명이 필요한 인증서 목록을 얻습니다.

$ sudo puppetca – 목록

그리고 클라이언트 인증서에 서명합니다.

$ sudo puppetca – nomad.grinder.com 서명

이제 클라이언트는 자유롭게 서버에 연결하여 설정을 받을 수 있습니다.

안타깝게도 기사 내에서 Puppet의 모든 기능을 보여주는 것은 불가능합니다. 그러나 보시다시피 이는 다수의 시스템을 동시에 관리하는 데 따른 대부분의 문제를 해결할 수 있는 기능적이고 유연한 도구입니다. 그리고 가장 중요한 것은 이 프로젝트가 작지만 지속적으로 성장하는 커뮤니티를 모으는 데 성공했다는 것입니다. 그러므로 좋은 아이디어가 죽거나 옆으로 치워지는 일이 없기를 바라자.

행운을 빌어요!

1. BladeLogic 프로젝트 웹사이트 – http://www.bladelogic.com.
2. OpsWare 프로젝트 웹사이트는 http://www.opsware.com입니다.
3. Cfengine 프로젝트 웹사이트는 http://www.cfengine.org이다.
4. Puppet 프로젝트 웹사이트는 http://reitivelabs.com/projects/puppet입니다.
5. 꼭두각시 요리책 - http://www.reitivelabs.com/trac/puppet/tagspuppet%2Crecipe.
6. 더 빠른 라이브러리 –