안지현

※ 컨테이너 띄울 때 고정 IP 추가해서 실행시키기

send-host에서 진행 (여기서 send-host가 프론트 리버스프록시 서버)

# 각 컨테이너에서 진행
# apt update
# apt install nano -y
# apt install systemctl
# nano /etc/nginx/nginx.conf

http { } 안에 위 코드 추가

만약 위 코드 작성 후 접속 실패 시 해당 파일의 맨 마지막 줄 지워주기

# systemctl reload nginx
# systemctl restart nginx.service
# systemctl status nginx.service

※ 전체적인 토폴로지 구성

external-net을 sendhost(프론트) 컨테이너에 연결

ifconfig로 확인해보면 172.21(external) 대역이 잘 추가된 것을 확인할 수 있다.

1. nginx 인스턴스 생성

# 필요한 패키지 설치
# apt-get update
# apt-get install -y curl gnupg2 ca-certificates lsb-release

# ubuntui-keyring 패키지 설치
# apt-get install -y ubuntu-keyring

# nginx.list 파일 생성
# curl -s https://nginx.org/keys/nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg > /dev/null
# 다운로드 키 올바른지 확인
# gpg --dry-run --quiet --no-keyring --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg

# 저장소 설정 (안정 버전)
# echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list
# apt-get update

# nginx 설치
# apt-get update
# apt-get install -y nginx
# nginx -v
# systemctl start nginx

위와 같이 잘 접속되는 것을 확인할 수 있다.

2. 로드밸런싱 하도록 엔진엑스 설정 바꾸기

# apt update
# apt install openssh-server
# apt install nano
# nano -l /etc/ssh/sshd_config  # 14, 38, 57라인 주석해제
# service ssh restart
# apt install openjdk-17-jdk -y
# apt install vim -y

무중단 배포를 위한 여러 서버를 생성하기 위해 위와 같은 절차를 수행한다.

Home > Manage Jenkins > System에서 위와 같이 jenkins-worker2를 추가해준다.

또한, stress_test_deploy의 설정에서 jenkins-worker2를 추가해준다. Exec command에는 jenkins-worker에서 작성했던 구문을 넣어준다.

# ssh-keygen -t rsa -f ~/.ssh/id_rsa

먼저, ssh로 연결하기 위해서 위 명령어를 이용하여 ssh키를 발급한다.

위에서 확인한 공개키/개인키의 주소로 이동한 후 조회해보면 위와 같이 공개키와 개인키를 확인할 수 있다.

Jenkins는 개인키로 발급하고, 발급된 서명을 각 가상 PC에서 공개키로 검증하게 하므로 공개키 정보를 확인해야 한다.

해당키를 위와 같이 확인할 수 있고, 이 공개키를 잘 저장해둔다.

# apt install openssh-server
# nano -l /etc/ssh/sshd_config
# service ssh restart

또한, Jenkins-worker 인스턴스에서 위 명령어를 이용해 해당 파일을 수정해준다. 해당 파일의 14번, 38번, 57번 주석을 해제한다.

$ docker run -d -it --net jenkins-net --name jenkins-worker ubuntu:22.04
$ docker exec -it jenkins-worker bash
# apt update
# apt-get install vim
# apt-get install nano
# su jihyun

Jenkins가 관리할 가상 PC를 하나 더 생성해 준 후 ~/.ssh 경로에 authorized_keys 파일을 만들어준다.

.ssh 폴더는 700, authrized_keys 파일은 600으로 권한을 설정한 후 authorized 파일에 복사한 공개키를 저장해준다.

위와 같이 잘 복사된 것을 확인할 수 있다.

Jenkins 서버에서 ssh를 활용한 스크립트 전달이 가능하도록 플러그인을 설치해야 한다.

플러그인에서 publish 검색 후 public over ssh를 설치한다.

Manage Jenkins > System 창 하단의 Publish over SSH란으로 이동한 후 Key 부분에 아까 생성한 개인키를 붙여넣는다.

