컨테이너 be1 (port = 8080:8080) // main컨테이너 be2 (port = 8081:8080) // backup롤링 배포 전략1. be1을 먼저 오프라인 시킴2. be1이 오프라인이기 때문에 로드밸런서가 백업서버(be2)로 트래픽을 보냄3. be2가 트래픽을 처리하는동안 be1을 최신 이미지로 업데이트4. 업데이트가 끝나면 be1을 다시 온라인5. be1이 온라인 상태가 되었기 때문에 트래픽이 다시 be1으로 이동함6. be2의 최신화를 진행deploy 스크립트sudo sed -i 's/localhost:8080/localhost:8080 down/g' /etc/nginx/nginx.confsudo nginx -s reload (변경된 설정만 불러오기 때문에 웹서버가 중단되지 않는다)(이후부터 spring-main은 죽은 서버로 취급된다)docker stop "spring-main"docker img rmi seaworld0125/hoppy:latestsudo docker run -d --name spring-main --rm -p 8080:8080 seaworld0125/hoppy:latestspring-main container 상태 확인 - up상태라면 다음으로 진행sudo sed -i 's/localhost:8080 down/localhost:8080/g' /etc/nginx/nginx.confsudo sed -i 's/localhost:8081/localhost:8081 down/g' /etc/nginx/nginx.confsudo nginx -s reload(이후부터 spring-sub은 죽은 서버로 취급된다)docker stop "spring-sub"docker img rmi seaworld0125/hoppy:subdocker image tag seaworld0125/hoppy:latest seaworld0125/hoppy:subdocker run -d --name spring-sub --rm -p 8081:8080 seaworld0125/hoppy:subsudo sed -i 's/localhost:8081 down/localhost:8081/g' /etc/nginx/nginx.confsudo systemctl reload nginx수정된 전략1. 평소에 main, sub를 모두 사용함2. deploy가 실행되면 nginx.conf가 수정되어 main은 로드밸런싱에서 down 처리 됨3. down처리가 되어있는 동안에 새로운 도커 이미지로 업데이트 수행4. down처리 된 것을 복수하고 동시에 sub를 down 처리함5. sub도 마찬가지로 업데이트6. down 처리되어 있는 것을 복구하면 끝이렇게 수정한 이유는 인터넷에 퍼져있는 service-url.inc를 사용하는 방법은 nginx에서 지원하는 방법이 아닐뿐더러 내가 원하는대로 응용하기 어려웠다.nginx의 health check기능을 사용할 수 있다면 가장 좋겠지만 유료여서 어쩔 수 없었고, 라이브러리가 있는 것 같았지만 이미 설정을 끝내둬서 다시 다운받기 조금 그랬다,,ㅠ그래서 결국 인터넷에 퍼져있는 service-url.inc를 이용하는 방법과 비슷한 방법을 생각했다. service-url.inc를 수정하는 것도 결국 nginx의 설정을 수정하는 것이기 때문에 conf 수정을 다른 방식으로 자동화해주면 된다고 생각했다. 따라서 sed 명령어로 특정 문자열을 치환해서 nginx를 reload하는 방식을 생각했다.. 거의 편법이라고 볼 수 있다.음 물론 지금 예제는 매우 간단한 conf 파일이어서 가능한 것이겠지만, 복잡하다면 꼭 서버 설정 conf를 따로 빼서 진행을 해야한다. 안그러면 sed 명령어가 다른 부분까지 치환할 수 있기 때문에 위험하다는 생각이 들었다. 또한 이건.. 너무 구린 방식이어서 더 좋은 방식이 뭐가 있는지 찾아 볼 예정이다.