답변:
물론 Puppet, Ansible, Chef 각각에 대해 몇 가지 장단점이 있으며 여기에 좋아하는 도구를 추가하십시오 . 그래서 저는 의견을 멀리하고 Ansible의 장점을 사실로 공유하려고 노력할 것입니다.
Ansible을 다른 것보다 우선하는 주요 기능은 대상 노드에서 실행되는 일부 사용자 정의 / 추가 에이전트에 의존하지 않고 ssh 연결에서만 발견되는 것입니다. 예, 여전히 노드에 ssh 서버, Python 및 많은 Python 라이브러리가 필요하며 선택한 배포판 (또는 행운이 있거나 일부 Windows 노드가 있음)이 제공되지 않으면 조금 있습니다. 부트 스트랩에 고통. 그러나 그것은 가능하지 않으며, 심지어 당신의 배포판에 대해 다시 생각하게 할 수도 있습니다.
이렇게하면 모니터링을 단순화하고 추가 리소스를 소비하지 않으며 시스템이 항상 데몬을 루트로 강제 실행하지 않으며 일반적으로 UNIX 철학에서 더 나은 느낌을받습니다. Chef는 chef-soloPuppet을 마스터없이 실행할 수 있지만 각각 복제 및 후크를 통해 "다른 방향"으로 작동합니다. Ansible을 사용하는 동안 소스 리포지토리를 병합하면 Jenkins, git master 또는 Rundeck과 같은 다른 도구와 같이 우리 모두가 편한 방식으로 배포를 시작할 수 있습니다.
template모듈은이를 매우 쉽게 만듭니다.
아니요, Puppet에서 Ansible (또는 그 반대로)로 이동하는 사람들은 두 도구를 사용하여 수행 할 수 있거나 수행 할 수없는 것과 관련이 없습니다. 꼭두각시 / 요리사 / 맛보기-그것은 주로 맛의 문제입니다.
예를 들어 Ansible은 Python을 기반으로하며, Python 개발자는 일반적으로 DSL을 배울 필요가없는 Ruby 또는 Chef (요리사)를 선호합니다. Python 개발자가 Ansible을 쉽게 확장 할 수 있습니다.
그러나 본질적으로 그들은 당신이 달성 할 수있는 점에서 모두 매우 유사합니다. 일부는 일부 영역에서는 상대적 강점과 다른 영역에서는 약점이 있지만 일반적으로 팀의 스타일 / 문화 / 선호도에 따라 선택됩니다.
Puppet 4.0까지는 여러 서버 나 서비스에서 응용 프로그램 분산 을 조정하는 쉬운 방법이 없었 습니다 . 이는 Puppet에서 작업을 구체적으로 주문하기가 어려웠 기 때문에 설계 선택이었습니다 . Ansible은 특히 여러 서버에서 단계를 조정하고 주문하는 데 더 나았습니다. 이는 잘못된 순서의 단계로 인해 최종 일관성에 도달 할 때까지 해당 단계를 반복하여 오류를 복구 할 수없는 응용 프로그램에서 특히 중요했습니다.
그것은 더 이상 문제가 아니기 때문에 구별은 주로 선호를 기반으로합니다.