데이터베이스 정규화

|

SQL 첫걸음 8장 데이터베이스 설계 부분을 읽고 정리한 내용입니다.

34장 데이터베이스 설계

  1. 데이터베이스 설계 : 데이터베이스의 스키마 내에서 테이블, 인덱스, 뷰 등의 객체를 정의하는 것
    • 논리명과 물리명
    • 자료형

35장 데이터베이스 정규화

  • 데이터베이스 정규화 (database normalization)
    • 테이블을 올바른 형태로 변경하고 분할하는 것
    • 데이터베이스의 설계 단계에서 수행, 기존 시스템을 재검토할 때 수행
  • 정규화의 목적
    • 하나의 데이터는 한 곳에 있어야 한다.
    • 하나의 데이터가 한 곳에만 저장되어 있다면 데이터를 변경 하더라도 한 곳만 변경하는 것으로 끝낼 수 있다. (상품코드 0001의 상품명이 변경 되었을때는?)
    • 반면 정규화되지 않은 데이터베이스는 여기저기 중복해서 저장된 데이터를 검색하고 일일이 변경해야 한다. 또한 인덱스가 지정된 열의 데이터가 변경되는 경우에는 인덱스도 재구축 해야 한다.
    • 하지만 기본키는 분할된 테이블끼리 연계하기 위해 작성한, 이른바 내부적인 데이터임으로 변경될 일은 거의 없다. 따라서 정규화를 통해 테이블에 대한 인덱스의 재구축을 억제할 수 있다.
  • 정규화
  • 제1정규형
    • 관계형 데이터베이스 테이블에는 하나의 셀에 하나의 값만 저장할 수 있다는 제약이 있음
    • 반복되는 데이터를 가로 (열 방향)이 아닌 세로 (행 방향)로 늘리는 것이 제1 정규화의 1단계이다
    • 제1정규화에서는 테이블 분할과 기본키 지정이 이루어진다.
      • 주문 - 주문번호를 기본키로 갖는다
      • 주문상품 - 주문번호 + 상품코드를 묶어서 기본키로 갖는다
  • 제2정규형
    • 기본키에 중복이 없는지 조사하여 테이블을 분할한다.
    • 이때 기본키에 의해 특정되는 열과 그렇지 않은 열로 나누는 것으로 정규화가 이루어 진다.
    • 부분 함수 종속성을 찾아내서 테이블을 분할하는 것이 제2정규화이다
      • 여기서 함수 종속성이란 키 값을 이용해 데이터를 특정지을수 있는 것을 가리킨다.
  • 제3정규형
    • 기본키 이외의 부분에서 중복이 없는지를 조사하여 테이블을 분할한다.
    • 고객 테이블을 분리하고 고객번호라는 기본키를 지정한다.
  • 제5정규형 까지 있지만 대부분 제3정규형까지의 정규화를 채택한다.

HTTPS와 SSL 인증서, SSL 동작방법

|

생활코딩의 ‘https와 ssl 인증서’ 수업과 HTTP 완벽가이드 14장 ‘보안 HTTP’을 읽고 정리한 내용입니다. 개인공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.

HTTP & HTTPS

views
HTTPS는 HTTP를 안전하게 만드는 방식이다
  • HTTP
    • 인터넷 상에서 정보를 주고 받기위한 프로토콜(양식과 규칙의 체계)
    • 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜
    • 암호화되지 않은 방법으로 데이터를 전송한다. (악의적인 감청, 데이터 변조의 가능성)
  • HTTPS
    • 보안이 강화된 HTTP
    • Hypertext Transfer Protocol Over Secure Socket Layer의 약자
    • 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다.
    • HTTPS는 HTTP의 하부에 SSL과 같은 보안계층을 제공함으로써 동작한다.
views
HTTPS는 TCP위에 놓인 보안계층(SSL)위의 HTTP이다