SSH Servers 추가를 눌러 하단에 확장시킬 수 있는 창을 이용하여 아래 그림과 같이 Jenkins가 관리한 가상 PC 정보를 입력해준다.

① Name에는 식별 가능한 이름을 작성한다.

② Hostname에는 비공인 IP를 넣어준다.

jenkins-worker의 ip를 확인 후 아래 사진의 Hostname 부분에 입력해준다.

③ Username에는 우분투 계정명을 적어준다. 

④ Remote Directory에는 홈 디렉토리를 사용한다.

우측 하단의 Test Configuration으로 확인하여 Success가 뜨면 테스트 접근에 성공한 것이다.

※ ssh 접근 오류가 발생하는 경우

# apt install openssh-server
# nano -l /etc/ssh/sshd_config    # 14, 38, 57 주석 해제
# service ssh start

배포 스크립트는 Item이라는 단위로 관리된다.

New Item에서 Freestyle project를 이용한다.

하단의 post-build action을 위 항목으로 선택해준다.

고급에서 Verbose output in console을 체크해야 좀 더 자세하게 로그를 볼 수 있다.

Exec command에 수행할 명령어를 작성해준다.

저장 후 콘솔 output을 확인해보면 해당 인스턴스에서 ls -a 명령을 수행한 결과를 확인할 수 있다.

위와 같이 해당 인스턴스에서 입력했을 때와 같은 결과인 것을 확인할 수 있다.

스트레스 테스트용 스프링 어플리케이션 jar(war) 배포 해보기

먼저, 위와 같이 gradlew 파일이 보이는 지점으로 이동한다.

./gradlew build 명령어를 이용해 빌드를 수행한다. (기존 build가 있다면 ./gradlew clean build)

위와 같이 BUILD SUCCESSFUL 문구를 확인할 수 있다.

dir로 확인해보면 아까는 없었던 builld 폴더가 생성된 것을 확인할 수 있다.

build > libs 폴더에 jar(혹은 war) 파일이 생성된 것을 볼 수 있다.

위와 같이 java -jar [파일명] 명령을 내리면 위와 같이 잘 접속되는 것을 확인할 수 있다.

이런 방식으로 만들어진 애플리케이션을 배포할 수 있다.

위 프로세스를 젠킨스에 구축하기

먼저, 젠킨스에서 새로운 아이템을 freestyle로 생성해준다.

위와 같이 ssh 추가 한 후 고급에서 verbose를 선택해준다.

rm -rf swu_stresstest_example                                       # 혹시 기존에 클론뜬 폴더가 존재한다면 삭제
git clone https://github.com/dev-library/swu_stresstest_example.git # 클론하기
cd swu_stresstest_example                                           # 작업 폴더를 받아온 폴더로 이동
chmod 544 ./gradlew                                                 # gradlew의 권한을 바꿔서 실행가능하게 변경
./gradlew clean build                                               # 클린 및 빌드를 통해 jar파일 생성
java -jar ./build/libs/spring_rest-0.0.1-SNAPSHOT.jar               # 생성된 jar파일로 서버 실행

이와 같이 터미널창에서 빌드할 때 사용할 구문을 적어주면 된다.

빌드를 해보면 클론까지는 성공했으니 java가 없다는 오류를 볼 수 있다.

# apt install openjdk-17-jdk -y
# java -version

위 명령을 통해 자바를 설치할 수 있다.

젠킨스에서 다시 빌드해보면 빌드가 잘 되고, 위와 같이 잘 접속되는 것을 확인해볼 수 있다.

※ 돌고 있던 스프링부트 어플리케이션 종료는 ps -ef나 kill 등의 명령어로 종료시킬 수 있다.

해당 구문을 스크립트 파이프라인 상단에 배치하면 새로운 배포 시작 전에 무조건 프로세스를 종료시키면서 시작할 수 있다.

1. Jenkins란?

지속적인 통합 및 배포를 지원하는 오픈소스 자동화 도구로 소스코드의 변경사항을 자동으로 빌드, 테스트, 배포 가능

→ 개발자들이 코드 변경 사항을 더 빠르게 통합하고, 자주 테스트하며 빠르게 배포할 수 있도록 돕는 것이 목적

