작은 사람들이 어떻게 꼭두각시를 효과적으로 배우고 사용할 수 있습니까? [닫은]

6 개월 전, 비영리 프로젝트에서 서버 수가 현재와 1 년 사이에 실질적으로 증가 할 것으로 예상하기 때문에 시스템 관리를 Puppet 제어 환경으로 마이그레이션하기 시작했습니다.

결정이 내려진 이후 IT 직원들은 너무 자주 짜증을 냈습니다. 그들의 가장 큰 반대는 :

• "우리는 프로그래머가 아니며 시스템 관리자입니다";
• 모듈은 온라인에서 사용할 수 있지만 많은 모듈이 서로 다릅니다. 바퀴가 너무 자주 재발견되고 있습니다.
• 리포지토리의 코드는 투명하지 않아서 오래 전에 작성했을 수도있는 매니페스트와 모듈을 통해 어떻게 되풀이해야하는지 알아 봅니다.
• 하나의 새로운 데몬은 새로운 모듈을 작성해야하며, 규칙은 다른 모듈과 유사해야하며 어려운 프로세스입니다.
• "그냥 실행하고 작동 방식을 보자"
• 커뮤니티 모듈에서 알려지지 않은 수많은 '확장': 'trocla', 'augeas', 'hiera'... 시스템 관리자는 어떻게 추적 할 수 있습니까?

대규모 조직이 sysadmin을 Puppet 코스에 파견하여 Puppet 마스터가되는 이유를 알 수 있습니다. 그러나 소규모 플레이어가 코스에 가지 않고 기본적으로 브라우저와 편집기를 통해 배우면 퍼펫을 전문가 수준으로 배우는 방법은 무엇입니까?

나는 앞서 새로운 인프라를 배포 인형을 사용하기 시작 단순히 (구입 잘 간주 주제에) 책을. 나는 대부분의 사람들이 실제로 전문적인 꼭두각시 훈련을 얻는다고 생각하지 않습니다. 프로세스를 환경에 맞게 만들 수있을 때까지 예제를 작업했습니다. 이것은 2011 년 12 월이므로 몇 주 안에 기본 사항을 이해하고 제작 프레임 워크를 마련 할 수있었습니다. CFEngine에 대한 배경 지식 이있는 구성 관리에 익숙 하지 않았지만 많은 sysadmins의 우려가 공명합니다. 실수를해서 여러 번 리팩토링해야했지만 일이 만족스럽게 이루어졌습니다.

당신의 요점에 대한 몇 가지 메모 ...

• 전통적인 시스템 관리 역할이 변화하고 있습니다. 적응하거나 남겨 두십시오. 나는 성공적인 시스템 엔지니어 였지만 도구도 수정해야합니다 (예 : Python을 배우십시오). 가상화를 통한 하드웨어 추상화와 퍼블릭 및 프라이빗 클라우드 서비스가 관심을 끌면서 개별 서버에 대한 관심이 줄어 듭니다. 이는 시스템 작업 자동화 및 구성 관리를 사용하여 많은 수의 서버를 제어하는 ​​것을 의미합니다. 믹스에 DevOps 개념 을 추가 하면 고객 / 최종 사용자의 기대 와 요구 사항이 변경되고 있음을 알 수 있습니다.

• 온라인에서 사용할 수있는 꼭두각시 모듈은 스타일과 구조가 다르므로 중복, 중복 및 중복 된 노력이 많이있었습니다. 내가 함께 일한 한 개발자는 "온라인에서 작동하는 것을 찾는 데 자신 만의 도구를 개발했을 수 있습니다!"라고 말했습니다. Puppet이 모범 사례 또는 올바른 방법을 찾는 관리자보다 개발자 유형에 더 호소력이 있음을 깨달았습니다 .

• 사물이 어떻게 연결되어 있는지 느끼기 위해 많이 문서화하십시오. 흔들리는 정의와 표준 작업 방식이 없기 때문에 구성 관리 구조는 실제로 환경에 고유합니다. 그 투명성은 내부에서 개발되어야 할 것입니다.

• 서버와 역할을 구성한 방식에 따라 모듈을 복제하여 새 데몬을 수용하거나 기존 매니페스트에 서비스를 추가하는 것이 상당히 쉽다고 주장합니다.

• 더 큰 서버 그룹으로 변경 사항을 적용하기 전에 단일 대상에서 테스트하는 데 많은 시간을 보냈습니다. 대표 서버에서 직접 인형을 실행하면 변경 사항을 디버깅하고 그 영향을 평가할 수있었습니다. 어쩌면 그것은 약간 보수적이지만 필요했습니다.

