해당 내용은 Class101의 현직 대기업 개발자 푸와 함께하는 진짜 백엔드 시스템 실무! 강의를 기반으로 작성했습니다.
무중단 배포 환경에 대해 잘 모든다면 이전 글을 참고해주세요.
위 그림과 같이 Nginx로 로드밸런싱하여 무중단으로 배포 할 수 있는 환경 구성하기
인스턴스 만들기를 클릭하면 인스턴스 생성 화면이 나온다.
복제하고 싶은 인스턴스의 설정이 그대로 되어있다.
여기서 이름과 리전만 변경해주면 된다.
강의에서는 젠킨스 인스턴스에 관해 성능향상 경고가 나와서
머신을 e2-micro → e2-small로 변경한다.
하지만 내 화면에서는 인스턴스를 종료하라는 경고가 나온다.
수동으로 인스턴스 머신 사양을 수정하려했으나 어차피 300달러 크레딧이면 충분할테니
그냥 진행한다. 수정하고 싶다면 공식 레퍼런스를 참고하자.
젠킨스 인스턴스에 접속하려 했는데 접근이 되지않아 인스턴스를 재시작하고
젠킨스 서버를 다시 구동시켜준다.
sudo systemctl start jenkins
지난번에 설정한 인스턴스와 같이 서버 설정을 추가한다.
Name, Hostname(내부IP)만 변경해주면된다.
젠킨스 인스턴스만 워커 인스턴스에 접근 가능해야한다.
따라서 젠킨스의 공개키를 각 인스턴스에 추가해줘야한다.
이전에 1번 워커 인스턴스에서 진행했었는데 Test Configuration 결과 키가 사라졌다.
1번 ~ 3번 모두 공개키를 추가해주자.
그러나 이 키는 매일 초기화 되기 때문에 공개키를 복사하는 과정을 매일 수행해줘야한다.
지금은 인스턴스가 3개이지만 스케일 아웃으로 엄청나게 늘어난다면..?
그래서 gcp에서는 ssh 키를 따로 관리하는 곳이 존재한다. 아래에서 살펴보자.
이렇게 설정 해주면 앞으로 생성되는 모든 인스턴스 + 현재 생성된 인스턴스의 authorized_keys 항목에 젠킨스의 공개키가 항상 들어가서 배포를 따로 설정해주지 않아도
알아서 SSH로 접속 할 준비가 되어있는 상태가 된다.
대시보드에서 좌측에 구성 버튼을 클릭하고 Add Server를 클릭해 2,3 인스턴스도 추가한다.
Exec Command는 1번 인스턴스와 똑같이 복사한다.
명령어에서 /dev/null은 로그를 휴지통으로 보내고 있는거와 같다.
1번 인스턴스에는 이미 8080 포트로 실행중인 애플리케이션이 있다는 로그가 찍혀있다.
(지난번에 8080포트로 이미 애플리케이션을 띄워놨기 때문이다.)
2,3번은 도커 데몬이 실행중이지 않다는 로그가 찍혀있다.
2,3번 워커 인스턴스에서 도커를 실행시켜준다.
이대로하면 저번에 삽질했던 것 처럼 권한 에러가 날것이다. 권한도 같이 추가하자
sudo systemctl start docker
sudo chmod 666 /var/run/docker.sock
서울 리전은 총 4개의 인스턴스밖에 생성 못하기 때문에 타이완으로 선택했다.
워커 인스턴스와는 다르게 머신을 미디움으로 선택했다.
부팅 디스크 → CentOS7 , 방화벽 체크
sudo yum install nginx
sudo systemctl start nginx
upstream cpu-bound-app {
server {instance_1번의내부_ip}:8080 weight=100 max_fails=3 fail_timeout=3s;
server {instance_2번의내부_ip}:8080 weight=100 max_fails=3 fail_timeout=3s;
server {instance_3번의내부_ip}:8080 weight=100 max_fails=3 fail_timeout=3s;
}
location / {
proxy_pass http://cpu-bound-app;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
sudo systemctl reload nginx
현재 nginx.conf 파일의 수정한 내용을 반영하기 위해 reload 명령어를 사용했다.
이와 비슷한 동작을 하는 restart 명령어가 있는데 무슨차이가 있을까?
reload
프로세스를 종료하지 않고 해당 서비스의 설정 파일들을 다시 로딩
서비스에 따라 configuration 파일을 리로드하도록 설정하지 않은 경우가 있다.
따라서 변경한 설정이 적용되지 않을 수 있다는 의미이다. 굉장한 삽질 포인트이다.
아무리 리로드해도 변경한 설정이 적용되지 않는다면 restart를 해보자.
restart
서비스를 종료 후 재시작한다. PID가 변경된다.
서비스가 종료 후 재시작 되기 때문에 configuration 파일 등을 무조건 새로 가져와서 실행시키므로 변경사항이 무조건 반영된다.
이후 nginx에 /hash/123 경로로 url을 입력하면 404 에러가 나온다.
에러 로그를 확인해보자.
sudo tail -f /var/log/nginx/error.log
Nginx에서 네트워크 자원을 엑세스 하지 못해서 발생하는 오류이다.
rule을 추가해줘야 Nginx에서 tomcat으로의 네트워크 접근이 가능해진다.
sudo setsebool -P httpd_can_network_connect on
다시 요청해보면 정상적으로 응답이 온걸 확인할 수 있다.
Nginx 인스턴스에 요청을 날렸는데 워커 인스턴스에 있는 애플리케이션의 응답이 오는
신기한 경험을 할 수 있다!
머신 이미지를 통한 인스턴스 복제
추가한 인스턴스들도 젠킨스로 배포 자동화 설정
Gcp 인스턴스 생성 -> Nginx 설치 -> 로드밸런싱 설정
다음에는 지금까지 설정한 로드밸런싱 환경을 기반으로 스트레스 테스트를 진행해 보자.
이번 글에서 사용한 명령어 모음