「마이크로서비스 & 파이어베이스 CI·CD」(5) github Action & 파이어베이스 호스팅 연결

 

이번 포스팅에서 github Action에 이어 파이어베이스 호스팅까지 연결해보자.

 

 

 

 

---

1] 파이어베이스 호스팅 설정

marketing폴더의 코드를 빌드하는 파이어베이스 호스팅 사이트를 추가한다.

 

01

파이어베이스 호스팅: 사이트 추가

 

파이어베이스 호스팅에서 새로운 사이트를 추가한 뒤, 사이트 이름을 복사한다.(firebase.json에서 사용될 예정)

 

그리고 marketing폴더에서 firebase init hosting을 실행한다. 만일 firebase명령어가 실행되지 않는다면 'firebase-tools' npm모듈을 설치하고 로그인 한다. (아래 사진의 container폴더(x) → marketing(o))

 

01

marketing/  firebase-tools설치 및 login

 

marketing> firebase 초기화

 

 

호스팅 설정에서 기본 폴더는 'dist(웹팩 빌드)'로 설정한다.

 

firebase hosting 초기설정

 

 

 

 

 

 

---

2] firebase.json

호스팅 초기설정 결과 생성된 firebase.json에서 'marketing'전용으로 추가한 파이어베이스 호스팅 이름을 넣어준다.

 

marketing/firebase.json

 

 

 

 

 

---

3] .babelrc

웹팩으로 생성될 dist파일에서 JSX문법을 js로 변경하는 babel설정을 한다.

 

marketing/.babelrc

 

 

 

 

 

---

4] webpack.prod.js 수정 (marketing & container)

 4-1]  marketing/webpack.prod.js

웹팩은 marketing에서 dist폴더로 모든 파일을 빌드한다. 그리고 파이어베이스는 dist폴더에 있는 파일을 'https://marketing-xxx.web.app'(파이어베이스 호스팅에서 생성한 추가 사이트)의 루트 폴더(/)에 업로드 한다.    

marketing/config/webpack.prod.js

 

모든 파일을 빌드했을 상황을 가정한다면, container(https://xxx.web.app)는 런타임으로 마케팅 파일을 GET방식으로 가져온다. 이때 container가 요청하는 파일의 경로는 'https://marketing-[사용자 지정 사이트명].web.app/remoteEntry.js'와 같다. 그러므로 웹팩은 밀드과정에서 marketing폴더에 있는 파일의 경로를 로컬로 지정해서는 안 된다. 위와 같이 firebase 호스팅에서 설정한 marketing 호스팅 주소를 'publicPath'값③으로 지정해야 한다.

 

 

 

 4-2]  container/webpack.prod.js

container는 marketing의 빌드파일(remoteEntry.js)을 "https://marketing-[사용자 주소].web.app"에서 가져온다. 그러므로 remotes 경로를 로컬이 아닌 파이어베이스 호스팅(마케팅 사이트)으로 재지정 해야 한다.

 

container/config/webpack.prod.js

 

 

 

 

 

 

 

---

 5]  marketing.yml 생성

github Action의 실행파일, marketing.yml을 다음과 같이 생성한다.

 

.github/workflow/marketing.yml

 

 

만일, github Action없이 파이어베이스 호스팅 만으로 Micro FrontEnd를 구현하려면 아래와 같은 간단한 방식을 추천한다. 웹팩과 github Action을 섞는 부분이 부담스럽다면, CTO가 없는 스타트업과 같은 곳에서 굳이 초기설정에 애쓸 필요가 없기 때문이다.

 

 

https://fireship.io/lessons/deploy-multiple-sites-to-firebase-hosting/

Deploy Multiple Sites to Firebase Hosting

 

특히, 모놀리틱 방식으로 서비스를 런칭한다면, 파이어베이스 호스팅 사이트를 추가할 필요가 없다. dist1, dist2, dist3, ... 이와 같은 방식으로 여러 폴더를 생성한 뒤에 firebase.json에서 각 폴더를 지정하면 된다. 

 

https://firebase.google.com/docs/hosting/multisites?hl=ko 

여러 사이트에서 프로젝트 리소스 공유  |  Firebase 호스팅

 

하지만 mircoFront 환경에서 배포를 결정했다면, 포스팅의 내용과 같이 파이어베이스 호스팅 사이트를 각 개발팀마다 확보해야 한다.

 

 

 

 

 

 

 

** 기타: 앵귤러 관련

혹시 React가 아닌 Angular를 이용해서 micro FrontEnd제작한다면, 아래 사이트가 도움된다.

 

https://dev.to/bitovi/how-to-build-a-micro-frontend-with-webpacks-module-federation-plugin-n41

How to Build a Micro Frontend with Webpack's Module Federation Plugin

 

 

 

 

 

** 기타: firebase.json:: rewrites 관련

포스팅을 진행하며 firebase.json의 rewrites항목이 micro FrontEnd를 설정하기에 적합할 것이라 착각했다. 하지만 rewrites는 특정 경로에 접속하는 링크를 특정 파일과 결합하는 역할, 말 그대로 재작성 하는 기능이 전부였다. 

 

ex) https://stackoverflow.com/questions/30147602/how-do-i-make-a-custom-subdomain-on-firebase

How do I make a custom subdomain on Firebase?

 

rewrites기능 덕분에 micro FrontEnd구축에 x삽질 펐다. 혹시 필자와 비슷한 시도를 하려는 분들은 그냥 파이어베이스 호스팅 사이트를 추가하는 방법을 사용하시길 추천한다. rewrites로 특정 파일을 지정하더라도 1개의 호스팅 내에서는 한계가 있음(런타임 파일이 늘어날수록 고착화가 심해짐)

 

 

 

 

 

** 기타: 웹팩 Federation

웹팩 관련 자료를 찾다보면 심하게 틀린 내용이 구글에 난잡하게 퍼져있다. 웹팩 4와 5의 차이점 때문에 택도 없는 내용이 버젓이 해결책으로 둔갑해 있다. 웹팩 관련 부분은 웹팩 공식사이트의 내용에 따르는 편이 백번 옳다. 가령, 파일명 설정에서 [module]과 같은 설정은 웹팩5에서 사용되지 않는다. 웹팩은 한번 잘못되면 손댈 수 없을 정도로 코드가 심하게 꼬이므로 반드시 버전에 맞춰 사용할 것을 적극 권장한다. 

 

https://webpack.kr/concepts/module-federation/

Module Federation | 웹팩