1) Jenkins 주요 특징

① 지속적 통합

② 지속적 배포

③ 유연한 플러그인 시스템

④ 스크립트 기반 파이프라인

⑤ 분산 빌드

⑥ 강력한 커뮤니티 및 생태계

2. Jenkins 환경설정

컨테이너로 진행하기 위해 위와 같이 네트워크와 도커를 생성한 후 진행한다.

1) JAVA 설치

Jenkins는 Java 응용 프로그램으로 Java 8 이상을 설치해야 한다.

$ sudo apt update
$ sudo apt install openjdk-17-jdk
$ java -version    # 자바 버전 확인

2) Jenkins 설치

① Jenkins 레포지토리 추가

$ curl -fsSL https://pkg.jenkins.io/debian/jenkins.io-2023.key | sudo tee /usr/share/keyrings/jenkins-keyring.asc > /dev/null
$ echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null

② Jenkins 최신 버전 설치

$ sudo apt update
$ sudo apt install jenkins
$ systemctl status jenkins    # 서비스 상태 확인

※ 사실 docker의 Jenkins 이미지를 받아서 컨테이너로 띄워도 된다.

3) Jenkins 설정

localhost:9090으로 접속해보면 위와 같은 페이지가 나온다.

위 페이지에 있는 경로파일을 조회하여 나온 암호(32글자)를 붙여넣어준다.

권장 플러그인 설치 상자를 클릭하면 설치 프로세스가 즉시 시작된다.

위와 같이 정보들을 입력하여 admin 사용자를 설정한다.

위와 같이 Jenkins URL을 설정하라는 창이 뜨고, 필드는 자동으로 생성된 URL로 채워진다.

위와 같은 창이 뜨면 설정이 완료된 것이고, start using Jenkins 버튼을 클릭하면 이전 단계 중 하나에서 만든 관리 사용자로 로그인한 Jenkins 대시보드로 리디렉션된다.

1. 로그로테이션

1) 개념

- 리눅스 시스템에서 로그 파일을 관리하고 유지하는 프로세스

- 로그 파일은 시간이 지남에 따라 매우 커질 수 있기 때문에 로그파일을 주기적으로 교체해줄 필요가 있다.

2) 로그로테이션

① 로그 파일 설정

② 로그로테이션 설정

③ logrotate 설정 파일 작성

④ 로그로테이션 주기 설정

⑤ 로그 파일 압축 및 백업

⑥ 새로운 빈 로그 파일 생성

⑦ 로그 파일 삭제

☆ 로그로테이션은 시스템 관리에서 중요한 작업 중 하나이며 로그 파일의 크기를 관리하고 시스템 성능을 최적화하는 데 도움이 된다.

2. logrotate 패키지를 사용해 상세한 로그 파일 관리방침 설정하기

1) 패키지 설치

$ sudo apt-get install logrotate

2) logrotate 서비스 동작 원리

$ cat /etc/cron.daily/logrotate

logrotate 설치 시 cron에서 매일 자정에 수행하는 작업을 모아두는 /etc/cron.daily 경로 아래에 logrotate 파일이 생성된다.

즉, logrotate는 cron 서비스에 의해 daily job으로 실행되고, 매일 자정에 rotate 조건을 검사하고 실행한다.

3) logrotate.conf에 등록된 기본 경로에 스크립트 등록

$ cat /etc/logrotate.conf

logrotate.conf에서 rotate 스크립트를 등록할 기본 경로 확인

위와 같이 /etc/logrotate.d 경로에 등록된 스크립트를 감지하도록 되어 있다.

include </your/additional/logrotate/path> 구문으로 기본 경로로 삼을 디렉토리를 추가할 수 있다.

→ 기본 경로에 등록된 rotate 스크립트는 매일 자정에 조건 검사 및 수행

4) logrotate 설정 파일 예시

