우리 팀은 한조각님의 강의를 듣고 각자 맡은 부분을 좀 더 집중적으로 공부해오는 시간을 가졌다!
강의는 아래 참고 ,,
Spring Boot, AWS로 백엔드 서비스 한 사이클 완성하기
드디어 마지막 파트!! [지속적 코드 관리와 배포, CI/CD]
내가 담당한 파트는 보안 파트였다.
우선 강의를 보면서 실습하기 바빠 내용은 나중에 이해하게 되는 ,,
정리해볼게요 레츠고
보안 강화하기
AWS SSM : 우리가 이걸 왜 하냐면요
우선, AWS SSM은 GitHub Actions가 EC2 서버에 직접 SSH로 들어가지 않고, AWS를 통해 더 안전하게 명령을 대신 실행시키는 방식
결론적으로는 개발자가 코드를 main에 push하면, 사람이 EC2에 접속해서 일일이 docker pull, docker run 같은 걸 치지 않아도 자동으로 새 버전이 배포되게 하는 과정!
그래서 우리는 서버에 실제로 반영되게 만들어봐요.
- 간단한 흐름 1단계: 개발자가 코드를 GitHub에 올림 2단계: GitHub Actions가 자동으로 빌드함 3단계: Docker 이미지로 만듦 4단계: 그 이미지를 Docker Hub에 올림 5단계: AWS 쪽에 “이 최신 이미지 받아서 서버 다시 실행해”라고 시킴 6단계: EC2 서버에서 새 컨테이너가 뜸 = 배포 완료
SSH와 SSM
- SSH = 어떻게 원격 접속할까?에 대한 일반 기술/프로토콜
- SSM = AWS가 제공하는 서버 관리 서비스 = SSH 없이도 명령 실행, 접속, 세션 관리 등을 하게 해주는 AWS 도구
쉽게 비유하면,
- SSH는 “문 여는 방식”
- SSM은 AWS가 만든 “관리 시스템”
SSH 말고 왜 SSM을 써요?
우선, 우리는 SSH 방식을 쓰는 실습도 해보았어요. (EC2를 0.0.0.0.으로 설정해봤어요.)
GitHub Actions가 EC2에 직접 SSH 접속해서:
- 기존 컨테이너 stop/rm
- 최신 Docker 이미지 pull
- docker run
히지만, 이 방식은
- GitHub Actions가 EC2에 직접 들어가야 하고
- 보안그룹에서 22번 포트를 열어야 하고
- 모든 IP에 대해 22번 포트를 허용
⇒ 위험해서 운영 서버에 권장하지 않는다!
비유를 해보자면,
- SSH 방식: 배달원이 우리 집 비밀번호를 가지고 직접 집 안에 들어가서 물건 놓고 감
- SSM 방식: 배달원이 관리사무소(AWS)에 맡기면, 관리사무소가 내부 직원(SSM Agent) 통해 집 안에 전달
AWS SSM?
AWS가 서버를 원격 관리하게 해주는 서비스
:
aws ssm send-command가 SSM 에이전트를 통해 EC2 인스턴스에서 명령을 실행
= ⭐ EC2 안에 SSM Agent가 있어야 함⭐
흐름도: GitHub Actions → AWS 인증 → AWS SSM → EC2 명령 실행
갑자기 등장하는 OIDC
예전 방식은 GitHub Secrets에 AWS Access Key / Secret Key를 오래 저장해두고 인증하는 경우가 많았다.
대신, OIDC를 써서 GitHub Actions가 AWS에 “나 진짜 이 저장소 워크플로우 맞아”라고 증명하고, AWS가 잠깐 쓸 수 있는 임시 자격증명(STS)을 발급해주는 구조!
비유해보자면
- GitHub Actions: “나 이 저장소에서 돌아가는 공식 워크플로우야”
- AWS: “오케이, 그럼 잠깐 쓸 수 있는 출입증 줄게”
- 그 출입증으로 SSM 명령 실행
우리가 작성한 코드 최상단 permissions: id-token: write가 OIDC를 통해 AWS 인증을 받기 위해 필요한 부분
스프링 프로파일
환경마다 다른 설정을 나눠서 쓰기 위한 기능
ex. 아래의 3가지 환경이 있다고 하자!
- 개발 환경(dev)
- 테스트 환경(test)
- 운영 환경(prod)
각 환경에서 DB 주소, 로그 레벨, 시크릿 값, 외부 API 주소같은 것이 다를 수 있다.
그런데?! 한 파일에 왕창 넣어버리면 위 험 해
그래서?! 어느 환경에서 도는지에 따라 설정을 다르게 적용해보자!
왜 써요!를 정리해보자면
- 개발/운영 설정 분리
: 개발할 때는 로컬 DB 쓰고, 운영할 때는 AWS RDS 사용
그러면 이렇게 두 개로 나눠야 한다!
- dev: localhost DB
- prod: RDS DB
- 보안 문제
: 운영용 비밀번호, 운영 DB 주소를 개발 설정이랑 섞어두면 위험하다. 특히 GitHub에 잘못 올리면 큰일!!!!!!
- 배포 자동화에 유리
: Docker나 EC2에서 실행할 때 prod 프로파일로 띄우면 운영용 설정이 자동으로 적용
즉, 같은 코드인데 실행 환경에 따라 다르게 동작하게 만들 수 있다!
마무리
4주만에 완강을 했다 😎
역시 스터디같은 강제성이 없으면 힘든 것 같다 ,, 그래도 이렇게 긴 강의를 끝낼 수 있어서 뿌듯하다 !
중간고사 끝나면 전체적으로 한 번 훑는 시간을 가져야겠다. 시간에 쫓겨 공부한 부분이 있어 살짝 아쉽 !
직접 해보면서 배우는 게 베스트라지만 프로젝트 시작할 생각에 걱정이 저어어어엉말 많다 ,,
우선 다음주에 있을 미니프로젝트부터 힘내보자 껄껄