SSL 디지털 인증서

  • 클라이언트와 서버간의 통신을 공인된 제3자(CA) 업체가 보증해주는 전자화된 문서

SSL 인증서의 장점 및 역할

  • 통신 내용이 노출, 변경되는 것을 방지
  • 클라이언트가 접속하려는 서버가 신뢰 할 수 있는 서버인지 확인가능
  • SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.

SSL에서 사용하는 암호화의 종류

  • 암호 : 텍스트를 아무나 읽지 못하도록 인코딩하는 알고리즘
  • 키 : 암호의 동작을 변경하는 매개변수, 키에 따라서 암호화 결과가 달라지기 떄문에 키를 모르면 복호화가 불가능하다.

대칭키 암호화 방식

  • 인코딩과 디코딩에 같은 키를 사용하는 알고리즘
  • 단점 : 단점은 발송자와 수신자가 서로 대화하려면 둘 다 공유키를 가져야 한다는 것이다.
  • 대칭키를 전달하는 과정에서 키가 유출이 되면 암호의 내용을 복호화할 수 있기 때문에 위험하다
  • 이를 보완하기 위해서 나온 방법이 공개키 암호화 방식이다.

공개키 암호화 방식

  • 인코딩과 디코딩에 다른 키를 사용하는 알고리즘
  • A키로 암호화를 하면 B키로 복호화를 할 수 있고, B키로 암호화 하면 A키로 복호화 할 수 있는 방식
  • 인코딩 키 (public key)는 공개되어 있으며 (그래서 공개키 암호방식이라는 이름이 붙었다.) 보통 디지털 인증서안에 포함되어 있다.
  • 디코딩 키는 (secret key)는 호스트만이 개인 디코딩 키를 알고있다.
  • 공개키와 비공개키의 분리는 메시지의 인코딩은 누구나 할 수 있도록 해주는 동시에, 메시지의 디코딩은 비밀키 소유자에게만 부여한다.
  • 이는 클라이언트가 서버로 안전하게 메시지를 발송하는 것을 쉽게 해준다.
  • 단점 : 공개키 암호화 방식의 알고리즘은 계산이 느린 경향이 있다.

디지털 서명

views
디지털 서명의 동작방식



  • 전자 서명을 통해서 누가 메시지를 썼는지 알려주고, 메시지가 위조되지 않았음을 증명할 수 있다. 전자서명은 SSL 인증서 에서 서비스를 보증하는 방법으로 활용된다.
  • 공개키와 비공개키는 안전한 데이터 전달 이외에도, 데이터 제공자의 신원을 보장 하는데 사용할 수 있다.
  • 비공개키의 소유자가 비공개 키를 이용해서 정보를 암호화 => 공개키와 함께 암호화된 정보를 전송 => 수신자는 공개키로 암호화된 정보를 복호화
  • 암호화된 데이터를 공개키를 가지고 복호화 할 수 있다는 것은 그 데이터가 공개키와 쌍을 이루는 비공개키에 의해서 암호화 되었다는 것을 의미한다.
  • 즉 공개키가 데이터를 제공한 사람의 신원을 보장해주게 되는 것이다. 이러한 것을 전자 서명이라고 부른다.

CA (Certificate Authority)

  • 디지털 인증서를 제공하는 공인된 기업 (Certificate Authority 혹은 Root Certificate)
  • 대표적인 CA 서비스 제공 기업과 시장점유율
    • Symantec (VeriSign, Thawte, Geotrust) with 42.9% market share
    • Comodo with 26%
    • GoDaddy with 14%
    • GlobalSign with 7.7%

SSL 인증서의 서비스 보증방법 및 동작방법

인증서 내용

  • 인증서의 내용은 CA의 비공개 키를 이용해서 암호화 되어 웹브라우저에게 제공된다.
    • 서비스 정보 (인증서 발급자, CA의 디지털 서명,서비스 도메인)
    • 서버측 공개키

