[최민수] sprint11

[chamysj]

mission11

미션 목표

• Github Actions로 테스트, 배포 자동화
• Docker 이미지 만들기

요구사항

• Github Actions 활용
• 브랜치에 pull request가 발생하면 테스트를 실행하는 액션을 구현해 주세요.
• main 브랜치에 push가 발생하면 AWS 배포를 진행하는 액션을 구현해 주세요.
• 개인 Github 리포지터리에서 Actions 동작을 확인해 보세요.
• Docker 이미지 만들기
• 다음을 만족하는 Dockerfile과 docker-compose.yaml을 작성해 주세요.
• Express 서버를 실행하는 Dockerfile을 작성해 주세요.
• Express 서버가 파일 업로드를 처리하는 폴더는 Docker의 Volume을 활용하도록 구현해 주세요.
• 데이터베이스는 Postgres 이미지를 사용해 연결하도록 구현해 주세요.
• 실행된 Express 서버 컨테이너는 호스트 머신에서 3000번 포트로 접근 가능하도록 구현해 주세요.

제출파일

• Github actions는 .github/workflows/ 폴더에 저장해서 제출합니다.
• Docker 관련 파일들은 프로젝트 폴더 최상위에 저장합니다.

주요 변경사항

• 배포 과정에서 ssh를 0.0.0.0/0으로 열어서 일시적으로 허용하는 것이 임시방편인 느낌이 들어서 다른 방법을 찾아보다가 github runner를 알게됐고, Ec2에 runner 설치하여 운영, 보안 및 안정성을 강화하고자 했습니다.
• 배포 중 npm ci 과정이 길어지면서 runner가 지속적으로 오프라인으로 떨어지는 현상이 발생하여 원인을 찾다가 ec2의 낮은 사양을 원인으로 의심하여, swapfile 형태로 2gb swap을 생성하고 활성화하여 메모리 압박 상황을 완하했습니다. 이후 러너가 오프라인으로 떨어지는 빈도가 줄었고 배포의 안정성도 개선됨을 체감했습니다.

스크린샷

[kes2020]

ec2 에 self-hosted RUNNER를 사용하셨다는거군요~! 그렇게되면 22번 포트를 열지않아도 되어서 보안적으로 훨씬 나은 선택이십니다.
민수님의 ec2 사양이 프리티어에서 제공하는 t3.micro 였을텐데 이경우 npm ci 과정에서 러너의 프로세스들 + os 기본사용 +npm ci 시 사용되는 자원들이 t3.micro에서 제공하는 램을 초과해서 프로세스가 강제종료되어서 runner 가 죽었을 겁니다.
따라서 부족한 사양에 대한 대안으로 swap으로 문제해결을 하실 생각을 한점도 대단하신것같아요~! 하지만, Swap으로 해결하는것은 임시방편이라, 보통 ec2의 사양을 올려서 안정적으로 서비스를 운영 할 수 있다는 것도 알아 두시면 좋을 것 같습니다!