HTTPS : Http + Secure. 기존의 HTTP에 "안전"을 더한 형태. 그럼 뭘 안전하게 하는 것인가? 크게 2가지로 볼 수 있다
내가 사이트에 보내는 정보들을 제 3자가 못 보게 한다
내가 접속하는 사이트가 신뢰할 수 있는 사이트인지 알려준다
그러면 이 두 가지 내용이 어떤 원리로 구현되는가?
1은 비대칭키를 사용한 암호화로 가능하다. 서버가 가진 "공개키"로 암호화해서 보내면, 해당 암호문은 "개인키"를 가진 서버만이 해독 가능하다. 따라서 제 3자가 내가 보내는 트래픽을 엿봐도 해독(복호화)할 수 없다. (제 3자도 서버의 공개키를 알 수는 있겠지만, 비대칭키의 특성상 공개키로 암호화한 내용을 공개키로 복호화할 수 없기 때문)
2도 마찬가지로 비대칭키 특성을 통해 가능하다. 서버에서 보내는 정보는 서버의 "개인키"로 일부가 암호화돼있다. 그러나 내가 가진 서버의 "공개키"로는 오직 해당 서버의 "개인키"로 암호화한 것만 복호화가 가능하다. 즉 해당 서버가 아닌 다른 서버에서 온 내용은 내가 가진 공개키로는 복호화가 안 된다는 거다. 이 때 신뢰가능한, 즉 공인된 특정 기관에서 내가 가진 공개키가 해당 서버의 공개키가 맞다는 인증만 받는다면 해당 서버를 신뢰할 수 있게 되는 것.
그럼 프로그래머의 영역에서, HTTPS는 실제로 어떻게 구현될까?
우선 jofe라는 사이트가 공개키들을 뿌렸다고 가정하자. 난 이 공개키가 jofe란 사이트의 공개키인지(즉 정품인지)를 확인할 수 있어야 한다. 이를 인증해주는(보장해주는) 공인된 기관들이 존재하며, 이들을 CA(Certificate Authority)라고 부른다. 우리가 사용중인 브라우저들엔 이 CA들의 목록이 저장돼있다.
이런 상황에서, 내(client)가 jofe(server)에 접속할려고 한다. 랜덤한 데이터나 만들어서 서버에게 주면, 서버는 그에 대한 답변으로 랜덤한 데이터와 "CA에서 발급해준 해당 서버의 인증서"를 만들어서 내게 준다. (클라이언트 서버가 악수했다고 표현)
그럼 클라이언트는 해당 인증서가 진품인지를 판단하는데, 이 때 브라우저에 내장된 CA들의 정보를 통해 확인한다. CA의 인증을 받은 인증서들은 해당 CA의 개인키로 암호화돼있기 때문에 그 CA의 공개키로 복호화가 가능하다. 즉 받은 인증서가 진품이라면 브라우저에 있는 C의 공개키로 해당 인증서를 복호화 가능한 것이다.
성공적으로 복호화된 인증서에는 인증서를 보낸 서버(jofe)의 "공개키"가 들어있다. 하지만 그렇다고 이제부터 바로 내가 서버로 보낼 메시지들을 공개키로 암호화해서 보낼 수 있는 건 아니다. 왜냐하면 비대칭키는 대칭키 방식보다 컴퓨터에 주는 부담이 크기 때문. (주고받을 다량의 데이터를 하나하나 비대칭키로 암호화하는 건 부담이 된다는 것)
따라서 주고받을 데이터를 "대칭키"로 암호화한다. 대칭키를 사용하는 경우의 가장 큰 단점은 양쪽이 똑같은 키를 가져야 하므로 어쨌거나 한 번은 서로 통신을 해서 키를 주고받아야 하는데, 이 때 탈취당할 위험이 있다는 거다. 이 때 클라이언트는 아까 악수할 때 만들어진 데이터들을 이용해 임의의 대칭키를 만든 다음, 서버로 이를 공유할 때 "비대칭키"를 사용한다. 즉 서버의 "공개키"로 임의로 만든 대칭키를 암호화하여 보낸다는 말. 서버는 이를 자신의 "개인키"로 복호화하여 클라이언트가 만든 대칭키를 그대로 쓸 수 있게 되는 거고, 이제 양쪽이 서로 대칭키를 갖게 됐으니 이를 통해 서로 데이터들을 암호화하여 통신할 수 있게 된다.
그림으로 나타내면 다음과 같다
우선 클라이언트가 랜덤한 데이터를 만들어 서버로 보낸다
그러면 서버도 랜덤한 데이터와 함께 CA에서 발급해준 인증서를 보낸다(이 인증서는 해당 CA의 개인키로 암호화돼있다)
클라이언트는 브라우저에 내장된 CA목록들을 통해 해당 CA의 공개키로 인증서를 복호화한다. 어떤 공개키로도 복호화가 안되면 당연히 서버 쪽을 신뢰할 수 없는 거고, 복호화됐다면 인증서를 보낸 서버를 공인된 서버라고 신뢰할 수 있게 된다.
또한 해당 인증서는 서버의 공개키를 가지고 있어서, 복호화에 성공했다면 요로코롬 서버의 공개키를 얻게 되는 거다.
이제 클라이언트는 아까 만들었던 클라이언트쪽의 랜덤데이터와 서버로부터 받은 서버쪽 랜덤데이터를 활용해 대칭키를 만들고, 이를 인증서에 들어있던 서버의 공개키로 암호화하여 서버에게 보낸다.
서버는 이를 자신의 개인키로 복호화할 수 있고, 이를 통해 클라이언트와 서버가 동일한 대칭키를 갖게 되는 것이며 이를 통해 데이터를 서로 암호화하고 복호화하며 통신할 수 있게 된다.
이전에 로컬에서 도커 이미지를 빌드하고 이를 도커 허브에 올린 뒤 ec2에서 이미지를 풀하고 컨테이너를 돌리는 식으로 배포해봤었는데, 새로운 기능을 추가하고 수정도 하면 이 과정을 하나하나 하기는 귀찮다. 그래서 jenkins라는 오픈소스를 활용해 빌드하고 테스트, 배포하는 과정을 자동화해본다.
또한, 나름대로의 코드 품질 개선과 혹시 모를 보안 위협에 대비하기 위해 sonarqube라는 코드 정적 분석 툴을 사용할 건데, 이는 sonarcloud라는 서비스를 통해 간단하게 도입해볼 것이다.
그림으로 시퀀스를 나타내면 다음과 같다.
pull request가 생기면 sonarqube(sonarcloud)에서 코드 정적 분석을 한다.
웹훅을 수신하면, jenkins쪽에서 지정된 깃헙 리포지토리의 코드를 땡겨온다 (+ application.properties 설정)
이를 gradle을 통해 빌드하고(jar)
이를 docker image로 빌드한 뒤 도커 허브에 푸쉬.
실제 서비스가 돌아갈 ec2에서 도커 허브에 푸쉬된 이미지를 땡겨와 돌리게끔 하면 된다
이 때 단순히 gradle로 빌드한 jar를 서비스를 돌릴 ec2로 보낼 수도 있지만(scp등으로) 멘토님 가라사대 요즘은 도커 모르면 안 된다라고 하셔서, 도커에 익숙해질 겸 도커 이미지를 만들고 이를 전달하는 식으로 가기로 했다. 그러면 도커로 띄운 젠킨스에서 도커 이미지를 만들어내야 해서, 도커 내에 도커를 설치해야 하니 이 점 유의
0. sonarcloud 설정
깃헙 계정으로 가입해서 설정만 딸깍딸깍 누르면 된다. sonarcloud를 설치할 레포지토리들을 선택하면 지가 알아서 설치되고, 이후 pull request를 날리면 지가 알아서 다음과 같이 분석 결과를 남겨준다
1. ec2 띄우고 docker 설치 및 swap 메모리 설정
참고로 ec2는 public subnet에 띄웠다. private subnet에 띄우면 깃헙 쪽에서 웹훅을 보낼 때 직접 받을 수 없기 때문에, 편의를 위해 그리 한 것임.
아 그리고 EBS볼륨을 20GB로 해줬다! 기본인 8GB로 해줬다가 용량이 없다고 하는 문제가 생겼었기 때문.
-v : 호스트와 컨테이너를 볼륨 마운트. 이를 통해 컨테이너와 호스트 머신 간에 데이터를 공유할 수 있음
-v /var/run/docker.sock:/var/run/docker.sock -> 컨테이너 내부에서 호스트머신의 docker 데몬과 상호작용하게끔 하는 것.
-v jenkins_home:/var/jenkins_home -> jenkins 설정과 데이터를 영구적으로 저장하기 위함
-u root : 컨테이너 내에서 jenkins를 root사용자로 실행
그 뒤 다음 커맨드를 통해 docker.sock파일의 권한을 수정해준다(다른 사용자도 접근 가능하게끔). 참고로 컨테이너 밖에서 실행해준다.
sudo chmod 666 /var/run/docker.sock
참고로 docker.sock은 도커 데몬과 컨테이너 간의 통신을 위한 소켓 파일이다.(그래서 ls -l로 보면 파일타입이 s가 나옴) 이를 통해 컨테이너 내부에서도 호스트 머신의 docker데몬과 통신 가능하며, 이를 통해 컨테이너 내부에서도 docker커맨드를 쓸 수 있게 되는 것. 컨테이너 내에서도 docker데몬에 대한 권한을 부여하기 위해 위 커맨드를 통해 권한을 주는 거라고 생각하면 된다.
3. 컨테이너 내 도커 설치
엇? 컨테이너 내에서도 호스트의 도커 데몬과 통신할 수 있게끔 한 거면 도커를 설치할 필요가 없지 않나? (나는 도알못이기 때문..) 왜 도커를 설치하지?
이럴 거면 docker run을 할 때 굳이 -v를 해서 docker.sock을 컨테이너로 마운트한 이유가 없지 않나? 그냥 컨테이너에서 도커 깔았으면 거기서 자체적으로 도커 데몬 쓰면 되지..(참고로 이를 Docker in Docker, DinD라고 부르고 소켓파일 마운트해서 호스트의 도커 데몬을 쓰는 방식을 Docker ouf of docker, Dood라고 부른다)
간단하다. 제 아무리 호스트 꺼여도, 어찌됐건 도커 데몬과 통신하려면 도커 클라이언트가 필요하기 때문에 도커를 설치하는거다. 다만 데몬을 호스트 꺼를 사용한다는 것. (그냥 DinD로 컨테이너 내에서 자체 도커 데몬을 써도 되나, 보안상 이를 권하지 않는다고 한다. 무려 도커공식피셜임. 참고로 도커를 요로코롬 컨테이너 내에 깔아도 docker.sock은 호스트와 마운트된 걸 사용하게 된다)
그림으로 표현하면 아래와 같은 형태가 되겠다.
찾아보니 나는 젠킨스 이미지를 바로 컨테이너로 띄우면서 docker.sock을 마운트하고 컨테이너 내에 도커를 설치한 반면, 젠킨스 이미지를 베이스로 도커를 설치하는 도커이미지를 만든 다음(즉 젠킨스를 한 번 더 포장한 이미지인데 도커가 설치돼있는 이미지가 된다) 컨테이너 띄울 때 docker.sock을 마운트하는 방식도 있다.
암튼.. 컨테이너 내에 도커를 설치해본다
우선 docker exec을 해서 컨테이너 내부로 들어간 다음, 위에서 한 것과 똑같은 가이드북대로 설치했다.
근데 중간에 apt-get update를 하니 The repository 'https://download.docker.com/linux/ubuntu bookworm Release' does not have a Release file이라는 오류가 났었다. 이는 아래 글을 참고해 /etc/apt/sources.list.d/docker.list를 지운 뒤 실행함으로써 해결했다
(/etc/apt/sources.list.d : 이 디렉토리에 있는 파일들은 APT 패키지 관리자에게 소프트웨어 패키지 저장소를 추가하는 데 사용됨)
(docker.list : Docker 패키지를 제공하는 저장소를 가리키며, 이 저장소는 Docker 엔진과 관련된 패키지를 제공)
근데 또 이번엔 sudo apt-get install docker-ce docker-ce-cli containerd.io (이하 생략) 커맨드에서 Package docker-ce is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source라는 메시지와 함께 오류가 났다. 아까 docker.list를 삭제했던게 원인인 듯 한데.. 문제는 얘를 삭제안하면 다른 오류가 계속 나던 상황이라.. 해결방법을 찾아보다가, docker.list를 지운 상태에서 아래 커맨드를 실행하니 설치가 잘 됐다.
curl -fsSL get.docker.com -o get-docker.sh
bash get-docker.sh // 다운받은 쉘 스크립트 파일 실행
이렇게 하니 설치가 됐다. curl을 통해 get.docker.com으로부터 도커를 설치하는 스크립트를 get-docker.sh란 파일로 다운받은 뒤 이를 실행하는 커맨드다.
4. application.properties 설정
내 프로젝트는 .gitignore를 통해 application.properties를 깃 관리 대상에서 제외했다. 따라서 나중에 젠킨스에서 깃헙 리포지토리에 있는 코드를 땡겨가도 그래도 빌드해 사용한다면 문제가 생길 것이다. application.properties를 주입하는 방법은 여러 가지가 있겠지만, 나는 컨테이너의 /home/env밑에 application.properties를 두고 나중에 젠킨스에서 이걸 가져다 쓰는 식으로 구성했다.
docker exec -it jenkins bash // 컨테이너 내부로 들어가기
cd /home
mkdir env // /home밑에 env 디렉토리 생성
cd env
echo "{application.properties 내용}" >> application.properties
이런 방식으로 만들었었다.
여까지 했다면, 이제 젠킨스라는 툴을 사용해 ci cd 파이프라인을 구축할 준비가 된 거다. 젠킨스 설정은 젠킨스에서 제공하는 웹 인터페이스(즉 사이트)를 통해 가능하니, 웹사이트로 들어가 설정을 진행해본다.
5. 젠킨스 웹사이트 접속 (ec2의 퍼블릭ip:8080)
docker exec -it {컨테이너명} bash 같은 걸로 컨테이너 안에 들어가서 저 경로로 cat찍으면 패스워드 볼 수 있으니 그리 하면 된다. (사실 엄밀히 말하면 들어간다기보다는 컨테이너에서 작업할 수 있게 해주는 커맨드라고 보는게 맞다)
추천해주는 플러그인 설치한 뒤, 회원가입 페이지(?)같은 게 나온다. 자신의 플젝에 맞게 설정하면 된다.
6. 젠킨스 설정 - jdk, gradle, github & dockerhub token
jar 빌드를 위해 jdk와 gradle을 설정해줄 필요가 있고, 깃허브 리포지토리에 있는 코드들을 땡겨와야 하기 때문에 github token이 필요하며, 도커 이미지를 도커허브에 올리기 위해 dockerhub token도 필요하다. 우선 jdk와 gradle설정부터 시작해본다
프로젝트에서 jdk11버전을 썼다면 모를까, 나는 17버전을 쓰기 때문에 따로 설정을 해줘야 한다.
subdirectory : url을 통해 다운된 파일을 압축 해제 했을 때 나오는 폴더 이름
jdk-17.0.8.1+1
gradle 설정도 jenkins관리 - tools에서 해주며, 플젝에서 쓰는 spring boot에서 사용중인 버전과 똑같은 놈으로 하면 된다.
본인 스프링부트 프로젝트의 gradle> wrapper >gradle-wrapper.properties에서 확인 가능하다
그리고 jenkins관리 - Credentials로 가서 깃허브 토큰을 등록한다. 깃허브 토큰을 발급받는 과정은 생략한다.
이 때 kind를 secret text가 아닌 username with password로 해준다. git이 뭐 지원 안한다고 함
username : 깃허브 계정 (이메일)
password : 깃헙 토큰
id : 본인이 식별할 수 있는 거 암거나 작성
마찬가지로 dockerhub token도 발급받은 뒤 똑같이 username with password로 등록해주면 된다. username은 도커허브 계정(아이디) 넣으면 되고, password에 토큰값 넣어주면 되고, id도 본인이 식별가능한 거 써주면 된다
7. 젠킨스 설정 - ssh 관련 설정
도커 이미지를 도커 허브에 푸시한 뒤, ssh로 서비스를 배포할 ec2에 접속해 도커허브로부터 이미지를 땡기는 작업을 하게 된다. 이를 위해 ssh를 사용하는데, 예전엔 Publish Over SSH라는 걸 썼던 듯 하나 지금은 못 쓰는 듯 하다. (새로운 openssh에서 ssh-rsa키 유형이 비활성화됐다고 한다. https://github.com/jenkinsci/publish-over-ssh-plugin/issues/247#issuecomment-1153768171)
그러면 이제 젠킨스가 띄워진 ec2에 ssh키를 물리적으로 둘 수도 있을 텐데, 이건 사실상 현관문 바로 앞에 키를 두는 방식이니 좋지 않다. 찾아보니 ssh agent플러그인을 젠킨스에서 다운받아 쓰는 방법이 있어, 이를 쓰기로 한다.
jenkins관리 -> 플러그인 -> available plugins로 가서 ssh agent를 install한다
난 이미 설치해서 안 뜬다
그 다음 아까 깃헙&도커허브 토큰을 등록했을 때처럼 ssh key정보를 등록한다.
cat으로 ec2의 ssh key(pem파일)을 본 다음, 내용물을 적어주면 된다.
8. 깃허브 웹훅 설정
리포지토리 세팅 -> Webhooks로 가서 http://젠킨스서버ip:8080/github-webhook/을 등록한다
그리고 깃허브 쪽에서 보내는 웹훅을 젠킨스서버가 잘 받기 위해, 젠킨스 서버에 대한 보안그룹에서 깃허브 쪽에서 오는 인바운드들이 열려 있어야 한다.
General - GitHub project에 리포지토리 url(.git으로 끝나는..)을 입력한다.
그리고 build triggers에서 다음과 같이 체크해준다
그리고 파이프라인 스크립트를 작성한다.
난 다음과 같이 작성해줬다.
pipeline {
environment {
repository = "{도커허브계정}/{레포지토리 이름}" // 이메일말고 아이디
DOCKERHUB_CREDENTIALS = credentials('등록해둔 도커허브토큰id') // jenkins에 등록해 놓은 docker hub credentials 이름
dockerImage = ''
}
tools {
jdk "{jdk이름}" //아까 jdk등록할 때 name으로 준 값
}
agent any
stages {
stage('GitHub Repository Clone') {
steps { // url의 main branch 내용을 credential을 통해 땡겨온다
git branch: 'main', credentialsId: '{등록해둔 깃헙토큰id}', url: '{깃헙 리포지토리 주소(.git으로 끝나는)}'
}
}
stage('Set Application.properties') {
steps {
sh '''
if [ ! -d ./src/main/resources ]; then
mkdir ./src/main/resources
else
echo "resources directory alreay exist"
fi
if [! -e ./src.main/resources/application.properties ]; then
rm ./src/main/resources/application.properties
fi
cp /home/env/application.properties /var/jenkins_home/workspace/{지어준 파이프라인 이름}/src/main/resources
cat ./src/main/resources/application.properties
'''
}
}
stage('Build jar') {
steps{
sh '''
echo 'start bootJar'
echo $JAVA_HOME
./gradlew clean bootJar
'''
}
}
stage('Docker build') {
steps {
sh '''
docker build -t $repository:latest .
'''
}
}
stage('Dockerhub Login'){
steps {
sh '''
echo $DOCKERHUB_CREDENTIALS_PSW | docker login -u $DOCKERHUB_CREDENTIALS_USR --password-stdin
'''
}
}
stage('Push Docker image') {
steps {
sh '''
docker push $repository:latest
'''
}
post {
success {
echo 'push success'
}
failure {
echo 'push failure'
}
}
}
stage('Run New Docker Container'){
steps {
sshagent(credentials: ['ssh-key']) {
sh '''
ssh -o StrictHostKeyChecking=no ubuntu@{서비스 띄울 ec2 ip} 'sudo docker ps -a'
// 기존에 돌아가던 컨테이너 삭제
ssh -o StrictHostKeyChecking=no ubuntu@{서비스 띄울 ec2 ip} '
if [ "$(sudo docker ps -q --filter name={삭제할 컨테이너명}" ]; then
sudo docker rm -f $(sudo docker ps -aq --filter name={삭제할 컨테이너명})
else
echo "no there containers"
fi
'
// 기존 이미지 삭제
ssh -o StrictHostKeyChecking=no ubuntu@{서비스 띄울 ec2 ip} '
if [ "$(sudo docker images -q)" ]; then
sudo docker rmi $(sudo docker images -q)
else
echo "no there images"
fi
'
ssh -o StrictHostKeyChecking=no ubuntu@{서비스 띄울 ec2 ip} 'sudo docker pull {아까 푸시한 이미지명}'
ssh -o StrictHostKeyChecking=no ubuntu@{서비스 띄울 ec2 ip} 'sudo docker run -d --name={컨테이너명} -p 8080:8080 {풀받은 이미지명}'
'''
}
}
}
stage('Clean Docker Image') {
steps {
sh '''
docker rmi $repository:latest
'''
}
}
}
}
참고 : docker image -q 또는 docker ps -q -> 아이디값만 보게 해준다.
이후 깃헙에서 푸시를 해보니..
다음과 같이 파이프라인이 잘 돌아가는 걸 확인할 수 있다.
어찌보면 남들 다 하는 ci cd 구성이지만.. 그래도 처음 해보면서 삽질 여러가지 하면서 배운 게 많은 것 같다. DinD나 DooD도 있고, 특히 쉘 스크립트 작성을 꽤나 해보게 됐다ㅋㅋㅋㅋ.. jar로 빌드하고, 도커 이미지 빌드하고, 도커허브에 푸쉬하고, 서비스 띄울 ec2에선 기존 컨테이너랑 이미지 삭제한 뒤에 새로 풀받아서 돌리고.. 한 스텝 한 스텝 성공할 때마다 왠지 모를 희열이 느껴졌다.
다만 아직 고려해야할 부분들이 더 많다. 당장 도커 이미지만 봐도 일단 전부다 latest를 달아서 하게끔 했는데, 이것보다는 빌드별로 번호를 매겨서 붙여주는게 더 나을 거다. 또한 지금 구축한 것대로라면 기존에 돌아가던 컨테이너를 내리고 새로 이미지를 받은 뒤 컨테이너를 띄우는 동안은 서비스가 중단된다!! 즉 무중단 배포도 고려해야 할 것이다.
기능 개발을 해야 할 게 남아 있는 만큼, 그리고 https 구축도 해야 하는 만큼 일단 그것들에 먼저 신경을 쓰고 해야 할 듯 하다..
여기서 http블록 안에 직접 server 블록을 작성해줌으로써 웹 서버에서 특정 도메인, 호스트 이름, 포트 또는 IP 주소와 관련하여 요청을 어떻게 처리할지를 정의할 수 있다. 또는 위에 적혀있듯이 /etc/nginx/sites-enabled나 /etc/nginx/conf.d에 작성한 conf파일에 적힌 내용을 include하는 식으로도 server 블록을 정의할 수 있다(즉 직접 nginx.conf안에 작성하든가, 아니면 외부에서 작성한 후 include로 끌고 올 수 있다)
이 server 블록은 각 블록별로 하나의 웹사이트 또는 가상 호스트(Virtual Host)를 의미한다. 즉 여러 개의 server 블록을 작성해 다수의 도메인을 하나의 서버에서 가동할 수 있는 것이고, 이는 다수의 도메인에 대해 하나의 서버에서 각기 다른 페이지를 서비스할 수 있다는 말이다. server 블록은 다음과 같이 작성 가능하다.
server {
listen 80;
server_name example.com;
location / {
# example.com에 대한 설정 ...
}
}
listen : nginx server가 클라이언트로부터 요청을 수신하는 방법을 정의. 걍 어느 ip 어느 포트로 올 건지를 말 그대로 listen한다는 것을 설정하는 부분
server_name : 해당 server 블록이 처리할 도메인이나 호스트네임 또는 ip주소를 지정. 클라이언트로부터 request가 오면 header에 있는 Host값과 이 server_name값이 일치하면 해당 server블록을 활성화하는 것임. server_name을 없애고 listen에 example.com:80으로도 작성 가능함
location 블록 : 특정 URL 경로 또는 패턴에 대한 요청을 처리하는 방법을 정의. 해당 경로에 대한 프록시 패스를 처리한다든지..그런 것들을 설정해줄 수 있다. 위 예제에선 example.com의 모든 요청(/이니까~)에 대한 모든 요청에 대해 location블록에 설정한 내용이 동작할 것임. 필요에 따라 한 server 블록에 여러 location블록을 둘 수 있음
기타 다른 설정도 가능..
여기서 내가 처음에 헷갈렸던 건, "server_name으로 해당 server블록이 처리할 도메인을 적으라는 것". 아니 그러면 naver 도메인같은 걸 여기 적어줘도 되는거야? 란 생각이 들었다. 그러면 말이 안 되지 않나? 저 문장대로면 브라우저에 naver치고 들어가는 걸 naver서버가 아니라 내가 띄운 nginx가 처리해야 한다는 거 아닌가?
그리고 애당초 난 처음엔 server_name을 프록시 대상의 도메인이나 ip주소를 적어줘야 하는 줄 알고 있었다.. (nginx를 리버스 프록시로 쓸 생각으로 설치했었고 자료를 찾아봤어서...) 그래서 nginx 처음 쓰는데 server_name에 프록시 대상으로 was의 주소(nginx를 웹서버, spring boot를 was로 사용해서 was의 주소를 적어줬었음)를 줬는데 잘만 동작하길래 내가 이해한 게 맞다 싶었다. 근데 알고 보니 server_name으로는 server블록이 처리할 도메인과 같이 웹서버에 관한 뭔가를 쓰는 거여서 뭐지? 싶던 거.
"난 server_name으로 웹서버가 아닌 was에 대한 걸 적어줬는데 왜 프록시 패스가 잘 되는거지?"
그래서 실험을 좀 했다.
우선 server 블록은 다음과 같이 1개만 작성된 상태
server_name에 was(spring boot)의 사설 ip를 박아뒀었다. nginx는 public subnet에 띄웠었고, was랑 같은 vpc안에 있으니 사설 ip를 통해서도 접근이 가능하기 때문에, was의 사설 ip를 server_name에 박아줘도 된다고 생각했음. 그래서 proxy_pass에 server_name에 준 주소를 그대로 써먹은 모습을 확인 가능하다.
암튼 이렇게 두면, 잘 된다. nginx쪽에 request를 보내면 잘만 was쪽으로 request를 던져준다. 근데 왜 잘 되는 건지는 몰랐다. 일단 server_name에 10.0.1.88을 박아뒀으니 reqeust의 Host와 매칭되진 않을텐데? 근데 왜 프록시 패스가 잘 되지?
바보같은 생각이지만(?) Host와 server_name이 매칭이 안 되면 10.0.1.88로 뭔지 모르겠지만 보내나,,? 싶었다. 그래서 server 블록을 하나 더 추가해줬다.
이렇게 하니, 안된다. nginx쪽으로 보낸 request가 was쪽으로 던져지지 않는다(즉 was에 request가 오지 않음). 매칭이 안 된다고 10.0.1.88로 무조건 보내는 건 아닌 듯 하다. 근데 이상하게 두 server 블록의 순서를 바꿔주면 됐었음. (이때까진 이유를 몰랐다)
사실 이때까지도 server_name을 프록시 대상의 ip를 줘야 하지 않을까란 의심(?)을 버리지 못한 상태라,, server_name이랑 request의 Host가 정확히 어떻게 매칭이 되는거지라는 생각이 들었다.. server_name을 아예 nginx가 띄워져있는 ec2의 public ip를 주면 어떨까?란 생각이 들어서 바꿔봤고..실험해봤다
ㅇㅇ. 이렇게 하니 nginx로 보낸 request가 was로 잘 전달된다.
음 그러면 확실하게 server_name은 프록시 대상과는 아무런 연관이 없다. server_name과 request의 Host가 매칭돼야 하는거라면, nginx가 띄워진 ec2의 public ip를 server_name으로 줬을 때 해당 ip로 보내는 request의 Host와 매칭되는건 당연하다. 그러면 아까 들었던 의문으로 돌아가서.. server_name으로 아무 도메인(네이버 등)이나 막 줘도 request의 Host랑 매칭만 되면 동작하겠다는 생각이 들었다. 그러나 주소창에 naver를 치고 들어가면 당연히 내 nginx가 이를 캐치할 리는 없고..엇? nginx로 보내는 request에 담긴 Host값만 잘 조작하면 프록시 패스가 되겠네?란 생각이 들었다. 당장 실험에 옮기기로 했다
server_name에 www.naver.com 입력하고
nginx로 보내는 request의 Host를 www.naver.com적어서 보내본다.
결과는..!
response가 왔다는거 = nginx에서 was로 request를 던져줬다. 라는 것.. 즉 예측에 성공했다.
아하! server 블록을 여러 개 둔 뒤 블록별로 server_name을 이것저것 주면, 클라이언트에서 request의 Host를 직접 조작해서 보내는 것을 통해 이런저런 조작을 할 수 있구나~! 이렇게 활용하나보다~!
싶었으나! 이내 깨달았다.
"하나의 ip주소에 여러 도메인을 연결한다면"..!
즉..nginx는 물리적으로 하나의 콤퓨타 위에서 돌아가고 있으니, 해당 컴퓨터에 대한 하나의 ip로 요청을 보낼 건데.. 그 ip가 여러 도메인에 연결돼있다면, 우리 킹갓 nginx가 그 도메인들 별로 각기 다른 서비스를 제공해줄 수 있다는 거다. 뭐 클라이언트에서 직접 request의 Host를 직접 조작해서 보내는..그런 이상한 짓(?)은 안 하는거(물론 원한다면 할 순 있겠지만..)
근데 그러면 아까 server블록을 하나만 작성했는데 server_name이 request의 Host와 매칭이 안 됐는데도 동작했던 이유는 뭘까? 그리고 server블록을 여러 개 뒀었는데 순서에 따라 어떨 땐 동작하고 어떨 땐 동작하지 않던 이유는 뭘까?
간단하다. Host와 매칭되는 server블록이 하나도 없으면, 기본으로 설정된 server 블록 또는 제일 처음 작성된 server 블록이 활성화된다고 한다. 그래서 그랬던 거..따라서 server 블록의 server_name은 필요에 따라 굳이 작성할 필요가 없다. (server블록이 하나만 있다거나 등등..)
이런 삽질과 구글링을 통해 배운 걸 정리하면..
nginx설정은 nginx.conf를 편집해서 가능
server블록에 대한 걸 설정하려면 -> nginx.conf에 직접 작성 또는 /etc/nginx/sites-enabled에 심볼릭 링크로 걸어둔 파일을 통해(nginx.conf에서 여깄는 것들을 include로 땡겨오니까)
server_name은 nginx가 띄워진 ip 또는 그 ip에 묶인 도메인들을 작성. ip에 묶인 도메인이 여러 개면 각 도메인별로 다른 페이지 등을 제공 가능
server 블록이 여러 개일때 request의 Host와 server_name이 매칭되는게 하나도 없으면 기본 또는 젤 처음 작성된 server블록을 활성화
로컬에서 spring boot로 작업중인 서버를 private subnet의 ec2에 띄워보고, public subnet에는 nginx를 띄워서 둘을 연결해본다. 즉 nginx로 보내는 요청이 spring boot로 가게끔 설정해본다. (즉 nginx를 프록시로 활용!)
private subnet에 띄운 ec2에 스프링부트 서버 배포
1. ubuntu베이스의 ec2를 생성한다 (amazon linux 베이스여도 됨). 보안그룹 적용시 public subnet에 둘 nginx로부터 오는 트래픽에 대한 인바운드를 열어야 하며, rds나 elastiCache를 사용하는 경우 그 놈들로 가는 트래픽에 대한 아웃바운드를 열어야 한다. (당연히 nginx쪽에서의 아웃바운드와 rds & elastiCache쪽에서의 인바운드도 열어야 함). 또한 bastion host를 통한 ssh접속을 위해 bastion host로부터 오는 22번 포트 인바운드도 열어둬야 한다.
2. ssh등을 활용해 private subnet에 띄운 ec2에 접속한다. ssh로 접속하는 경우 키가 필요하며, scp(secure copy)를 통해 로컬에 있는 키를 public subnet에 띄운 ec2로 보내서 ssh를 두 번 거치는 방법도 있으나 사실 이는 비밀번호가 걸린 현관문 바로 앞에 열쇠를 두는 행위나 마찬가지다. 따라서 나는 ssh jump라는 방식을 통해 ec2에 접속했다.
Host somsatang-webserver-1
HostName 13.124.18.245
User ubuntu
IdentityFile /Users/chosanghyun/Downloads/sst.pem
Host somsatang-was-1
HostName 10.0.1.88
User ubuntu
IdentityFile /Users/chosanghyun/Downloads/sst.pem
ProxyJump somsatang-webserver-1
5. Intellij에서 다음과 같이 우측의 Gradle을 누르고 bootJar을 눌러 jar를 만들어준다
6. /build/libs에 jar파일이 생긴다. /build/libs, 즉 jar가 있는 디렉토리로 가서 Dockerfile을 만들어주고 다음과 같이 작성한다
FROM openjdk:17
ARG JAR_FILE=*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]
openjdk는 프로젝트에서 사용중인 자바 버전에 맞게 11이나 17등을 써주면 된다.
FROM openjdk:17: Docker 이미지의 기본 이미지를 지정. 이 경우에는 OpenJDK 17 이미지를 사용하는 것이며, 이 이미지는 Java 17 환경을 제공한다
ARG JAR_FILE=*.jar: Docker 빌드 시에 사용할 변수를 정의. JAR_FILE이란 변수를 정의한 것이며, 기본값은 현재 디렉토리에 있는 모든 .jar 확장자를 가진 파일 중 하나
COPY ${JAR_FILE} app.jar: COPY 명령을 사용하여 호스트 머신에서 Docker 컨테이너로 JAR 파일을 복사하라고 하는 것. ${JAR_FILE} 변수는 방금 정의한 그 변수가 맞다. 이 파일은 컨테이너 내부에 app.jar로 복사된다.
ENTRYPOINT ["java","-jar","/app.jar"]: 컨테이너가 시작될 때 실행할 명령을 정의하는 것. 이 경우에는 Java를 실행하여 app.jar 파일을 실행한다는 의미다. 즉, Docker 컨테이너가 시작되면 Java 애플리케이션을 실행하고 jar 파일(= app.jar)을 실행한다.
즉 정리하면
"자바 17버전 환경에서 컨테이너를 실행할 건데",
"현재 디렉토리에서 .jar파일이 있으면 걜 JAR_FILE이란 변수에 저장하고",
"app.jar라는 이름으로 복사한 다음",
"컨테이너를 시작할 때 'java -jar'라는 커맨드를 활용해 app.jar를 구동할 거야"
server_name : 이 값으로는 도메인 or 호스트 or IP주소 작성. server 블록을 여러 개 둘 수 있으며, 클라이언트가 보낸 request의 header안에 있는 Host값이 이 server_name값과 일치하는 server 블록이 활성화된다. 만약 Host값과 매칭되는게 없다면 기본적으로 설정된 server블록 또는 첫 번째로 작성된 server 블록이 활성화된다
location / {블라블라..} : /에 해당하는 URL, 즉 모든 요청에 대한 설정을 {}안에 정의한다는 뜻 (만약 /api로 했다면 해당 경로로 오는 요청들에 대한 설정을 정의한다는 뜻이 되겠져)
proxy_pass : /에 해당하는 URL, 즉 모든 요청을 이 URL로 리다이렉트한다
proxy_set_header : 헤더 설정
6. 방금 작성한 설정파일을 nginx가 읽을 수 있도록 설정할 차례. /etc/nginx/sites-enabled로 이동한다.
cd /etc/nginx/sites-enabled
이 디렉토리는 /etc/nginx/sites-available에 있는 설정 파일 중 활성화할 설정 파일을 "링크(심볼릭 링크)"로 관리하는 디렉토리다. ls를 누르면 default가 링크돼있는 걸 확인할 수 있고, 다음 커맨드를 통해 default를 지운다
sudo rm default
7. 우리가 아까 만든 설정파일에 링크를 걸어준다
sudo ln -s /etc/nginx/sites-available/{아까 만든 설정파일명}
심볼릭 링크 : 파일 시스템에서 다른 파일이나 디렉토리를 가리키는 일종의 포인터. 링크된 파일의 내용을 복제하는 개념이 아닌 단순히 참조만 하는, 걍 포인터라고 생각하면 됨
8. nginx를 재시작해 설정 파일을 적용한다
sudo service nginx restart
9. nginx가 띄워진 ec2의 ip주소로 요청을 보내면 private subnet에 띄운 spring boot로 전달되는 걸 볼 수 있다
