Puppet은 구성 관리 시스템입니다. 호스트를 원하는 상태로 만들고 이 상태를 유지하는 데 사용됩니다.

저는 Puppet과 함께 일한 지 XNUMX년이 넘었습니다. 이 텍스트는 기본적으로 공식 문서의 핵심 사항을 번역하고 순서를 변경한 편집본이므로 초보자가 Puppet의 본질을 빠르게 이해할 수 있습니다.

기본 정보

Puppet의 운영 체제는 클라이언트-서버이지만 제한된 기능으로 서버리스 작업도 지원합니다.

작업의 풀 모델이 사용됩니다. 기본적으로 XNUMX분마다 한 번씩 클라이언트가 서버에 연결하여 구성을 적용합니다. Ansible로 작업한 경우 다른 푸시 모델을 사용합니다. 관리자가 구성 적용 프로세스를 시작하지만 클라이언트 자체는 아무 것도 적용하지 않습니다.

네트워크 통신 중에는 양방향 TLS 암호화가 사용됩니다. 서버와 클라이언트는 자체 개인 키와 해당 인증서를 갖습니다. 일반적으로 서버는 클라이언트에 대한 인증서를 발급하지만 원칙적으로 외부 CA를 사용할 수도 있습니다.

선언문 소개

꼭두각시 용어로 인형 서버에 연결하다 노드 (노드). 노드 구성이 작성되었습니다. 선언문에서 특별한 프로그래밍 언어 - Puppet DSL.

Puppet DSL은 선언적 언어입니다. 이는 개별 리소스 선언 형식으로 원하는 노드 상태를 설명합니다. 예를 들면 다음과 같습니다.

• 파일이 존재하며 특정 콘텐츠가 있습니다.
• 패키지가 설치되었습니다.
• 서비스가 시작되었습니다.

리소스는 상호 연결될 수 있습니다.

• 종속성이 있으며 리소스가 사용되는 순서에 영향을 미칩니다.
  예를 들어, "먼저 패키지를 설치한 다음 구성 파일을 편집한 다음 서비스를 시작합니다."
• 알림이 있습니다. 리소스가 변경된 경우 구독한 리소스에 알림을 보냅니다.
  예를 들어 구성 파일이 변경되면 서비스를 자동으로 다시 시작할 수 있습니다.

또한 Puppet DSL에는 함수와 변수는 물론 조건문과 선택기도 있습니다. EPP 및 ERB 등 다양한 템플릿 메커니즘도 지원됩니다.

Puppet은 Ruby로 작성되었으므로 많은 구성과 용어가 Ruby에서 가져왔습니다. Ruby를 사용하면 Puppet을 확장할 수 있습니다. 즉, 복잡한 논리, 새로운 유형의 리소스, 기능을 추가할 수 있습니다.

Puppet이 실행되는 동안 서버의 각 특정 노드에 대한 매니페스트가 디렉터리로 컴파일됩니다. 디렉토리 함수, 변수 및 조건문 확장의 값을 계산한 후 리소스와 그 관계의 목록입니다.

구문 및 코드 스타일

제공된 예제가 충분하지 않은 경우 구문을 이해하는 데 도움이 되는 공식 문서 섹션은 다음과 같습니다.

• 다양한 언어 구성의 구문.
• 리소스 구문.
• 노드를 설명하는 구문입니다.

매니페스트의 예는 다음과 같습니다.

# Комментарии пишутся, как и много где, после решётки.
#
# Описание конфигурации ноды начинается с ключевого слова node,
# за которым следует селектор ноды — хостнейм (с доменом или без)
# или регулярное выражение для хостнеймов, или ключевое слово default.
#
# После этого в фигурных скобках описывается собственно конфигурация ноды.
#
# Одна и та же нода может попасть под несколько селекторов. Про приоритет
# селекторов написано в статье про синтаксис описания нод.
node 'hostname', 'f.q.d.n', /regexp/ {
  # Конфигурация по сути является перечислением ресурсов и их параметров.
  #
  # У каждого ресурса есть тип и название.
  #
  # Внимание: не может быть двух ресурсов одного типа с одинаковыми названиями!
  #
  # Описание ресурса начинается с его типа. Тип пишется в нижнем регистре.
  # Про разные типы ресурсов написано ниже.
  #
  # После типа в фигурных скобках пишется название ресурса, потом двоеточие,
  # дальше идёт опциональное перечисление параметров ресурса и их значений.
  # Значения параметров указываются через т.н. hash rocket (=>).
  resource { 'title':
    param1 => value1,
    param2 => value2,
    param3 => value3,
  }
}

들여쓰기와 줄 바꿈은 매니페스트의 필수 부분은 아니지만 권장되는 부분은 있습니다. 스타일 가이드. 요약:

• XNUMX칸 들여쓰기, 탭은 사용되지 않습니다.
• 중괄호는 공백으로 구분되지만 콜론은 공백으로 구분되지 않습니다.
• 마지막 매개변수를 포함하여 각 매개변수 뒤에는 쉼표가 표시됩니다. 각 매개변수는 별도의 줄에 있습니다. 매개변수가 없고 매개변수가 하나인 경우에는 예외가 있습니다. 쉼표 없이 한 줄에 쓸 수 있습니다(예: resource { 'title': } и resource { 'title': param => value }).
• 매개변수의 화살표는 동일한 레벨에 있어야 합니다.
• 자원 관계 화살표가 앞에 표시됩니다.

pappetserver의 파일 위치

자세한 설명을 위해 “루트 디렉터리”라는 개념을 소개하겠습니다. 루트 디렉터리는 특정 노드에 대한 Puppet 구성이 포함된 디렉터리입니다.

루트 디렉터리는 Puppet 버전과 사용되는 환경에 따라 다릅니다. 환경은 별도의 디렉터리에 저장되는 독립적인 구성 집합입니다. 일반적으로 git과 함께 사용되며, 이 경우 환경은 git 브랜치에서 생성됩니다. 따라서 각 노드는 하나의 환경 또는 다른 환경에 위치합니다. 이는 노드 자체에서 구성하거나 다음 기사에서 설명할 ENC에서 구성할 수 있습니다.

• 세 번째 버전("old Puppet")에서 기본 디렉터리는 다음과 같습니다. /etc/puppet. 환경 사용은 선택 사항입니다. 예를 들어 이전 Puppet에서는 환경을 사용하지 않습니다. 환경이 사용되는 경우 일반적으로 다음 위치에 저장됩니다. /etc/puppet/environments, 루트 디렉터리는 환경 디렉터리가 됩니다. 환경을 사용하지 않는 경우 루트 디렉터리가 기본 디렉터리가 됩니다.
• 네 번째 버전(“new Puppet”)부터 환경 사용이 필수가 되었으며 기본 디렉터리가 다음으로 이동되었습니다. /etc/puppetlabs/code. 따라서 환경은 다음 위치에 저장됩니다. /etc/puppetlabs/code/environments, 루트 디렉터리는 환경 디렉터리입니다.

