사람들이 CloudInit를 사용하는 대신 Amazon Cloud Formation에서 Puppet / Chef를 사용하는 이유는 무엇입니까?


84

우리는 "미리 베이킹"되지 않은 AMI EC2 인스턴스를 사용할 계획입니다. 즉, 스핀 업되면 AWS Linux의 베어 설치입니다. 부트 스트랩 프로세스는 python, tomcat과 같이 필요한 다양한 설치를 가져옵니다. 최소 3 개의 인스턴스와 최대 8 개의 인스턴스가 있습니다.

이러한 요구 사항을 고려할 때 Amazon Cloud Formation (CloudInit)을 사용하는 것보다 Puppet / Chef를 사용하는 것이 유용할까요?

내가 볼 수있는 가장 좋은 점은 Puppet을 사용했다면 스크립트와 비교하여 무슨 일이 일어나고 있는지 확인하기 위해 감사하기 쉬운 선언적 프로그래밍이 있다는 것입니다. 또한 CloudInit에는 16k 스크립트 크기 제한이 있으며 이는 우리가 실행할 수도 있고 그렇지 않을 수도 있습니다.

내 질문에 대한 답변으로 여기에서 제공 할 수있는 특정 이유로 CloudInit에서 Puppet 또는 Chef로 이동 한 사람이 있습니까?


2
저와 같은 일부 사람들은 CloudFormation에서 간단한 사용자 데이터 스크립트 (cloud-init에서 지원)를 사용합니다. 더 긴 스크립트는 S3에서 다운로드하고 초기 사용자 데이터 스크립트로 실행할 수 있습니다.
Eric Hammond

cloud-init는 불가지론 적이며 여러 클라우드 공급자가이를 사용합니다. AWS, Google 클라우드 플랫폼 및 Microsoft Azure에서 실행할 수 있습니다. ( cloud-init.io ) 반면, AWS :: CloudFormation :: Init는 불가지론 적이 지 않습니다. 아마존 특정입니다.
Jordan Stewart

답변:


83

CloudInit보다 장점이 있습니까? 예, 물론, 그들 중 다수!

물론 CloudInit 스크립트가 서버를 프로비저닝하면 위에서 아래로 실행되도록 작성할 수 있습니다. 하지만 구성 파일을 변경하거나 사용자를 추가하거나 패키지를 업데이트하거나 새 패키지를 설치해야하는 경우 어떻게됩니까? 결국 서버에 로그인하거나이를위한 스크립트를 작성하게되며 불가피하게 서버 상태가 불일치하게됩니다.

CloudInit는 구성 관리가 아닙니다. 구성 관리 소프트웨어를 사용하기로 선택한 경우 Puppet / Chef / 기타 에이전트를 부트 스트랩하는 단 하나의 작업에만 cloud init를 사용합니다.

Puppet은 패키지 설치 자동화, ssh 키 설정 또는 Tomcat 힙 조정에만 도움이되지 않습니다. 그것은 사물의 상태를 보장합니다. 개발자가 오전 3시에 Java 앱 문제를 해결하고 Tomcat 구성을 변경하면 Puppet이이를 다시 변경합니다. 모든 노드 또는 그룹의 Python 버전을 빠르게 변경할 수 있으며 누군가 다른 버전을 설치하면 Puppet이이를 다시 변경합니다.

애플리케이션 스택이 변경되고 RabbitMQ, Jetty 또는 새로운 RDBMS를 사용하기 시작하면 변경 사항을 수만 또는 수천 대의 서버에 쉽게 테스트하고 배포 할 수 있습니다.

백엔드보고, 감사 및 보안 준수와 같은 구성 관리 소프트웨어를 사용하는 다른 많은 이유가 있습니다.


14
때에 따라 다르지. 장기 실행 서비스 (일반적으로 AD, DB)의 경우 구성 관리가 필요할 수 있습니다. 그러나 다른 대체 가능한 폐기 서버의 경우 실제로는 아닙니다. ASG, hadoop 또는 elasticsearch의 클러스터 노드에서 관리되는 웹 서버. 구성을 변경하려면 서버를 버리고 새 서버를 부팅하면됩니다.
Sleeper Smith

64

구성 관리의 전체 요점은 시스템을 예측 가능하고 일관되게 가동하는 것입니다. CloudFormation과 cloudinit는 순전히 AWS로 제한되어있을 때 훌륭하지만 (CloudFormation 템플릿 디버깅은 비참한 경험 이지만) 데이터 센터 리소스와 AWS를 모두 사용하는 애플리케이션이나 로컬 테스트 환경 또는 개발 머신은 어떻습니까?

순전히 AWS에 존재한다면 cloudinit 만 있으면되지만, 규모에 관계없이 모든 애플리케이션에 대해 현실적이라고 확신하지는 못합니다 (예를 들어 Netflix는 작성한 OSS 기술을 사용하여 AMI를 사전 베이킹합니다. 전 세계에 공개되었습니다 . 자세한 내용 은 이 동영상 을 참조하세요.) 고 가용성 애플리케이션은 종종 VPC를 기반으로하는 지역을 초월하며 VPN을 통해 데이터 센터에 백업하는 경향이 있으며 데모, 스테이징, 테스트 또는 개발 환경에도 영향을 미치지 않습니다. 머신 프로비저닝을 담당하는 사람으로서 제가하고 싶은 마지막 일은 반복 작업이거나 여러 프로비저닝 방법을 디버깅하는 것입니다.

따라서 Chef 또는 Puppet. 데이터 센터에서와 마찬가지로 AWS에서도 잘 작동하며, 때때로 즉시 필요한 데모 환경 에서와 마찬가지로 Vagrant 를 실행하는 개발 머신에서도 잘 작동 합니다. cloudinit와 Chef 또는 Puppet을 모두 유지하는 것보다 cloudinit에서 Chef 또는 Puppet을 시작하는 것이 좋습니다.


1
@ u0001와는 : 동영상 링크 고정
크리스토퍼

5

버리는 서버의 경우 자동 확장 그룹 뒤에서 실행한다고 말하면 cloudinit이면 충분할 것입니다. Linux 쉘 스크립트 또는 Windows powershell 스크립트가 트릭을 수행해야합니다.

장기간 실행되는 서버 인 경우 요리사, 꼭두각시 또는 도커를 관리 할 계획이라면 수락 된 답변에 언급 된대로 이점을 얻을 수 있습니다. 사용 후 장점이 보이지 않으면 도구가 필요하지 않을 것입니다.


완전히 동의 해. Puppet과 Chef는 복잡하며 단순히 새 서버를 삭제하고 가져 오는 것만으로 서버를 교체 할 수 있다면 실제로 사용하지 않는 것이 좋습니다. 꼭두각시 / 셰프가 훌륭한 특정 시나리오가 있지만 각 시나리오에서 사용하는 추가 복잡성에 가중치를 두어야합니다.
bobmarksie 2015

0

제 경험상, AWS에서 제공하는 기본 GUI 도구로 쉽게 수행 할 수있는 간단한 작업이 있지만 더 복잡한 작업에 들어가면 바로 사용할 수있는 작업에 제한이 있음을 알게됩니다. 그들의 도구.

이 시점에서 중지하거나보다 복잡한 목표를 달성하고 간단한 작업을 수행하는 데 도움이되는 다른 도구 (예 : Chef 또는 Puppet)를 찾을 수 있습니다.

당신의 선택.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.