여러 서버 구성 파일에 git 사용

우리는 많은 소스 코드를 git으로 마이그레이션했으며 현재 솔루션에 매우 만족합니다. 서버 구성 파일의 버전을 동일한 시스템에 유지하려고하지만 원하는 방식으로 작동하지 않는 몇 가지 사항이 있으며 여기에서 누군가 경험을 공유 할 수 있기를 바랍니다.

이 질문은 서버 구성 파일에 개정 제어 사용 과 유사 합니까? 하지만 해당 질문에 대한 제안으로는 작동하지 않는 몇 가지 특별한 요구 사항이 있습니다.

현재 설정은 구성 파일에 하위 버전을 사용합니다. 해당 저장소는 다음과 같습니다

 / # 저장소의 루트
 +-www.domain.com/ # www 구성
 | \--기타/
 | \-아파치 2 /
 +-dev.domain.com/ # dev 구성
 | +-등 /
 | \--고르다/
 | \-app1 /         
 | dev의 app1에 대한 \-conf / # 구성
 준비를위한 \-staging.domain.com/ # 구성

subversion을 사용하면 저장소의 하위 디렉토리를 체크 아웃 할 수 있기 때문에 제대로 작동합니다. 또한 svn : externals를 사용하여 여러 구성 설정에 대한 하나의 공통 구조를 가리킬 수 있습니다. 모든 버전의 디렉토리에 있는 .svn 파일 만 다루어야했습니다 . 반면에 힘내 SVN을 가지고 있지 않습니다 외관 및 스파 스 체크 아웃은 항상 동일하게 실제 디렉토리 루트에서 경로를 필요로한다.

git으로의 마이그레이션을 논의 할 때 서버 구성 버전 관리에 대한 주요 요구 사항 을 적어 보았습니다 .

• 우리는 단일 저장소만을 원한다
• 중앙 리모컨으로 변경 사항을 쉽게 푸시 할 수 있어야합니다
• 변경 세트에는 실제 작성자가 포함되어야합니다.

하나의 저장소에 모든 구성을 가지고 작업 사본으로 하위 경로 만 갖는 좋은 방법이 있습니까? 현재 두 가지 접근법을 고려하고 있지만 먼저이 질문을하고 싶었습니다.

1. 는 IF .git 저장소가 고정 된 위치에있는, 예를 들면 곳은에 / var에 , 우리는 작업 디렉토리 "대상"에서 하위 경로에 링크 할 수 있습니다. 주요 문제 : 단일 파일을 심볼릭 링크하는 것 외에는 내용 만 가져 오기 위해 / etc 에서 다른 디렉토리 로 "링크"하는 방법을 알지 못합니다.
2. 이 SO 질문에 대한 다른 대안을 찾았습니다 . 하나의 저장소에 여러 가지가 있음을 제안합니다. 이것은 확실히 복잡성을 증가시킬 것이지만, 우리가 이런 식으로 노력하는 것을 볼 수 있습니다.

구성 파일 관리를 위해 단일 컴퓨터에서 git을 사용하면 정상적으로 작동하지만 사용하려는 사람이 있어야합니다.

감사합니다
Kariem

나는 전에 이와 같은 것을 사용했다; 이것이 작동하는 방식입니다.

레포 설정

1. 자식 저장소 "etc_files"를 만듭니다.
2. "server / www", "server / dev"등과 같은 각 머신 유형에 대한 분기를 작성하십시오.
   • git은 분기 이름에서 슬래시를 지원합니다. 이렇게하면 가지를 머리에 똑바로 유지할 수 있습니다.
   • 머신이 충분하지 않은 경우 각 머신마다 분기가있을 수 있습니다.
3. "modules / apache", "modules / cups"등과 같은 공유 인프라의 각 부분에 대한 분기를 만듭니다.
   • 이 분기는 같은 모든 머신간에 동일한 파일을 보유하기위한 것 /etc/resolv.conf입니다. 이것들은 "svn : externals"repos에 보관 한 파일들입니다.