루트 디렉터리에 하위 디렉터리가 있어야 합니다. manifests, 노드를 설명하는 하나 이상의 매니페스트가 포함되어 있습니다. 또한 하위 디렉터리도 있어야 합니다. modules, 모듈이 포함되어 있습니다. 조금 후에 어떤 모듈이 있는지 알려 드리겠습니다. 또한 이전 Puppet에는 하위 디렉터리도 있을 수 있습니다. files, 여기에는 노드에 복사하는 다양한 파일이 포함되어 있습니다. 새 Puppet에서는 모든 파일이 모듈에 배치됩니다.

매니페스트 파일의 확장자는 다음과 같습니다. .pp.

몇 가지 전투 사례

노드 및 해당 리소스에 대한 설명

노드에서 server1.testdomain 파일을 생성해야 합니다 /etc/issue 내용이 있는 Debian GNU/Linux n l. 파일은 사용자 및 그룹이 소유해야 합니다. root, 액세스 권한은 다음과 같아야 합니다. 644.

우리는 선언문을 작성합니다:

node 'server1.testdomain' {   # блок конфигурации, относящийся к ноде server1.testdomain
    file { '/etc/issue':   # описываем файл /etc/issue
        ensure  => present,   # этот файл должен существовать
        content => 'Debian GNU/Linux n l',   # у него должно быть такое содержимое
        owner   => root,   # пользователь-владелец
        group   => root,   # группа-владелец
        mode    => '0644',   # права на файл. Они заданы в виде строки (в кавычках), потому что иначе число с 0 в начале будет воспринято как записанное в восьмеричной системе, и всё пойдёт не так, как задумано
    }
}

노드의 리소스 간 관계

노드에서 server2.testdomain nginx가 실행 중이어야 하며 이전에 준비된 구성으로 작업해야 합니다.

문제를 분해해 보겠습니다.

• 패키지를 설치해야 합니다. nginx.
• 구성 파일을 서버에서 복사해야 합니다.
• 서비스가 실행되어야 합니다. nginx.
• 구성이 업데이트되면 서비스를 다시 시작해야 합니다.

우리는 선언문을 작성합니다:

node 'server2.testdomain' {   # блок конфигурации, относящийся к ноде server2.testdomain
    package { 'nginx':   # описываем пакет nginx
        ensure => installed,   # он должен быть установлен
    }
  # Прямая стрелка (->) говорит о том, что ресурс ниже должен
  # создаваться после ресурса, описанного выше.
  # Такие зависимости транзитивны.
    -> file { '/etc/nginx':   # описываем файл /etc/nginx
        ensure  => directory,   # это должна быть директория
        source  => 'puppet:///modules/example/nginx-conf',   # её содержимое нужно брать с паппет-сервера по указанному адресу
        recurse => true,   # копировать файлы рекурсивно
        purge   => true,   # нужно удалять лишние файлы (те, которых нет в источнике)
        force   => true,   # удалять лишние директории
    }
  # Волнистая стрелка (~>) говорит о том, что ресурс ниже должен
  # подписаться на изменения ресурса, описанного выше.
  # Волнистая стрелка включает в себя прямую (->).
    ~> service { 'nginx':   # описываем сервис nginx
        ensure => running,   # он должен быть запущен
        enable => true,   # его нужно запускать автоматически при старте системы
    }
  # Когда ресурс типа service получает уведомление,
  # соответствующий сервис перезапускается.
}

이 작업을 수행하려면 Puppet 서버에 대략 다음과 같은 파일 위치가 필요합니다.

/etc/puppetlabs/code/environments/production/ # (это для нового Паппета, для старого корневой директорией будет /etc/puppet)
├── manifests/
│   └── site.pp
└── modules/
    └── example/
        └── files/
            └── nginx-conf/
                ├── nginx.conf
                ├── mime.types
                └── conf.d/
                    └── some.conf

리소스 유형

Полный список поддерживаемых типов ресурсов находится 문서에서, 여기에서는 실제로 대부분의 문제를 해결하는 데 충분한 다섯 가지 기본 유형을 설명하겠습니다.

파일

파일, 디렉터리, 심볼릭 링크, 해당 콘텐츠 및 액세스 권한을 관리합니다.

매개 변수 :

• 리소스 이름 — 파일 경로(선택 사항)
• 통로 — 파일 경로(이름에 지정되지 않은 경우)
• 확인 - 파일 형식:
  • absent - 파일 삭제
  • present — 모든 종류의 파일이 있어야 합니다. (파일이 없으면 일반 파일이 생성됩니다.)
  • file - 일반 파일
  • directory - 디렉토리
  • link - 심볼릭 링크
• 함유량 — 파일 내용(일반 파일에만 적합, 다음과 함께 사용할 수 없음)  또는 목표)
• — 파일 내용을 복사하려는 경로에 대한 링크(와 함께 사용할 수 없음) 함유량 또는 목표). 구성표가 있는 URI로 지정될 수 있습니다. puppet: (그런 다음 꼭두각시 서버의 파일이 사용됩니다) 그리고 구성표를 사용하여 http: (이 경우 무슨 일이 일어날지 명확해지기를 바랍니다.) 그리고 다이어그램을 통해서도 file: 또는 스키마가 없는 절대 경로로(그러면 노드에 있는 로컬 FS의 파일이 사용됩니다)
• 목표 — 심볼릭 링크가 가리키는 위치(와 함께 사용할 수 없음) 함유량 또는 )
• 소유자 — 파일을 소유해야 하는 사용자
• 그룹 — 파일이 속해야 하는 그룹
• 모드 — 파일 권한(문자열)
• 재귀 - 재귀적인 디렉토리 처리를 가능하게 합니다.
• 하제 - Puppet에 설명되지 않은 파일을 삭제할 수 있습니다.
• 정력에도 유리합니다. - Puppet에 설명되지 않은 디렉토리를 삭제할 수 있습니다.

꾸러미

패키지를 설치하고 제거합니다. 알림 처리 가능 - 매개변수가 지정된 경우 패키지를 다시 설치합니다. 다시 설치_새로 고침.

매개 변수 :