SSL 인증서의 서비스 보증방법

  • 웹브라우저가 서버에 접속하면 서버는 제일 먼저 인증서를 제공한다.
  • 브라우저는 인증서를 발급한 CA가 자신이 갖고있는 CA 리스트에 있는지 확인한다.
  • 리스트에 있다면 해당 CA의 공개키를 이용해서 인증서를 복호화 한다.
  • 인증서를 복호화 할 수 있다는 것은 이 인증서가 CA의 비공개키에 의해서 암호화 된 것을 의미한다. 즉 데이터를 제공한 사람의 신원을 보장해주게 되는 것이다.

SSL 동작방법

  • 공개키 암호 방식은 알고리즘 계산방식이 느린 경향이 있다.
  • 따라서 SSL은 암호화된 데이터를 전송하기 위해서 공개키와 대칭키 암호화 방식을 혼합하여 사용한다.
  • 안전한 의사소통 채널을 수립할 때는 공개키 암호를 사용하고, 이렇게 만들어진 안전한 채널을 통해서 임시의 무작위 대칭키를 생성 및 교환한다. 해당 대칭키는 나머지 데이터 암호화에 활용한다.
    • 실제 데이터 암호화 방식 : 대칭키
    • 상기 대칭키를 서로 공유하기 위한 암호화 방식 : 공개키

SSL 통신과정

  • 컴퓨터와 컴퓨터가 네트워크를 통해서 통신을 할때 핸드쉐이크 -> 세션 -> 세션종료 의 과정을 거친다.
  • 암호화된 HTTP 메시지를 교환하기 전에 클라이언트와 서버는 SSL 핸드쉐이크를 진행한다.
  • 핸드쉐이크의 목적은 아래와 같다.
    • 프로토콜 버전번호 교환
    • 양쪽이 알고 있는 pre master secret 키 생성 및 교환
    • 양쪽의 신원 인증
    • 채널을 암호화 하기 위한 임시 세션 키 생성
  • SSL 통신과정을 간단하게 도식화 하면 아래와 같다.
  • 생활코딩 SSL의 동작방법에 아주 쉽게 설명되어 있어서 함께 참고하면 좋다.



views

참고

Django 배포연습 4 - uwsgi 를 통한 Django 실행

|

nginx, uwsgi, docker를 활용한 배포 연습 과정을 기록한 글입니다.
개인 공부 후 자료를 남기기 위한 목점임으로 내용상에 오류가 있을 수 있습니다.

  • nginx, uwsgi를 통해서 아마존 EC2에서 장고 앱 어플리케이션을 실행시켜 보는 것을 목표로 한다.
  • 최소한의 설정만을 포함한다.

uWSGI 실행 옵션

웹 서버 관리용 유저 생성

> sudo adduser deploy-user

uWSGI 설치

(virtualenv 환경 내부에서)
> pip install uwsgi

uwsgi 실행 옵션에 대한 설명

uwsgi 1)--http 2):8000 3)--home (virtualenv경로) 4)--chdir (django프로젝트 경로) 5)-w (프로젝트명).wsgi
1) uwsgi를 실행하는데 http로 오는 요청을 받겠다.

nginx <-> wsgi 통신은 기본적으로 socket 방식을 사용한다. HTTP 방식을 사용할 수 있지만 통신에서 로스가 많이 발생하는 단점이 있다. 그에 비해서 wsgi app은 서버 안쪽에서 서버의 요청을 django 어플리케이션에 중계하는 역할을 하기 때문에 무거운 HTTP 요청을 보다는 socket이라는 전송방식을 사용한다. (HTTP에 비해서 훨씬 가볍게 설정이 가능)

2) 8000 포트번호로 오는 요청을 받겠다.
3) uwsgi가 돌아갈 파이썬 환경 홈

uwsgi 자체가 파이썬 인터페이스이기 때문에 어떤 파이썬 환경에서 사용할지에 대한 경로가 필요함

4) uwsgi가 요청을 받고 실행할 파이썬 어플리케이션의 경로로 이동 (change directory)

