쉘 스크립트보다 Chef / Puppet을 사용하는 이유는 무엇입니까?


81

꼭두각시 및 요리사 도구를 처음 사용합니다. 그들이하고있는 작업은 쉘 스크립팅으로 수행 할 수있는 것 같습니다. 어쩌면 쉘 스크립트에서 수행되었을 수도 있습니다.

나는 그들이 더 읽기 쉽다는 것에 동의합니다. 그러나 읽기만하는 것 외에 쉘 스크립트에 비해 다른 장점이 있습니까?

답변:


56

도메인 별 언어는 작성하는 코드의 양에 큰 차이를 만듭니다. 예를 들어 다음과 같은 차이가별로 없다고 주장 할 수 있습니다.

chmod 640 /my/file

file { "/my/file":
    mode => 640,
}

그러나 이것들 사이에는 큰 차이가 있습니다.

FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
     # where the URL contains "Hello world"

file { "/my/file":
    mode => 640,
    owner => foo,
    group => bar,
    content => "Hello world",
}

wget이 실패하면 어떻게됩니까? 스크립트가 어떻게 처리합니까? 그리고 스크립트에 $ FILE이 있어야 올바른 내용이 포함 된 무언가가 있으면 어떻게됩니까?

echo "Hello world" > $FILE퍼펫은 서버에서이 모든 것을 컴파일하는 반면 첫 번째 예제에서는 스크립트가 클라이언트에서 실행되어야한다는 점을 제외하고는 스크립트에 넣을 수 있다고 주장 할 수 있습니다 . 따라서 컨텐츠를 변경하는 경우 서버에서만 컨텐츠를 변경해야하며 원하는만큼 많은 시스템에 대해 컨텐츠를 변경해야합니다. 꼭두각시가 종속성을 처리하고 문제를 자동으로 전달합니다.

적절한 구성 관리 도구를 사용하면 시간과 복잡성을 줄일 수 있습니다. 더 많이 시도할수록 더 많은 셸 스크립트가 부적절한 것처럼 보이고 꼭두각시로 수행하면 더 많은 노력을 절약 할 수 있습니다.


9
@Paul Gear, 구성 관리 도구가 장기적으로 나아가는 길이라고 말하는 것은 지나치게 단순화 된 것입니다. 예를 들어, AWS를 사용하면 셸 스크립트가 서버를 처음부터 구축하고 몇 가지 테스트를 실행할 수 있으며, AWS 안정성이 확인되면 이미지를 만들 수 있습니다. 그런 다음 이미지를 미리 테스트하거나 스테이징 환경에 배치하여 추가 테스트를 수행 할 수 있습니다. 이미지의 유효성을 검증 한 후 프로덕션 환경으로 전환하십시오. 이 시나리오에서는 구성 관리 도구가 전혀 도움이되지 않습니다.
Derek Litz

사람들이 매일 사용하는 100 대의 전용 서버를 관리하고 싶다면 (실수 여부에 대한 제어 권한이 거의 없음) 구성 관리 도구를 사용해야합니다.
데릭 리츠

6
이것은 매우 설득력있는 예가 아닙니다. 나는 wget으로 시작할 수 있었고 이상한 상태로 끝나지 않을 것입니다. 단계 중 하나라도 성공하지 못하면 롤백되는 트랜잭션과 같은 파일입니까?
PSkocik

33

이것은 인기가없는 의견이지만 구성 관리 시스템이 반드시 더 좋은 것은 아닙니다. 때로는 단순한 것이 가장 좋습니다.

선택한 구성 시스템과 관련하여 명확한 학습 곡선과 관리 오버 헤드가 있습니다. 결국 의존성을 소개하고 있습니다. 자동화와 마찬가지로 배포 된 구성에서 보안이 유지되도록주의해야합니다.

구성 관리를 배포 한 몇 개의 인스턴스 만 있었지만 문제가 발생했습니다. 반복적 인 구성과 구성 가능한 쿠키 커터 배포를 수행해야하는 수많은 시스템이 항상 존재했습니다.


10
환경 관리 비용이 너무 커서 자동화 관리가 훨씬 저렴할 때. Git에서 관리되는 변경 사항을 스크립팅하거나 ssh 멀티플렉서에서 설정하는 것이 더 간단한 경우 우리는 그렇게합니다. 나에게 가장 중요한 것은 시스템을 모니터링하고 모든 것이 예상대로 작동하는지 확인하는 것입니다. 무언가 잘못 구성되었을 때 경고를받는 한, 구성 방법이 그렇게 중요하지는 않습니다.
kenchilada

