20240911 TIL: main workflow 정상화하기 & gunicorn swagger 활성화하기

✅ 오늘 배운 것

오늘은 두 가지의 과제가 있다. 하나는 main workflow를 정상화해서 develop 브랜치의 내용이 main 브랜치로도 반영되도록 모종의 에러를 해결해야 한다. 또 다른 하나는 현재 develop 브랜치에서 settings 파일의 debug 변수를 True로 두고 있음에도 swagger 페이지가 제대로 표시되지 않는 오류(오류인지 정상 작동하는 것인지는 모르겠지만 우리 입장에서는 나타나야 하기 때문에 오류로 간주했다)가 있다. 

 

우선 첫 번째 업무부터 해 보자. main workflow가 과연 모종의 이유로 롤백되고 있는지를 먼저 확인하자. AWS ECS의 클러스터의 서비스 로그를 확인해봤는데 'rolled back'이라는 문구가 눈에 띄었다. 모종의 이유로 ECS가 롤백되고 있었다. 

 

CloudFormation에서 더 구체적인 로그를 보니, 이전에 개발서버에 있었던 거의 똑같은 이슈가 프로덕션 서버에 발생하고 있었다. 디렉토리명이 맞지 않아서 생긴 오류였다.

 

그래서 'onestep_be.settings.prod' 라는 모듈을 main 브랜치에서 사용하고 있는지를 확인해 보았다. 태스크 정의 JSON 파일에서 변수를 동적으로 넣어 주는 코드에서 해당 값을 넣어주고 있었다..!! 이 부분은 develop, main 브랜치 모두에서 수정되지 않은 부분이기 때문에 두 브랜치 모두 바꿔주어야 했다. 

 

해당 코드의 settings를 setting으로 바꿔 주고 다시 커밋을 올렸다. 다시 롤백이 발생하는지를 지켜봐야겠다. 우선 워크플로우는 무사히 잘 실행되었다. 

 

다행히 develop에서 새로 개발된 피쳐들이 프로덕션 서버에도 잘 적용되는 것을 확인할 수 있었다.

---

다음은 swagger view가 제대로 표시되지 않는 오류를 다뤄 보려고 한다. 찾아보니 이 부분은 크게 두 가지의 원인이 있을 수 있겠다. 첫 번째는 settings 파일의 DEBUG 변수 값에 따라서 swagger view를 표시하지 않도록 설정이 될 수 있다고 한다. 이 부분은 예상했던 부분이었다. 

 

그러나 DEBUG의 값이 False인 프로덕션과는 달리, DEBUG의 값이 True인 개발 서버에서도 swagger view가 표시되지 않으므로 이 문제만은 아닌 것 같았다. 

 

다른 가능성으로는, 현재 문제는 'python manage.py runserver' 명령어를 사용하다가 gunicorn 기반의 명령어를 사용하면서 swagger 페이지가 보이지 않게 된 것이므로 이 부분과 관련이 있을 수 있겠다. 찾아보니 python manage.py runserver로 서버를 띄울 때랑 gunicorn으로 서버를 띄울 때랑 정적 파일을 참조하는 방식이 다르다고 한다. 

 

그렇다면 gunicorn에서 어떻게 로컬 서버에 있는(사실 swagger 관련 파일이라 나는 이 파일들의 존재도 모르긴 했다. 어쨌든!) 정적 파일들을 서빙하게 할까? 집단지성의 힘을 빌리니 간단한 코드 몇 줄을 추가하면 된다고 한다. 

# onestep_be.urls
from django.contrib.staticfiles.urls import staticfiles_urlpatterns

urlpatterns += staticfiles_urlpatterns()

 

✅ 궁금한 점

1. gunicorn은 원래는 어떻게 정적 파일을 서빙했을까

2. staticfiles_urlpatterns는 어떤 역할을 하길래 gunicorn이 python manage.py runserver와 똑같은 정적 파일을 서빙하도록 할 수 있는 걸까