구성 관리자 (예 : Puppet / Chef / Ansible)를 사용하는 것이 언제 적절한가요?

현재 직장에서는 2 개의 VMware 호스트 시스템, OpenBSD 물리적 시스템, 3 개의 데비안 VM 및 6 개의 Windows Server VM (2008/2012)을 살펴 봅니다.

Puppet 또는 Chef와 같은 구성 관리 도구를 구현하려고합니다. 이것이 합리적입니까, 아니면 도구 학습의 오버 헤드가 이점을 능가합니까? 관리 효율성과 구현 비용의 전환점은 어디입니까?

단일 서버 만 관리하더라도 학습 할 가치가 있습니다.

예, 학습 곡선이 있습니다. 예, 당신은 좌절 할 것입니다. 그러나 이러한 비용의 경우, 안정적이고 일관된 원 클릭 배포, 버전 제어 서버 구성, 테스트 / 개발 환경 설정 용이성 등을 통해 여러 번 상환됩니다.

현재 직업의 이점 외에도 이력서에 CM 시스템을 추가 할 수 있다는 것이 큰 승리입니다. 현대의 sysadmin은 이제 숙련되지 않은 경우 구성 관리 시스템 에 최소한 노출 될 것으로 예상됩니다 .

((!) 참고 : 물론 Ansible을 고려 그것은 나의 선호하는 CM, 그리고이다. 아주 쉽게 위로 실행하려면 - 또한, 창문이 잘 따라오고있다 Ansible에서 지원 중 하나를 인형이나 요리사보다 훨씬 쉽다..)

Puppet 또는 Chef와 같은 구성 관리 도구를 구현하려고합니다. 이것이 합리적입니까, 아니면 도구 학습의 오버 헤드가 이점을 능가합니까?

얼마나 많은 시간과 돈을 타야하는지, 그리고 타는 돈인지 아닌지에 따라 합리적입니다.

구성 관리 도구 (그들 중 하나)는 오늘날 시장에서 귀중한 기술이되었습니다.

CM 도구를 배우고 구현하는 데 시간을 투자하는 것이 비즈니스 나 환경의 관점에서 수행하는 가장 효율적인 방법은 아니지만 기술 측면에서는 가치가있을 수 있습니다.

관리 효율성과 구현 비용의 전환점은 어디입니까?

대부분의 구성 관리 도구는 설치 및 진행이 어렵다는 경고와 함께 무료로 제공됩니다.

이 질문은 실제로 서버 관리를 위해 매일 수행하는 작업에 따라 다르므로 대답하기가 약간 어렵습니다. 전혀 많은 작업을 수행 할 필요가 없다면 구성 관리 도구가 완전히 과도 할 수 있습니다.

인프라를 예측 가능하고 기본 상태로 강제 적용해야하는 경우 SaltStack 또는 Ansible과 같은 기본 사항을 선택하는 데 큰 영향을 미치지 않을 수 있습니다.

개인적으로 솔트는 서버로 이동하기 쉽고 부트 스트랩을 매우 쉽게 수행 할 수 있으며 매우 기본적인 원격 실행 및보고에 사용할 수 있습니다.

명심하십시오, 나는 편견이 있습니다. 각 CM 도구를 직접 평가해야합니다.

@EEAA가 말했듯이 서버 수는 관련이 없습니다. 단일 시스템에서 구성 관리를 사용하면 다음과 같은 이점이 있습니다.

• 문서화 된 설정 (CM 스크립트를 통해 문서화 됨)
• 안정적인 배포 (설정을 계속해서 다시 배포 할 수 있음)
• 설정 복원력 (현재 서버 크록 크-새 파일을 회전)
• 재사용 (두 번째 서버가있는 시점에 도달했을 때-이미 첫 번째 서버에서 재활용 할 수있는 CM 스크립트가 있음)
• 업그레이드 (다른 플랫폼 위에있는 새로운 설정과 비슷합니다)

나는 자주 일하지 않고 작은 세부 사항을 모두 잊어 버릴 때 모든 개인 서버에 CM을 구현해야한다고 말할 수 있습니다. CM 스크립트를 사용하는 동안 시간이 많이 걸리는 것처럼 보일 수 있습니다. 장기적으로 설정하는 데 소요되는 시간이 훨씬 더 많이 절약됩니다.

Puppet 및 Ansible에 대한 경험이 있습니다. Puppet은 선언적이지만 절차 적이므로 IMO가 더 간단합니다. 두 가지 모두 장단점이 있지만 꼭두각시의 암호 오류로 인해 머리카락이 충분했습니다.

깨끗하고 재사용 가능한 구성을 만들려면 많은 작업이 필요합니다. 클라우드 또는 클러스터와 같이 매우 유사한 서버가 두 대 이상인 경우 비용이 실제로 지불되기 시작합니다.

그러나 독립 실행 형 서버에서도 일부 사용이 가능합니다. 관리자, 표준 (로컬 변형 포함) sshd, postfix 또는 snmpd 구성을 설정하고 정책 준수 또는 쉘 쇼크 취약성 테스트와 같은 간단한 정보 수집에도 사용할 수 있습니다.

또한 EEAA에서 언급했듯이 서버가 서버를 기본 상태에서 실행 상태로 가져 오는지 확인하면 설정을 문서화하는 값이 있습니다. 변경 사항이 버전 화되고 문서화되도록 버전 관리 시스템 (git)과 결합하는 것이 좋습니다. 관리자 팀이 있으면 매우 유용합니다.

꼭두각시 또는 기타 관리 시스템은 여기에 다른 답변으로 강조 표시된 큰 이점을 제공하지만 관리와 관련하여 은색 총알은 없습니다.

예를 들어 복잡한 시스템에 꼭두각시 클래스를 만들려면 시간과 노력이 많이 들며 때로는 함정이 많기 때문에 찢어 지기도하며 오류 메시지가 항상 100 % 명확하지는 않으며 소프트웨어 업그레이드시 꼭두각시를 새로운 사양에 맞게 조정하는 데 시간을 투자해야합니다 또는 절차 및 이에 가장 적합한 접근 방법 파악 (예 : 선언적이며 업그레이드는 일반적으로 절차 적)

또한 클래스에 대한 변경 사항을 제어 된 방식으로 롤아웃하는 방법과 다양한 버전의 매니페스트를 유지 관리하는 방법을 파악해야합니다.

때가되면 관리 솔루션을 업그레이드하는 방법도 고려해야합니다.

예를 들어 퍼펫 클래스를 작성하는 데 상당한 시간을 소비하는 경우 원 클릭 설치를 많이 수행하여 실제 혜택을 누려야합니다.

나는 여전히 그리고 적절한 곳에서 탐색하는 것이 좋습니다. 예를 들어 설정 파일 배포는 시작하기에 좋은 곳이 될 수 있습니다.