깃랩 CI/CD 구축 후기

깃랩 CI/CD

주요 목표

미니PC 활용해서 CI/CD 적용 후 미니PC의 도커에서, 배포환경과 개발환경을 분리하되
동일한 배포, 및 운영 환경 자동화 구축

세부 목표

배포, 개발환경은 미니PC를 일컫는 말이며,
로컬 환경은 개발인 진행중인 PC를 일컫는 단어로 정의함.

1. 배포환경 및 개발 환경을 동일하게 구성할 것
   (배포 환경에 따라 소스코드 변경할 필요가 없어야함)
2. 배포, 개발, 로컬환경에서는 SSL 인증서를 이용한 보안쿠키를 사용해야하며,
   (레디스 미적용으로 인한 별도의 쿠키 사용 필요.)
   배포와 개발 환경에서와 동일하게
   로컬환경에서도 개발서버의 nginx의 리버스 프록시로 로컬PC의 IDE에 접속하도록 구성함.
3. 도커 네트워크를 구분하여, 개발환경과 배포환경의 기본 로직 구조를 동일하게 맞출것.
4. 배포, 개발 환경을 배포하되, 포트포워딩은 nginx 컨테이너의 포트포워딩만 이용하여, 프론트, 백엔드, DB 컨테이너의 호스트PC에 대한 포트개방을 하지 않을 것.
5. 배포 환경의 인증서는 클라우드플레어 서비스를 이용하지 않고, let's encrypt로 진행.
6. 모든 환경의 인증서 최초 구성은 자동화로 구성할 것.

성과

1. Nginx가 무엇인지, 어떤 역할을 하는지, 리버스 프록시를 사용하는 방법을 알게됨
2. 개발용 사설 ip 를 위한 ssl 인증서, let's encrypt 인증서 발급 방법의 차이를 알고 다룰수 있음.
   개발용 사설 ip → 인증서를 사용할 서버에 mkcert를 설치 후 인증서 발급 (기한 10년)
   배포용 도메인 → let's encrypt 인증서 초기화 및 발급 방법 2가지 (제미나이 답변)
   1. 80 포트 오픈 → let's encrypt 에서 도메인 주소로 http 접속 → 접속 성공시 인증서 발급 → 발급된 인증서 파일을 이용해 https (443 포트) 가 적용된 nginx 실행 이후 갱신 로직에 따라 주기적으로 갱신
   2. 볼륨할당한 폴더에 파일 이름만 인증서, 키 파일의 이름만 생성후, 갱신하는 형태로 처리하기.
      (1번의 초기화 형태를 사용함)
3. 도커, 도커 데몬, 러너, ci/cd 잡컨테이너, 도커컴포즈, 도커파일 의 상관관계를 파악함
   도커의 호스트PC에서 ci/cd를 통해 잡컨테이너 가 도커 컴포즈를 실행시킬때, 도커 컴포즈의 dockerfile을 실행시킬때, 러너가 갖고있는 프로젝트 파일을 참조해 도커 이미지를 빌드하거나, 컨테이너 실행시 볼륨 마운트 하는 방법을 알게 되었음.
4. 프로젝트의 초기 ci/cd 구성 방법을 알 수 있게 됨

보완점

1. 초기 목표였던 개발 서버 배포시 브랜치별 이름을 서브디렉토리로 접근하는 것을 구현해야함.
   (설정 복잡해짐 A프론트 A백엔드 에서 B프론트가 A백엔드에 붙거나, 로컬 환경의 프론트가 A백엔드 또는 B백엔드, 로컬 백엔드 등 여기저기 붙도록 설정하는것 )
   (다만 현재 개발서버로 사용하는 미니pc의 사양이 n100 이고,
   깃랩, 깃 러너에 더불어 배포, 개발환경을 위한 컨테이너 구성만으로도 다소 벅찬 것 같음.
   상시 구동 및 저소음, 저전력을 염두에 두고 선택한 사양이고, 다수의 인원을 위한 설계가 필요 없고, 가능하더라도 나 혼자 이리저리 테스트 하며 생기게 될 복잡한 컨테이너 구성을 관리 및 제거를 잘 할거라는 보장이 없음.
   소수의 인원에게 맞는 소규모 컨테이너 관리로 가는것이 맞는듯. )
2. 2명 이상의 개발PC가 있더라도,
   개발서버의 nginx를 리버스 프록시를 구성해
   동일한 도메인 주소를 사용하여
   로컬 네트워크 안이라면 각각 자기 자신의 개발pc에 접속 되도록 하기
   (현재는 나 혼자 개발하기 때문에 로컬네트워크에 내 pc 아이피로 이동시키는중)
   (백엔드를 개발 서버에 배포해야만 테스트 가능)