• 커뮤니티 모듈에 얼마나 의존하는지 잘 모르겠습니다. 나는 몇 가지 작업에 Augeas를 사용 하기 시작 했고 그것이 CFEngine에서 당연한 기능이라는 사실을 애도했습니다.

결국, 꼭두각시에 관해서는 잘 정의 된 표준이없는 것 같습니다. Puppetmaster에서 디렉토리 구조를 구성하는 방법, 인증서 서명을 관리하는 방법 이해, 모든 곳에서 적절한 역방향 DNS 가져 오기, Puppet을 통해 환경 에 맞게 확장 할 수있는 방법, 커뮤니티 모듈을 활용하는시기 및 자체 빌드를 이해하는 방법을 이해하는 데 어려움이있었습니다 . 그것은 생각의 변화이며 그것이 시스템 관리자를 공황 상태로 만드는 방법을 봅니다. 그러나 이것은 처음부터 구축 된 솔루션이므로 도구를 평가하는 데 고급 스러움이있었습니다. 이 방법으로 가기로 한 결정은 마음가짐과 퍼펫의 추진력을 바탕으로 한 것입니다. 새로운 것을 배우려는 노력의 가치가있었습니다.

기억 이 사이트가 너무 좋은 자원이다.

이전 작업에서 Puppet의 파일럿 구현 작업을 맡았습니다. 이제는 Ruby가 아닌 프로그래밍 배경을 가지고 있으므로 다른 사람들만큼 문제가 없습니다.

그러나 전통적이지 않은 패러다임에 경험이없는 프로그래머 도 Puppet에 문제가 있습니다. Puppet은 명령적인 것이 아니라 선언 적이기 때문 입니다. 이런 의미에서 Puppet은 구성 파일과 거의 비슷하게 작동합니다. 상황을 설명하고 Puppet이 나머지를 처리합니다.

조종사 후에 저는 12 명의 다른 관리자에게 Puppet을 교육하고 두 가지 행사에서 이에 대한 프레젠테이션을 할 수있었습니다. 그 경험에서 내가 얻은 것은 일부 관리자가 가져 갔지만 일부 관리자는 그렇지 않았습니다. 이들은 프로그래밍 기술과 다양한 수준의 전문 지식이없는 전통적인 관리자였습니다.

내가 주목 한 한 가지는 꼭두각시가 지속적인 연습이 필요 하다는 것 입니다. 훈련을 받고 모듈을 작성한 다음 한 달 또는 두 달 동안 다른 일을하는 사람들은 거의 유용한 기술을 가지고 꼭두각시로 돌아 왔습니다. 매주 작은 일을 계속했던 사람들은 결코 능력을 잃지 않았습니다.

이 두 가지 관찰을 바탕으로 모든 사람이 매주 Puppet 클래스, 정의 또는 모듈을 추가하는 것이 좋습니다 (적어도 두세 번 이상). 여전히 그것에 익숙하지 않은 사람들은 그것을 할 수있는 기술이 부족할 수 있습니다.

다시 말하면, 꼭두각시가 상위에서 그들에게 부과 된 경우, 그들은 단순히 그들이 일하는 방식을 방해하는 경영진으로 인식 한 것에 반응하고있을 것입니다. 그것은 그들에게 선택하게하는 경우가 될 수 있는 상황을 개선 할 사용하는 구성 관리 시스템. 대안은 다음과 같습니다.

• ANSIBLE : 이것은 새로운 기능이지만 쉘 명령과 ssh를 기반으로하므로 기존의 sysadmins에게 유도 할 수 있습니다.
• Chef : 어쩌면 그들의 문제는 선언적인 스타일 일 것입니다.이 경우 Chef는 Ruby 경험이 있다면 더 나을 것입니다.
• SaltStack : 파이썬 기반 및 오픈 소스
• CFEngine : 오래되고 빠르며 전통적입니다.

필자는 유일하게 시스템 관리자 인 작은 상점에서 2 년 동안 Puppet을 사용했습니다. 내가 가진 가장 큰 장애물은 소프트웨어를 올바르게 개발하는 방법을 배우는 것입니다. 개발자들에게 12 번을하지 말라고 말한 것을 망치지 않은 1 주일이 지나지 않았습니다. 너무 많은 코드를 체크인하고 체크인하지 않았으며 태그를 지정하지 않았으며 분기하지 않았으며 구문 검사기를 실행하지 않았으며 표준을 사용하지 않았습니다. 나는 다음 중 일부를 추천합니다.

