[Spring Boot] 2. 서버 개발 환경 분리 (Spring Cloud Config 적용) 및 배포 자동화

[배경]

• 기존의 장고 프로젝트를 배포서버와 개발서버로 나누어서 운영했음.
• ( 테스트 환경 설정파일 / 개발 서버 환경 설정파일 / 배포서버 환경 설정 파일 ) 모두 달랐다. 외부에 노출되면 안되는 정보들이 있어서 github 에 무턱대고 업로드 할 수가 없었다. => 로컬에서 직접 관리했다.
• 하나의 리눅스 서버 안에서, 유저를 나누어서 환경을 분리했다.. 
• 프로젝트 하위에 rsync 로 직접 설정파일을 넣어주고 있었다.
• 빠르게 환경 설정 파일을 변경해야할 일들이 생겨서, 직접 리눅스 서버 파일을 수정했다가 나중에 내 로컬 원본을 수정했다 하면서, 설정파일 관리가 힘들어짐.
• 동아리 예산 문제, 학교 네트워크 문제 등으로 서버를 옮기거나 재시작해야하는 등 프로젝트를 새로운 환경에서 재빌딩하는일이 종종 있었는데, 그때마다 매번 설정파일이 힘들게했음..

설정파일 좀... 그만 신경쓰고 싶어! 살려줘..!!

 

---

생각했던 방법..!

1. gitignore + 환경별 설정파일 유지..? => 팀원간 공유가 까다롭다..

사실 이 방식은 기존에 사용했던 방식인데, 결론부터 말하자면 여전히 번거로운 작업이다.

 

기존의 설정파일은 4가지로 이루어져 있었다.

1. settings/local.py 로컬 개발용 설정파일 (업로드 o)
2. settings/dev.py 개발 서버용 설정파일 (업로드 x)
3. settings/production.py 배포 서버용 설정 파일 (업로드 x)
4. settings/test.py 테스트 코드 설정 파일 (업로드 o)

장고가 html 렌더링까지 하던 상황에서 팀원들간에 협업을 하려면,

각자 로컬 db 를 이용해 프로젝트를 띄워 작업해야했다.

 

노출되면 안되는 취약한 정보들이 있기 때문에 github 에 올려서는 안되었고, (gitignore)

 

설령 취약한 정보를 따로 분리해서 올린다고 하더라고,

팀원들이 자신의 local db 환경에 맞게 추가적으로 설정해주어야 하는 일이 있었다.

(package 폴더에 추가 파일을 생성해서 임포트 하는 방식으로 해결했었다...)

 

2. CI/CD 툴을 이용해서 빌드할 때마다 꽂아줘야하나?

github action 이나 jenkins 등을 이용해서 빌드-런 할때마다 꽂아주는 방식도 생각해봤다.

 

기존의 1번 방식보다는 훨씬 깔끔한 방식이 될 수 있을거 같다.

 

업로드하면 안되는 개발서버와 운영서버 설정은 젠킨스가 따로 관리하면,

 

여기저기 분산되는 일이 덜 할것 같았다.

 

하지만

  1) 결국 원본 설정파일을 변경하기 위해서는 직접 젠킨스 서버에 접속해서 변경해야 한다는 점,

  2) 비용의 문제로 서버를 여러대 운영할 수 없다 => 개발서버에서 설정파일을 같이 관리해야 한다는 점,

  3) 학업을 병행하고 있는 팀원들이 추가적인 학습이 필요하게 된다는 점. (CI/CD 를 위한 사용이 아니라 환경설정을 위한 신규 작업이므로,,, 기존에는 ci/cd 를 적용하지 않고 있었다.) 

 

위의 단점이 존재했다. 얻는 것에 비해 단점이 꽤 크다고 생각했다.

 

3. spring cloud config

  검색을 좀 해보니 스프링 클라우드 컨피규레이션이라는 것이 있었다.

 

MSA 환경에서 설정파일을 중앙집중화하여 관리하기 위한 패키지이다.

 

이 때 당시에는 MSA 를 위한 것인지는 몰랐다.... ㅎㅎ

 

로컬 저장소, 깃헙 저장소 등에 설정파일을 저장해두었다가

spring cloud config 에게 필요할 때 요청하면 해당 설정파일을 받을 수 있다.

 

이 개념이 좀 낮설기는 했는데,

 

"와 이런게 있다고? 진짜 딱인데?" 라는 생각이 파박 들었다.

 

서버에서는 spring cloud config 만 띄워놓으면,

개발 서버를 reload 할 때마다 알아서 설정파일을 요청하고 받아오는 것! 

설정파일 관리도 깃헙 레파지토리로 할 수 있고, 암복호화까지 가능하다!

설정파일 수정, 관리도 쉽고, 적용도 너무 쉬웠다.

 

로컬(windows)에서 wsl2 로 테스트 해보면서

설정파일이 적용 규칙, 캐시 설정 등을 확인한 후에,

서버에 최종 적용했다.

 

기존의 spring 환경에서 해결할 수 있다는 점이 가장 큰 메리트였다.

 

---

[배포 자동화]

 

장고 프로젝트를 할 때에는 매번 서버에 접속해서 빌드 & 런하는 스크립트를 실행시켜주었다.

 

그런데 cicd 툴 찾아보면서 github action 으로 배포 자동화를 하면 간단하게 해결할 수 있을 것 같았다.

 

dev 브런치 또는 production 브런치에 pr 이 머지되면

    => github action 으로 ssh 접속 후 프로젝트 빌드

    => 기존에 돌아가던 서버 어플리케이션 종료

    => 새로 빌드된 프로젝트 실행 (이 때 설정파일이 자동 적용된다.) -Dprofile=dev 이런식으로 환경을 분리한다.

위와 같은 순서로 자동 배포되도록 설정했다.

또 설정이 완료되면 slack 으로 알림이 오도록 설정했는데,

 

처음에는 잘 되다가 나중에 안되기 시작해서, 일단 슬랙 알림은 적용을 중단해 놓은 상태이다. ㅠㅠ

 

지금은 jvm 을 환경별로 하나만 띄우면 되서 간단하지만

 

나중에 멀티 모듈이나 MSA 등의 아키텍처로 확장되는 경우에는 젠킨스를 도입하는 것을 고려해봐야겠다.

 

 

---

[결론]

1. 환경설정 파일을 쉽게 관리하고 적용할 수 있는 방안 => spring cloud config
2. pr 머지 시에 배포를 자동으로 할 수 있는 방안 => github action

이 두가지를 적용했더니 개발하는 일이 많이 편해졌다.

 

더 편하게 개발할 수 있도록 짱구를 많이 굴려봐야겠다.