# 로그 파일을 저장할 경로 및 설정 시작
/var/log/syslog {
    rotate 7                          # 최대 7개의 백업 파일을 유지합니다.
    size 30                           # 30k 초과시 순환합니다.
    daily                             # 매일 로그를 로테이션합니다.
    create 0600 root root             # rotation된 로그파일 생성
    missingok                         # 로그 파일이 없는 경우 경고 없이 진행합니다.
    notifempty                        # 로그 파일이 비어 있는 경우 로테이션을 스킵합니다.
    delaycompress                     # 이전 로그 파일을 압축하기 전에 1회 로그를 더 남깁니다.
    compress                          # 이전 로그 파일을 압축합니다.
    postrotate                        # 로테이션 후에 실행할 스크립트의 시작입니다.
    /usr/bin/killall -HUP syslog-ng   # syslog-ng 프로세스에 HUP 신호를 보냅니다.
    endscript                         # postrotate 스크립트의 끝입니다.
}
# 로그 파일 경로 및 설정 끝

/var/log/syslog 파일을 매일 로그로테이션하며, 최대 7개의 백업 파일을 유지한다.

missingok, notifempty, delaycompress, compress는 다양한 옵션을 설정하는 데 사용되고, postrotate와 endscript 사이의 부분은 로그로테이션 이후에 실행할 스크립트를 지정한다.

3. 일 단위보다 더 자주 logrotate를 실행하는 방법

임의의 커스텀 경로에 logrotate 스크립트를 등록하고 crontab에 등록해서 실행

→ cronjob의 실행 주기인 1분마다 rotate 수행 가능

# cron 주기에 따라 logrotate -vf <로테이트 파일명> 으로 커스텀 파일을 강제로 즉시 실행
*/10 * * * * deploy /usr/sbin/logrotate -s /home/username/logrotate/status -vf /your/custom/logrotate/file/path >> /your/custom/logrotate/path/logrotate_exec_log.log 2>&1

위와 같이 -s 옵션을 통해 logrotate 수행 status를 관리하는 파일 경로를 수동으로 지정해야 한다.

4. 실습하기

- 로그로테이트 : 기존의 로그 파일을 썰어주는 역할

- 먼저, 원본 로그파일이 저장된 경로를 적고 { }를 추가로 적어주어야 함

- su 유저명 그룹명 형식으로 하나 더 적어주어야 함

<log file> { 
    # 주기
     [daily, weekly, monthly, yearly <cycle of rotates>]
    # 로테이트 횟수
     [rotate <number of rotates>]
    # 로테이트 실행 후 비어있는 로그 파일 생성
     [create <permission value> <owner> <own group>]
    # 로그 파일 크기가 설정 값 보다 크고 지정한 주기가 됐을때 로테이트 수행
     [minsize <1M, 100k>]
    # 로그 파일 크기가 설정 값 보다 크거나 지정한 주기가 지났을때 로테이트 수행
    [maxsize <1M, 100k>]
    # 주기에 관계 없이 로테이트를 수행하는 로그 파일 크기
    [size <1M, 100k>]
    # 로테이트를 통해 새로 생성되는 파일에 날짜를 덧붙혀서 생성하는지 여부
     [dateext]
    # 로테이트를 통해 생성되는 파일을 압축하는지 여부
     [compress]
    # 설정을 참고할 로그로테이트 파일 위치
     [include /etc/logrotate.d]
    # 로그 파일이 존재하지 않는 경우 메시지 출력 (기본 값)
     [nomissingok]
    # 로그 파일이 존재하지 않아도 오류로 처리하지 않음
     [missingok]
    # 로테이트 시 기존 로그 파일 복사 후 제거 후 빈 파일로 생성
     [copytruncate]
    # 로그 썰기 전후 처리작업 
		 [prerotate]
				# prerotate 로직 작성
		 [endscript]
		 [postrotate]
				# postrotate 로직 작성
		 [endscript]
}

※ 위와 같이 다양한 옵션이 있다.

이제 위 두 파일을 생성해준다.

rotate_result.log는 로그로테이트 시 pre, post script에 의해 콘솔에 찍힐 값을 담을 파일이다.