• 리소스 이름 — 패키지 이름(선택 사항)
• name — 패키지 이름(이름에 지정되지 않은 경우)
• 공급자 — 사용할 패키지 관리자
• 확인 — 원하는 패키지 상태:
  • present, installed - 설치된 모든 버전
  • latest - 최신 버전이 설치됨
  • absent - 삭제됨(apt-get remove)
  • purged — 구성 파일과 함께 삭제됨(apt-get purge)
  • held - 패키지 버전이 잠겨 있습니다(apt-mark hold)
  • любая другая строка — 지정된 버전이 설치되었습니다.
• 다시 설치_새로 고침 - 만약 true, 알림을 받으면 패키지가 다시 설치됩니다. 빌드 매개변수를 변경할 때 패키지를 다시 빌드해야 하는 소스 기반 배포에 유용합니다. 기본 false.

서비스

서비스를 관리합니다. 알림 처리 가능 - 서비스를 다시 시작합니다.

매개 변수 :

• 리소스 이름 — 관리할 서비스(선택 사항)
• name — 관리해야 하는 서비스(이름에 지정되지 않은 경우)
• 확인 — 원하는 서비스 상태:
  • running - 출시
  • stopped - 중지됨
• 가능 — 서비스 시작 기능을 제어합니다.
  • true — 자동 실행이 활성화되었습니다(systemctl enable)
  • mask - 위장한 (systemctl mask)
  • false — 자동 실행이 비활성화되었습니다(systemctl disable)
• 다시 시작 - 서비스를 다시 시작하는 명령
• 지위 — 서비스 상태를 확인하는 명령
• 다시 시작했습니다 — 서비스 initscript가 다시 시작을 지원하는지 여부를 나타냅니다. 만약에 false 매개변수가 지정되었습니다. 다시 시작 — 이 매개변수의 값이 사용됩니다. 만약에 false 및 매개변수 다시 시작 지정되지 않음 - 서비스가 중지되었다가 다시 시작됩니다(그러나 systemd는 다음 명령을 사용합니다) systemctl restart).
• 상태가 좋지 않음 — 서비스 initscript가 명령을 지원하는지 여부를 나타냅니다. status. 만약 false이면 매개변수 값이 사용됩니다. 지위. 기본 true.

임원

외부 명령을 실행합니다. 매개변수를 지정하지 않은 경우 생성, 경우에만, ...을 제외하면 또는 새로 고침 전용를 사용하면 Puppet이 실행될 때마다 명령이 실행됩니다. 알림 처리 가능 - 명령을 실행합니다.

매개 변수 :

• 리소스 이름 — 실행할 명령(선택 사항)
• 명령 — 실행할 명령(이름에 지정되지 않은 경우)
• 통로 — 실행 파일을 찾을 경로
• 경우에만 — 이 매개변수에 지정된 명령이 XNUMX 반환 코드로 완료되면 기본 명령이 실행됩니다.
• ...을 제외하면 — 이 매개변수에 지정된 명령이 XNUMX이 아닌 반환 코드로 완료되면 기본 명령이 실행됩니다.
• 생성 — 이 매개변수에 지정된 파일이 존재하지 않으면 기본 명령이 실행됩니다.
• 새로 고침 전용 - 만약 true, 이 exec가 다른 리소스로부터 알림을 받을 때만 명령이 실행됩니다.
• cwd — 명령을 실행할 디렉터리
• 사용자 — 명령을 실행할 사용자
• 공급자 - 명령을 실행하는 방법:
  • POSIX — 자식 프로세스가 간단히 생성되므로 다음을 지정해야 합니다. 통로
  • 껍질 - 명령이 쉘에서 실행됩니다. /bin/sh, 지정되지 않을 수 있습니다. 통로, 글로빙, 파이프 및 기타 쉘 기능을 사용할 수 있습니다. 일반적으로 특수 문자(|, ;, &&, || 기타).

크론

cronjob을 제어합니다.

매개 변수 :

• 리소스 이름 - 일종의 식별자일 뿐
• 확인 — 왕관 작업 상태:
  • present - 존재하지 않는 경우 생성
  • absent - 존재하는 경우 삭제
• 명령 - 실행할 명령
• 환경 — 명령을 실행할 환경(환경 변수 목록 및 해당 값을 통해) =)
• 사용자 — 명령을 실행할 사용자
• 분, 시간, 주일, 월, 월 일 — cron을 실행할 시기. 이러한 속성 중 하나라도 지정되지 않으면 crontab의 해당 값은 다음과 같습니다. *.

퍼펫 6.0에서 크론 마치 상자에서 꺼낸 puppetserver에서는 일반 사이트에 문서가 없습니다. 그러나 그는 상자 안에 있어요 puppet-agent에서는 별도로 설치할 필요가 없습니다. 해당 문서를 볼 수 있습니다. Puppet의 다섯 번째 버전에 대한 문서에서또는 GitHub에서.

일반적인 리소스 정보

리소스 고유성에 대한 요구 사항

우리가 흔히 저지르는 실수는 중복 선언. 이 오류는 동일한 이름을 가진 동일한 유형의 리소스가 두 개 이상 디렉터리에 나타날 때 발생합니다.

그러므로 나는 다시 다음과 같이 쓸 것이다: 동일한 노드에 대한 매니페스트에는 동일한 제목을 가진 동일한 유형의 리소스가 포함되어서는 안 됩니다!

이름은 같지만 패키지 관리자가 다른 패키지를 설치해야 하는 경우가 있습니다. 이 경우 매개변수를 사용해야 합니다. name오류를 방지하려면 다음을 수행하세요.

package { 'ruby-mysql':
  ensure   => installed,
  name     => 'mysql',
  provider => 'gem',
}
package { 'python-mysql':
  ensure   => installed,
  name     => 'mysql',
  provider => 'pip',
}

다른 리소스 유형에는 중복을 방지하는 데 도움이 되는 유사한 옵션이 있습니다. name у 서비스, command у 임원, 등등.

메타 매개변수

각 리소스 유형에는 특성에 관계없이 몇 가지 특수 매개변수가 있습니다.

메타 매개변수의 전체 목록 Puppet 문서에서.

짧은 목록:

• 필요 — 이 매개변수는 이 리소스가 의존하는 리소스를 나타냅니다.
• 전에 - 이 매개변수는 이 리소스에 의존하는 리소스를 지정합니다.
• 가입 — 이 매개변수는 이 리소스가 알림을 받는 리소스를 지정합니다.
• 통보 — 이 매개변수는 이 리소스로부터 알림을 받는 리소스를 지정합니다.

나열된 모든 메타 매개변수는 단일 리소스 링크 또는 대괄호로 묶인 링크 배열을 허용합니다.

리소스 링크