10
@ewwhite "자동화하기로 결정했을 때" xkcd.com/1205
MikeyB

3
Ansible과 같은 최신 도구는 Chef 또는 Puppet보다 배포 / 관리 오버 헤드가 상당히 적으므로 종속성이 거의 없거나 전혀 없습니다 (특히 에이전트 없음). 이로 인해 채택 기준이 실제로 낮아집니다.
GomoX

2
@ewwhite 개인 생산성을 원할 때 자동화합니다. 자동화를 통해 배우고 일상적인 작업을 통해 배우지 않습니다. 학습 = 생산성 향상 및 반복 개선. 자동화는 이것과 결합하여 더 많은 긍정을 만들어냅니다. 부정적인 눈이 아니라 긍정적 인 눈덩이입니다. 기술 진보 대 기술 부채.
Derek Litz

2
@ABB 아니요, 암시되지 않습니다. 쉘 스크립트는 언급하지 않고 자동화를 일반적인 관행으로 언급합니다. 쉘 스크립트를 사용하여 작업을 자동화하고 수동으로 작업하는 대신 스크립팅 추상화를 배울 수 있습니다.이 작업을 다시 수행하면 시간을 절약 할 수 있으며 실수를 방지 할 수 있습니다. 또한 다음 스크립트를 마지막 스크립트보다 조금 더 잘 작성할 수 있어야합니다. 긍정적 인 눈덩이 ... 그러나 스크립트 작성 전문가이며 다시 실행할 스크립트를 작성하지 않으면 시간을 배우거나 절약하는 데 도움이되지 않습니다.
Derek Litz

23

당신은 당신의 자신의 질문에 대답했습니다 ...

자동화는 더욱 확장 가능하고 형식화되고 있습니다 . 오늘날 꼭두각시와 요리사는 표준으로 간주됩니다 ( 구직 광고 확인 ).

함께 사용되는 쉘 스크립트는 그 자리를 차지하지만 DevOps 이동의 맥락에서 확장 가능 하지 않습니다 . 가독성은 그 일부입니다.


7
쉘 스크립트가 어떻게 공식화되지 않습니까? 구인 광고를 인용하면 설득력있는 주장을 할 수 있습니까? 그리고 개발자는 개발자로서 착취 당하기 때문에 개발자가 부끄러운 일입니다. 이 링크는 확장성에 대해 아무 것도 말하지 않습니다. 쉘 스크립트가 확장 가능하지 않다는 주장이 있습니까? 꼭두각시가 흥미 롭다고 생각하지만 반드시 대답의 이유가있는 것은 아닙니다.
Acumenus

직업 광고는 특정 기술에 대한 실제 시장을 반영합니다. 예, 의도 한 목적으로 구성 관리를 사용하는 것이 쉘 스크립트보다 확장 성 있고 강력하며 문서화가 쉽습니다. 나는 많은 환경에 있었고, 내가 본 대부분의 스크립트는 "생산 품질"로 간주되고 예외를 처리하도록 구성되지 않았습니다. 이유를 이해하려면 허용 된 답변을 참조하십시오.
ewwhite

1
"개발자 들로서 착취 당하고 있기 때문에 개발자들은 매우 부끄러운 일입니다." 이것은 단순히 사실이 아닙니다. DevOps는 웹 개발과 마찬가지로 개발 전문 분야입니다. 소프트웨어 개발의 패턴과 관행은 여전히 ​​적용됩니다. DevOps에 대해 읽어야합니다.
Chaim Eliyah

13

Chef는 복잡한 인프라, 특히 모든 유형의 클라우드 환경에서 표준화되지 않은 방식으로 구성된 셸 스크립트를 수동으로 ftp 또는 scp해야하는 경우 보다 훨씬 쉽게 복잡한 인프라 설정 을 관리하고 버전을 지정할 수 있도록합니다. 얼마나 많은 종속성을 관리해야하는지에 따라이 승리의 규모는 크게 다를 수 있으므로 CM 솔루션으로의 이동 결정은 많은 사람들에게 명백하지 않습니다.

Chef의 실질적인 장점은 종종 dem 등 이다 . 겹치는 관심사로 실행되는 레시피의 조합에 관계없이 리소스의 상태를 확인할 수 있다는 것은 쉘 스크립트 구성에 비해 큰 이점입니다. 지금 구성을위한 쉘 스크립트를 가지고 있다면, 의도하지 않은 / 원치 않는 결과없이 여러 번 실행할 수있는 스크립트가 몇 개인 지 자문 해보십시오.

