당신은 멋쟁이, 우리는 장고쟁이~

EB CLI 로 사이트 배포하기

지난 포스팅까지, Elastic Beanstalk 에 배포를 위한 기본 설정과, Elastic Beanstalk 를 위한 추가 설정까지 마쳤습니다 (ebextensions 폴더 생성후, django.config 파일 생성 완료)

Elastic Beanstalk 에 사이트를 배포할 준비가 다 되었습니다.

프로젝트 디렉토리는 아래와 같은 구조로 되어 있습니다.

1
2
3
4
5
6
7
8
9

(eb_env)  dhkang  ~/elastic_beanstalk/ebdjango  l
total 24K
drwxr-xr-x 4 dhkang dhkang 4.0K  9월 24 13:09 .
drwxr-xr-x 5 dhkang dhkang 4.0K  9월 24 12:52 ..
-rw-r--r-- 1 dhkang dhkang    0  9월 24 12:55 db.sqlite3
drwxr-xr-x 3 dhkang dhkang 4.0K  9월 24 12:55 ebdjango
drwxr-xr-x 2 dhkang dhkang 4.0K  9월 24 13:12 .ebextensions
-rwxr-xr-x 1 dhkang dhkang  540  9월 24 12:52 manage.py
-rw-r--r-- 1 dhkang dhkang   27  9월 24 13:06 requirements.txt

자 이제, 어플리케이션 환경을 생성하고, 설정된 어플리케이션을, Elastic Beanstalk 로 배포합니다.

EB CLI 를 사용하여, 배포하기 위해 아래 순서대로 진행 해 봅니다

Elastic Beanstalk 를 위한 설정

지난 포스팅까지, django2.1.1 기반의 django 프로젝트를 하나 생성해 주었습니다.

아무것도 수행하지 않는 어플리케이션이지만, 이 간단한 어플리케이션을 Elastic Beanstalk 에 배포하기 위해서는, 아래와 같은 몇가지 설정들을 해주어야 합니다.

1. requirements.txt 파일 생성
2. .ebextensions 폴더 생성후, 그 안에 django.config 파일 작성

Django 프로젝트 생성하기

django-admin startproject ebdjango 명령어를 실행하여, ebdjango 라는 프로젝트를 하나 생성해 줍니다.

1
2
3
4
5

(eb_env)  dhkang  ~/elastic_beanstalk  ls
eb_env
(eb_env)  dhkang  ~/elastic_beanstalk  django-admin startproject ebdjango
(eb_env)  dhkang  ~/elastic_beanstalk  ls
ebdjango  eb_env

ebdjango라는 폴더가 생성되고, 프로젝트가 생성된것을 확인 할수 있습니다.

배포전 환경설정

Elastic Beanstalk 에 Django 애플리케이션을 배포하기 위해서 필요한 환경 설정들이 몇가지 있습니다.

배포 작업을 진행하기 전에, 로컬 컴퓨터에서 배포를 위한 설정들을 하나씩 해주고.

Django 어플리케이션을 Elastic Beanstalk 에 배포하도록 할겁니다.

AWS Elastic Beanstalk 주요 환경

• AWS 계정
• Python 3.6
• pip
• virtualenv
• awsebcli
• Django 2.1.1

Django 버전은,

Elastic Beanstalk Python 구성 버전과 호환 되어야 합니다

Django 2.2 는 Elastic Beanstalk Python 3.6 플랫폼과 호환되지 않으므로

Django2.1.1 을 기반으로 한 프로젝트 실습을 진행 합니다.

파이썬 3.6 가상환경 생성 부터 진행해 봅니다 (ubuntu18.04)

Django 애플리케이션 배포하기

AWS Elastic Beanstalk 에 Django 애플리케이션을 배포하는 연습을 진행 해 보려 합니다.

우선, 배포 진행을 하기전에 알아야할 주요 환경은 아래와 같습니다.

주요 환경

• AWS 계정
• Python 3.6
• pip
• virtualenv
• awsebcli
• Django2.1.1

Django 버전은,

Elastic Beanstalk Python 구성 버전과 호환 되어야 합니다

Django 2.2 는, Elastic Beanstalk Python 3.6 플랫폼과는 호환되지 않으므로,

Django 2.1.1 기반으로 한 프로젝트 실습을 진행 합니다.

AWS Elastic Beanstalk 로 배포하기

Django 로 프로젝트를 개발한뒤에는, 아무래도 서비스를 실제 배포하여 사용할수 있습니다.

수 많은 배포 방법들이 존재하지만, 배포는 프로그래밍과는 또다른 의미로 어렵습니다.