1. 수행 방법을 모르거나 제대로 수행하지 못하는 소프트웨어를 개발하고 있음을 인식하십시오. 새로운 것이기 때문입니다.
2. 코드로서의 인프라는 현실이며 일단 혹을 극복하면 상당히 강력합니다. 나는 일부 개발자들을 초대하고, 현재 개발 프로세스 (또는 부족한)를 보여주고, 눈썹을 올릴 때 공격을받지 않으며, 제안을 진지하게 받아들입니다. 완전히 부적절하지 않은 한 개발자가 사용하는 시스템과 프로세스를 사용하는 것이 좋습니다.
3. 꼭두각시 타사 모듈은 90 %의 시간을 소비합니다. 나는 그들을 읽었다. 나는 그들로부터 아이디어를 훔칠 것입니다. 주요 편집없이 시스템으로 가져 오지 않습니다. 그러나 멋진 기능을 추가하는 꼭두각시 stdlib를 가져옵니다.
4. augeas와 hiera. 그 두 가지를 배우십시오. 첫 번째는 기존 파일의 복잡한 편집을 가능하게합니다. 두 번째는 외부 데이터 저장소입니다.
5. 데이터와 코드를 분리하십시오. 이것은 배우기가 더 어려운 개념 중 하나입니다. 모니터링 호스트와 같은 값을 모듈 코드로 하드 ​​코딩하는 것은 좋지 않습니다. 모듈이 소비 할 수있는 데이터 저장소 (db, yaml (Hiera는 이것을 기본값으로 사용), csv 등)에 넣는 것이 좋습니다. 예를 들어 Mysql을 사용하는 웹앱이 있습니다. 이것이 허용하는 것은 코드와 데이터를 개별적으로 푸시하는 기능입니다. 이를 통해 개발 프로세스가 더 간단 해집니다.
6. 퍼펫 파서 는 사전 또는 사후 코드 체크인 프로세스의 일부로 유효성 검사 및 꼭두각시 린트 를 제공합니다. 또한 rspec 테스트는 속도가 빨라지면 좋은 아이디어 일 수 있습니다.
7. 스타일 가이드 / 코드 표준을 작성하여 사용하십시오. "아파치를 설치하는 코드는 어디에 있습니까?"는 일반적인 문제입니다. 모듈이 대부분 같으면 쉬워야합니다.

요약하면이 모든 문제에 부딪 쳤으므로 대부분의 sysadmin 친구가 있습니다. 구성 관리 시스템을 잘 사용하려면 시간이 다소 걸립니다. 일단 당신이 당신이없이 어떻게 살았는지 궁금해 할 것입니다. "서버에 로그인하여 수동으로 변경 하시겠습니까? Ick."

6 개월 전, 비영리 프로젝트에서 서버 수가 현재와 1 년 사이에 실질적으로 증가 할 것으로 예상하기 때문에 시스템 관리를 Puppet 제어 환경으로 마이그레이션하기 시작했습니다.

퍼펫은 구성 관리 이상의 의미를 지니고 있으며 문서 형태입니다.

결정이 내려진 이후 IT 직원들은 너무 자주 짜증을 냈습니다.

태도 조정이 필요합니다.

"We're not programmers, we're sysadmins";

다시, 태도. 서버용 conf 파일을 만들 수 있습니까? 요구 사항과 복잡성 이 진화함에 따라 템플릿 / '프로그래머'항목을 쉽게 처리 할 수 ​​있습니다 .

모듈은 온라인에서 사용할 수 있지만 많은 모듈이 서로 다릅니다. 바퀴가 너무 자주 재발견되고 있습니다.

대답하기 힘든 하나-나는 항상 가장 꼭두각시 모듈을 선호합니다. 판단은 확실하다. 제 생각에는 일부 모듈은 '너무 까다 롭습니다'.

리포지토리의 코드는 투명하지 않아서 오래 전에 작성했을 수도있는 매니페스트와 모듈을 통해 어떻게 되풀이해야하는지 알아 봅니다.

꼭두각시 문제처럼 들리지 않지만 조직이나 문서 문제가 더 많습니까?

하나의 새로운 데몬은 새로운 모듈을 작성해야하며, 규칙은 다른 모듈과 유사해야하며 어려운 프로세스입니다.

그 데몬은 관리하기에 간단하다면 클래스가 될 수 있습니다. 나는 당신이 컨벤션에 의해 무엇을 의미하는지 잘 모르겠습니다. 아니면 코드 형식을 따라 이야기하고 있습니까?

"Let's just run it and see how it works"

