꼭두각시 (Puppet)는 실제로 멀티 마스터 환경에주의를 기울이고 있습니다. 메인? 꼭두각시의 많은 부분이 중앙 집중화되는 것을 좋아합니다. 인증 기관, 인벤토리 및 대시 보드 / 보고서 서비스, 파일 버킷 팅 및 저장된 구성-모두 대화 할 수있는 장소가 하나 뿐인 설정에서 최상의 상태를 유지합니다.

그러나 기본 사이트를 잃어 버렸을 때 일부 기능이 정상적으로 손실되면 다중 마스터 환경에서 작동하는 많은 부품을 얻는 것이 매우 효과적입니다.

---

기본 기능부터 시작하여 마스터에 노드보고를 가져 오십시오.

모듈과 매니페스트

이 부분은 간단합니다. 버전 관리가 가능합니다. 분산 버전 제어 시스템 인 경우 중앙 집중식으로 동기화하고 장애 조치 사이트에서 필요에 따라 푸시 / 풀 플로우를 변경하십시오. Subversion 인 경우 svnsync장애 조치 사이트 에 대한 저장소를 원할 수 있습니다.

인증 기관

여기서 한 가지 옵션은 마스터간에 인증 기관 파일을 간단히 동기화하여 모두 동일한 루트 인증서를 공유하고 인증서에 서명 할 수 있도록하는 것입니다. 이것은 항상 “잘못하고있다”고 생각했다.

• 한 마스터가 다른 마스터로부터 들어오는 연결에 대해 클라이언트 인증에 자신의 인증서가 실제로 유효한 것으로보아야합니까?
• 인벤토리 서비스, 대시 보드 등에서 안정적으로 작동합니까?
• 도로에 유효한 DNS 대체 이름을 어떻게 추가합니까?

솔직히이 옵션에 대한 철저한 테스트를 수행했다고 말할 수는 없습니다. 그러나 Puppet Labs는 여기 참고 사항에 따라이 옵션을 권장하지 않는 것 같습니다 .

따라서 중요한 것은 중앙 CA 마스터를 보유하는 것입니다. 모든 클라이언트와 다른 마스터가 CA 인증서와 CRL을 캐시하기 때문에 모든 트러스트 관계는 계속 작동합니다 (CRL을 자주 새로 고치지는 않지만)하지만 새 인증서에 서명 할 수있을 때까지 기본 사이트를 백업하거나 장애 조치 사이트의 백업에서 CA 마스터를 복원합니다.

하나의 마스터를 선택하여 CA로 작동하고 다른 모든 마스터가이를 비활성화하게합니다.

[main]
    ca_server = puppet-ca.example.com
[master]
    ca = false

그런 다음 해당 중앙 시스템이 모든 인증서 관련 트래픽을 가져 오기를 원할 것입니다. 이에 대한 몇 가지 옵션이 있습니다.

1. SRV3.0 의 새로운 레코드 지원을 사용하여 모든 에이전트 노드가 CA의 올바른 위치를 가리 키도록합니다._x-puppet-ca._tcp.example.com
2. 모든 에이전트 ca_server에서 구성 옵션 설정puppet.conf

3. 에이전트에서 올바른 마스터로 CA 관련 요청에 대한 모든 트래픽을 프록시하십시오. 예를 들어, 승객을 통해 Apache에서 모든 마스터를 실행중인 경우 비 CA에서이를 구성하십시오.

   SSLProxyEngine On
   # Proxy on to the CA.
   ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
   # Caveat: /certificate_revocation_list requires authentication by default,
   # which will be lost when proxying. You'll want to alter your CA's auth.conf
   # to allow those requests from any device; the CRL isn't sensitive.
   

그리고 그렇게해야합니다.

---

보조 서비스로 넘어 가기 전에 부가 정보;

마스터 인증서의 DNS 이름

나는 이것이 바로 3.0으로 전환해야 할 가장 강력한 이유라고 생각합니다. “모든 ol ‘작업 마스터”에서 노드를 가리키고 싶다고 가정하십시오.

2.7에서는와 같은 일반 DNS 이름 puppet.example.com이 필요하며 모든 마스터는 인증서에이 이름 이 필요합니다. 즉 dns_alt_names, 구성에서 설정하고, 마스터로 구성되기 전에 가지고 있던 인증서를 다시 발행하고, 목록에 새 DNS 이름을 추가해야 할 때 인증서를 다시 발행하는 것을 의미합니다 (여러 DNS 이름을 에이전트가 자신의 사이트에서 마스터를 선호하게합니다.)

3.0에서는 SRV레코드 를 사용할 수 있습니다 . 모든 고객에게 이것을 제공하십시오;

[main]
    use_srv_records = true
    srv_domain = example.com

그런 다음 마스터에게 특별한 인증서가 필요하지 않습니다. SRVRR에 새 레코드를 추가 _x-puppet._tcp.example.com하면 그룹의 라이브 마스터입니다. 또한 마스터 선택 로직을보다 정교하게 만들 수 있습니다. 사이트마다 다른 SRV레코드 세트를 설정하여 “모든 ol ‘작업 마스터이지만 사이트의 레코드 마스터를 선호합니다” ; dns_alt_names필요 하지 않습니다.

---

보고서 / 대시 보드

이 방법은 중앙 집중식으로 가장 잘 작동하지만 기본 사이트가 다운 되어도 문제없이 살 수 있다면 아무런 문제가 없습니다. 모든 마스터를 올바른 위치에 구성하여 보고서를 작성하십시오.

[master]
    reports = http
    reporturl = https://puppetdash.example.com/reports/upload

.. 그리고 모든 준비가 끝났습니다. 보고서 업로드 실패는 구성 실행에 치명적이지 않습니다. 대시 보드 서버가 토스트되면 손실됩니다.

팩트 인벤토리

대시 보드에 붙어있는 또 다른 좋은 점은 인벤토리 서비스입니다. 으로 facts_terminus로 설정 rest중앙 재고 서비스가 다운되었을 때 설명서에 권장하는대로,이 사실은 구성 실행을 깰 수 있습니다. 여기서 비결 inventory_service은 비 중앙 마스터 에서 종단 을 사용하여 정상적으로 실패하는 것입니다.

facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140

중앙 인벤토리 서버가 ActiveRecord 또는 PuppetDB를 통해 인벤토리 데이터를 저장하도록 설정하고 서비스가 제공 될 때마다 최신 상태를 유지해야합니다.

---

따라서 CA를 사용하여 복원 할 때까지 새 노드의 인증서에 서명 할 수없는 예쁜 기본 구성 관리 환경에 만족한다면 괜찮을 것입니다. 이러한 구성 요소 중 일부 가 배포하기에 더 친숙한 경우 .

---

답변