직장에서 우리는 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로 푸시 할 수 있습니다.
당신은 어떻게 생각하십니까? 어떤 충고 나 제안이든 열어 두었습니다 :-)
이상한 베어 리포 지 토리는 조금 이상하게 보입니다. 또한 커밋이 예상대로 작동하지 않으면 롤백에 대해 확신 할 수 없습니다.
+1 귀여운 아스키 그래프입니다. 그것은 거의 잊혀진 기술/예술입니다. – quetzalcoatl