2013-05-06 2 views
3

직장에서 우리는 Nagios에 대한 스크립트와 확장 기능을 개발했습니다. 우리는 ~ 30 고객 (각 고객 Nagios 서버가)에 감독 서비스를 제공합니다. 일부 고객은 특정 구성 (매우 특정한 것을 확인하고 메인 라인에 포함시키지 않는 새 모듈 ...)을 가지고 있습니다.다수의 다른 원격지에서 git 워크 플로우

지금 Nagios 서버 버전은 많이 다릅니다 (일부 서버는 2 년이며 업데이트 계획이 없습니다).

배포 자동화를 위해 git으로 전환하고 지속적인 통합을 사용하여 클라이언트의 Nagios에서 무언가를 깨뜨리지 않는지 궁금합니다.

여기 내 생각 :

     1 single server 
            \___________________________________________________ 
            |             | 
dev1 -----\    /---------|---> remote1 (bare) ----> remote1 (nagios etc/) | 
      \   /  |_________________________________________________| 
      \   /
       \  /
dev2 ---- main server (bare) -----------> remote2 (bare) ----> remote2 (nagios etc/) 

... 

의 devs 및 베어 리모트 + 리모컨이 고객에있는 경우 주 서버는 사무실에 있습니다.

나는 이미 게시물 수신 후크를 사용하여 자동으로 원격으로 푸시 할 수있었습니다.

remote1 (베어)에서 remote1까지 나는 remote1로 cd 할 다른 후크를 사용할 수 있으며 git pull. 그런 다음 간단한 Nagios 명령을 통해 구성을 테스트하고 문제가 발생하면 이전 커밋으로 되돌릴 수 있습니다.

원격 노드간에 파일이 다르다면 잠시만 gitignore를 사용하거나 주 서버에서 다른 분기를 사용할 수 있습니다. 따라서 customer1 분기를 remote1로 푸시 할 수 있습니다.

당신은 어떻게 생각하십니까? 어떤 충고 나 제안이든 열어 두었습니다 :-)

이상한 베어 리포 지 토리는 조금 이상하게 보입니다. 또한 커밋이 예상대로 작동하지 않으면 롤백에 대해 확신 할 수 없습니다.

+0

+1 귀여운 아스키 그래프입니다. 그것은 거의 잊혀진 기술/예술입니다. – quetzalcoatl

답변

0

git을 배포 도구로 사용할 수도 있지만 실제로 의도 한 기능은 아닙니다. 아마도 cfengine 또는 Capistrano을 고려해야합니다.

+0

답장을 보내 주셔서 감사합니다. 따라서 개발 및 배포를 분리해야한다고 생각하십니까? 나는 이미 약간의 꼭두각시를 알고 있으며 cfengine도 살펴볼 것입니다. – TatrefThekiller

+0

git hook을 사용하여 여러 호스트가 포함 된 배포 시스템을 설정할 수 있다는 것은 의심의 여지가 없습니다. 이미 경로를 시작한 것 같습니다. 어쩌면 그것은 당신의 필요를 충족시킵니다. git은 리비전 추적을 염두에두고 설계되었지만 배포에 유용하지는 않습니다. – gcbenison

관련 문제