Local RDS와 Remote RDS의 분기
Opened this issue · 2 comments
과제 4에서 얼추 배포 작업이 끝나가는 상황에서 질문이 생겨 여쭤보고자 합니다.
과제에서는 deploy branch를 통해 작업이 진행되는데요, 아마 seminar4 추가 영상에서 세미나장님도 master 또는 특정 브랜치에서 계속 작업을 했을 거라 생각됩니다.
16분부터 살펴보시면 미리 aws에서 서버가 작동하게끔 ini 파일을 재시작한 후 http://3.34.178.249/api/v1/user/ (현재는 DRF static file을 적용시켜서 localhost:8000과 똑같은 화면입니다.) 와 기존에 익숙한 local에서 python manage.py runserver를 실행시켜 작동하는 localhost:8000/api/v1/user/를 비교하는 장면이 나옵니다.
EC2 settings.py에서의 DATABASES['HOST']는 AWS RDS의 'waffle-backend.cf1b7zf4o8nc.ap-northeast-2.rds.amazonaws.com'와 같은 원격 주소로, local settings.py에서의 DATABASES['HOST']는 '127.0.0.1'로 설정되어있을 거라고 생각합니다.
여기서 질문인데, 코드를 수정하고 새롭게 merge된 version을 배포하려면 EC2 서버에서 git pull을 받아야하는데, 만약 제대로 구별을 해주지 않는다면 AWS RDS 주소와 local RDS 주소끼리 충돌이 일어나지 않을까 예상됩니다. 따라서 이를 해결하기 위해 환경변수 설정 등을 통해 일반적인 개발 시에는 localhost RDS로 연결을 하되, EC2를 이용할 때는 자동으로 AWS RDS로 연결하게끔 추가로 작업을 해야하는지 궁금합니다.
일단 저는 세미나 4 추가 영상 당시에 EC2 instance 내에서 딱히 새로운 branch로 checkout하지 않고, pull 받아온 master branch에서 그대로 작업했던 것 같습니다. git add를 통해 staging도 하지 않고 그냥 file만 딱 naive하게 수정한 상황이었지요. 여러분께는 과제 4를 위해 deploy branch를 비슷한 방식으로 활용하라고 과제 내용애서 언급드렸습니다. 별 게 아니라, instance 내에서 해당 branch를 기준으로 pull 받고 file 수정도 거기서 하라는 것이었지요. 물론 해당 경우에는 EC2 instance 내에서 deploy branch에서 commit도 하고, push도 해서 변경 사항이 remote repository에 반영되도록 하여 세미나 진행자들이 확인할 수도 있게 해달라고 말씀드렸지요. 별 차이는 아닙니다.
다만 제가 세미나 4 추가 영상에서 만약 배포 환경을 위해 수정한 요소들, 예를 들면 repository 내에 uwsgi 관련 파일들을 추가 작성하거나 settings.py의 ALLOWED_HOSTS, DEBUG, DATABASES, CACHES 설정 등을 변경한 것을 그냥 file 수정만 딱 해두면 나중에 해당 instance를 terminate시키거나 했을 때 변경 사항이 모두 날아갈테니, 지금의 naive한 git pull 배포 방식에서는 과제 4에서처럼 아무래도 특정 branch(master가 아닌)에 commit, push해두는 것이 좋을 것입니다.(애초에 git pull 배포 방식이 아니면 이런 고민이 필요 없을 수도 있을 것입니다. 실제 큰 서비스에서는 이러한 원시적인 배포 방식을 거의 사용하지 않을 것입니다.) 그리고 서버 변경 사항을 새롭게 EC2 instance 내에서 새롭게 배포할 때에는, 해당 변경 사항이 master에 반영되어있을테니, EC2 instance 내부에서 선택하고 있는 branch에다가 git merge origin/master 등의 명령어로 remote repository의 master를 가져와 merge시키면(물론 혹시 master의 변경사항이 setting에 관한 것을 포함하여 conflict가 있을 수도 있겠죠) 되겠지요. 이렇게 하면 master의 변경 사항을 지속적으로 반영하면서, instance 내에서만 배포 환경을 위해 수정한 파일 내역도 git으로 관리할 수 있을 것입니다.
그리고 이런 관점 외에도, 더 효율적이고 실질적으로는 local에서 서버를 실행할 때와 배포 환경에서 서버를 실행할 때, 아무래도 settings.py 등에서의 서버 설정을 다르게 해주어야 할 수 있을 것입니다. 또는 local에서 서버를 실행할 때에도, 정말 단순한 개발 환경을 위해 내 local DB에 연결하고 싶을 수도 있지만, 때로는 production 환경(일반적으로 실제 서비스를 하고 있는 환경을 뜻합니다)의 DB에 연결하여 개발한 내용을 테스트해보고 싶을 수도 있습니다.(물론 이 경우 production DB의 data를 잘못 조작하지 않도록 깊은 주의가 필요할 것입니다. 잘못하면 일시적으로(또는 영구히) 회사가 망할테니까요.) 사실 실제 회사 급 개발환경에서는, RDS 서비스를 production 환경을 위한 DB를 위해서만 이용하는 것이 아니라, 개인 local 환경(이건 그냥 개발하는 사람이라면 각자 당연히 갖춰져있겠죠) 외에도 회사 내 개발자들이 공유하는 develop 환경(실제 서비스를 하는 환경은 아니지만 매우 유사하게(평행세계처럼) 환경을 갖춰두어 더욱 리얼한 테스트가 가능하게 하는 환경)을 위한 DB도 생성해둡니다. EC2 등 모든 서비스도 세트로 2배로 사용하는 느낌이지요. 아무튼, 그렇기 때문에 같은 서버를 실행하더라도 환경 변수 등을 주는 것에 따라 local, develop, production 등의 세팅으로 서버가 실행되게 할 수 있는 것이지요.
Python은 스크립트 언어이므로 Django에서 이러한 분기를 태우는 것은 매우 직관적으로 간단합니다. 단적으로, 우리가 이미 익숙한 DEBUG_TOOLBAR 환경 변수에 따라 django-debug-toolbar를 적용한 상태로 서버를 실행할지 여부를 결정하는 것이 그런 것입니다. 일반적으로 MODE 같은 환경 변수에다가 dev, prod 등의 값을 받아 이럴 땐 이 DATABASES 설정으로, 저럴 땐 저 DATABASES 설정으로 연결하는 식으로 if-else 분기를 태워서 settings.py를 만들어둡니다. 또는 아예 설정 파일을 두 개 이상으로 분리시키고, settings.py가 그것을 환경 변수에 따라 다르게 import 하게 할 수도 있구요. 사실 굳이 settings.py에 집착할 필요도 없습니다! 여기를 보면 알 수 있듯, manage.py가 설정 파일로서 무엇을 읽을지 맘대로 조작 가능합니다. 공식적으로는 이 line에 있는 DJANGO_SETTINGS_MODULE을 활용하는 것이 좋은 방식일 것입니다. 이것도 그냥 프로그래밍의 영역이기에 방법은 무한할 것입니다. 매번 수동으로 파일을 수정하는 것은 귀찮고 지루하며 멍청하고 실수가 발생하기도 쉬운 방식이니까 어떻게 하면 이를 해소할 수 있을까 다양한 방식으로 고민할 수 있을 것입니다. 제가 여기서 언급한 수단들은 git과 환경 변수인 것이겠네요.
답변 감사합니다!