새로운 기계 만들기

1. 새 머신에서 git repo를 복제하고 해당 머신 유형의 분기를 확인하십시오.
   • 사람들이 테스트하지 않고 프로덕션 시스템에서 변경 사항을 커밋하지 못하도록 읽기 전용 복제본으로 만듭니다.
2. git pull매일 자동 으로 repo가 되도록 cron 작업을 설정하십시오 .

기계 지점 변경

단일 머신 브랜치에서 코드를 변경하는 것은 간단합니다. git checkout개발 환경에서 적절한 지점 만 변경하고 변경 한 다음 중앙 저장소로 다시 커밋하십시오. 해당 분기의 모든 시스템은 다음에 cron 작업이 실행될 때 자동으로 변경 사항을 가져옵니다.

모듈 브랜치 변경

모듈 브랜치의 코드 변경은 두 단계로 이루어 지므로 약간 까다 롭습니다.

1. git checkout 적절한 모듈 브랜치
2. 변경 사항을 작성하여 중앙 서버에 커미트하십시오.
3. git checkout해당 모듈 분기를 사용하는 각 시스템 분기와 모듈 분기를 병합합니다. git은 이전에 해당 모듈 분기를 병합했으며 마지막 공통 상위 이후에 발생한 변경 사항 만 알았습니다.

이 방법에는 장점과 단점이 있습니다. 한 가지 이점은 모듈 분기를 변경하여이를 필요로하는 기계 분기에 적용 할 수 있다는 것입니다. 이는 준비가 될 때까지 이전 버전을 유지하지 않는 기계 분기를 허용합니다. 따라서 단점은 모듈 분기를 사용중인 각 컴퓨터 분기로 모듈 분기를 병합해야한다는 것입니다. 커밋 트리를 통과하고 자동으로 병합을 수행하는 스크립트를 사용하지만 여전히 고통 스럽습니다.

대안으로 최신 버전의 git은 " submodules "를 지원합니다 .

서브 모듈을 통해 외부 저장소를 소스 트리의 전용 서브 디렉토리에 임베드 할 수 있으며 항상 특정 커밋을 가리 킵니다.

이를 통해 "svn : externals"트리와 같은 것을 만들 수 있으며, 현재와 거의 같은 방식으로 업데이트 할 수 있습니다.

여기에 약간의 덩어리가 있지만 포스트 수신 후크가 작업을 수행 할 수있는 것처럼 들립니다.

Repo 마스터는 / var / master에 저장되며
후크는 / var / localclone에 복제
한 다음 호스트 별 세부 정보를 복사
합니다. 각 서버에서 로컬로 .git / post-receive 후크를 설정해야합니다 (적절한 설정).

또한 git보다 꼭두각시 또는 요리사와 같은 것을 원한다고 들리므로 git을 실행하여 구성 및 모듈을 중앙에서 관리하고 puppet / chef가 배포 및 확인을 관리하도록 할 수 있습니다

여기에 내가 생각한 빠른 작업이 있습니다
. /var/repo
2라는 중앙 저장소 가 있습니다. 전역에있는 파일을 해당 디렉토리의 모든 도메인에 넣습니다.
모든 하위 도메인에 대한 분기를 작성합니다 /var/repo/subdomain1, /var/repo/subdomain2등
(4)은 지점에 대한 푸시가 마스터로 병합 후 후크를 만듭니다.

따라서 구성을 변경하면 해당 구성이 /var/repo/subdomain2마스터와 즉시 병합되므로 저장소를 완전히 가져오고 모든 구성 파일을 가질 수 있습니다.
개별 하위 도메인 구성을 가져 오려면 적절한 분기를 당기십시오.

설정 파일을 넣는 방법 /var/repo/*은 완전히 다른 문제입니다 (크론 탭, 생각할 수 있습니다)

~ $