AWS Python Django Application 배포

이번 글에서 다룰 부분은 AWS(Amazon Web Service)에서의 Python 설치를 다루도록 하겠습니다.

사실 AWS에서 Python을 설치하는 것은 자습서 상에서 매우 잘 나타나 있지만, 여러 페이지를 옮겨다니면서 확인해야 하기 때문에 번거로움이 있었습니다.

이에 따라, 제 블로그에서는 옮겨다니는 번거로움을 줄이는 대신, 연재글의 형태로 순서대로 진행할 수 있도록 할 예정이니 참고하시기 바랍니다.

※ AWS의 VPC 네트워크 구축, IAM 서비스, S3 Storage 서비스 구축 부분은 생략하겠습니다.

※ AWS Console 수행을 위한 계정은 이미 보유하고 있어야 하며, VPC, S3는 이미 구축이 사전에 되어 있어야 하니 참고하시기 바랍니다.

※ PUTTY, XMING 미리 설치해주시기 바랍니다. (설치 링크는 왼쪽의 글자를 누르면 됩니다)

이전 글: 

2018/05/12 - [Onik Lab./AWS Python] - AWS EC2 (Ubuntu) 구축 및 접속

2018/05/19 - [Onik Lab./AWS Python] - AWS CLI, AWS EB CLI 설치

2018/05/19 - [Onik Lab./AWS Python] - AWS Python Django Application 환경설정

10. Elastic Beanstalk 배포를 위한 구성

이전 글에서 수행했던 명령에 바로 이어서 한다면 가상환경이 이미 활성화되어 있는 상태일 것입니다.

하지만 가상환경에 들어오지 않았다면 가상환경을 먼저 들어가도록 합니다.

(eb-virt) ~/ebdjango$ source ~/eb-virt/bin/activate

그 다음에는 전에 실행했던 pip freeze를 실행합니다. 하지만 이번에는 실행 결과를 requirements.txt에 저장합니다.

(eb-virt) ~/ebdjango$ pip freeze > requirements.txt

이 부분은 매우 중요합니다. Elastic Beanstalk에서 애플리케이션을 실행할 때 어떤 패키지를 설치할 것인지를 결정하는데, 이 때 requirements.txt 파일을 참조하기 때문입니다. 

다음은 .ebextensions을 새로 생성한 후, django.config 파일을 생성해서 애플리케이션을 시작하는 데 사용되는 WSGI 스크립트 위치를 지정합니다.

(eb-virt) ~/ebdjango$ mkdir .ebextensions
(eb-virt) ~/ebdjango$ vi .ebextensions/django.config

django.config는 없는 파일이므로 새로 생성해야 하며, 다음의 내용을 넣도록 합니다.

option_settings:
  aws:elasticbeanstalk:container:python:
    WSGIPath: ebdjango/wsgi.py

다음은 가상환경을 비활성화 합니다.

(eb-virt) ~/ebdjango$ deactivate

(그러나 제가 테스트한 결과, 가상환경을 비활성화 하지 않고 다음 작업을 진행해도 문제는 없었습니다. 다만, 가상환경 활성화가 애플리케이션에 패키지를 추가하거나 로컬에서 실행할 때 활성화를 한다는 점에 비추어 봤을 때에는 주 용도로 사용될 때에만 가상환경을 활성화하는 것을 권장합니다.)

11. Elastic Beanstalk 배포

개인적으로 이 부분에서 시간을 많이 소모한 것 같습니다.

세팅을 똑같이 했는데도 에러메시지가 매번 다르게 나타났지 싶었습니다.

사실 정확한 원인을 찾아내는 데에는 어려움이 있었지만, 어떤 유형의 오류가 있었는지도 소개하도록 하겠습니다.

참고문서: https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/create-deploy-python-django.html

먼저 Elastic Beanstalk(이하 EB) Repository를 초기화하고, Application을 생성해 줍니다.

~/ebdjango$ eb init -p python-2.7 django-tutorial
Application django-tutorial has been created.

python 2.7을 사용할 것이므로 언어는 다음과 같이 사용하도록 합니다.

※ 제가 이 부분과 관련해서 eb init 만 입력하고 여러 가지 테스트를 많이 해봤습니다만, 위와 같이 사용 언어(python-2.7) 및 애플리케이션 이름(django-tutorial)을 다 입력하는 것이 가장 안정적입니다. 물론 애플리케이션 이름은 어떤 것을 써도 문제는 전혀 없습니다.

참고문서에서는 SSH를 통해 실행할 때 Pair Key를 입력하는 방법도 추가로 나와있지만, 이 게시물에서는 생략합니다.

(실제로 생략해도 문제 없습니다)

이제 실제로 애플리케이션을 생성하도록 합니다.

/ebdjango$ eb create django-env

※ 이 부분 역시 'eb create'만 실행한 후 환경 이름을 직접 입력하는 방법도 해봤지만, 처음부터 환경이름을 명령어 뒤에 붙여주고 실행하는 것이 안정적입니다. 오히려 별도로 여러가지 입력을 하다가 에러가 발생하는 상황이 더욱 많이 발생합니다.

이 부분에서 시간이 거의 5분정도 소요 되니, 그 사이에 다른 준비를 하셔도 무방합니다.

생성이 완료되었으면 실제 가동을 하도록 합니다.

~/ebdjango$ eb open

테스트 결과는 다음과 같습니다.

먼저 django-env2라는 개발 환경에서 실행한 결과입니다.

다음은 django-env3라는 개발 환경에서 실행한 결과입니다.

모두 예상했듯이, django-env3 의 결과처럼 나오는 것이 정상이고, django-env2의 결과처럼 나오는 것이 비정상입니다.

놀랍게도 두 개의 환경은 모두 같은 환경설정에 같은 운영체제, 같은 설정값을 한 웹 애플리케이션입니다.

그런데도 이렇게 정반대의 결과가가 나온 이유는 저도 사실 파악을 하지는 못했습니다만,

한 가지 추정되는 것은 django-env2 가 제대로 나오지 않고, S3 Storage의 미사용 중인 Bucket을 삭제한 이후로 올바르게 나타난 것으로 보아 EB에 배포할 때 사용되던 이름 문제인 것으로 추정됩니다. (다만 정확한 원인은 좀 더 알아보겠습니다)

다음은 ebdjango/ebdjango/setting.py 에서 TIME ZONE을 수정합니다.

위와 같이 'ROK'라고 입력했는데, 이는 Republic of Korea의 줄임말로 군대에서 많이 듣던 용어였을 것입니다.

AWS의 Timezone은 한국을 ROK로 공식 표기하므로 이를 참고하시면 됩니다.

다음은 애플리케이션을 EB 환경에 배포합니다.

~/ebdjango/$ eb deploy

여기까지가 실제 Application을 배포하는 부분입니다.

참고자료에는 관리자 페이지 설정 및 배포 부분도 같이 나와있는데, 해당 부분은 블로그에서 언급하기보다는 직접 자료를 보시면서 실습하는 것이 더욱 유익할 것으로 생각됩니다.

이상 Python Django Application 배포를 마치도록 하며, 추후 실제 실습을 통해서 더욱 좋은 글로 찾아뵙겠습니다.