리소스 링크는 단순히 리소스에 대한 언급입니다. 주로 종속성을 나타내는 데 사용됩니다. 존재하지 않는 리소스를 참조하면 컴파일 오류가 발생합니다.

링크의 구문은 다음과 같습니다. 대문자가 포함된 리소스 유형(유형 이름에 이중 콜론이 포함된 경우 콜론 사이의 이름 부분이 모두 대문자로 표시됨), 대괄호 안의 리소스 이름(이름의 대/소문자) 변하지 않는다!). 공백이 없어야 하며, 타입명 바로 뒤에 대괄호를 쓴다.

예 :

file { '/file1': ensure => present }
file { '/file2':
  ensure => directory,
  before => File['/file1'],
}
file { '/file3': ensure => absent }
File['/file1'] -> File['/file3']

종속성 및 알림

여기에 문서가 있습니다.

앞에서 설명한 것처럼 리소스 간의 단순 종속성은 전이적입니다. 그런데 종속성을 추가할 때는 주의하십시오. 순환 종속성을 생성하면 컴파일 오류가 발생할 수 있습니다.

종속성과 달리 알림은 전이되지 않습니다. 알림에는 다음 규칙이 적용됩니다.

• 리소스가 알림을 받으면 업데이트됩니다. 업데이트 작업은 리소스 유형에 따라 다릅니다. 임원 명령을 실행하고, 서비스 서비스를 다시 시작하고, 꾸러미 패키지를 다시 설치합니다. 리소스에 업데이트 작업이 정의되어 있지 않으면 아무 일도 일어나지 않습니다.
• Puppet을 한 번 실행하는 동안 리소스는 한 번만 업데이트됩니다. 이는 알림에 종속성이 포함되고 종속성 그래프에는 주기가 포함되지 않기 때문에 가능합니다.
• Puppet이 리소스 상태를 변경하면 리소스는 이를 구독하는 모든 리소스에 알림을 보냅니다.
• 리소스가 업데이트되면 이를 구독하는 모든 리소스에 알림이 전송됩니다.

지정되지 않은 매개변수 처리

일반적으로 일부 리소스 매개변수에 기본값이 없고 이 매개변수가 매니페스트에 지정되지 않은 경우 Puppet은 노드의 해당 리소스에 대해 이 속성을 변경하지 않습니다. 예를 들어, 다음 유형의 리소스가 있는 경우 파일 매개변수가 지정되지 않았습니다. owner을 선택하면 Puppet은 해당 파일의 소유자를 변경하지 않습니다.

클래스, 변수 및 정의 소개

구성의 동일한 부분을 가지고 있지만 차이점도 있는 여러 노드가 있다고 가정합니다. 그렇지 않으면 모든 것을 하나의 블록으로 설명할 수 있습니다. node {}. 물론 구성의 동일한 부분을 간단히 복사할 수도 있지만 일반적으로 이는 나쁜 해결책입니다. 구성이 커지고 구성의 일반적인 부분을 변경하면 여러 곳에서 동일한 내용을 편집해야 합니다. 동시에 실수하기 쉬우며 일반적으로 DRY(반복하지 마십시오) 원칙이 고안된 데에는 이유가 있습니다.

이 문제를 해결하기 위해 다음과 같은 디자인이 있습니다. 클래스.

수업

클래스 포펫 코드의 명명된 블록입니다. 코드를 재사용하려면 클래스가 필요합니다.

먼저 클래스를 설명해야 합니다. 설명 자체는 어디에도 리소스를 추가하지 않습니다. 클래스는 매니페스트에 설명되어 있습니다.

# Описание класса начинается с ключевого слова class и его названия.
# Дальше идёт тело класса в фигурных скобках.
class example_class {
    ...
}

이 후에 클래스를 사용할 수 있습니다.

# первый вариант использования — в стиле ресурса с типом class
class { 'example_class': }
# второй вариант использования — с помощью функции include
include example_class
# про отличие этих двух вариантов будет рассказано дальше

이전 작업의 예 - nginx의 설치 및 구성을 클래스로 이동해 보겠습니다.

class nginx_example {
    package { 'nginx':
        ensure => installed,
    }
    -> file { '/etc/nginx':
        ensure => directory,
        source => 'puppet:///modules/example/nginx-conf',
        recure => true,
        purge  => true,
        force  => true,
    }
    ~> service { 'nginx':
        ensure => running,
        enable => true,
    }
}

node 'server2.testdomain' {
    include nginx_example
}

변수들

이전 예제의 클래스는 항상 동일한 nginx 구성을 가져오기 때문에 전혀 유연하지 않습니다. 구성 변수에 대한 경로를 만들어 보겠습니다. 그러면 이 클래스를 사용하여 모든 구성으로 nginx를 설치할 수 있습니다.

할 수 있다 변수 사용.

주의: Puppet의 변수는 변경할 수 없습니다!

또한 변수는 선언된 후에만 액세스할 수 있습니다. 그렇지 않으면 변수의 값은 다음과 같습니다. undef.

변수 작업의 예:

# создание переменных
$variable = 'value'
$var2 = 1
$var3 = true
$var4 = undef
# использование переменных
$var5 = $var6
file { '/tmp/text': content => $variable }
# интерполяция переменных — раскрытие значения переменных в строках. Работает только в двойных кавычках!
$var6 = "Variable with name variable has value ${variable}"

인형은 네임스페이스, 그리고 그에 따라 변수는 가시 영역: 같은 이름의 변수가 다른 네임스페이스에 정의될 수 있습니다. 변수 값을 확인할 때 변수는 현재 네임스페이스에서 검색된 다음 바깥쪽 네임스페이스에서 검색됩니다.

네임스페이스 예:

• 전역 - 클래스 또는 노드 설명 외부의 변수가 거기로 이동합니다.
• 노드 설명의 노드 네임스페이스
• 클래스 설명의 클래스 네임스페이스.

변수에 액세스할 때 모호성을 방지하려면 변수 이름에 네임스페이스를 지정할 수 있습니다.

# переменная без пространства имён
$var
# переменная в глобальном пространстве имён
$::var
# переменная в пространстве имён класса
$classname::var
$::classname::var

nginx 구성의 경로가 변수에 있다는 데 동의합시다. $nginx_conf_source. 그러면 수업은 다음과 같이 보일 것입니다:

class nginx_example {
    package { 'nginx':
        ensure => installed,
    }
    -> file { '/etc/nginx':
        ensure => directory,
        source => $nginx_conf_source,   # здесь используем переменную вместо фиксированной строки
        recure => true,
        purge  => true,
        force  => true,
    }
    ~> service { 'nginx':
        ensure => running,
        enable => true,
    }
}

