키보드 단축키 - 다양한 조합 할당

키보드의 Win, Shift, Space, Backspace, Num Lock, Ctrl, Fn, Enter, Alt, Insert 버튼은 어디에 있습니까?

디스크 매개변수, 마킹 중앙 구멍이란

개인 계정 "Bashinformsvyaz Basinformsvyaz 개인 계정 채널 추가

주문형 정보학의 문제 해결

Lada Largus의 신호가 작동하지 않습니다.

인형 설치 중. Master of puppets: Puppet 원격 구성 관리 시스템 설치 및 구성

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

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

꼭두각시 오픈 소스 - 완전히 무료 버전
Puppet Enterprise는 최대 10개의 서버에 대해 무료이며 라이선스가 필요합니다.

최신 배포판 패키지에 포함된 Puppet 오픈 소스 서버 및 에이전트 설치를 고려하십시오. 다음은 Ubuntu 12.04 Precise Pangolin에 대한 것입니다.

서버 부분인형이라고 한다 꼭두각시 주인, 설치를 시작하겠습니다.

:~# apt-get puppetmaster 설치

이제 클라이언트:

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

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

서버=puppet.local 보고서=true pluginsync=false

초기 단계에서는 pluginsync를 비활성화하는 것이 좋습니다.

인증서 요청을 생성하도록 꼭두각시 클라이언트를 시작하겠습니다.

:~# puppetd --verbose --test 정보: linux.local용 새 SSL 키 생성 info: ca용 인증서 캐싱 정보: linux.local용 새 SSL 인증서 요청 생성 정보: 인증서 요청 지문(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 info: linux.local용 캐싱 인증서 정보: 플러그인 정보 검색: Caching certificate_revocation_list for ca 정보: linux.local용 캐싱 카탈로그 정보: 구성 버전 "1356278451" 적용 정보: 상태 파일 생성 / var/lib/puppet/state/state.yaml 알림: 0.02초 만에 카탈로그 실행 완료

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

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

:~# 꼭두각시 적용 --configprint 모듈 경로 /etc/puppet/modules:/usr/share/puppet/modules

모듈에 대한 디렉토리 생성

:~# cd /etc/puppet/modules :~# mkdir 호스트; CD 호스트; mkdir 매니페스트; CD 매니페스트

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

