프로젝트를 진행하면서 개발은 오케이..어느정도 해왔다. 그렇지만 내가 이렇게 개발한다한들 실제 사용자들이 내 프로젝트가 있는지 없는지도 모른다면? 말짱 꽝이다..
그렇기때문에 배포는 필수적인것이다 ✨
1. AWS S3
배포를 도와주는 많은 툴들이 있지만 그 중에 보편적으로 사용하는 AWS의 S3를 활용해보자.
먼저 AWS란 현재 가장 보편적으로 사용되는 클라우드 컴퓨팅 서비스로 그 중 S3는 특정 파일을 저장해 인터넷상에서 접근할 수 있도록 해주는 서비스이다.
CRA로 React환경을 구축하고 빌드하면 build파일들이 생성되고 이를 브라우저에서 접근해서 실행하면 CSR의 특징으로 S3서비스를 통해 배포할 수 있다.
2. AWS S3로 배포해보기
2-1. AWS 계정 생성
배포를 하려면 일단 AWS 계정을 먼저 생성한다 !
신용카드 등록 해야해서 유료인가하지만 프로젝트 배포정도는 무료이고 인증용으로 돈을 가져갔다가 다시준다 ㅎ
그 후 콘솔에서 S3에 접속한다.
2-2. 버킷 생성
버킷 이름을 설정하고 버킷을 저장할 AWS리전을 선택한다.
보통의 토이 프로젝트 같은 소규모 같은 부분은 우리나라 한정에서만 접근하면 되니까 전세계에 있는 AWS 서버 중 서울에 있는 곳으로 지정해준다.
그 뒤로 우리는 해당 배포 URL을 알고있는 누구나 접근을 허용해야하므로 기본적으로 설정되어있는 엑세스차단 체크를 풀어준다. 퍼블릭 상태가 될 수 있음을 알고 있습니다에는 체크표시 !
2-3. 배포할 파일들을 업로드
만들어진 객체에 배포할 파일들을 업로드해준다. 업로드 버튼을 눌러서해도 되고 drag & drop으로 해도된다. 여기에 업로드 할 파일들은 이전에 말했듯이 빌드하여 생성된 파일들을 업로드 해준다.
업로드 할 파일 객체들에 index.html이 보여야한다 ! (그 위 상위폴더들 xxx)
2-4. 웹 사이트 호스팅 활성화
그 후 속성 탭에 가서 정적 웹 사이트 호스팅을 설정해준다.
활성화 한 후 기본 페이지, 즉 /경로로 들어왔을 경우 보이는 기본페이지다. CSR 기반의 React프로젝트이니까 index.html로 지정해준다. 오류가 발생했을 때 예외페이지도 설정해줄 수 있다.
따단! 활성화를 시키면 배포된 URL을 보내준다!!
이제 한번 웹사이트를 접근해보자!!
🥲...끝날때까지 끝난게 아니었다...왜 안보이니....
403 error는 권한없음 에러! 나 너 누군지는 알겠어(인증 ok) 그치만 너는 여기에 접근할 권한이 없단다(인가 fail) 요런 말이다.
그렇다면 허락을 해주면 되겠지?
2-5. 버켓 정책 설정
해당하는 Resource, 즉 해당 버킷 ARN에 대해 GetObject(객체를 가져오는 행동)을 허락하겠다.라는 의미의 정책을 설정해주었다.
(Sid는 해당 정책에 대한 unique한 id로 무슨 역할을 하는 정책인지에 대한 것들이 드러나게끔 설정해준다.)
이렇게하면 드디어 웹사이트에 페이지가 등장!!!!
이제 아까 받은 URL로 우리나라 어디에서 접근하든 빠르게 내 프로젝트를 확인할 수 있다 😎
실무에서도 이렇게 하는지는 잘 모르겠다.(엑세스 차단을 해제해도 문제가 없을까..?)
일단 이렇게하면 AWS S3에 배포는 성공적으로 끝마쳤다.
그렇다면 해당 프로젝트가 수정될때마다 AWS 사이트에 들어가서 버킷에 들어가서 다시 파일들을 업로드하는 이런 귀찮은 짓을 해야할까?ㅠㅠㅠ
역시 개발자는 자동화...배포를 자동화하여 지속적인 배포(CD)를 구축해보자!
3. Github Action을 이용한 지속적인 배포
출처: GitHub Actions 공식문서(https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions)
github action은 이러한 과정을 거치는데 이 과정을 workflow라고 한다.
push, pull request open, issue open등의 특정한 활동을 Event라고 부르며 Event가 발생했을 때 Runner가 동작한다. Runner는 workflow를 실행할 서버를 의미하며 직접 컴퓨터를 관리할 필요없이 가상의 Runner에서 workflow를 실행시킬 수 있다.
하나의 Runner에는 여러개의 Job이 존재한다. Job에는 자주 사용되는 기능들을 모아둔 Action을 등록할 수 있다. 설정파일에서 use 키워드와 함께 사용할 수 있으며 브랜치로 체크아웃하고, 환경을 설정하는 등 복잡하지만 자주 사용되는 과정들을 미리 정의해두고 편리하게 활용할 수 있으며 GitHub Marketplace에서 Action들을 검색하고 활용할 수 있다.
repository를 생성하면 이렇게 Action탭에 workflow를 만들게끔 되어있다.
내 스스로 세팅할 수도 있고 이미 많은 템플릿들도 있어서 선택해서 만들어주면 된다.ㅎㅎ
나는 직접 만들어서 세팅을 해보도록 하겠다.
S3 sync를 맞춰주는 action을 marketplace의 가장 많이 설치된 버전으로 가져와서 등록해보았다.(역시 자동화 좋아하는 개발자들..ㅎ)
해당 workflow는 main브랜치에 push가될 때 npm run build를 실행하고 기존에 버킷에 있던 파일들은 delete한 후 build파일에 있는 파일들을 해당 리전에 있는 해당 버킷에 업로드하겠다라는 의미이다.
(workflow만드는건 공식문서에 잘 나와있으니 이것도 참고하기!)
workflow파일은 YMAL형태의 .yml파일로 저장되어야하며 프로젝트파일/.github/workflows/경로안에 위치해있어야한다. env에 보이는 환경파일들은 노출이되면 안되기 때문에 github action에 등록한 후 환경변수를 불러오는 형식으로 불러와준다.
⚠️ 환경변수를 설정하면 다시 들어가도 보여주지 않기 때문에 잘 기억을 해둔다!
(accesskey도 마찬가지로 secret accesskey는 다시 알려주지 않는다)
AWS 환경변수 설정하는 곳 ↓
AWS access key 발급하는 곳 ↓
자 이제 해당 repository main 브랜치에 push를 해서 돌려보자!
번외. 에러 핸들링
역시나 마주한 에러들.... 에러 핸들링은 따로 정리해두겠습니다!!
마침내 성공!! 😂
드디어.....드디어..초록빛...!!!
성공적으로 배포를 마쳤습니다!🙏
프론트엔드가 배포까지 알아야하냐구요?
네. 그렇습니다.
프론트엔드도 우리가 만드는 서비스에 책임을 가지고 있어야 합니다.
개발 프로세스를 알고 문제가 생겼을 때 트러블슈팅을 하기 위해 배포를 알아야합니다.💪🏻