node 'server2.testdomain' {
    $nginx_conf_source = 'puppet:///modules/example/nginx-conf'
    include nginx_example
}

그러나 주어진 예는 클래스 내부 어딘가에 그러한 이름을 가진 변수가 사용된다는 "비밀 지식"이 있기 때문에 좋지 않습니다. 이 지식을 일반화하는 것이 훨씬 더 정확합니다. 클래스는 매개변수를 가질 수 있습니다.

클래스 매개변수 클래스 네임스페이스에 있는 변수는 클래스 헤더에 지정되며 클래스 본문에서 일반 변수처럼 사용할 수 있습니다. 매니페스트에서 클래스를 사용할 때 매개변수 값이 지정됩니다.

매개변수는 기본값으로 설정될 수 있습니다. 매개변수에 기본값이 없고 사용할 때 값이 설정되지 않은 경우 컴파일 오류가 발생합니다.

위의 예에서 클래스를 매개변수화하고 두 개의 매개변수를 추가해 보겠습니다. 첫 번째 필수 매개변수는 구성에 대한 경로이고, 두 번째 선택적 매개변수는 nginx가 포함된 패키지 이름입니다(예를 들어 Debian에는 패키지가 있습니다). nginx, nginx-light, nginx-full).

# переменные описываются сразу после имени класса в круглых скобках
class nginx_example (
  $conf_source,
  $package_name = 'nginx-light', # параметр со значением по умолчанию
) {
  package { $package_name:
    ensure => installed,
  }
  -> file { '/etc/nginx':
    ensure  => directory,
    source  => $conf_source,
    recurse => true,
    purge   => true,
    force   => true,
  }
  ~> service { 'nginx':
    ensure => running,
    enable => true,
  }
}

node 'server2.testdomain' {
  # если мы хотим задать параметры класса, функция include не подойдёт* — нужно использовать resource-style declaration
  # *на самом деле подойдёт, но про это расскажу в следующей серии. Ключевое слово "Hiera".
  class { 'nginx_example':
    conf_source => 'puppet:///modules/example/nginx-conf',   # задаём параметры класса точно так же, как параметры для других ресурсов
  }
}

Puppet에서는 변수가 입력됩니다. 먹다 많은 데이터 유형. 데이터 유형은 일반적으로 클래스 및 정의에 전달된 매개변수 값의 유효성을 검사하는 데 사용됩니다. 전달된 매개변수가 지정된 유형과 일치하지 않으면 컴파일 오류가 발생합니다.

유형은 매개변수 이름 바로 앞에 작성됩니다.

class example (
  String $param1,
  Integer $param2,
  Array $param3,
  Hash $param4,
  Hash[String, String] $param5,
) {
  ...
}

클래스: 클래스 이름과 class{'classname':} 포함

각 클래스는 유형의 리소스입니다. 수업. 다른 유형의 리소스와 마찬가지로 동일한 노드에 동일한 클래스의 두 인스턴스가 있을 수 없습니다.

다음을 사용하여 동일한 노드에 클래스를 두 번 추가하려고 하면 class { 'classname':} (차이가 없고 매개변수가 다르거나 동일함) 컴파일 오류가 발생합니다. 그러나 리소스 스타일의 클래스를 사용하는 경우 매니페스트에서 모든 매개변수를 즉시 명시적으로 설정할 수 있습니다.

그러나 사용하는 경우 include, 그러면 원하는 만큼 클래스를 추가할 수 있습니다. 사실은 include 클래스가 디렉터리에 추가되었는지 확인하는 멱등성 함수입니다. 클래스가 디렉터리에 없으면 추가하고, 이미 있으면 아무 작업도 수행하지 않습니다. 하지만 사용하는 경우 include 클래스 선언 중에는 클래스 매개변수를 설정할 수 없습니다. 모든 필수 매개변수는 외부 데이터 소스(Hiera 또는 ENC)에서 설정되어야 합니다. 다음 기사에서 이에 대해 이야기하겠습니다.

정의하다

이전 블록에서 말했듯이 동일한 클래스는 노드에 두 번 이상 존재할 수 없습니다. 그러나 어떤 경우에는 동일한 노드에서 다른 매개변수와 함께 동일한 코드 블록을 사용할 수 있어야 합니다. 즉, 자체적인 리소스 유형이 필요합니다.

예를 들어, PHP 모듈을 설치하기 위해 Avito에서 다음을 수행합니다.

1. 이 모듈로 패키지를 설치하십시오.
2. 이 모듈에 대한 구성 파일을 만들어 보겠습니다.
3. php-fpm 구성에 대한 심볼릭 링크를 만듭니다.
4. php cli의 구성에 대한 심볼릭 링크를 만듭니다.

그러한 경우에는 다음과 같은 디자인이 필요합니다. 정의하다 (정의, 정의된 유형, 정의된 리소스 유형) Define은 클래스와 유사하지만 차이점이 있습니다. 첫째, 각 Define은 리소스가 아닌 리소스 유형입니다. 둘째, 각 정의에는 암시적 매개변수가 있습니다. $title, 선언되면 리소스 이름이 표시됩니다. 클래스의 경우와 마찬가지로 정의를 먼저 설명하고 그 후에 사용할 수 있습니다.

PHP용 모듈을 사용한 간단한 예:

define php74::module (
  $php_module_name = $title,
  $php_package_name = "php7.4-${title}",
  $version = 'installed',
  $priority = '20',
  $data = "extension=${title}.son",
  $php_module_path = '/etc/php/7.4/mods-available',
) {
  package { $php_package_name:
    ensure          => $version,
    install_options => ['-o', 'DPkg::NoTriggers=true'],  # триггеры дебиановских php-пакетов сами создают симлинки и перезапускают сервис php-fpm - нам это не нужно, так как и симлинками, и сервисом мы управляем с помощью Puppet
  }
  -> file { "${php_module_path}/${php_module_name}.ini":
    ensure  => $ensure,
    content => $data,
  }
  file { "/etc/php/7.4/cli/conf.d/${priority}-${php_module_name}.ini":
    ensure  => link,
    target  => "${php_module_path}/${php_module_name}.ini",
  }
  file { "/etc/php/7.4/fpm/conf.d/${priority}-${php_module_name}.ini":
    ensure  => link,
    target  => "${php_module_path}/${php_module_name}.ini",
  }
}

node server3.testdomain {
  php74::module { 'sqlite3': }
  php74::module { 'amqp': php_package_name => 'php-amqp' }
  php74::module { 'msgpack': priority => '10' }
}

Duplicate 선언 오류를 잡는 가장 쉬운 방법은 Define입니다. 이는 정의에 상수 이름을 가진 리소스가 있고 일부 노드에 이 정의의 인스턴스가 두 개 이상 있는 경우에 발생합니다.

