Information Security Study

240703 KT클라우드 인스턴스 생성 및 ssh 접속, 젠킨스 접속, webhooks 자동 배포, Nginx로 무중단배포 스크립트 작성하기, 부하테스트 본문

네트워크 캠퍼스/KT클라우드-Jenkins

240703 KT클라우드 인스턴스 생성 및 ssh 접속, 젠킨스 접속, webhooks 자동 배포, Nginx로 무중단배포 스크립트 작성하기, 부하테스트

gayeon_ 2024. 7. 3. 15:04

KT클라우드 인스턴스 생성 및 ssh 접속

 

jenkins 인스턴스 하나 생성

 

 

 

key pair 발급

 

 

Networking -> 공인 ip 선택 -> 접속설정

을 눌러 포트를 열어준다.

 

 

 

ssh -i 키이름.pem root@공인ip

로 접속하면 된다.

 

 

 

위와 같은 방법으로 젠킨스 인스턴스 1개, 배포용 인스턴스 2개, 리버스 프록시용 엔진엑스 인스턴스 1개를 생성했다.

 

 

젠킨스 접속하기

그리고 젠킨스 인스턴스에 도커, 자바, 젠킨스를 설치했다. (노션 참고)

나중에 배포 시 jar 파일을 실행해야 하기 때문에 자바 설치는 배포용 인스턴스 2개에도 진행해야 한다.

 

 

 

젠킨스 설치 후

젠킨스 인스턴스의 공인 ip:8080

로 들어간다.

위 화면에서 알려주는 경로로 관리자 암호를 찾아서 입력하고

 

 

 

제안된 플러그인을 설치한다.

 

 

 

유저 정보까지 입력하면 젠킨스 접속 완료!

 

 

jenkins ssh 접속

 

 

rsa 키 발급

 

 

 

디렉터리와 파일 권한 변경

 

instance-1, instance-2에도 ssh로 접속하고

~/.ssh/authorized_kesy 파일에 jenkins-instace 공개키를 붙여 넣어 저장한다.

 

 

 

publish over ssh 플러그인 설치

 

 

 

젠킨스 관리 -> system

으로 들어와서 key에 jenkins-instance의 비밀키를 입력한다.

 

 

 

밑에 서버 추가를 눌러 관리를 받는 가상 pc 정보를 입력하면 된다.

 

 

 

test 접속 성공

 

 

Webhook으로 자동 배포하기

 

webhook으로 자동 배포할 item 생성

 

 

 

git 선택

아래 url에 연동할 레포지토리 url을 입력한다.

이렇게 하면 execute shell에 clone 구문을 작성하지 않아도 된다.

 

 

 

github hook 옵션 선택

이 옵션을 선택하면 깃허브에 hook 요청이 들어갔을 때 자동으로 빌드가 된다.

 

 

 

빌드 명령어

 

 

 

빌드 후 조치에 들어가서

instance-1, instance-2 서버를 추가한다.

jenkins-instance의 .jar 파일을 instance-1, instance-2에 전송한다.

 

포트 충돌이 나지 않고 정상적으로 실행될 수 있도록 각 instance Exec command 창에 위와 같이 프로세스 종료 명령어를 추가로 작성했다.

전송 후 java 애플리케이션을 백그라운드에서 실행하고

표준 출력, 표준 오류를 nohup.out 파일에 저장한다.

 

이때 딜레이 배포를 하기 위해 2번 pc부터 exec command 맨 위에

sleep 30과 같이 대기시키는 명령어를 작성해 롤링방식 무중단 배포를 구현했다.

 

 

 

각 인스턴스의 공인 ip로 접속이 잘 된다.

 

 

 

출력 구문 변경 후 commit change를 하면

 

 

 

자동으로 빌드가 시작된다.

 

Nginx로 무중단배포 스크립트 작성하기

 

노션 참고 후 여러 설정한 뒤 nginx-instance에 nginx를 설치한다.

 

 

 

nginx 가동

 

 

 

포트번호 없이 nginx-instance의 공인 ip로 접속할 수 있다.

 

 

worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" '
                      'backend_server=$upstream_addr';


        upstream cpu-bound-app {
          server 인스턴스1공인ip:8080 weight=100 max_fails=3 fail_timeout=3s;
          server 인스턴스2공인ip:8080 weight=100 max_fails=3 fail_timeout=3s;
        }

        server {
                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;
                }
        }



    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;
}

 

설정 파일 수정 후 재가동

 

 

 

nginx-instacne의 공인 ip로

instance-1이나 instance-2에 직접 접속했을 때처럼 hello 페이지를 볼 수 있다.

 

 

 

로고 끝에 보면 backend_server의 주소가 바뀌고 있다.

로드밸런싱이 되고 있는 것을 볼 수 있다.

 

 

부하테스트

 

1) instance-1 서버 한 대로 부하테스트를 진행했을 때

 

 

2) nginx로 로드밸런싱 했을 때

 

로드밸런싱을 했을 때 확연히 response_time과 에러 수가 줄어들었다.