logrotate_status는 프로세스 상태를 저장해주는  파일로 데몬에 의해 관리하지 않는 경우 필요하다.

# 로그로테이트를 logrotate 데몬 프로세스가 관리하는 기본 경로가 아닌 곳에서 실행할 경우
# s 옵션으로 프로세스 스테이터스 경로를 별도로 지정해야 함
# f 옵션은 rotate 강제 실행, -v 옵션은 verbose 로 실행 내용을 콘솔에 출력

/usr/sbin/logrotate -s /home/username/logrotate/status -vf /your/logrotate/file/path > /your/rotate/job/checking/file.log 2>&1

실행해보면 위와 같이 lock이 걸려 있어서 로그로테이트를 할 수 없다고 나온다. 

이를 해결하기 위해서 추가적인 조작이 필요하다.

logrotate_status 파일의 권한을 600으로 만들어 현재 로그인 중인 유저만 참조할 수 있게 해야 한다.

위와 같이 로그를 썰어주는 것을 확인할 수 있고, 원래 로그 파일 뒤에 .1이라는 확장자가 붙는다.

• 로그를 수납하는 서버를 따로 두겠습니다. 인스턴스 두 개를 더 만들어주세요.
• 하나는 수납용 서버, 이제 우리가 수업에 활용한 서버 + 방금 생성한 서버가 로그를 발송하는 서버가 됩니다.
• 양 서버에서 크론탭에서 어플리케이션 및 서버 자원에 대해 주기적으로 로그를 찍어주는 크론잡을 등록해주세요.
• 예를들어 로그를 분마다 찍는다면 n시간에 1번 그간 쌓인 로그파일의 이름을 전송하는 시점.log로 변경한 다음, 로그 수납 서버로 전송하고, 원본 서버에 있던 로그는 지우는 크론잡을 작성해주세요. 이 때, 발송서버가 2개이므로, 각 발송된 로그파일은 어떤 서버에서 발송했는지 확인할 수 있도록 해 주세요.
• 위 과정을 완성하셨다면 해당 작업에 대해 노션이나 블로그 포스팅을 남겨주세요.
• 위 과정이 완료되었다면 어떤 도메인의 인프라를 활용할지도 설계하고 운영 시나리오를 작성해주세요.

네트워크 설정

$ docker network 대역폭 설정

$ docker run 할 때 고정ip 지정해서 실행하기

먼저, 위와 같이 172.30 대역을 사용하는 lognet이라는 네트워크 

로그 파일을 수집해주는 savelog와 서버 자원을 주기적으로 찍어주는 로그 파일을 전송할 서버 2개를 생성해주었다.

# apt-get update
# apt-get install iputils-ping
# apt-get install net-tools

같은 내부망 안에서 서로 통신이 되고 있는 것을 확인할 수 있다.

# service ssh start
# apt-get install openssh-server

전송하고받을 컨테이너에서 netstat -ntl로 확인해보면 위와 같이 ssh (22번) 포트가 잘 열려있는 것을 볼 수 있다.

위와 같이 scp 명령어로 파일을 전송할 수 있고, Permission Denied 오류가 뜨는 경우 파일이나 경로의 권한 설정이 제대로 되어있는지 확인해야 한다.

서버 설정 

$ docker run -it --net=네트워크명 --name=서버명 ubuntu:22.04 bash

# apt-get update

# apt-get install cron

# apt-get install file

# apt-get install nano 

# apt-get install sudo

# adduser 유저명

# service cron start

위와 같이 job1 컨테이너에서 memlog.sh 파일을 수정한 후 실행하면 전송받을 컨테이너의 비밀번호를 입력하라는 문구가 나오고, 비밀번호 확인이 되면 파일이 전송된다.

savelog 컨테이너로 가서 확인해보면 파일이 잘 받아진 것을 볼 수 있고, 명령어가 수행된 내용도 잘 저장된 것을 확인할 수 있다.

쉘스크립트 작성

① job1.mem.sh

먼저, 저장할 로그파일의 경로를 설정해주는 log_file 변수를 만들었다.

