나는 일반적으로 구성 관리를 통해 길을 배우고 있으며 꼭두각시 를 사용하여 특히 그것을 구현하고 있는데 꼭두각시로 관리 해서는 안되는 시스템의 측면이 무엇인지 궁금합니다 .
예를 들어 일반적으로 호스트 이름이 시스템을 퍼펫 관리에 대여하기 전에 호스트 이름이 이미 설정되어 있다고 가정합니다. 최소한 puppetmaster에 연결하는 데 사용 된 네트워크에서 기본 IP 연결이 작동하고 있어야합니다. 꼭두각시를 사용하여 DNS 영역 파일을 자동으로 만드는 것은 유혹적이지만 DNS 역방향 포인터는 물건을 시작하기 전에 이미 있어야하거나 인증서가 재미있을 것입니다.
꼭두각시에서 IP 구성을 제거해야합니까? 또는 꼭두각시를 처음 시작하기 전에 설정해야하지만 꼭두각시로 IP 주소를 관리해야합니까? IP가 여러 개인 시스템 (예 : WAN, LAN 및 SAN)은 어떻습니까?
무엇에 대한 IPMI ? ipmitool 을 사용하여 전부는 아니더라도 대부분을 구성 할 수 있으므로 꼭두각시로 자동화 할 수 있도록 콘솔 액세스 (물리적, LAN을 통한 원격 KVM 등)를받지 않아도됩니다. 그러나 모든 꼭두각시 에이전트 실행에서 상태를 다시 확인하는 것은 나에게 시원하지 않으며 시스템에 대한 기본 액세스 권한은 다른 작업을 수행하기 전에 갖고 싶은 것입니다.
또 다른 전체 이야기는 업데이트 설치에 관한 것입니다. 나는이 특정 시점에 가지 않을 것입니다 .SF에 대해 많은 질문이 있으며 다른 시스템 관리자 사이에 많은 다른 철학이 있습니다. 나 자신, 나는 꼭두각시 업데이트 일을하자 (예.뿐만 아니라하기로 결정 ensure => installed우리가 예를 들어 꼭두각시 (더 확신 할 때 나중에 일이 작업의 자동화를 떠나) 우리가 이미 사용되므로 수동으로 업데이트를 할. 추가하여 MCollective을 에 믹스).
그것들은 내가 지금 내 마음에 얻은 몇 가지 예였습니다. 꼭두각시에서 손이 닿지 않는 곳에 시스템의 측면이 있습니까? 또는 다른 방법으로, 프로비저닝 시간에 설정해야하는 것과 시스템에서 “정적으로”구성된 것 사이의 선은 어디에 있으며 중앙 집중식 구성 관리를 통해 처리되는 것은 무엇입니까?
답변
일반 규칙 : 구성 관리를 사용하는 경우 구성의 모든 측면을 관리하십시오. 중앙 집중화할수록 환경 확장이 쉬워집니다.
구체적인 예 (질문에서 모든 “이것이 당신이 그것을 관리하고자하는 이유”설명에서 인용) :
IP 네트워크 구성
랙에 장비를 버리기 전에 장비에서 주소 / 게이트웨이 / NS를 구성했습니다. 나머지 구성을 수행하기 위해 어떻게 퍼펫을 실행하지 않겠습니까?
그러나 이제 환경에 다른 이름 서버를 추가하고 모든 시스템을 업데이트해야한다고 가정 해보십시오. 구성 관리 시스템이 그렇게하지 않겠습니까?
또는 회사가 인수되고 새 모회사 가 번호 시스템에 맞도록 192.168.0.0/24 주소에서 10.11.12.0/24로 변경하도록 요구 합니다.
또는 갑자기 대규모 정부 계약을 체결합니다. 단지 캐치 만하면 IPv6 RIGHT FREAKIN ‘NOW를 설정 해야합니다 .
네트워크 구성은 우리가 관리하고 싶은 것 같습니다 …
IPMI 구성
IP 주소와 마찬가지로, 머신을 랙에 넣기 전에이를 설정해야합니다. 기능이있는 머신에서 IPMI, 원격 콘솔 등을 활성화하는 것이 상식입니다. 많이 변하지 않는 …
… 위의 IP 구성에서 언급 한 가상의 획득까지-이 192.168-net 주소를 비워야하는 이유는 새로운 회사의 대주주에 따라 IPMI- 랜드이므로 모든 IPMI 카드를 업데이트해야하기 때문입니다. 지금은 누군가의 예약 된 IP 공간을 짓밟을 것이기 때문입니다.
좋아, 여기에 약간의 확장이 있지만, 당신이 말했듯이 모든 것을 관리 할 수 있으므로 ipmitoolPuppet이 도구를 실행하고 다른 모든 작업을 수행하는 동안 구성을 확인하지 않는 이유는 무엇입니까? 아무것도 아프지 않을 것이므로 IPMI도 포함시킬 수 있습니다 …
업데이트
소프트웨어 업데이트는 회색 영역에 가깝습니다. 조직에서이를 위해 꼭두각시를 평가하고 “아주 부족한”것으로 나타 났으므로이 radmind목적으로 사용 합니다. Puppet이 radmind를 호출 할 수없는 이유는 없습니다. 실제로 구성 관리를 위해 Puppet으로 마이그레이션 할 때 정확히 무슨 일이 일어날 지!
여기서 중요한 것은 모든 업데이트를 표준 방식 (조직 전체 또는 플랫폼 내 표준)으로 설치하는 것입니다. 철저한 테스트를 거친 한 Puppet이 업데이트 프로세스를 시작하지 않아야하는 이유는 없습니다. 꼭두각시가 엉망이되지 않도록 모든 것을.
Puppet이 자체적으로 좋은 일을 할 수 없다고 결정한 경우 Puppet 이이 작업에 더 적합한 도구를 호출 할 수없는 이유도 없습니다 …
답변
바퀴를 재발 명하지 마십시오.
예, 50 개의 퍼펫 가상 사용자 리소스를 보유하고 필요에 따라 모듈에서이를 실현할 수 있지만 가능하면 LDAP를 사용하십시오.
나는 쓴 경험에서 말합니다. ldap은 아직 옵션이 아니지만.
또 다른 예는 DNS를 사용하는 것이 아니라 호스트 파일을 내보내는 것입니다.
답변
- 꼭두각시는 오케스트레이션 시스템이 아닙니다. 특히:
- 꼭두각시 VM은 자체 수명주기가 있기 때문에 VM 오케스트레이션에 적합하지 않습니다.
- 꼭두각시는 응용 프로그램 릴리스 관리 / 복잡한 업그레이드에 적합하지 않습니다. 독립형 퍼펫 실행은이를 위해 악용 될 수 있지만 최소한 퍼펫이 제어하는 것이 아니라 래퍼 스크립트 또는 사람 로봇입니다.
- 꼭두각시 (Puppet)는 훌륭한 사용자 관리 시스템이 아닙니다 ( 삭제 된 사용자까지도 모든 사용자 항목을 효과적으로 관리 해야합니다. 따라서 다른 솔루션을 찾으십시오)
- 꼭두각시는 좋은 구성 데이터베이스가 아닙니다 (일부 종류의 외부 데이터베이스 및 ENC, Hiera 또는 이와 유사한 접착제 사용).
물론 Puppet을 사용하여 이러한 모든 작업을 수행 할 수 있습니다. 그러나 최상의 솔루션은 아닙니다. 때로는 망치를 내려 놓고 렌치를 찾으십시오.
그러나 Puppet은 머신의 기본 구성을 유지 관리하고 VM을 수행하고 오케스트레이션, 사용자 관리 등을 해제 할 수있는 도구를 설치하는 데 매우 능숙합니다.
답변
나는 대부분 voretaq7에 동의하지만 몇 가지주의 사항이 있습니다.
-
시스템이 DHCP를 사용하지 않는 한 꼭두각시에서 IP 주소를 구성하는 경우는 거의 없습니다 (대부분의 “클라우드”공급자가이를 수행한다고 가정). 꼭두각시로 네트워크 구성을 위반 한 상황이 있었지만 노드가 꼭두각시 마스터에게 연락 할 방법이 없었기 때문에 꼭두각시로 구성을 수정할 수 없었습니다.
-
나는 업데이트 관리가 시스템 도구의 손에 달려 있다고 믿으며, 꼭두각시를 영광스러운 크론으로 사용하여 개선하는 것을 보지 못합니다.
답변
필자의 경우 Ruby, Rubygems, build-essential, git 등과 같은 최소 시스템 구성 (Ubuntu)을로드하는 부트 스트랩 스크립트가 있습니다. Puppet 매니페스트는 버전 제어하에 있으며 저장소를 복제합니다. 거기에서 부트 스트랩 스크립트 hostname --short는 유효하다고 가정 하고 시도합니다 puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.
질문에 대답하려면 :
- 내 스크립트는 기본 네트워크 연결 (DNS, IP)을 가정하고 관리하거나 변경하지 않습니다.
- 내 스크립트는 머신의 ID가 정확하다고 가정하고 변경하지 않습니다.
- 내 스크립트는 루비 / 루비 젬 / 망할 놈의 존재하지만, 가정 않습니다 이후 그것을 관리 할 수 있습니다.
답변
네트워크 구성을 위해 꼭두각시를 사용할 필요가 없다고 생각하십시오. 일반적으로 한 번 구성된 것입니다. 또한 IP 또는 MAC 또는 꼭두각시로 가져올 수있는 비슷한 실수가 있으면 쓰레기를 얻을 수 있습니다.