manage.py가 있는 source root 폴더를 지정해야함

5) 실행시 어떤 wsgi 설정 파일을 갖고 실행할지를 지정

chdir 옵션을 통해서 이동한 장고 프로젝트 경로안에서 package 모듈 이름으로 찾는다
(config/wsgi가 아닌 config.wsgi)

uwsgi 실행 예시 (ubuntu 서버에서)

  • ex) pyenv virtualenv이름이 mysite-env, django프로젝트가 /srv/mysite/django_app, 프로젝트명이 mysite일 경우
  • 실행 후 :8000으로 접속하여 요청을 잘 받는지 확인
uwsgi --http :8000 --home ~/.pyenv/versions/mysite-env --chdir /srv/mysite/django_app -w mysite.wsgi

uwsgi 실행 예시 (로컬에서)

  • uwsgi는 로컬에서도 동일하게 실행 가능
  • 단 wsgi.py 파일에서 settings가 debug를 바라보도록 수정 필요 (ALLOWED_HOSTS에 localhost포함)
  • 로컬에서는 debug, 서버에서는 deploy settings를 바라보도록 하려면 wsgi.py 파일을 settings 처럼 분리하는것이 좋음
uwsgi --http :8000 --home /usr/local/var/pyenv/versions/deploy_ec2 --chdir /Users/Dev/deploy_ec2/django_app -w config.wsgi

uWSGI 설정분리 및 실행

wsgi 파일 분리하기

  • wsgi 파일을 debug/deploy로 분리하여 uwsgi 실행시에 실행환경에 맞는 settings를 바라보도록 조절한다.
├── django_app
│   ├── config
│   │   ├── __init__.py
│   │   ├── settings
│   │   │   ├── __init__.py
│   │   │   ├── base.py
│   │   │   ├── debug.py
│   │   │   └── deploy.py
│   │   ├── urls.py
│   │   ├── wsgi.py  # runserver용 wsgi 파일
│   │   └── wsgi  # uwsgi용 wsgi 파일
│   │       ├── __init__.py
│   │       ├── debug.py
│   │       └── deploy.py
│   ├── db.sqlite3
│   └── manage.py
  • wsgi.py 예시 (runserver시에 사용)
import os

from django.core.wsgi import get_wsgi_application

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.settings.debug")

application = get_wsgi_application()

  • wsgi 분기 예시 (uwsgi 실행시 사용)
from django.core.wsgi import get_wsgi_application

# wsgi/debug.py
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.settings.debug")

application = get_wsgi_application()

# wsgi/deploy.py

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.settings.deploy")

application = get_wsgi_application()

로컬에서 uwsgi 실행

uWSGI debug용 설정 파일 작성 예시

  • 위의 예시와 같이 uwsgi 실행시 모든 옵션을 적어야한다면 번거롭기 때문에 설정파일을 따로 생성한다.
  • 참고로 ini 파일에서는 ~/ (home폴더) 사용이 불가능하기 때문에 절대경로 입력이 필요하다.
[uwsgi]
home = /usr/local/var/pyenv/versions/deploy_ec2
chdir = /Users/Dev/deploy_ec2/django_app
module = config.wsgi.debug
http = :8000

uwsgi 실행

  • 로컬 컴퓨터에서 실행후 localhost:8000 으로 접속 확인
uwsgi -i .config_secret/uwsgi/debug.ini

ubuntu에서 uwsgi 실행

uWSGI deploy용 설정 파일 작성 에시

  • linux 서버 정보를 기준으로 작성해야 한다.
  • 파일경로 예시 : /srv/deploy_ec2/.config_secret/uwsgi/deploy.ini
[uwsgi]

# Django-related settings
# the base directory (full path)
chdir = /srv/deploy_ec2/django_app       
# Django's wsgi file
module = config.wsgi.deploy              
# the virtualenv (full path)
home = /home/ubuntu/.pyenv/versions/deploy_ec2 ; VirtualEnv location