느리고 안전하다고 생각하면 나쁘지 않습니다. 나는 여전히 요점을 얻기 위해 VM으로 시작합니다.

커뮤니티 모듈에서 알려지지 않은 수많은 '확장': 'trocla', 'augeas', 'hiera'... 시스템 관리자는 어떻게 추적 할 수 있습니까?

postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl modules .. 원하는 것을 고르고 사용 하시겠습니까? 이 소리가 다시 태도 같은 것 같아요 ...

대규모 조직이 sysadmin을 Puppet 코스에 파견하여 Puppet 마스터가되는 이유를 알 수 있습니다. 그러나 소규모 플레이어가 코스에 가지 않고 기본적으로 브라우저와 편집기를 통해 배우면 퍼펫을 전문가 수준으로 배우는 방법은 무엇입니까?

내가 어떤 과정에 참석하지 않은 - 나는 동안 생각 은 sysadmin보다 더 많은 프로그래머, 나는 그것이 성취 아무것도 얻을 수있는 많은 프로그래밍 기술을 필요로하지 않았다 발견했다.

꼭두각시 문서는 매우 철저합니다. 내장 유형에주의를 기울이고 다른 모듈이 어떻게 구성되는지 살펴보십시오. 나는 그것이 매우 쉽다고 말하지는 않지만, 그렇게 어렵지는 않습니다. 꼭두각시를 위해 인프라를 준비하는 데 약간의 시간이 걸리지 만 확장 할 때 투자 한 시간을 잘 보내야합니다.

KISS (간단한 바보 유지)-새로운 기술은 요구 사항이 있기 때문에 존재하기 때문에 사용하지 마십시오. 배치에 필요한 최소 요구 사항을 사용하고 필요에 따라 업데이트하십시오. 가장자리. 기본 설정으로 시작하여 빌드하면 더 쉽게 선택할 수 있으며 코스가 필요하지 않습니다 (이것도 가능합니까?).

다른 영역은 시스템 관리자입니다. 그들이 프로그래밍을 할 수 없다면, 어떤 도구를 사용하든 대부분의 작업을 스크립팅해야하는 대규모 배포에 충분한 수준을 유지하고 있습니까?

나는 비영리 단체에서도 일하고 ​​있으며 처음에는 Linux 박스를 집에 가져오고 그 직후에 Puppet을 관리해야했습니다. 우리가 한 일이 실제로 진행되는 데 도움 이 된 몇 가지 구체적인 일이 있습니다 .

가장 먼저 나는 타사 모듈을 멀리하려고 노력했다. 기본 제공 도구는 관리의 90 %를 처리합니다. 내가 사용하는 가장 큰 타사 유틸리티는 방화벽 모듈입니다. 모든 사용자 정의 사실 등은 전체 팀과 함께 개발됩니다. 템플릿 모듈을 개발하고 파일 관리, 패키지, 서비스 등을 모두이 템플릿에서 표준화 한 상태로 유지합니다.

둘째, 내장 모듈 사용을 표준화 한 후 Git 및 Atlassian 's Crucible을 사용하여 모든 구성 변경 사항을 검토하기 위해 비영리 무료로 사용하기 시작했습니다. 이것은 원하는 투명성을 제공합니다.

셋째, 기본 옵션 세트로 새 호스트를 자동으로 추가 할 수 있도록 Puppet 설정을 자동화했습니다. 이 문제를 해결하는 방법에는 여러 가지가 있습니다. 이미 완전한 킥 스타트 환경이 있었기 때문에 스크립트를 추가하기로했습니다.

"우리는 프로그래머가 아니라 시스템 관리자입니다."

저와 같은 회색 수염은 전문 프로그래머보다 더 나은 프로그래머 가 될 것으로 예상 되거나 시스템 관리자 에게 결코 전달할 수 없었을 것 입니다.

이제 우리는 "시스템 관리자"를 보유하고 있습니다. 기본적으로 Windows 데스크톱 사용자는 어느 시점에서 Linux로 변환되어 프로그래밍 할 수 없으며 그에 대한 잘못된 점을 찾지 못합니다.

방 안에있는 코끼리는 경영진이 그러한 파괴적인 태도를 용인하는 이유입니다. 누구 또는 무엇을 파괴? 비즈니스와 인프라에.

