나는 (내 목적과 상황에 따라) 시스템 구성 파일의 버전을 지정하고 두 컴퓨터(라이브 및 백업 모두 '프로덕션'으로 간주해야 함) 간의 배포(소유권 및 모드)를 관리하는 가장 좋은 방법을 찾고 있습니다. 이 시스템을 사용하여 백업 머신(EC2 인스턴스)에서 관련 및 지정된 구성을 자동으로(그러나 선택적으로) 복제하고 관리할 수 있기를 원합니다.
현재 해당 시스템은 주로 웹 및 SMTP 서버이지만(사용자 사서함은 저장하지 않음) 프로젝트가 성장하고 있으며 향후 요구 사항이 무엇인지 누가 알겠습니까? 예를 들어, 미래 어느 시점에는 라디오와 웹 기반 채팅을 구현할 가능성이 있습니다.
나는 서버를 기존 방식으로 관리한 다음(예: 필요에 따라 라이브 서버에 들어가서 변경) 해당 변경 사항(일단 확정된)을 관리 시스템에 저장하는 것을 선호합니다. (좋아요, 솔직하게 말하면유기적으로: 필요와 상황에 따라 작업을 수행할 수 있는 유연성을 잃고 싶지 않습니다.) 다른 곳에서 조정하고 테스트한 구성을 배포하는 것보다 이 접근 방식이 더 예측 가능하고 예상치 못한 일이 발생할 가능성이 적다고 생각합니다. 라이브 시스템에서 구성을 망칠 가능성이 있습니다!)
나는 철학적으로 말하면 이것이 앞뒤로 진행되며 자원(테스트 인프라, 더 중요한 것은 인력)이 있다면 아마도 반대 방향으로 할 것이라는 것을 알고 있습니다. 그렇다면 나는 내가 가진 것을 감당해야 합니다. 나는 구조를 충분히 좋아하지만 과도한 인프라는 그 자체로 생명을 얻고 어느 시점에서 그 가치를 잃습니다.
몇 가지 숙제를 하고 몇 가지 옵션을 검토했지만 그 중 어느 것도 내가 원하는 대로 실제로 작동하지 않는 것 같아서 현재 자체 솔루션을 출시하고 싶은 유혹을 받고 있습니다. 이 질문의 목적은 내가 생각하지 못한 것이 무엇인지 확인하고 잘못된 나무를 짖기 전에 온전한 상태인지 확인하는 것입니다.
옵션
Puppet과 같은 선언적 메타 구성 시스템,그 중에서도는 많은 서버가 관련되어 있고 서버 간 차별화가 거의 없거나 전혀 없는 경우, 특히 구성이 어떤 모습이어야 하는지 미리 명확한 경우 좋은 선택일 수 있습니다. 인프라를 준비하지 않고 이러한 도구를 사용하는 것은 현명하지 않다고 생각합니다.
또한 약간 무겁고 지나치게 복잡합니다. 나는 유일한 관리자입니다. 나는 여가 시간에 이 일을 하며, 나에게 무슨 일이 일어나면 내가 남겨둔 것은 무엇이든 나를 따라오는 행운의 남자/여자가 합리적으로 제정신이어야 합니다.
etckeeper가 그렇게 할 수도 있지만, 내가 본 바로는 /etc 이외의 다른 것을 관리하는 데에는 적합하지 않습니다. 즉, 전통적으로 /usr/local/bin에 있는 사용자 정의 스크립트를 저장하는 데는 적합하지 않습니다. 또한 etckeeper는 아마도모두/etc의 경우 특정 항목(예: postfix, apache, fall2ban, ssh 및 아마도 munin)만 버전화하는 것을 선호한다고 생각합니다.
간단한 git 또는 svn repo는 확실히 수행되지 않습니다. git은 권한을 추적하지만 소유권은 추적하지 않고 svn도 추적하지 않기 때문입니다.
svn은
.svn추적되는 모든 디렉터리에 하위 디렉터리를 유지하는 반면,.git작업 복사본의 루트 디렉터리에만 존재합니다. 두 경우 모두 장점과 단점이 있습니다..svn특정 위치에 디렉토리가 있으면 일부 장소(예: /etc/apache2/sites-enabled)에서는 문제가 없지만 다른 곳에서는 두뇌가 작동하지 않는 스크립트/도구가 작동하지 않을 수 있습니다. (저는 예전에 뭔가를 읽었다고 확신합니다. cron은.svn/etc/cron.d의 디렉토리에는 괜찮았지만 depmod는 /lib/modules에는 없었나요?)반면
.git에 /를 사용하면 git은 다음을 고려합니다.모든 것(아마도) 다른 git repos도 추적할 수 있는 후보입니다!
맞춤형 솔루션
제가 제안하는 것은 다음과 같습니다: 기본 머신(예: /usr/local/sc-repo)에 저장된 Subversion 저장소와 다음으로 작성된 관리 스크립트피스븐이는 다음을 구현합니다.
파일의 모드와 권한을 사용자 정의 속성으로 저장하는 add(기본적으로 재귀적이지는 않음). 또한
$Id$구성 파일의 태그가 마음에 들기 때문에svn:keywords올바르게 설정되었는지 확인할 수 있습니다.저지르다
파일이 작성된 후 소유권과 모드를 적용하는 업데이트
되돌리기, 마찬가지
diff와 같은 권한이지만 소유권 및 모드에 대한 것이며 필요한 경우 수정하기 위한 수정 플래그가 있습니다.
백업 머신은 SSH를 통해 저장소에 액세스하고 매일 밤 업데이트 작업을 수행합니다. (메인 머신의 백업 저장소(S3)에서 사이트 SQL 및 애플리케이션 파일 시스템을 복원하는 것과 같은 다른 작업도 수행할 것이며 아마도 메인 머신에 추가된 새 패키지를 찾아 패키지에 추가하는 해커리를 작성해야 할 것입니다. 백업 머신 — 그러나 이 질문의 범위를 벗어나는 모든 것.)
왜 전복인가?
나도 알아, 좋아하고 그래많이나는 git보다 svn에 더 익숙합니다. 네, 아마 공룡일 거예요.
Pysvn은 쉬우며 이전에도 사용해 본 적이 있습니다.
svn은 버전이 지정된 사용자 정의 속성을 지원합니다. 여기서 git은 지원하지 않는 것 같습니다.
이것은 분산 개발이 아닙니다. 분산 저장소는 이익 없이 문제를 복잡하게 만듭니다. 원격 시스템에서의 커밋은 거의 발생하지 않으므로 원격 저장소 가용성은 관련이 없습니다.
귀하의 피드백에 감사드립니다. 나는 이것에 대해 가능한 한 많이 생각해 보았지만 뭔가를 놓쳤을 것입니다.
답변1
바퀴를 재발명하지 마세요. 필요한 작업을 수행하기 위한 도구가 존재합니다. 당신은보고 싶을 수도 있습니다bcfg2, 특히 구성 파일에 특히 중점을 두는 것 같기 때문입니다. 서비스에 대해서도 생각해 보세요. 프로덕션 서버와 관련하여 중앙 저장소는 어디에 있어야 합니까?
아마도 중간 옵션은 출력을 완전히 수정하는 것일 수 있습니다.청사진도구. 저는 Blueprint를 사용하여 기존 시스템을 리버스 엔지니어링합니다. 블루프린트 실행의 출력은 셸 스크립트, Puppet 모듈 또는 Chef Cookbook을 생성할 수 있습니다. 프로덕션 서버에서 구성이 확인되면 이 도구를 사용하여 시스템 상태를 캡처한 다음 결과에 태그를 지정하고 버전을 지정할 수 있습니다. 읽다예제를 통해이것이 귀하의 사용 사례에 적합하다고 생각되면 다시 보고해 주세요.
답변2
특히 Puppet과 같은 선언적 메타 구성 시스템은 많은 서버가 서로 거의 또는 전혀 구별되지 않고 관련되어 있는 경우, 특히 구성이 어떤 모습이어야 하는지 미리 명확한 경우 좋은 선택일 수 있습니다. 인프라를 준비하지 않고 이러한 도구를 사용하는 것은 현명하지 않다고 생각합니다.
저는 단일 머신 설정에도 Puppet을 사용합니다(하지만 Chef, Ansible, Salt 등이 존재합니다). 나는 아직 누군가가 기계 구성이 어떤 모습이어야 하는지 미리 명확하게 밝힌 상황을 경험하지 못했습니다. (아마도 많은 사람들이 이후 구성이 어떤 모습이어야 하는지 명확하지 않았지만 이는 완전히 다른 문제입니다.)
"스테이징 인프라"에 관해서는방랑자그리고버추얼박스(또는 다른 지원 가상화 기술) - 비용이 전혀 들지 않도록 개발 컴퓨터에서 실행하세요. 나는 그것 없이는 Puppet 매니페스트 개발을 수행하지 않습니다. 또한 자동화된 테스트트래비스 CI
또한 약간 무겁고 지나치게 복잡합니다. 나는 유일한 관리자입니다. 나는 여가 시간에 이 일을 하며, 나에게 무슨 일이 일어나면 내가 남겨둔 것은 무엇이든 나를 따라오는 행운의 남자/여자가 합리적으로 제정신이어야 합니다.
이렇게 말하고 많은 문서, 예제, 기존 "라이브러리" 및 활발한 개발을 통해 기존 솔루션 대신 자체 개발 솔루션을 계획하는 방법을 설명하는 것은 일관성이 없는 것 같습니다.