uid = deploy-user       ; adduser 명령을 통해서 추가한 웹서버 관리용 유저
gid = deploy-user       ; group id

# the socket (use the full path to be safe
socket = /tmp/ec2.sock  ; 상기 유저가 해당 tmp 폴더에 대해서 모든 권한을 가져아함
chmod-socket = 666      ; 소켓 소유 권한 (읽고, 쓰기)
chown-socket = deploy-user:deploy-user ;소켓 소유자 adduser 명령을 통해서 추가한 유저 정보 (uid:gid)

# process-related settings
# master
master = true
enable-threads = true
pidfile = /tmp/ec2.pid

vacuum = true                  ;ec2.pid, ec2.sock 파일 자동삭제 (uwsgi 종료시)
logger = file:/tmp/uwsgi.log   ;log 경로

폴더 권한 변경

  • /tmp 폴더의 권한을 adduser를 통해서 추가한 deploy-user로 변경
sudo chown -R deploy-user:deploy-user /tmp

uwsgi 실행

  • /tmp/mysite.pid, /tmp/mysite.sock 파일을 생성하고 요청을 받을 준비완료
> sudo -u deploy-user /home/ubuntu/.pyenv/versions/deploy_ec2/bin/uwsgi -i /srv/deploy_ec2/.config_secret/uwsgi/deploy.ini
  • –http 옵션을 추가하면 :8000으로 접근 가능
> sudo -u deploy-user /home/ubuntu/.pyenv/versions/deploy_ec2/bin/uwsgi --http :8000 -ini /srv/deploy_ec2/.config_secret/uwsgi/deploy.ini

서버 접속시 uWSGI 자동 실행

uWSGI 서비스 설정파일 작성

sudo vi /etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service
After=syslog.target

[Service]
ExecPre=/bin/sh -c 'mkdir -p /run/uwsgi; chown deploy-user:deploy-user /run/uwsgi'
ExecStart=/home/ubuntu/.pyenv/versions/deploy_ec2/bin/uwsgi --uid deploy_user --gid deploy_user --master --emperor /etc/uwsgi/sites

Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=all

[Install]
WantedBy=multi-user.target

리부팅 시 자동으로 실행되도록 설정

  • 실행 실패시 에러로그는 /var/log/syslog에서 확인할 수 있다.
# 실행
> sudo systemctl start uwsgi.service
> sudo systemctl enable uwsgi
# 상태확인
> systemctl status uwsgi

