다음으로 swap file에 대해 읽기 및 쓰기 권한을 수정하고 Linux swap 영역을 설정한다.
이후 swap 공간에 swap file을 추가해 swap file을 즉시 사용할 수 있도록 만들어준다.
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# 모두 성공했는지 확인
sudo swapon -s
swapon -s 명령어를 입력했을 때 Filename에 /swapfile이 나와야 한다.
이제 /etc/fastb 파일을 편집해 부팅 시 swap file이 활성화 되도록 해준다.
아래 명령어로 fstab 파일을 열어주고
/swapfile swap swap defaults 0 0 을 가장 마지막 줄에 추가해준 뒤 저장하고 종료하면 된다.
sudo vi /etc/fstab
그리고 아래처럼 free -h 를 입력했을 때 이미지와 같이 swap total이 2.0Gi가 되었다면 성공이다!
2. JDK17 설치
프로젝트 환경과 일치하는 JDK 17을 설치한다.
어려운 것은 없기 때문에 짧게 정리.
sudo apt-get update
sudo apt-get install openjdk-17-jdk
# openjdk version "17.0.11" 이런식으로 출력되어야 한다. 설치기간에따라 조금 차이는 있을 수 있다.
java -version
# 환경변수 설정
sudo vi /etc/profile
# /etc/profile 최하단에 아래 코드를 추가한 뒤 저장한다.
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
export PATH=$PATH:$JAVA_HOME/bin
export CLASSPATH=$JAVA_HOME/jre/lib:$JAVA_HOME/lib/tools.jar
#EC2 Instance reboot
sudo reboot now
#적용 확인
echo $JAVA_HOME
echo $PATH
echo $CLASSPATH
혹시 apt-get update 명령어를 수행했을 때 Some index files failed to download. They have been ignored, or old ones used instead. 라는 오류가 발생한다면 보안그룹의 아웃바운드 규칙을 확인한다.
아웃바운드 규칙이 모든 트래픽을 허용하고 있지 않다면 오류가 발생한다.
아웃바운드 규칙을 허용하는 것 만으로 문제를 해결했지만 그렇지 않은 경우도 있다고 해 그 방법들도 정리한다.
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.4/install.sh | bash
source ~/.bashrc
nvm install 21.7.1
# 21.7.1을 사용하겠다는 명령어
nvm use 21.7.1
# 21.7.1을 default 버전으로 설정
nvm alias default 21.7.1
# node 버전 확인
node -v
이것도 딱히 정리할 내용은 없어서 패스!
4. Nginx 설치
Nginx의 설치는 아래 명령어로 처리한다.
그리고 알아서 실행된다고 하지만 확실하게 명령어를 통해 실행시켰다.
sudo apt-get install nginx
sudo service nginx start
Nginx 설정 파일을 생성하고 적용해야 한다.
Nginx 설치 이후 /etc/nginx/sites-available에 접근하면 default라는 파일이 존재한다.
이 파일을 수정하는 케이스도 봤지만 파일을 만들어서 처리하는 경우가 더 많이 보였기 때문에 해당 방법으로 처리했다.
새로운 파일로 test.conf라는 파일을 만들어주고 이 파일을 sites-enabled에 심볼릭 링크를 만들어 이 설정파일을 통해 처리하도록 하는 과정이다.
예시로 도메인은 nvaer.com이라고 가정했고, EC2 public IP는 11.111.111.111로 가정했다.
만약 이 포스팅들을 처음부터 보고 있다면 도메인은 없을테니 public IP만 알고 있으면 된다.
cd /etc/nginx/sites-available
# 이 명령어를 수행했을 때 default가 존재해야 한다.
ls -al
# test.conf 파일을 생성한다. 이름은 상관없고 .conf로만 만들어주면 된다.
sudo vi test.conf
# test.conf의 내용
server {
listen 80; # IPv4
listen [::]:80; # IPv6
# 도메인 연결이 안되었다면 임시로 EC2 public IP를 적는다. 도메인 연결후 수정하면 됨.
server_name naver.com
# 배포할 프로젝트의 메인 경로로 설정. 만약 localhost:8080/main이 메인 경로라면 / 가 아닌 /main으로.
location / {
proxy_pass http://11.111.111.111:8080; #EC2 public IP와 프로젝트 서버 포트 작성
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
}
# ALB 대상그룹 Health check에 활용
# 원래라면 상단의 메인 경로를 통해 체크되는데 뭘해도 저 경로로 잡히지가 않아서 불가피하게 추가
# 메인 경로로 health check가 되지 않는다면 아래 코드를 작성.
location /health {
return 200 'healthy';
add_header Content-Type text/plain;
}
}
# sites-enabled에 심볼릭 링크 생성
sudo ln -s /etc/nginx/sites-available/test.conf /etc/nginx/sites-enabled
# site-enabled에 default가 존재한다면 default만 적용되기 때문에 제거해준다.
# 제거하더라도 site-available에는 존재하기 때문에 백업을 따로 할 필요는 없다.
# 주의 해야할 사항은 site-enabled에 존재하는 default만 제거해야 한다.
sudo rm default
# nginx 재구동
sudo service nginx reload
# or
sudo service nginx restart
# or
sudo systemctl restart nginx
여기에 추후 추가되는 사항도 있다.
만약 ACM을 통해서 인증서를 받지 않는 경우에는 80포트 아래에 443 포트도 추가해줘야 하고 그렇게 되면 인증서 정보가 꼭 들어가줘야 한다.
테스트는 ACM을 통해 인증서를 발급 받았기 때문에 위 내용으로 처리가 가능하지만 그렇지 않은 경우는 아래와 같이 작성해준다.
# test.conf
server {
listen 80; # IPv4
listen [::]:80; #IPv6
listen 443; # https 포트 추가.
listen [::]:443;
server_name naver.com # 도메인명 혹은 public IP
# 인증서 설정 추가
ssl_certificate /certificate 경로/certificate.crt;
ssl_certificate_key /cerficiate key 경로/private.key;
location / {
proxy_pass http://11.111.111.111:8080; # public IP
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
}
# AWS 대상그룹 Health check를 위해 필요
location /health {
return 200 'healthy';
add_header Content-Type text/plain;
}
}
443 포트까지 설정했는데 인증서 정보가 없다면 오류가 발생한다.
가장 아래에 /health는 이후 ALB 대상 그룹 생성의 health check에 사용되는데 원래는 그냥 기본 메인 경로를 통해 체크가 되었었는데 뭘 해도 안되길래 추가해서 200을 반환하도록 처리했더니 정상적으로 동작했다.
처음부터 추가할 필요는 없고 만약 대상 그룹에서 health check가 되지 않는다면 그때 작성해서 시도해보는 것도 좋을듯!
5. Jenkins 설치 및 빌드 Job 설정을 제외한 나머지 처리
Jenkins 설치와 페이지 접근, Jenkins의 계정 생성까지 정리.
Jenkins도 이전과 설치 방법이 좀 바뀌엇다.
# Jenkins 공개키 다운로드 및 저장
curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key | sudo tee \ /usr/share/keyrings/jenkins-keyring.asc > /dev/null
# Jenkins Repository 추가
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
/etc/apt/sources.list.d/jenkins.list > /dev/null
# 패키지 목록 업데이트 후 Jenkins 설치
sudo apt update
sudo apt install jenkins
# 상태 확인
sudo systemctl status jenkins
# 초기 비밀번호 ( 따로 메모 )
sudo cat /var/lib/jenkins/secrets/initialAdminPassword
# 포트 변경전 권한 수정
sudo chmod 777 /usr/lib/systemd/system/jenkins.service
# 포트 번호 원하는 번호로 수정 후 저장
sudo vi /usr/lib/systemd/system/jenkins.service
# 꼭 권한을 다시 원래대로 수정한다
sudo chmod 444 /usr/lib/systemd/system/jenkins.service
# jenkins 재시작
sudo systemctl daemon-reload
sudo serivce jenkins restart
# 만약 그래도 변경되지 않았다면 아래 파일에서도 포트 변경 후 재시작
sudo vi /etc/default/jenkins
설치는 위 과정을 따라가기만 하면 무리없이 처리된다.
상태 확인 명령어를 수행했을 때 active가 정상적으로 나와야 하고 초기비밀번호의 경우 Jenkins 페이지 접근했을 때 필요하므로 저장해두도록 한다.
Jenkins 설치 이후에는 8080이 기본 포트로 설정되는데 프로젝트에서 8080 포트를 사용하기 때문에 9095 포트로 변경해줄 필요가 있어 포트 번호를 수정해준다.
마지막 재시작까지 수행하고 나면 EC2 public IP:jenkinsport 를 통해 페이지에 접근할 수 있다.
그럼 가장 먼저 비밀번호를 입력하라고 하는데 중간에 조회했던 초기 비밀번호를 붙여넣기 해준다.
그럼 이제 아래와 같은 페이지가 나오게 되는데 설정에 따라 다르겠지만 Install suggested plugins를 선택해 기본 플러그인들을 설치하도록 한다.
플러그인 설치가 완료된 이후에는 아래처럼 계정 생성 페이지가 나오는데 스킵해도 되지만 계정을 생성해줬다.
그럼 아래처럼 접근 URL이 나온다.
보통 접근한 URL이 그대로 나오기 때문에 딱히 건드릴 필요는 없을 것 같다.
이후 Jenkins 메인 페이지에서 Jenkins 관리 탭으로 이동한다.
System Configuration의 Plugins 로 이동.
Available plugins 탭으로 이동해 설치할 플러그인들을 설치해야 한다.
설치할 플러그인은 아래와 같다.
Post build task
NodeJS
GitHub Integration
플러그인을 하나 설치할때마다 재부팅 선택지가 있는데 이건 따로 언급되는 것을 본적이 없다.
그래도 그냥 있는 기능이니까 재부팅을 해줬다.
Post build task는 빌드를 처리할 때 사용할 것이고, NodeJS는 React 빌드를 위해 설치했다.
GitHub Integration은 git webhook 연동에 사용된다.
모든 플러그인을 설치했다면 Node에 대해 설정해줘야 할 것이 있다.
다시 Jenkins 관리 탭으로 이동해 이번에는 System Configuration의 Tools로 이동한다.
그리고 하단으로 쭉 내려보면 NodeJS Installiations가 존재한다.
이미지는 이미 설정해둔 상태라 그렇지만 Add NodeJS라는 버튼이 빨간 박스 위치에 있을 것.클릭!!
EC2 인스턴스에 설치한 것과 동일한 21.7.1 버전을 사용하도록 하는 과정이다.
Install automatically를 체크해 자동으로 설치하도록 한다.
다 처리했다면 Apply 누른뒤 Save!
그럼 이제 Jenkins에서 빌드를 제외한 기본적인 설정은 끝이다.
6. ElastiCache Redis OSS 캐시 생성 및 Redis 설치
EC2에 Redis를 설치하기 전 ElastiCache에서 Redis OSS 캐시를 생성한다.
AWS에서 ElastiCache로 접근하고 리소스 하위에 있는 Redis OSS 캐시 탭으로 이동해 Redis OSS 캐시 생성 버튼을 클릭한다.
아래 이미지처럼 배포 옵션에서는 자체 캐시 설계를 선택하고 생성 방법은 클러스터 캐시로 선택한다.
클러스터 모드는 비활성화를 선택한다.
테스트이기 때문에 굳이 사용할 것 같지 않은데다가 활성화 하면 추가적인 요금도 발생한다.
클러스터 정보에는 이름을 작성해주면 된다.
위치 탭에서는 위치에 대해 AWS 클라우드를 선택하고 클러스터 설정에서 포트는 기본값 그대로 유지했다.
위치 탭의 다중 AZ는 이미지와 다르게 활성화된 상태일텐데 클러스터 설정 하단의 복제본 개수를 0으로 바꿔주면 비활성화 된다.
이것도 테스트에 필요하진 않아서 0으로 수정했다.
노드 유형의 경우 24년 7월 기준으로 기본 값이 cache.r7g.large로 되어있다.
이렇게 큰게 필요없기도 하고 이것도 유형 선택에 따라 요금이 달라지기 때문에 프리티어에 해당하는 t3.micro를 선택했다.
연결 탭에서는 새 서브넷 그룹 생성을 선택하고 서브넷명을 작성해준다.
그리고 서브넷 선택됨 탭의 관리 버튼을 눌러 자신의 리전에 해당하는 서브넷을 선택해주면 되는데 여러개를 선택할 수 있다.
가용영역 배치는 따로 건드릴 것은 없어서 그대로 두고 다음 버튼을 클릭!
다음 페이지인 고급 설정에서는 보안 그룹만 선택해주고 나머지는 건드리지 않았다.
보안 그룹 역시 기존에 생성한 모든 환경에 대해 열어준 그 보안 그룹을 선택했다.
여기서 다시 한번 생각해보면 왜 보안그룹을 하나로 처리하지 말아야 하는지 알 수 있다.
열어줘야 하는 인바운드 규칙은 6379 포트 하난데 하나의 보안그룹을 사용하면 괜히 Redis cache에 80, 443, 8080 등등 규칙이 들어가 있게 된다.
뭐.. 일단은 테스트니까~
하단의 다음 버튼을 누르면 생성이 완료되고 이제 EC2에서 Redis를 설치한다.
sudo apt-get update
# build-essential과 wget 설치
sudo apt-get install build-essential wget
# Redis의 최신 버전을 포함하는 tar.gz 다운로드
wget http://download.redis.io/redis-stable.tar.gz
# 다운로드 받은 파일 조작
tar xvzf redis-stable.tar.gz
cd redis-stable
make distclean
make
# redis 접속
# -h 이후에는 ElasticCache 엔드 포인트를 적는다. com 뒤에 포트는 ' : '가 아닌 -p로 수정해준다.
src/redis-cli -c -h RedisOSS 캐시 기본 엔드포인트 -p 6379
여기서는 조금 생소했던 tar xvzf ~~~ 코드에 대해 조금 정리를 한다.
tar는 tar 아카이브 조작을 위한 유틸리티이다.
xvzf는 각각 의미가 있는데 아래와 같은 의미를 갖는다.
x - 파일 추출
v - 자세한 모드(추출 과정을 보여준다)
z - gzip 압축 해제
f - 파일 지정
make distclean도 정리.
make는 Makefile을 읽고 소프트웨어를 빌드하는 명령어다.
distclean은 모든 빌드 아티팩트와 설정 파일을 제거하여 소스트리를 초기 상태로 되돌리는 make 타겟이다.
주로 이전 필드의 잔여물을 제거하기 위해 사용한다.
이후 make 명령어는 Makefile에 정의된대로 소스코드를 빌드한다. 여기서는 Redis 서버와 클라이언트 프로그램이 컴파일 된다.
그럼 이제 마지막 라인에 작성된 명령어를 통해 redis에 접속할 수 있다.
이때 명령어 입력 위치는 redis-stable이다.
명령어를 입력할 때 엔드포인트는 포트를 제외한 com 까지만 작성해주면 된다.
Redis 접속 이후 정상 동작하는지 명령어를 통해 체크하면 된다
프로젝트의 application.yml에서도 redis 관련 정보 host에 엔드포인트를 작성하면 되는데 접속 명령어때와 마찬가지로 com 까지만 작성해주면 된다!