적절한 CM 솔루션은 플랫폼 간 자동화 및 팀 협업을 단순화하여 대규모의 성공을 보장합니다. 잘 정리되고 적절히 유지 관리되고 버전이 지정된 셸 스크립트 그룹으로이 모든 작업을 수행 할 수 있습니다. "왜"라고 스스로에게 물어야합니다. Chef / Puppet 및 이와 유사한 기술은 재능있는 SysOps 그룹이 동일한 문제를 반복해서 해결하고 더 나은 옵션을 제공하기 시작하는 데 지 쳤기 때문에 생겨났습니다.

주요 작품 :

  • dem 등식
  • 종속성 관리 용이성 (버전 관리)
  • 표준화 된 조직 (업계 수준에서 수용 됨)
  • 서버 구성 작업을 시스템 수준 세부 정보와 분리하기위한 추상화
  • 지역 사회 지식을 활용하는 능력 (위의 모든 원칙을 수용하도록 보장됨)

3
ss로는 dem 등성이 거의 불가능합니다. 종속성은 yum / apt 등으로 잘 관리됩니다. 수락은 관련이 없습니다. ss에 대한 커뮤니티 지식이 있습니다. 그러나 많은 스크립트를 복사 할 필요가없고 중앙에 시스템을 구성 할 필요가 없다는 점에 동의합니다. 꼭두각시에는 클라이언트 측 에이전트가 필요하다고 들었습니다.
Acumenus

10

Puppet 및 Chef와 같은 최신 구성 관리 도구를 사용하면 구성된 서버를 달성하는 데 필요한 활동 을 걱정하지 않고 시스템 상태 를 정의 할 수 있습니다 .

예를 들어, chmod 명령은 파일이 존재하고 파일을 소유 한 사용자가 존재하며 디렉토리가 작성되었다고 가정합니다. 따라서 스크립트는 이러한 전제 조건을 모두 고려해야합니다.

상태 기반 구성 관리 도구가 더 간단합니다. 파일에 올바른 권한이 있는지 확인하면됩니다. 그것이 달성되는 방법은 도구의 문제입니다.


1
실제로 필자 chmod는 파일이 스크립트에 의해 생성되었거나 존재 여부를 테스트했기 때문에 파일이 존재한다고 가정하지 않습니다.
Acumenus

9

서버를 사용할 수 있거나 한 번에 두 개 이상 일 어설 경우 전체 CM 시스템은 일련의 셸 스크립트보다 요구 사항을 훨씬 더 잘 충족시킬 수 있습니다.

빌드 요구 사항이 적당하지 않거나 유기적 인 자유 범위 공정 거래 서버를 수공으로 제작하려는 경우 간단하게 유지하십시오.

개인적으로 과거 공연에서 요리사를 광범위하게 사용 하면서이 공연에서 '간단하게 유지'하려고했지만 요리사가 제공 한 기본 요소, 추상화 및 힘을 실제로 놓쳤습니다. 몇 개의 쉘 명령으로 필요한 것을 얻을 수있는 상황이 되더라도 쉘에 쓰듯이 정확하게 쉘 명령을 입력하여 'command'블록으로 명령을 실행할 수 있습니다.

그렇게 말하면 서버 (chef-solo)없이 Chef를 실행할 수 있으며 Puppet에 아날로그가 있으므로 중앙 서버를 실행하지 않고도 다른 요리 책과 요리법을 활용할 수 있습니다.

또 다른 이점은 커뮤니티입니다. 많은 사람들이 있습니다 (많은 사람들이 당신보다 똑똑하고 경험이 풍부 할 것입니다). 개인적으로 나는 다른 사람이 나를 위해 더 많은 일을했을 때 그것을 좋아합니다.


1

쉘 스크립트 기반 서버 자동화 프레임 워크를 생성했습니다 : https://github.com/myplaceonline/posixcube

나는 이런 종류의 프로젝트를 만든 최초의 사람은 아니지만 내 요구에 맞는 것과 같은 것을 찾을 수 없었기 때문에 다른 사람들이 이것을 유용하다고 생각했습니다. 나는 Chef와의 경험 만 있었지만 Ansible과 다른 것들을 둘러보기 시작하면서 쉘 스크립트를 보여주고 싶었고 결과는 지금까지 좋아합니다.

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