이것으로부터 자신을 보호하는 것은 쉽습니다. 정의 내의 모든 리소스는 다음에 따라 이름을 가져야 합니다. $title. 대안은 리소스의 멱등적 추가입니다. 가장 간단한 경우 정의의 모든 인스턴스에 공통적인 리소스를 별도의 클래스로 이동하고 이 클래스를 정의에 포함하는 것으로 충분합니다. include 멱등성.

리소스를 추가할 때 멱등성을 달성하는 다른 방법, 즉 함수를 사용하는 방법이 있습니다. defined и ensure_resources하지만 이에 대해서는 다음 에피소드에서 말씀드리겠습니다.

클래스와 정의에 대한 종속성 및 알림

클래스와 정의는 종속성 및 알림 처리에 다음 규칙을 추가합니다.

• 클래스/정의에 대한 종속성은 클래스/정의의 모든 리소스에 대한 종속성을 추가합니다.
• 클래스/정의 종속성은 모든 클래스/정의 리소스에 종속성을 추가합니다.
• 클래스/정의 알림은 클래스/정의의 모든 리소스에 알립니다.
• 클래스/정의 구독은 클래스/정의의 모든 리소스를 구독합니다.

조건문 및 선택기

여기에 문서가 있습니다.

if

여기에 모든 것이 간단합니다.

if ВЫРАЖЕНИЕ1 {
  ...
} elsif ВЫРАЖЕНИЕ2 {
  ...
} else {
  ...
}

...을 제외하면

Except 는 if 의 역순입니다: 표현식이 false인 경우 코드 블록이 실행됩니다.

unless ВЫРАЖЕНИЕ {
  ...
}

케이스

여기에도 복잡한 것은 없습니다. 정규값(문자열, 숫자 등), 정규식, 데이터 유형을 값으로 사용할 수 있습니다.

case ВЫРАЖЕНИЕ {
  ЗНАЧЕНИЕ1: { ... }
  ЗНАЧЕНИЕ2, ЗНАЧЕНИЕ3: { ... }
  default: { ... }
}

선택기

선택자는 다음과 유사한 언어 구조입니다. case, 그러나 코드 블록을 실행하는 대신 값을 반환합니다.

$var = $othervar ? { 'val1' => 1, 'val2' => 2, default => 3 }

모듈

구성이 작으면 하나의 매니페스트에 쉽게 보관할 수 있습니다. 그러나 우리가 설명하는 구성이 많을수록 매니페스트에 더 많은 클래스와 노드가 존재하고 크기가 커지며 작업하기가 불편해집니다.

또한 코드 재사용 문제가 있습니다. 모든 코드가 하나의 매니페스트에 있으면 이 코드를 다른 사람과 공유하기가 어렵습니다. 이 두 가지 문제를 해결하기 위해 Puppet에는 모듈이라는 엔터티가 있습니다.

모듈 - 이는 별도의 디렉토리에 배치된 클래스, 정의 및 기타 Puppet 엔터티 세트입니다. 즉, 모듈은 Puppet 로직의 독립적인 부분입니다. 예를 들어 nginx 작업을 위한 모듈이 있을 수 있으며 nginx 작업에 필요한 것만 포함하거나 PHP 작업을 위한 모듈이 있을 수 있습니다.

모듈의 버전이 관리되며 모듈 간의 종속성도 지원됩니다. 모듈의 공개 저장소가 있습니다 - 꼭두각시 대장간.

Puppet 서버에서 모듈은 루트 디렉터리의 모듈 하위 디렉터리에 있습니다. 각 모듈 내부에는 매니페스트, 파일, 템플릿, lib 등의 표준 디렉터리 체계가 있습니다.

모듈의 파일 구조

모듈의 루트에는 설명이 포함된 이름을 가진 다음 디렉터리가 포함될 수 있습니다.

• manifests - 선언문이 포함되어 있습니다.
• files - 파일이 포함되어 있습니다.
• templates - 템플릿이 포함되어 있습니다.
• lib — Ruby 코드가 포함되어 있습니다.

이것은 디렉터리와 파일의 전체 목록은 아니지만 현재 이 기사에서는 이것으로 충분합니다.

모듈의 리소스 이름 및 파일 이름

여기에 문서가 있습니다.

모듈의 리소스(클래스, 정의)에는 원하는 이름을 지정할 수 없습니다. 또한 리소스 이름과 Puppet이 해당 리소스에 대한 설명을 찾는 파일 이름 사이에는 직접적인 연관성이 있습니다. 명명 규칙을 위반하면 Puppet은 리소스 설명을 찾지 못하고 컴파일 오류가 발생합니다.

규칙은 간단합니다.

• 모듈의 모든 리소스는 모듈 네임스페이스에 있어야 합니다. 모듈이 호출되면 foo, 그 안에 있는 모든 리소스의 이름을 지정해야 합니다. foo::<anything>아니면 그냥 foo.
• 모듈 이름을 가진 리소스가 파일에 있어야 합니다. init.pp.
• 기타 리소스의 경우 파일 이름 지정 체계는 다음과 같습니다.
  • 모듈 이름의 접두사는 삭제됩니다.
  • 모든 이중 콜론(있는 경우)은 슬래시로 대체됩니다.
  • 확장자가 추가되었습니다 .pp

예를 들어 설명하겠습니다. 내가 모듈을 작성한다고 가정해보자. nginx. 여기에는 다음 리소스가 포함되어 있습니다.

• 클래스 nginx 매니페스트에 설명된 init.pp;
• 클래스 nginx::service 매니페스트에 설명된 service.pp;
• 정의하다 nginx::server 매니페스트에 설명된 server.pp;
• 정의하다 nginx::server::location 매니페스트에 설명된 server/location.pp.

템플릿

템플릿이 무엇인지는 여러분도 알고 계시겠지만 여기서는 자세히 설명하지 않겠습니다. 하지만 만약을 대비해서 남겨둘게요 위키피디아 링크.

템플릿 사용 방법: 함수를 사용하여 템플릿의 의미를 확장할 수 있습니다. template, 템플릿 경로가 전달됩니다. 유형의 리소스 파일 매개변수와 함께 사용 content. 예를 들어 다음과 같습니다.

