GitHub Actions
- GitHub 안에서 돌아가는 자동화 도구
- GitHub에서 제공하는 CI/CD 도구로, 코드 변경 사항을 자동으로 테스트하고 배포할 수 있게 해준다
원래 수동이면:
- 코드 push
- 내가 직접 빌드
- 내가 직접 테스트
- 내가 직접 docker build
- 내가 직접 서버 접속
- 내가 직접 배포
GitHub Actions 쓰면:
- 코드 push
- GitHub가 알아서 빌드/테스트/배포
OIDC ( Open ID Connect )
비밀번호나 AWS 키를 GitHub에 저장해두지 않고도, GitHub Actions가 자기 신원을 AWS에 증명해서 잠깐만 쓸 수 있는 임시 권한을 받게 해주는 방식
- OAuth 2.0은 원래 권한 위임에 더 가깝고 ( 비밀번호를 직접 주지 않고, 다른 앱에게 제한된 권한만 맡기는 방식 )
- OIDC는 그 위에 인증 기능을 얹은 것
- OIDC = OAuth 2.0 + 인증 기능
즉,
- OAuth 2.0: “이 앱이 이 자원에 접근해도 되나?”
- OIDC: “지금 요청한 주체가 진짜 누구인가?” - Identity를 확인하는 데 초점을 맞춘다
그럼 왜 굳이 필요할까?
지금까지 한 방식은 GitHub Actions에서 EC2로 직접 SSH 들어가서 배포하는 방식
- EC2 private key를 GitHub secret에 넣어야 하고
- 보안그룹에서 22번 포트를 열어야 하고
- 0.0.0.0/0까지 열게 돼서 위험해질 수 있다
OIDC를 쓰면
GitHub Actions가 AWS에 “나 GitHub Actions 맞아”라고 증명하고, AWS가 그걸 믿고 짧은 시간짜리 임시 권한을 줘서, 그 권한으로 SSM을 통해 EC2에 명령을 내리게 할 수 있음
AWS SSM
: AWS Systems Manager
AWS가 EC2에 원격으로 명령을 내리게 해주는 관리 도구
- EC2에 SSH로 직접 접속해서
- docker pull
- docker run
이런 걸 직접 쳤는데 SSM을 쓰면:
- GitHub Actions가 AWS에 요청하고
- AWS Systems Manager가
- EC2에 대신 명령을 내려서 실행해줘
즉 “SSH로 직접 들어가는 대신, AWS를 통해 EC2를 원격 제어하는 방식”
GitHub Actions가 배포를 시작하고
→ OIDC로 GitHub Actions가 AWS 인증을 받고
→ AWS가 임시 권한을 발급함
→ GitHub Actions가 그 권한으로 SSM에 명령을 보냄
→ SSM이 EC2에서 명령을 실행함 EC2에서 기존 컨테이너를 중지/삭제하고, 최신 이미지를 pull한 뒤, docker run으로 다시 실행
IAM 역할 두가지
1) GitHubOIDCRole
GitHub Actions 쪽 역할
- GitHub Actions가 OIDC로 AWS에 인증한 뒤
- 이 역할을 맡아서
- ssm:SendCommand, GetCommandInvocation 같은 걸 할 수 있게 해줌
즉 AWS 입장에서는
“오케이, 너는 GitHub Actions 맞네.
그럼 이 역할까지만 맡아서 SSM 명령 보내는 건 허용해줄게.”
그래서 이 역할이 없으면
- GitHub Actions가 AWS에 로그인 비슷하게 들어왔다 해도
- 무슨 행동을 할 권한이 없어서
- SSM 명령을 못 보냄
인증 =/ 권한
2) EC2SSMInstanceRole
EC2 쪽 역할
- EC2 인스턴스가 SSM 관리 대상이 되게 하고
- SSM agent가 AWS와 통신하고
- 전달받은 명령을 실행할 수 있게 해줌
이 역할이 없으면,
GitHub Actions가 AWS에 요청을 잘 보내도
EC2가 SSM을 통해 명령을 받을 준비가 안 된 상태
- GitHubOIDCRole = “명령 보내는 쪽 권한”
- EC2SSMInstanceRole = “명령 받는 쪽 권한”
왜 application.yml을 dev와 prod 프로파일로 분리했을까?
개발 환경과 운영 환경의 역할이 다르다
- dev 환경
- 로컬에서 빠르게 실행하고 테스트하는 것이 목적
- DB 연결, SQL 확인, 수정 후 재실행이 편해야 함
- prod 환경
- 실제 서비스가 안정적으로 동작하는 것이 목적
- 보안, 성능, 안정성이 더 중요함
프로젝트 기준
- dev
- 로컬 MySQL 사용
- SQL 로그 출력
- 자동 스키마 반영
- prod
- AWS RDS 사용
- 환경변수로 DB 정보 주입
- SQL 로그 최소화
- 스키마 자동 변경 방지
개발 환경은 빠른 개발과 테스트, 운영 환경은 안정성과 보안
이 목표가 서로 다르기 때문에, 같은 설정을 그대로 쓰지 않고 profile로 분리해서 관리하는 것