클래스 호스트 ( # puppet.local 호스트 ( "puppet.local": sure => "present", target => "/etc/hosts", ip => "192.168.0.1", host_aliases => "puppet", ) # linux.local 호스트( "linux.local": 확인 => "현재", 대상 => "/etc/hosts", ip => "192.168.0.2", host_aliases => "linux", ) )

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

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

서버에서 매니페스트 확인:

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

클라이언트에서:

:~# ll /etc/hosts rw-r--r-- 1 root root 290 Dec 16 19:10 /etc/hosts :~# puppetd --verbose --test info: 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 서버를 폴링하고 필요한 경우 그에 따라 시스템을 조정합니다.

제어 큰 금액유닉스 시스템은 편리하다고 할 수 없습니다. 하나의 매개변수를 변경하려면 관리자가 각 시스템에 액세스해야 하며 스크립트는 모든 상황에서가 아니라 부분적으로만 도움이 될 수 있습니다.

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

꼭두각시 기능

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

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

꼭두각시 언어

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

파일("/etc/passwd":

소유자 => 루트,

그룹 => 루트,

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

이름 => $ 운영 체제 ? (

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

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

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

보장 => 참,

구독 => 파일

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

$homeroot = "/홈"

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

$(홈루트)/$이름

$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에서 이러한 파일을 소유하는 그룹은 wheel입니다. 따라서 리소스를 완전히 다시 작성하지 않도록 새로운 수업 Linux 클래스를 상속할 freebsd:

클래스 freebsd는 Linux를 상속합니다(

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

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

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

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

사용자("$이름":

확인 => 존재,

comment => "$fulname",

gid => "$그룹",

그룹 => $ingroups,

회원 => 최소,

쉘 => "/bin/bash",

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

필요 => 그룹[$그룹],

exec("$이름 홈디렉토리":

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

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

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

이제 새로 만들기 위해 계정 user_homedir을 참조하십시오.

user_homedir("sergej":

그룹 => "세르게이",

전체 이름 => "Sergej Jaremchuk",

ingroups => ["미디어", " 관리자]

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

일정(매일:

기간 => 매일,

범위 =>

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

일정 => 매일

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

꼭두각시 설치

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

$ sudo apt-cache 검색 꼭두각시

puppet - 네트워크를 위한 중앙 집중식 구성 관리

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

설치는 패키지의 모든 필수 종속성을 설치합니다: factor libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get puppet puppetmaster 설치

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

$ ruby -ropenssl -e "넣다:예"

~$ ruby -rxmlrpc/client -e "입력:예"

오류가 수신되지 않으면 필요한 모든 것이 이미 포함된 것입니다. 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

실행 디렉토리 = /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 세션에서 피어 인증서가 확인되지 않습니다.

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

다른 문자열이 반환되면 서버를 확인해야 합니다.

$ 추신 보조 | 그렙 인형

꼭두각시 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 --sign nomad.grinder.com

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

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

세르게이 야렘추크

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

많은 수의 UNIX 시스템을 관리하는 것은 편리하지 않습니다. 하나의 매개변수를 변경하려면 관리자가 각 시스템에 액세스해야 하며 스크립트는 모든 상황에서가 아니라 부분적으로만 도움이 될 수 있습니다.

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

꼭두각시 기능

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

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

꼭두각시 언어

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

파일("/etc/passwd":

소유자 => 루트,

그룹 => 루트,

모드 => 644,

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

경로 /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":

별칭 => 암호

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

파일(sshdconfig:

이름 => $ 운영 체제 ? (

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

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

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

서비스(sshd:

보장 => 참,

구독 => 파일

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

$homeroot = "/홈"

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

$(홈루트)/$이름

$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에서 이러한 파일을 소유하는 그룹은 wheel입니다. 따라서 리소스를 완전히 다시 작성하지 않기 위해 linux 클래스를 상속할 새로운 freebsd 클래스를 생성해 보겠습니다.

클래스 freebsd는 Linux를 상속합니다(

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

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

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

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

사용자("$이름":

확인 => 존재,

주석 => "$fulname",

gid => "$그룹",

그룹 => $ingroups,

회원 => 최소,

쉘 => "/bin/bash",

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

필요 => 그룹[$group],

Exec("$이름 홈디렉토리":

명령 => "/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",

Ingroups => ["미디어", "관리자]

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

일정(매일:

기간 => 매일,

범위 =>

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

일정 => 매일

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

꼭두각시 설치

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

$ sudo apt-cache 검색 꼭두각시

~$ ruby -rxmlrpc/client -e "입력:예"

네

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

$ sudo /usr/bin/puppetmasterd --nonodes

클래스 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

실행 디렉토리 = /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 --list

nomad.grinder.com

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

$ sudo puppetca --sign nomad.grinder.com

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

아쉽게도 이 글의 한계 내에서 퍼펫의 모든 가능성을 보여주는 것은 불가능합니다. 그러나 보시다시피 이것은 많은 수의 시스템을 동시에 관리하는 대부분의 작업을 해결할 수 있는 기능적이고 유연한 도구입니다. 그리고 가장 중요한 것은 프로젝트가 작지만 지속적으로 성장하는 커뮤니티를 모을 수 있었다는 것입니다. 따라서 좋은 아이디어가 죽거나 옆으로 넘어가는 일이 없기를 바랍니다.

행운을 빕니다!

BladeLogic 프로젝트 사이트는 http://www.bladelogic.com입니다.
OpsWare 프로젝트 사이트는 http://www.opsware.com입니다.
Cfengine 프로젝트 사이트는 http://www.cfengine.org입니다.
Puppet 프로젝트 사이트는 http://reductivelabs.com/projects/puppet입니다.
인형 요리책 - http://www.reductivelabs.com/trac/puppet/tagspuppet%2Crecipe.
더 빠른 라이브러리 -

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

요구 사항

꼭두각시 설치(마스터 및 에이전트). 이에 대한 추가 정보 -.
Puppet 에이전트 노드를 제공하기 위해 하나 이상의 Ubuntu 14.04 가상 서버를 생성하는 기능.

꼭두각시 코드 기본 사항

자원

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

사용자("미첼":
확인 => 존재,
아이디 => "1000",
gid => "1000",
쉘 => "/bin/bash",
집 => "/집/미첼"
}

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

resource_type("리소스 이름"
속성 => 값
...
}

모든 Puppet 리소스 유형을 보려면 다음 명령을 입력합니다.

꼭두각시 자원 --types

이 가이드에서 리소스 유형에 대해 자세히 알아보세요.

선언문

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

클래스

기존 프로그래밍 언어와 마찬가지로 클래스는 오케스트레이션의 일부를 구성하고 재사용할 책임이 있습니다.

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

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

클래스 example_class(
...
암호
...
}

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

클래스 선언은 특정 클래스가 호출되는 코드의 위치입니다. 클래스를 선언함으로써 Puppet은 해당 코드를 처리합니다.

클래스 선언은 일반적이며 리소스 유형에 따라 다릅니다.

include 키워드를 사용하여 일반 클래스 선언이 코드에 추가됩니다.

example_class 포함

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

클래스( "example_class": )

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

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

모듈

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

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

매니페스트 쓰기

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

그래서 오케스트레이션을 하려면 우분투 서버 14.04에 LAMP 스택을 설치하고 다음 작업을 위한 리소스가 필요합니다.

apache2 패키지를 설치합니다.
apache2 서비스를 시작합니다.
패키지 설치 MySQL 서버, mysql-서버.
mysql 서비스를 시작합니다.
php5 패키지 설치
PHP 테스트 스크립트, info.php 만들기.
각 패키지를 설치하기 전에 apt 인덱스를 업데이트하십시오.

아래에서 이 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-server 설치
패키지("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 => 패키지["apache2"], # 패키지 "apache2" 요청
}

매니페스트 애플리케이션

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

sudo 꼭두각시 적용 --test

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

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

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

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

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

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

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

모듈 만들기

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

cd /etc/puppet/modules
sudo mkdir -p 램프/매니페스트

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

sudo vi 램프/매니페스트/init.pp

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

수업 램프(
}

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

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

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

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

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

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

에 가능성이 가장 높음 이 순간파일이 비어 있습니다. 다음 줄을 추가하십시오.

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

메모: 램프-1을 스택을 설치하려는 Puppet 에이전트의 호스트 이름으로 바꿉니다.

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

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

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

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

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

sudo 인형 에이전트 --test

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

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

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

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

MySQL 모듈 옵션을 전달할 수도 있습니다.

info.php를 올바른 위치에 복사할 리소스를 추가합니다. 소스 매개변수를 사용하십시오. 노드 블록에 다음 줄을 추가합니다.

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

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

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 인형 에이전트 --test

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

http://lamp_1_public_IP/info.php

결론

이제 Puppet 모듈 및 매니페스트에 대한 기본적인 이해가 생겼습니다. 간단한 매니페스트와 모듈을 직접 만들어보십시오.

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

태그: ,

얼마 전 잡지의 페이지에서 우리는 생활을 크게 단순화하는 UNIX 시스템용 Cfengine 원격 구성 관리 시스템을 고려했습니다. 시스템 관리자세트를 설정하는 작업을 자동화하여 네트워크 노드. 하지만 Cfengine이 아무리 편리하다 해도 Puppet이라는 시스템이 결여되어 있는 단점이 많다.

UNIX 유형 운영 체제를 실행하는 100~2대의 시스템 상태를 유지 관리하는 시스템 관리자 역할을 하고 있다고 상상해 보십시오. 각각은 튜닝, 주기적 업데이트 및 모니터링이 필요하지만 대부분이 유사한 기능을 수행한다고 가정합니다.

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

스크립트는 각 작업에 맞게 조정하기 위해 지속적으로 수정되어야 합니다. 스크립트는 운영 체제와 버전의 차이를 고려해야 하며 작업 시스템에 적용되기 전에 오랫동안 디버깅해야 합니다. 일반적으로 comme il faut가 아닙니다. 정답은 소위 원격 구성 관리 시스템을 사용하는 것입니다. 그 중 가장 유명한 것은 개방형 시스템인 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 puppet 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
# Facter 도구의 위치,
# OS에 대한 정보를 얻기 위해 사용
사실경로=$vardir/lib/factor
# 플러그인 동기화
# (서버에 설치된 플러그인 - 클라이언트에 복사됨)
플러그인싱크=참
# 템플릿이 있는 디렉토리(아래에서 이에 대해 읽어보세요)
templatedir=$confdir/템플릿
# 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
# echo "" >> /etc/puppet/puppet.conf
# echo "server=puppet-server.com" >> /etc/puppet/puppet.conf
#출구

클라이언트 시작:

$ sudo /etc/init.d/인형 시작

상태 설명 언어

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

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

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

파일 형식의 경우 이름은 파일의 경로와 동일하지만 일부 다른 형식의 경우 이름이 임의적일 수 있습니다. 소유자 => "루트" 행은 소유자 속성을 루트로 설정합니다. 즉, 지정된 파일은 관리자가 소유해야 함을 의미합니다.

각 리소스 유형에는 수정 가능한 고유한 속성 집합이 있으며 모든 리소스에서 사용할 수 있는 특수 메타 속성이 있습니다. 리소스의 중요한 특성 중 하나는 리소스에 연결할 수 있는 능력입니다. 이것은 종속성 체인을 형성하는 데 사용할 수 있습니다. 다음 항목은 /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(
패키지("nginx":
확인 => 설치
}
서비스("nginx":
확인 => 실행,
필요 => 패키지["nginx"],
}
}

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

# vi /etc/puppet/manifests/site.pp
서비스("오징어":
확인 => 실행,
필요 => 클래스["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
케이스 $operatingsystem(
redhat: ( 서비스 ( "httpd": 확인 => 실행 중))
데비안: ( 서비스 ( "apache": 확인 => 실행 중))
기본값: ( 서비스( "apache2": 확인 =>
달리기))
}

이 코드는 운영 체제에 따라 서비스 유형 리소스에 대해 서로 다른 옵션을 정의합니다(서비스 이름은 리눅스 배포판다를 수 있으므로 Puppet이 시작해야 하는 서비스는 각각에 대해 개별적으로 지정해야 합니다.

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

파일 서버

추가 파일을 머신에 복사하지 않고는 많은 원격 관리 작업을 완료할 수 없습니다. 사전 준비된 구성, 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":
소스 => "인형://httpd/httpd.conf",
모드 => 644,
}

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

결론

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

정보

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

연결

http://docs.puppetlabs.com - 꼭두각시 문서
http://docs.puppetlabs.com/guides/language_tutorial.html - 전체 설명꼭두각시 언어
http://docs.puppetlabs.com/references/stable/type.html - 리소스 유형

인형 설치 중. Master of puppets: Puppet 원격 구성 관리 시스템 설치 및 구성

꼭두각시 기능

꼭두각시 언어

꼭두각시 설치

요구 사항

꼭두각시 코드 기본 사항

자원

선언문

클래스

모듈

매니페스트 쓰기

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

매니페스트 만들기

매니페스트 애플리케이션

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

모듈 만들기

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

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

결론

인형?

설치

상태 설명 언어

인기 있는 Puppet 리소스 유형

파일 서버

결론

정보

연결

관련 출판물