특히 AWS 서비스를 다루는것만 해도 굉장히 복잡하기 때문에. Django 웹개발 공부를 진행하다가도, 배포에서 막힙니다.

배포에 막혀 너무 힘든 나날들을 보내다가, Elastic Beanstalk 로 배포를 시도해 보려 합니다.

Elastic Beanstalk 란?

AWS Elastic Beanstalk 는 JAVA, .NET, PHP, node.js, Python, Ruby, GO, Docker 를 사용하여,

Apache, Nginx, Passenger, IIS 와 같은 친숙한 서버에서 개발된 웹 애플리케이션 및 서비스를

간편하게 배포하고 조정할수 있는 서비스 입니다.

Elastic Beanstalk 의 이점

1. 빠르고 간편한 시작

   AWS 에 애플리케이션을 배포하는 가장 빠르면서 간단한 방법입니다. Git 을 통해 어플리케이션을 업로드 하면, Elastic Beanstalk 가 용량 프로비져닝, 로드 밸런싱, Auto Scaling, 모니터링에 대한 배포 정보를 자동으로 처리합니다. 개발자가 배포를 위한, 인프라나 리소스를 따로 구성할 필요가 없습니다.

2. 개발자 생산성

   Elastic Beanstlak 는 사용자 대신 배포를 위한 인프라를 운영 및 관리 해주므로, 개발자가 서버, 데이터베이스, 로드 밸런서, 방화벽, 네트워크 등을 관리하고 구성하는데에 시간을 들이지 않고. 오롯이 코드 작성에 집중할수 있게 해줍니다.

3. Auto Scaling

   자동 스케일링 설정을 사용하여, 어플리케이션의 특정 요건에 따라, 자동으로 어플리케이션을 확장 및 축소 합니다. CPU 사용률 지표를 참조하여 Auto Scaling 작업을 발생 시킵니다. 이는, 어플리케이션 비용을 최소화 하면서, 높은 워크로드나, 트래픽을 처리할수 있게 해줍니다.

4. 완벽한 리소스 제어

   EC2 인스턴스 유형과 같은 AWS 리소스를 어플리케이션에 가장 적합한 리소스로 자유롭게 선택할수 있습니다. 손쉽게 리소스, 인프라 요소 등을 제어하려면, Elastic Beanstalk 의 관리 기능을 사용하면 됩니다.

Models - Organising models in a package

Organising models in a package

manage.py startapp 커맨드는 models.py 를 포함한 어플리케이션 구조를 생성합니다. 많은 모델들을 가지고 있다면, 별도의 파일에 정리를 해두는것도 유용한 방법입니다.

그렇게 하기 위해서는, models 패키지를 생성해야 합니다.

1. models.py 를 없애고
2. app이름/models/디렉토리 를 생성합니다
3. app이름/models/디렉토리 안에, __init__.py 파일을 생성하고, 당신의 모델을 저장할 파일들을 생성합니다
4. __init__.py 파일에 import 해주어야 합니다

예를들어, organic.py , synthetic.py 가 모델 디렉토리 안에 있었다면,

__init__.py 파일에 import 해주는것을 잊지 않아야 합니다.

myapp/models/__init__.py

Multiple Inheritance

파이썬에서 서브클래스를 받는것과 같이, DJango 모델은 다수의 부모 모델들을 상속 받는게 가능합니다.

하지만, 파이썬에서 일반적으로 이름짓는 방식들이 이 Django 모델 클래스에 적용된다는점을 염두해 두고 있어야 합니다 (예, 예약어들은 클래스명으로 사용할수 없음)

특정 이름, (예, Meta) 가 나타나는 첫번째 기본 클래스가 사용 될것입니다. 예를들면, 이것의 의미는 만약 다수의 부모 클래스들이 Meta 클래스를 하나씩 가지고 있는다면, 오직 첫번째 것만 사용이 되고, 나머지들은 무시 됩니다.

보편적으로 우리는, 다수의 부모 클래스로부터 상속 받을 필요가 없는 경우가 많습니다. 주 사용처는, “mix-in” 클래스들을 사용할때 유용하다는 점입니다. 특정 추가 필드를 추가하거나 “mix-in” 을 상속받는 모든 클래스에 메서드를 추가할때 유용합니다.

당신의 상속 구조를 가능한한 최대로 간단하고 명료하게 유지하도록 노력해야 합니다. 그래야, 특정 정보가 어디서 왔는지 알아내기 위해 고생할 필요가 없어집니다.

Model Inheritance proxy models - 2

Base class restrictions

프록시 모델은 하나의 모델 클래스 (abstract 가 아닌것)을 상속 받아야 합니다