● uwsgi.service - uWSGI Emperor service
   Loaded: loaded (/etc/systemd/system/uwsgi.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2018-03-04 09:51:25 UTC; 1min 10s ago
 Main PID: 6546 (uwsgi)
   Status: "The Emperor is governing 0 vassals"
   CGroup: /system.slice/uwsgi.service
           ├─6546 /home/ubuntu/.pyenv/versions/deploy_ec2/bin/uwsgi --uid deploy-user --gid deploy-user --master --emperor /etc/uwsgi/sites
           └─6547 /home/ubuntu/.pyenv/versions/deploy_ec2/bin/uwsgi --uid deploy-user --gid deploy-user --master --emperor /etc/uwsgi/sites

참고

Django 배포연습 3 - EC2 ubuntu 서버 인스턴스 생성 및 기본 설정

|

nginx, uwsgi, docker를 활용한 배포 연습 과정을 기록한 글입니다.
개인 공부 후 자료를 남기기 위한 목점임으로 내용상에 오류가 있을 수 있습니다.

  • nginx, uwsgi를 통해서 아마존 EC2에서 장고 앱 어플리케이션을 실행시켜 보는 것을 목표로 한다.
  • 최소한의 설정만을 포함한다.

용어정리

  • 가상서버 : CPU와 메모리를 가진 클라우드 내 서버
  • 인스턴스 (instance) : AWS에서 가상 서버를 부르는 용어
  • EC2 (Elastic Compute Cloud) : 가상 인스턴스를 운영하는 서비스
  • 보안 그룹(security group) : 인스턴스에 대한 트래픽을 제어하는 가상 방화벽 역할
  • IAM (Identity and Access Management) : 사용자 엑세스 및 암호화 키 관리
  • 관리 콘솔 : AWS 서비스를 모두 관리하는 사용자 인터페이스

EC2 인스턴스 생성

  • aws amazon 서비스에서 EC2 => 인스턴스 시작 선택
  • 프리티어에서 사용 가능한 Ubuntu Server 16.04 LTS (HVM), SSD Volume Type 선택
  • 검토 및 시작을 선택하여 기본 조건을 사용하는 인스턴스를 생성

키페어 생성

  • EC2 인스턴스 생성시 키 페어 지정이 필요
    • 퍼블릭 키 : AWS에 저장
    • 프리이빗 키 : 사용자가 저장
  • 프라이빗 키는 키 페어 생성 시점에 한번만 다운로드 가능
  • 키페어를 사용하여 SSH를 통해 EC2 인스턴스에 접속 가능
  • 다운받은 .pem파일을 ~/.ssh폴더에 넣기

screen 35

SSH를 통한 EC2 접속

ssh -i <인증서위치> <계정>@<인스턴스 퍼블릭 DNS>
ssh -i ~/.ssh/key.pem ubuntu@ec2-1111-11-111lap-northeast-2.compute.amazonaws.com
  • 아래와 같은 에러 발생시 chmod 400 로 소유주만 읽을 수 있도록 권한설정을 해준다.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/Leehyunjoo/.ssh/key-pairs-test.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/Users/Leehyunjoo/.ssh/key-pairs-test.pem": bad permissions
Permission denied (publickey).

❯ chmod 400 key-pairs-test.pem

IAM 유저 생성

  • 사용자 엑세스 및 암호화 키 관리 (Identity and Access Management)
  • AWS에서 모든 권한을 다 사용할 수 있는 ROOT 유저 대신, 특정 권한만 가진 유저 생성
  • aws amazon 서비스에서 IAM 선택
  • AmazonEC2FullAccess 권한을 가진 IAM 유저 추가
  • 참고 : AWS 계정의 IAM 사용자 생성

EC2 인스턴스 ubuntu 기본 설정

  • EC2 인스턴스를 생성후 ssh로 ubuntu 서버에 접속하여 기본적인 프로그램을 설치한다.

python-pip설치

sudo apt-get install python-pip

zsh 설치

sudo apt-get install zsh

oh-my-zsh 설치

sudo curl -L http://install.ohmyz.sh | sh

Default shell 변경

sudo chsh ubuntu -s /usr/bin/zsh

pyenv requirements설치

공식문서

sudo apt-get install -y make build-essential libssl-dev zlib1g-dev libbz2-dev \
libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev libncursesw5-dev xz-utils

pyenv 설치

curl -L https://raw.githubusercontent.com/yyuu/pyenv-installer/master/bin/pyenv-installer | bash

pyenv 설정을 .zshrc에 기록

vi ~/.zshrc
export PATH="/home/ubuntu/.pyenv/bin:$PATH"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

Django 관련 설정

장고 애플리케이션은 /srv Directory 사용

sudo chown -R ubuntu:ubuntu /srv/

프로젝트 소스코드 추가 1 - git clone

  • github에 올라간 프로젝트 소스코드를 ubuntu 서버에 clone
  • secret_key 등이 포함된 폴더는 공개저장소에 올리지 않기 때문에 별도로 설정해줘야 함
git clone <자신의 프로젝트>

프로젝트 소스코드 추가 2 - secure copy (clone으로 대체 가능)

scp -i <인증서위차> -r <프로젝트폴더> ubuntu@<인스턴스 퍼블릭 DNS>:/srv/deploy_ec2
scp -i ~/.ssh/key.pem -r /Users/Dev/deploy_ec2/ ubuntu@ec2-111-1111-111.ap-northeast-2.compute.amazonaws.com:/srv/deploy_ec2"

pyenv 3.4.3설치 및 virtualenv생성

cd <clone 혹은 copy한 프로젝트 폴더>
pyenv install 3.4.3
pyenv virtualenv deploy_ec2
pyenv local deploy_ec2

requirements설치

pip install -r requirements.txt

runserver 테스트

  • 0:8000 으로 지정필요
  • 웹 브라우저에서 <퍼블릭 DNS:8000=""> 로 접속하기 위해서는 보안그룹(security group) 설정이 필요
cd deploy_ec2/django_app/
python manage.py runserver 0:8000 --settings=config.settings.debug

보안그룹 인바운드 설정 수정

  • 보안 그룹(security group)은 하나 이상의 인스턴스에 대한 트래픽을 제어하는 가상 방화벽 역할
  • Linux 인스턴스에 대한 Amazon EC2 보안 그룹
  • 보안그룹 기본 인바운드 설정
    • Type: SSH
    • Protocol: TCP
    • Port Range: 22
    • Source : 0.0.0.0/0 (전세계 어디서나)
  • SSH 접속은 사무실 혹은 집의 ip 에서만 가능하도록
  • Custom TCP Rule 8000번 포트 추가 (runserver시 8000번 포트를 통해서 접속)

screen 36

ALLOWED_HOSTS 설정

  • settings.py의 ALLOWED_HOSTS에 특정 서버의 IP주소나 도메인에 대해서만 장고 웹어플리케이션이 서빙을 수행할 수 있도록 한다.
ALLOWED_HOSTS = [
	'<ec2 domain name'>,
	또는
	'.amazonaws.com',  # 구체적으로 작성하는 편이 좋음
]

참고

Django 배포연습 2 - nginx, wsgi 개념

|

nginx, uwsgi, docker를 활용한 배포 연습 과정을 기록한 글입니다.
개인 공부후 자료를 남기기 위한 목점임으로 내용상에 오류가 있을 수 있습니다.

  • nginx, uwsgi를 통해서 아마존 EC2에서 장고 앱 어플리케이션을 실행시켜 보는 것을 목표로 한다.
  • 최소한의 설정만을 포함한다.

toy architecture

1. 클라이언트

웹서버(Nginx)로 HTTP 요청

2. 웹서버(Nginx)

웹 서버. 클라이언트로부터의 HTTP요청을 받아 정적인 페이지/파일을 돌려준다. (동적인 부분은 uWSGI가 담당) 가벼움과 높은 성능을 목표로 한다. 웹 서버, 리버스 프록시 및 메일 프록시 기능을 가진다.

3. Unix Socket

웹서버(Nginx) - 웹어플리케이션서버(uWSGI) 사이의 통신을 매개 HTTP 요청을 사용할 수도 있지만 서버 안쪽에서의 통신이기 때문에 socket 방식이 overhead가 적어서 더 효율이 좋음

4. 웹어플리케이션서버(uWSGI)

웹 서버(Nginx)와 웹 애플리케이션(Django)간의 연결을 중계 (Nginx에서 받은 요청을 Django에서 처리하기 위한 중계인 역할을 해준다) Nginx는 Python을 모르기 때문에 uWSGI는 HTTP 요청을 python으로, Django로 부터 받은 응답을 Nginx가 알 수 있도록 변환해준다.

5. Django

웹 애플리케이션. 웹 요청에 대해 동적데이터를 돌려준다.

WSGI

Web Server Gateway Interface
파이썬에서 웹 서버와 웹 애플리케이션간의 동작을 중계해주는 인터페이스 표준 웹클라이언트의 HTTP 프로토콜 요청을 Python Call로 변환하기 위한 매핑관계로 WSGI를 표준으로 사용 uWSGI는 WSGI 표준의 구현 (Wikipedia)

참고