또한, free 명령어를 이용하여 메모리 사용량을 가져오고, 로그 파일에 기록하는 스크립트를 작성했다.

② job1-send.sh

log_file : 메모리 사용량이 저장되는 로그파일의 절대 경로

remote_server : 전송할 savelog 서버의 주소와 파일을 저장할 경로

current_time : 현재시간

remote_file : 전송하는 시점의 시간으로 로그파일명 변경

해당 로그 파일이 어떤 서버에서 보내는 것인지 구분하기 위해 sed 명령어를 이용하여 파일의 첫 번째 줄에 위와 같은 문구를 추가했다. -i 옵션은 파일을 직접 수정하라는 의미이다. 1s(파일의 첫(s) 줄의 시작(^)에 /내용\울 추가하라는 의미이다.

scp 명령어를 이용하여 해당 파일을 복사하여 이동시킨 후 rm 명령어로 삭제한다.

실행권한을 준 후 실행시켜보면 위와 같이 잘 전송되는 것을 확인할 수 있다.

savelog 서버에서 확인해보면 위와 같이 잘 이동된 것을 확인할 수 있다.

크론탭 등록

크론탭에는 위와 같이 등록할 수 있다.

job1-mem.sh는 1분마다 실행되어 메모리 사용량을 1분마다 로그파일에 찍어준다.

job1-send.sh는 1시간(매시간 정각)마다 실행되어 전송 시점의 시간을 파일명으로 하는 로그파일을 savelog 서버에 보내주고 해당 파일을 삭제하게 된다.

위와 같이 job1-mem.sh 스크립트로 인해 생성된 job1-mem.log 파일을 확인해보면 1분마다 메모리 사용량이 저장되고 있는 것을 확인할 수 있다.

※ 리눅스 로깅은 보통 서버 자원이나 프로세스의 개수 등을 감시하다가 개수가 튀거나 자원이 부족해지는 상황을 모니터링하는 것이 일반적이다. 자원 관련이 아니라면 어플리케이션을 리눅스 위에서 돌리다 해당 어플리케이션이 뱉어내는 오류를 로깅하는 것이 1차적인 목적이다.

오류와 오류가 아닌 메시지를 모두 뱉어내는 자바 어플리케이션을 간단하게 만들고, 웹어플리케이션을 얹는 상황의 로깅 방법을 확인한다.

1. 리눅스에 자바 설치

$ sudo apt-get install openjdk-17-jdk  # 자바 설치
$ java -version                        # 자바 버전 확인
$ nano run_on_shell_j                  # 자바 프로그램 작성

먼저, 위 명령어로 리눅스에 자바를 설치한 후 run_on_shell_j라는 파일에 아래와 같은 코드를 작성했다.

loglog를 출력해주는 클래스 파일을 만들었고, 해당 파일을 실행해보면 위와 같이 잘 출력되는 것을 확인할 수 있다.

위 구문은 일반구문이므로 로그파일에 기록 시 그냥 기록된다. 

2. 어플리케이션에서 남겨준 에러로그를 리눅스에서 받아서 처리하기

1) 자바스크립트 기준

- 일반 로그 : console.log()

- 에러 로그 : console.err()

2) 자바 기준

- 일반 로그 : System.out.println() 혹은 log.info()

- 에러 로그 : System.err.println() 혹은 log.error()

위와 같이 코드 수정 후 catlogerr.log를 찍어보면 일반 로그인 loglog만 출력되는 것을 확인할 수 있다.

앞에서 배웠듯 유형 1, 유형 2로 분류되기 때문에 System.err.println()의 내역은 저장되지 않는 것이다.

이처럼 2>&1을 이용하여 저장하면 errerr도 문제없이 출력되는 것을 확인할 수 있다.

3. 로깅이 제대로 되고 있는지 좀 더 쉽게 확인하기

※ 해당 로깅 내역이 제대로 돌아가는지를 체크하기 위해 실제 현업에서는 크론탭을 2개씩 작성한다.

- 실행여부만 체크해주는 크론탭

- 실제 어플리케이션을 실행해주는 크론탭

💡 실습하기