프로젝트 배포하기

시작

SSAFY 과정이 끝나고 3개의 프로젝트를 완성할 수 있었다.
각각의 프로젝트를 배포해야겠다는 생각은 있었지만, 첫 코칭 과정이 호락호락하지 않았고, 이것저것 바쁘다보니 미루고만 있었다.
다음 프로젝트를 시작하기 전에 다시 한 번 배포를 진행하면서 도커나 리눅스에 익숙해질 필요가 있겠다고 느꼈다.
다시 설계부터 시작하면서 프로젝트에 맞게 배포해보려 한다.

설계

수정해야 하는 부분

각각의 서비스를 독립적으로 만들었으니, 수정해야 하는 부분도 많다.

1. 배포 방법
2. 도메인 수정
3. 젠킨스파일 수정
4. 도커파일 수정
5. 각 서비스 별 도메인 주소 변경

배포 방법

기존 서비스들은 각각 같은 포트를 사용하면서 배포되었었다.

• Spring
  • 7779
• Django
  • 7780
• nginx
  • 80, 443
• mariaDB
  • 3306

모두 같은 포트를 사용하고 있으니, 해당 서비스를 하나의 패키지로 묶지 않는 한 배포할 수 없다. 심지어 너무나 비효율적이다.
기존 서비스를 최대한 수정하지 않으며 모두 서비스할 수 있도록 서비스별로 포트를 다시 분배해야 한다.

포트

• Root
  • Jenkins
    • port : 50000
    • Docker Image : jenkins/jenkins
  • NGINX
    • port : 80, 443
    • Docker Image : nginx
• Challympic
  • Domain Address : /challympic
  • Client - Vue.js
    • port : 7770
    • Docker Image : nginx
    • Domain Address : /
  • Server - Spring Boot
    • port : 8880
    • Docker Image : openjdk:11
    • Domain Address : /api
  • DB - MariaDB
    • port : 6660
    • Docker Image : mariadb:10.6
    • database : challympic
• IBG
  • Domain Address : /ibg
  • Client - React
    • port : 7771
    • Docker Image : nginx
    • Domain Address : /
  • Server - Spring Boot
    • port : 8881
    • Docker Image : openjdk:11
    • Domain Address : /api
  • Server - Django
    • port : 8891
    • Docker Image : python
    • Domain Address : /data
  • DB - MariaDB
    • port : 6661
    • Docker Image : mariadb:10.6
    • database : ibg
• ILead
  • Client - React + Unity (webGL)
    • port : 7772
    • Docker Image : nginx

Jenkins

각각의 서비스 도메인에 맞게 3개의 프로젝트를 담당하는 젠킨스 하나가 필요하다.
각각 Challympic, IBG, ILead로 젠킨스 프로젝트를 생성하고 관리하도록 한다.

Domain Address

한번에 하나의 서비스만 배포했던 환경에서 각각의 서비스를 한번에 배포하기에, 새로운 Domain Address를 정리할 필요가 있었다.
각각 서비스 이름을 메인 도메인으로 하고, 그에 맞게 NGINX에서 배포해줄 수 있도록 구성하려 한다.
root server의 nginx가 리버스 프록시 역할을 메인으로 하며, 각각의 요청을 알맞는 서비스에 배포해주는 역할을 할 수 있을 것이다.

Client

각각의 서비스를 위한 정적 페이지가 단독적으로 필요하다.
각 서비스의 페이지를 보여주기 위한 웹서버의 역할로 nginx를 사용하며, 서비스에 대한 요청을 클라이언트와 서버로 나누어 리버스 프록시 하는 역할로 사용하게 된다.

Server

각 서비스에 따라 사용하는 서버가 조금씩 다르다. 가령 IBG의 경우는 api를 위한 Spring Boot 외에도 data를 처리하기 위한 Django가 하나 더 들어가게 된다. ILead는 심지어 서버 부분을 따로 저장하지 않는다.
요청은 /api를 기본으로 수신하게 된다.

DB

각 서비스마다 각각의 mariadb를 가지고 있도록 구현한다.
하나의 db로 관리할 수 있지만, 하나의 서비스에서 에러가 발생하여 실행되지 않는 경우 다른 서비스에 영향을 줄 수 있을 것이라 생각했기에, 각각의 데이터베이스를 나눠 사용할 수 있도록 하려 한다.

Architecture

마치며

기존에 배포했던 서비스를 마이그레이션하는 과정이다. 새로운 환경에 맞춰 수정해야 하는 부분이 많아, 배포 과정을 상세히 적어보려 한다.
서로 다른 도메인을 하나의 User Interface에서 제공한다는 점에서 아주 조금은 MSA를 활용한다고 볼 수도 있을 것 같다. 쿠버네티스의 활용이 신입 개발자에게 필요한지, 할 수 있는 부분인지는 잘 모르겠지만, 해당 과정을 통해 도커와 CI/CD 관련한 지식을 한층 쌓을 수 있을 것으로 기대한다.