하지만, 다중의 모델 (abstract 가 아닌것)들을 상속 받을수 없습니다.

프록시 모델은, 다른 데이터 베이스 테이블들에 존재하는 행(row) 들끼리 연결을 지원하지 않습니다.

프록시 모델은 abstract 모델이 어떤 모델 필드도 정의하지 않는다는 전제하에, 여러개의 abstract 모델 클래스들을 상속 받을수 있습니다.

프록시 모델은 또한, 공통된 부모 클래스 (단, abstract 클래스가 아니여야 함)를 공유한다는 전제하에, 몇개라도 프록시 모델들을 상속 받을수 있습니다.

Proxy model managers

프록시 모델에 어떤 model manager 도 지정하지 않는다면, 부모 모델의 manager 를 상속 받습니다.

만약 프록시 모델에 manager 를 정의 한다면, 정의된 manager 가 기본값이 됩니다.

물론, 어떤 manager 든지 부모 클래스에 정의된 manager 도 여전히 사용 가능합니다.

이전 포스팅에서 진행한 예시에 이어서, Person 모델의 쿼리에서 사용되는 기본 manager 를 바꿀수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12

from django.db import models

class NewManager(models.Manager):
    # ...
    pass 


class MyPerson(Person):
    objects = NewManager()
    
    class Meta:
        proxy = True

만약 새로운 manager 를 기존에 존재하는 기본값을 바꾸지 않고 프록시에 추가하고 싶으면, custom manager 문서에 나와 있는 기술들을 사용해서 바꿀수 있습니다.

새로운 manager 를 가지고 있는 클래스를 생성하고, 기본 베이스 클래스 뒤에, 생성한 클래스를 상속 시켜 주면 됩니다.

1
2
3
4
5
6
7
8
9
10

# 새로운 Manager 를 위한 Abstract 클래스를 생성해줍니다.
class ExtraManagers(models.Model):
    secondary = NewManager() 

    class Meta:
        abstract = True 

class MyPerson(Person, ExtraManagers):
    class Meta:
        proxy = True

프록시 상속과 관리되지않은 모델의 차이점

프록시 모델 상속은 Meta 클래스에 managed 속성을 사용한, 관리되지 않은 모델을 생성하는것과 비슷해 보일지 모릅니다.

조심스럽게 Meta.db_table 을 설정하여, 기존에 존재하는 모델의 그림자 같은 관리되지 않은 모델을 생성할수 있고, 파이썬 메서드도 추가할수 있습니다.

하지만, 그것은 매우 반복적이고 깨지기 쉬운 구조 입니다. 수정할때 마다, 모든 복사본들을 동기화 해야 하기 때문입니다.

한편으로는, 프록시 모델들은 정확하게 프록싱 하는 기존 모델의 동작 처럼 동작하게 만들어 졌습니다. 프록시 모델은 언제나 부모 모델과 동기화 되어 있습니다 (직접 필드와 메니져들을 부모에게서 상속 받기 때문).

보통 법칙들은

1. 기존 모델 혹은 데이터베이스를 미러링 하고, 모든 오리지널 데이터베이스 테이블 열들을 원하지 않을때, Meta.mangled=False 를 사용해 줍니다. 이 옵션은 데이터베이스 뷰들을 모델링 할때와 Django 로 제어되지 않는 테이블들을에 유용합니다.

2. 만약 모델의 파이썬 동작만 바꾸고 싶은데, 같은 필드들을 오리지널과 같이 유지하고 싶을때, Meta.proxy=True 로 설정해 줍니다. 이 설정은, 데이터가 저장될때, 프록시 모델이 정확한 오리지널 모델 저장구조의 복사본이 됩니다.
   

Model 상속 (Proxy models)

Proxy models

Multi-table 상속을 사용할때에는, 새로운 데이터베이스 테이블이 각 서브 클래스 마다 생성 됩니다.

이는 보통 우리가 의도하는 동작이고, 서브 클래스들은, 베이스 클래스에 존재하지 않는 추가적인 데이터 필드들을 저장하기 위한 공간이 필요합니다.

하지만, 때때로 모델의 파이썬 동작을 바꾸고 싶을때가 있습니다 - 기본 메니저를 변경하거나 혹은 새로운 메서드를 추가할때 처럼 말이죠.

이것이 바로 프록시 모델 상속이 존재하는 이유 입니다. 기존 모델을 위해서 새로운 proxy 를 생성하는것 입니다.

모델의 파이썬 동작을 바꾸고 싶을때, 기존 모델을 위한 새로운 proxy 를 생성 합니다.

예) 기본 메니져 변경, 새로운 메서드 추가 등등