Puppet [, CFEngine, Chef] 주제로 돌아 가기 : 이와 같은 솔루션을 설정하자마자 손실됩니다. 모두가집니다. 왜? 이 아이디어를 가진 사람은 훌륭하고 깔끔한 Kickstart [, JumpStart, 자동 설치 프로그램, AutoYaST, Ignite-UX, NIM] 운영 체제 패키지 형태로 캡슐화 된 구성 관리를 설계 할 수 없기 때문입니다. Puppet (또는 Chef 또는 CFEngine)과 같은 자동화 된 해킹 도구를 사용해야하는 경우 , 동일한 설계로 완전히 깨끗한 상태를 유지하고 관리되는 시스템을 완전히 소멸 시키는 프로세스 를 설계 하고 구현할 위치 가 부족함을 의미합니다. 자동화되고 완전히 비 대화식입니다.

또 다른 중요한 점은 누군가 해킹 시스템이나 응용 프로그램 구성을 수동 으로 수정 하기 위해 Puppet 또는 이와 같은 솔루션이 있어야 하는 경우 프로세스를 설계 한 경험이 없으며 프로세스에서 구성이 패키지 된 프레임 워크입니다 개별 부품으로. 실제로 Puppet 등을 구현하는 사람은 구성 요소 소유자, 릴리스, 구성 관리, Capability Maturity Model에 대한 개념이 없습니다. 이것은 업계에서 매우 심각한 문제로 빠르게 발전하고 있습니다.

Puppet과 함께 일하면서 Bash를 기본 시스템 도구 언어로 대체 한 Ruby도 배울 수있었습니다. "

Bourne 쉘 프로그램, AWK 및 sed를 사용하여 운영 체제 패키지의 사전 설치, 사후 설치, 사전 제거 및 사후 제거 섹션에서 포괄적 인 엔드 투 엔드 구성 관리를 캡슐화 할 수있는 경우 Ruby가 필요한 이유는 무엇입니까? 누군가가 난해한 루비 언어를 배우는 데 오래 걸리고 꼭두각시와 관련하여 그 방언이 완전히 불필요합니다. 셸 프로그램과 AWK를 사용하여 구성 관리 문제를 쉽게 해결할 수 있으며 해결되었습니다.

Puppet 매니페스트가 전체 컴퓨터 또는 새로운 서비스를 처음부터 구성하는 것을 보는 것은 멋진 느낌입니다.

그것은, 킥 스타트, AutoYaST를, 또는 JumpStart를 수행 볼 수없는, 심지어 쿨러 일이 단 한 줄의 코드없이 , 그리고 사용하여 운영 체제를 조회 할 수있는 어떤 비전이나 추가 소프트웨어를 필요로하지 않고, 내장 도구 , 어떤 클라이언트 - 서버를 아키텍처가 필요하고 (SSH는 더 훌륭하고, 훨씬 더 좋습니다), 운영 체제가 각각의 모든 변경 사항을 인식하고 있음을 확인하십시오.

5. 데이터와 별도의 코드. 이것은 배우기가 더 어려운 개념 중 하나입니다. 모니터링 호스트와 같은 값을 모듈 코드로 하드 ​​코딩하는 것은 좋지 않습니다. 모듈이 소비 할 수있는 데이터 저장소 (db, yaml (Hiera는 이것을 기본값으로 사용), csv 등)에 넣는 것이 좋습니다. 예를 들어 Mysql을 사용하는 웹앱이 있습니다. 이것이 허용하는 것은 코드와 데이터를 개별적으로 푸시하는 기능입니다. 이를 통해 개발 프로세스가 더 간단 해집니다.

... 또는 쉘 변수로 구성 파일을 템플릿 화하고 (예를 들어 ls -1 ...) 따옴표 를 사용하여 AWK를 사용하여 eval (1)을 호출하고 템플릿의 모든 변수를 확장하여 정확히 동일한 강력한 기능을 활용하는 쉘 스크립트를 작성할 수 있습니다 쉘에 내장 된 파서. 왜 그렇게 단순 할 수 있습니까? 구성 값을 어디에 저장합니까? 왜, 어디서든하시기 바랍니다, 같은 꽤 많이 (4) 파일 또는 오라클과 같은 데이터베이스 또는에서 pkginfo 예를 들어 같은 어디서나 . 초 복합 솔루션이 필요하지 않습니다. 위에서 언급 한 라이브러리 는 운영 체제 패키지의 사전 설치 또는 사후 설치 섹션에서 간단하게 소스 를 만들 수 있으므로 중복을 제거하고 중앙 코드를 활용할 수 있습니다.

그러나 무엇보다도 위의 인용문은 시스템 관리자가 아니라 시스템 엔지니어 가지도를 필요로하는 차세대 시스템 관리자의 예라는 것을 알았습니다 . 회색 수염을 찾아서 견습생으로 사인하십시오.