file { '/tmp/example': content => template('modulename/templatename.erb')

경로 보기 <modulename>/<filename> 파일을 의미 <rootdir>/modules/<modulename>/templates/<filename>.

그외에 기능이 있다 inline_template — 파일 이름이 아닌 템플릿 텍스트를 입력으로 받습니다.

템플릿 내에서 현재 범위의 모든 Puppet 변수를 사용할 수 있습니다.

Puppet은 ERB 및 EPP 형식의 템플릿을 지원합니다.

• EPP 문서.
• ERB 문서.

ERB에 대해 간단히

제어 구조:

• <%= ВЫРАЖЕНИЕ %> — 표현식의 값을 삽입합니다.
• <% ВЫРАЖЕНИЕ %> — 식의 값을 계산합니다(삽입하지 않고). 조건문(if)과 루프(각각)가 일반적으로 여기에 위치합니다.
• <%# КОММЕНТАРИЙ %>

ERB의 표현식은 Ruby로 작성됩니다(ERB는 실제로 Embedded Ruby입니다).

매니페스트에서 변수에 액세스하려면 다음을 추가해야 합니다. @ 변수 이름에. 제어 구문 뒤에 나타나는 줄바꿈을 제거하려면 닫는 태그를 사용해야 합니다. -%>.

템플릿 사용 예

ZooKeeper를 제어하는 ​​모듈을 작성한다고 가정해 보겠습니다. 구성 생성을 담당하는 클래스는 다음과 같습니다.

class zookeeper::configure (
  Array[String] $nodes,
  Integer $port_client,
  Integer $port_quorum,
  Integer $port_leader,
  Hash[String, Any] $properties,
  String $datadir,
) {
  file { '/etc/zookeeper/conf/zoo.cfg':
    ensure  => present,
    content => template('zookeeper/zoo.cfg.erb'),
  }
}

그리고 해당 템플릿 zoo.cfg.erb - 그래서:

<% if @nodes.length > 0 -%>
<% @nodes.each do |node, id| -%>
server.<%= id %>=<%= node %>:<%= @port_leader %>:<%= @port_quorum %>;<%= @port_client %>
<% end -%>
<% end -%>

dataDir=<%= @datadir %>

<% @properties.each do |k, v| -%>
<%= k %>=<%= v %>
<% end -%>

사실과 내장 변수

구성의 특정 부분은 현재 노드에서 발생하는 상황에 따라 달라지는 경우가 많습니다. 예를 들어 Debian 릴리스가 무엇인지에 따라 패키지의 하나 또는 다른 버전을 설치해야 합니다. 이 모든 것을 수동으로 모니터링하여 노드가 변경되면 매니페스트를 다시 작성할 수 있습니다. 그러나 이것은 진지한 접근 방식이 아니며 자동화가 훨씬 좋습니다.

노드에 대한 정보를 얻기 위해 Puppet에는 사실이라는 메커니즘이 있습니다. 사실 - 이는 전역 네임스페이스의 일반 변수 형태로 매니페스트에서 사용할 수 있는 노드에 대한 정보입니다. 예를 들어 호스트 이름, 운영 체제 버전, 프로세서 아키텍처, 사용자 목록, 네트워크 인터페이스 목록 및 해당 주소 등이 있습니다. 팩트는 매니페스트와 템플릿에서 일반 변수로 사용할 수 있습니다.

사실을 다루는 예:

notify { "Running OS ${facts['os']['name']} version ${facts['os']['release']['full']}": }
# ресурс типа notify просто выводит сообщение в лог

공식적으로 팩트에는 이름(문자열)과 값(문자열, 배열, 사전 등 다양한 유형 사용 가능)이 있습니다. 먹다 내장된 사실 집합. 직접 작성할 수도 있습니다. 사실 수집자가 설명되어 있습니다. Ruby의 함수처럼또는 어떻게 실행 파일. 사실은 형식으로도 제시될 수 있습니다. 데이터가 포함된 텍스트 파일 노드에.

작동 중에 puppet 에이전트는 먼저 사용 가능한 모든 사실 수집기를 pappetserver에서 노드로 복사한 후 이를 실행하고 수집된 사실을 서버로 보냅니다. 그 후 서버는 카탈로그 컴파일을 시작합니다.

실행 파일 형태의 사실

이러한 사실은 디렉토리의 모듈에 배치됩니다. facts.d. 물론 파일은 실행 가능해야 합니다. 실행 시 YAML 또는 key=value 형식으로 표준 출력에 정보를 출력해야 합니다.

모듈이 배포되는 포펫 서버에 의해 제어되는 모든 노드에 사실이 적용된다는 점을 잊지 마십시오. 따라서 스크립트에서 팩트가 작동하는 데 필요한 모든 프로그램과 파일이 시스템에 있는지 확인하십시오.

#!/bin/sh
echo "testfact=success"

#!/bin/sh
echo '{"testyamlfact":"success"}'

루비 사실

이러한 사실은 디렉토리의 모듈에 배치됩니다. lib/facter.

# всё начинается с вызова функции Facter.add с именем факта и блоком кода
Facter.add('ladvd') do
# в блоках confine описываются условия применимости факта — код внутри блока должен вернуть true, иначе значение факта не вычисляется и не возвращается
  confine do
    Facter::Core::Execution.which('ladvdc') # проверим, что в PATH есть такой исполняемый файл
  end
  confine do
    File.socket?('/var/run/ladvd.sock') # проверим, что есть такой UNIX-domain socket
  end
# в блоке setcode происходит собственно вычисление значения факта
  setcode do
    hash = {}
    if (out = Facter::Core::Execution.execute('ladvdc -b'))
      out.split.each do |l|
        line = l.split('=')
        next if line.length != 2
        name, value = line
        hash[name.strip.downcase.tr(' ', '_')] = value.strip.chomp(''').reverse.chomp(''').reverse
      end
    end
    hash  # значение последнего выражения в блоке setcode является значением факта
  end
end

텍스트 사실

이러한 사실은 디렉토리의 노드에 배치됩니다. /etc/facter/facts.d 오래된 인형이나 /etc/puppetlabs/facts.d 새로운 인형에서.

examplefact=examplevalue

---
examplefact2: examplevalue2
anotherfact: anothervalue

사실 확인

사실에 접근하는 방법에는 두 가지가 있습니다.

• 사전을 통해 $facts: $facts['fqdn'];
• 사실 이름을 변수 이름으로 사용: $fqdn.

사전을 사용하는 것이 가장 좋습니다. $facts또는 더 나은 방법으로 전역 네임스페이스($::facts).

다음은 문서의 관련 섹션입니다.

내장 변수

사실 외에도 다음과 같은 내용이 있습니다. 일부 변수, 전역 네임스페이스에서 사용할 수 있습니다.

• 신뢰할 수 있는 사실 — 클라이언트의 인증서에서 가져온 변수(인증서는 일반적으로 포핏 서버에서 발급되므로 에이전트는 인증서를 가져와 변경할 수 없으므로 변수는 "신뢰할 수 있습니다"): 인증서 이름, 인증서 이름 호스트 및 도메인, 인증서의 확장명.
• 서버 사실 —서버 정보와 관련된 변수—버전, 이름, 서버 IP 주소, 환경.
• 대리인 사실 — 팩터가 아닌 puppet-agent에 의해 직접 추가된 변수 — 인증서 이름, 에이전트 버전, puppet 버전.
• 마스터 변수 - Pappetmaster 변수(sic!). 에서와 거의 같습니다 서버 사실, 구성 매개변수 값도 사용할 수 있습니다.
• 컴파일러 변수 — 각 범위에서 다른 컴파일러 변수: 현재 모듈의 이름과 현재 객체에 액세스한 모듈의 이름. 예를 들어, 개인 클래스가 다른 모듈에서 직접 사용되지 않는지 확인하는 데 사용할 수 있습니다.

추가 1: 이 모든 것을 어떻게 실행하고 디버그하나요?

기사에는 인형 코드의 많은 예가 포함되어 있지만 이 코드를 실행하는 방법은 전혀 알려주지 않았습니다. 글쎄, 나는 내 자신을 정정하고 있습니다.

에이전트는 Puppet을 실행하는 데 충분하지만 대부분의 경우 서버도 필요합니다.

대리인

적어도 버전 XNUMX부터는 puppet-agent 패키지가 공식 Puppetlabs 저장소 모든 종속성(ruby 및 해당 gem)이 포함되어 있으므로 설치에 어려움이 없습니다. (저는 Debian 기반 배포판에 대해 이야기하고 있습니다. 우리는 RPM 기반 배포판을 사용하지 않습니다.)

가장 간단한 경우, 꼭두각시 구성을 사용하려면 서버리스 모드에서 에이전트를 시작하는 것으로 충분합니다. 꼭두각시 코드가 노드에 복사된 경우 puppet apply <путь к манифесту>:

atikhonov@atikhonov ~/puppet-test $ cat helloworld.pp 
node default {
    notify { 'Hello world!': }
}
atikhonov@atikhonov ~/puppet-test $ puppet apply helloworld.pp 
Notice: Compiled catalog for atikhonov.localdomain in environment production in 0.01 seconds
Notice: Hello world!
Notice: /Stage[main]/Main/Node[default]/Notify[Hello world!]/message: defined 'message' as 'Hello world!'
Notice: Applied catalog in 0.01 seconds

물론 서버를 설정하고 데몬 모드로 노드에서 에이전트를 실행하는 것이 더 좋습니다. 그런 다음 XNUMX분마다 한 번씩 서버에서 다운로드한 구성을 적용합니다.

작업의 푸시 모델을 모방할 수 있습니다. 관심 있는 노드로 이동하여 시작합니다. sudo puppet agent -t. 열쇠 -t (--test)에는 실제로 개별적으로 활성화할 수 있는 여러 옵션이 포함되어 있습니다. 이러한 옵션에는 다음이 포함됩니다.

• 데몬 모드에서 실행하지 마십시오(기본적으로 에이전트는 데몬 모드에서 시작됩니다).
• 카탈로그를 적용한 후 종료합니다(기본적으로 에이전트는 XNUMX분마다 한 번씩 계속 작동하고 구성을 적용합니다).
• 자세한 작업 일지를 작성하세요.
• 파일의 변경 사항을 표시합니다.

에이전트에는 변경 사항이 없는 작동 모드가 있습니다. 올바른 구성을 작성했는지 확실하지 않고 작동 중에 에이전트가 정확히 무엇을 변경하는지 확인하고 싶을 때 사용할 수 있습니다. 이 모드는 매개변수에 의해 활성화됩니다. --noop 명령줄에서: sudo puppet agent -t --noop.

또한 작업의 디버깅 로그를 활성화할 수 있습니다. 이 로그에는 puppet이 수행하는 모든 작업(현재 처리 중인 리소스, 이 리소스의 매개 변수, 시작하는 프로그램)에 대해 기록합니다. 물론 이것은 매개변수이다. --debug.

서버

이 기사에서는 pappetserver의 전체 설정과 여기에 코드를 배포하는 방법을 고려하지 않을 것입니다. 단지 기본적으로 소수의 서버에서 작동하기 위해 추가 구성이 필요하지 않은 완전한 기능을 갖춘 서버 버전이 있다는 점만 말씀드리겠습니다. 노드(예: 최대 XNUMX개). 더 많은 수의 노드를 조정하려면 조정이 필요합니다. 기본적으로 puppetserver는 XNUMX개 이하의 작업자를 실행합니다. 더 나은 성능을 얻으려면 노드 수를 늘려야 하며 메모리 제한을 늘리는 것을 잊지 마십시오. 그렇지 않으면 서버가 대부분의 시간 동안 가비지 수집을 수행합니다.

코드 배포 - 빠르고 쉽게 필요하다면 (r10k에서)[https://github.com/puppetlabs/r10k], 소규모 설치의 경우에는 충분합니다.

부록 2: 코딩 지침

1. 모든 로직을 클래스와 정의에 배치하세요.
2. 노드를 설명하는 매니페스트가 아닌 모듈에 클래스와 정의를 유지하세요.
3. 사실을 활용하세요.
4. 호스트 이름을 기반으로 if를 만들지 마십시오.
5. 클래스와 정의에 대한 매개변수를 자유롭게 추가하세요. 이는 클래스/정의 본문에 숨겨진 암시적 논리보다 낫습니다.

다음 글에서 이 방법을 추천하는 이유를 설명하겠습니다.

결론

소개를 마치겠습니다. 다음 기사에서는 Hiera, ENC 및 PuppetDB에 대해 설명하겠습니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

실제로 훨씬 더 많은 자료가 있습니다. 다음 주제에 대한 기사를 쓸 수 있고, 읽고 싶은 내용에 투표할 수 있습니다.

• 59,1%고급 꼭두각시 구성 - 다음 수준의 것들: 루프, 매핑 및 기타 람다 표현식, 리소스 수집기, 내보낸 리소스 및 Puppet, 태그, 공급자, 추상 데이터 유형을 통한 호스트 간 통신.13
• 31,8%"저는 어머니의 관리자입니다" 또는 Avito에서 다양한 버전의 여러 Poppet 서버와 친구가 된 방법과 원칙적으로 Poppet 서버 관리에 관한 부분입니다.7
• 81,8%퍼펫 코드 작성 방법: 계측, 문서화, 테스트, CI/CD.18

22명의 사용자가 투표했습니다. 9명의 사용자가 기권했습니다.

출처 : habr.com