답변:
도메인 별 언어는 작성하는 코드의 양에 큰 차이를 만듭니다. 예를 들어 다음과 같은 차이가별로 없다고 주장 할 수 있습니다.
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퍼펫은 서버에서이 모든 것을 컴파일하는 반면 첫 번째 예제에서는 스크립트가 클라이언트에서 실행되어야한다는 점을 제외하고는 스크립트에 넣을 수 있다고 주장 할 수 있습니다 . 따라서 컨텐츠를 변경하는 경우 서버에서만 컨텐츠를 변경해야하며 원하는만큼 많은 시스템에 대해 컨텐츠를 변경해야합니다. 꼭두각시가 종속성을 처리하고 문제를 자동으로 전달합니다.
적절한 구성 관리 도구를 사용하면 시간과 복잡성을 줄일 수 있습니다. 더 많이 시도할수록 더 많은 셸 스크립트가 부적절한 것처럼 보이고 꼭두각시로 수행하면 더 많은 노력을 절약 할 수 있습니다.
이것은 인기가없는 의견이지만 구성 관리 시스템이 반드시 더 좋은 것은 아닙니다. 때로는 단순한 것이 가장 좋습니다.
선택한 구성 시스템과 관련하여 명확한 학습 곡선과 관리 오버 헤드가 있습니다. 결국 의존성을 소개하고 있습니다. 자동화와 마찬가지로 배포 된 구성에서 보안이 유지되도록주의해야합니다.
구성 관리를 배포 한 몇 개의 인스턴스 만 있었지만 문제가 발생했습니다. 반복적 인 구성과 구성 가능한 쿠키 커터 배포를 수행해야하는 수많은 시스템이 항상 존재했습니다.
당신은 당신의 자신의 질문에 대답했습니다 ...
자동화는 더욱 확장 가능하고 형식화되고 있습니다 . 오늘날 꼭두각시와 요리사는 표준으로 간주됩니다 ( 구직 광고 확인 ).
함께 사용되는 쉘 스크립트는 그 자리를 차지하지만 DevOps 이동의 맥락에서 확장 가능 하지 않습니다 . 가독성은 그 일부입니다.
Chef는 복잡한 인프라, 특히 모든 유형의 클라우드 환경에서 표준화되지 않은 방식으로 구성된 셸 스크립트를 수동으로 ftp 또는 scp해야하는 경우 보다 훨씬 쉽게 복잡한 인프라 설정 을 관리하고 버전을 지정할 수 있도록합니다. 얼마나 많은 종속성을 관리해야하는지에 따라이 승리의 규모는 크게 다를 수 있으므로 CM 솔루션으로의 이동 결정은 많은 사람들에게 명백하지 않습니다.
Chef의 실질적인 장점은 종종 dem 등 이다 . 겹치는 관심사로 실행되는 레시피의 조합에 관계없이 리소스의 상태를 확인할 수 있다는 것은 쉘 스크립트 구성에 비해 큰 이점입니다. 지금 구성을위한 쉘 스크립트를 가지고 있다면, 의도하지 않은 / 원치 않는 결과없이 여러 번 실행할 수있는 스크립트가 몇 개인 지 자문 해보십시오.
적절한 CM 솔루션은 플랫폼 간 자동화 및 팀 협업을 단순화하여 대규모의 성공을 보장합니다. 잘 정리되고 적절히 유지 관리되고 버전이 지정된 셸 스크립트 그룹으로이 모든 작업을 수행 할 수 있습니다. "왜"라고 스스로에게 물어야합니다. Chef / Puppet 및 이와 유사한 기술은 재능있는 SysOps 그룹이 동일한 문제를 반복해서 해결하고 더 나은 옵션을 제공하기 시작하는 데 지 쳤기 때문에 생겨났습니다.
Puppet 및 Chef와 같은 최신 구성 관리 도구를 사용하면 구성된 서버를 달성하는 데 필요한 활동 을 걱정하지 않고 시스템 상태 를 정의 할 수 있습니다 .
예를 들어, chmod 명령은 파일이 존재하고 파일을 소유 한 사용자가 존재하며 디렉토리가 작성되었다고 가정합니다. 따라서 스크립트는 이러한 전제 조건을 모두 고려해야합니다.
상태 기반 구성 관리 도구가 더 간단합니다. 파일에 올바른 권한이 있는지 확인하면됩니다. 그것이 달성되는 방법은 도구의 문제입니다.
chmod는 파일이 스크립트에 의해 생성되었거나 존재 여부를 테스트했기 때문에 파일이 존재한다고 가정하지 않습니다.
서버를 사용할 수 있거나 한 번에 두 개 이상 일 어설 경우 전체 CM 시스템은 일련의 셸 스크립트보다 요구 사항을 훨씬 더 잘 충족시킬 수 있습니다.
빌드 요구 사항이 적당하지 않거나 유기적 인 자유 범위 공정 거래 서버를 수공으로 제작하려는 경우 간단하게 유지하십시오.
개인적으로 과거 공연에서 요리사를 광범위하게 사용 하면서이 공연에서 '간단하게 유지'하려고했지만 요리사가 제공 한 기본 요소, 추상화 및 힘을 실제로 놓쳤습니다. 몇 개의 쉘 명령으로 필요한 것을 얻을 수있는 상황이 되더라도 쉘에 쓰듯이 정확하게 쉘 명령을 입력하여 'command'블록으로 명령을 실행할 수 있습니다.
그렇게 말하면 서버 (chef-solo)없이 Chef를 실행할 수 있으며 Puppet에 아날로그가 있으므로 중앙 서버를 실행하지 않고도 다른 요리 책과 요리법을 활용할 수 있습니다.
또 다른 이점은 커뮤니티입니다. 많은 사람들이 있습니다 (많은 사람들이 당신보다 똑똑하고 경험이 풍부 할 것입니다). 개인적으로 나는 다른 사람이 나를 위해 더 많은 일을했을 때 그것을 좋아합니다.
쉘 스크립트 기반 서버 자동화 프레임 워크를 생성했습니다 : https://github.com/myplaceonline/posixcube
나는 이런 종류의 프로젝트를 만든 최초의 사람은 아니지만 내 요구에 맞는 것과 같은 것을 찾을 수 없었기 때문에 다른 사람들이 이것을 유용하다고 생각했습니다. 나는 Chef와의 경험 만 있었지만 Ansible과 다른 것들을 둘러보기 시작하면서 쉘 스크립트를 보여주고 싶었고 결과는 지금까지 좋아합니다.