<stdio.han>

이번엔 WSGI 서버인 Gunicorn 을 설치하고 사용해보자. WSGI 서버는 대표적으로 Gunicorn 과 uwsgi 가 있다. 우리는 Gunicorn 을 사용할 것이다.

구니콘은 서버에 필요한 도구이므로 서버 환경에 설치하자. AWS에 접속한 뒤 pip install gunicorn 명령을 해 설치하자.

설치후 테스트해보자. gunicorn --bind 0:8000 config.wsgi:application 명령을 해보자

/projects/mysite 디렉토리로 이동한 뒤 명령을 실행했다. 해석해보자면 --bind 0:8000 은 8000번 포트로 WSGI 서버를 수행한다는 의미이다. config.wsgi:application 은 WSGI 서버와 연결된 WSGI 어플리케이션은 config/wsgi.py 파일의 어플리케이션이라는 의미이다. 

http://고정IP:8000 으로 접속을 해보자.

이상하게 보일텐데 그 이유는 gunicorn 이 정적파일을 못읽었기 때문이다. 파이보는 bootstrap.min.css, bootstrap.min.js 등은 정적 파일인데 정적파일을 못 읽었기 때문이다. 일단 잘 작동하는것을 확인했으므로 control+c 로 구니콘을 종료하자.

구니콘은 포트를 이용해 서버를 띄울 수 있다. 아지만 Unix 계열 시스템에서는 포트로 서비스하기보다 유닉스 소켓을 사용하는 것이 빠르고 효율적이다. 이번엔 유닉스 소켓으로 서비스해보자. AWS 서버가 유닉스 계열 시스템인 우분투이다. 

이번엔 gunicorn --bind unix:/tmp/gunicorn.sock config.wsgi:application 명령을 했다. 잘 실행됬으니 종료하자.

AWS 서버에 Gunicorn 서비스로 등록해 보자. 구니콘의 시작, 중지를 쉽게 하고, 또 AWS 서버를 다시 시작할 때 Gunicorn 을 자동으로 실행하기 위해서이다.

먼저 환경변수를 수정하자.

/home/ubuntu/venvs/mysite.env 를 새로 만들고 작성하자.

vi 편집기로 작성했다.

내용 한줄만 작성하자. 그리고 /etc/systemd/system/ 디렉토리에 mysite.service 파일을 생성하자. 이 파일은 시스템 디렉토리에 저장해야 하므로 sudo vi mysite.service 같이 관리자 권한으로 작성해야 한다.

서비스 파일의 EnvironmentFile 항목이 우리가 작성한 환경 변수 파일을 사용하게 하는 설정이다. --workers 2 는 구니콘 프로세스를 2개 사용하라는 의미이다. 프로세스를 2개로 지정한 이유는 우리가 선택한 월 사용료 5달러 사양의 서버에는 이정도가 적당하기 때문이다.

이제 서비스를 실행해 보자. 서비스 파일이 관리자 디렉토리에 있으므로 실행 역시 관리자 권한으로 실행해야 한다.

sudo systemctl start mysite.service 명령을 해보자.

그리고 sudo systemctl status mysite.service 로 상태를 확인해보자. 다음처럼 잘 작동이 되지 않는다면 /var/log/syslog 파일에서 오류를 확인하고 수정하자.

마지막으로 AWS 서버가 다시 시작될때 구니콘이 자동으로 실행되도록 enabble 옵션을 추가해 서비스로 등록하자.

구니콘 서비스를 종료하려면 sudo systemctl stop mysite.service 

재시작 하려면 sudo systemctl restart mysite.service 명령을 하자.

지금까지 python manage.py runserver 명령어를 이용해 내장 서버를 구동하는 방식을 사용했다.

이제는 WSGI(위스키) 를 이용해 서버를 연다. WSGI 를 이용하면 기능이 더 많아지고, 이용자가 몰릴경우를 더 효율적으로 처리할 수 있다.

먼저 웹브라우저, 웹서버의 작동방식을 알아보자. 웹브라우저가 웹서버에 요청하는 페이지는 크게 두 가지 이다. 정적 페이지, 동적 페이지.

정적 페이지는 css, js, jpg, png 같은 변하지 않는 동일한 값을 리턴하는 정적 파일을 요청하는 것이다. 동적 페이지는 파이보의 메인페이지인 http://<고정 ip:8000> 같은 페이지를 요청하는 경우이다. 파이보 메인 페이지를 요청하면 질문 목록을 데이터베이스에서 조회해 리턴하고 그 목록은 DB가 변할때마다 바뀐다. 이런것을 동적 페이지라고 한다.

웹 서버는 정적 요청과 동적 요청을 처리하는 서버이다. 웹서버는 대표적으로 Apache, Nginx 등이 있다. 파이보는 장고와 잘 어울리는 엔진엑스(Nginx)를 웹서버로 사용할 것이다. 웹 서버는 정적 페이지 요청이 들어오면 간단하게 정적 파일을 읽어 응답한다. 하지만 동적 페이지 요청이 들어온다면 웹서버는 파이썬 프로그램을 호출해 질문목록을 조회해 리턴하는 파이썬 프로그램을 호출해야 한다. 하지만 대부분 웹 서버는 파이썬 프로그램을 호출하는 기능이 없다. 그러므로 파이썬 프로그램을 호출하는 WSGI(web server gateway interface) 서버가 반드시 필요하다. 웹 서버에 동적 요청이 발생하면 웹 서버가 WSGI 서버를 호출하고, WSGI 서버는 파이썬 프로그램을 호출하여 동적페이지 요청을 대신 처리한다.

WSGI 서버에는 여러 종류가 있지만 파이보는 Gunicorn을 사용할 것이다. 웹서버에 동적 페이지 요청이 발생하면 WSGI 서버를 호출하고 WSGI 서버는 다시 WSGI 어플리케이션을 호출한다. WSGI 어플리케이션은 장고, 플라스크 등이 있다. 파이보 시스템이 사용할 WSGI 어플리케이션은 우리가 지금까지 공부한 장고이다. WSGI 서버는 항상 projects\mysite\config\wsgi.py 파일을 경유해 Django 프로그램을 호출한다. 

간단하게 정리하자면 사용자가 웹서버에 정적요청을 할 경우엔 간단하게 웹 서버가 정적 파일을 찾아 응답한다.

이번엔 사용자가 웹서버에 동적요청을 할 경우에는 WSGI 서버(Gunicorn)를 호출하고 WSGI 서버는 WSGI 어플리케이션인 django 를 호출하고 장고는 데이터베이스를 조회해 응답해준다.

생능출판사 명품 운영체제

본 연습문제들은 작성자 본인이 푼것이라 틀릴 수 도 있습니다.

[개념체크]

1. 물리 메모리의 크기 한계를 극복하기 위한 메모리 관리 기술은?

③ 가상 메모리

2. 가상 메모리의 핵심 내용과 관계가 먼 것은?

③ 메모리 사용량이 적은 프로세스의 우선 스케줄링

3. 스래싱에 대한 해결책이 아닌 것은?

④ TLB의 항목수 늘리기

4. 스왑 영역으로 적합하지 않는 것은?

5. 가상 메모리 기법이 도입된 이유는?

① 물리 메모리보다 큰 프로세스를 실행시키기 위해

6. 가상 메모리 기법이 도입된 이유는?

① 물리 메모리의 크기 한계 극복

7. 요구 페이징에 대한 설명으로 틀린 것은?

③ 프로세스의 페이지를 가능한 많이 적재하도록 프레임을 할당하는 기법

8. 요구 페이징(demand paging)에서 요구(demand)의 의미는 무엇인가?

페이지가 필요할 때까지 물리 메모리에 적재하지 않고 두었다가, 페이지가 필요할때 물리 메모리를 할당받고 디스크에서 읽어 적재시킨다는 의미

9. 요구 페이징에서 요구의 의미에 가장 근접한 것은 무엇인가?

① 페이지 폴트가발생할 때

10. 페이지 테이블 항목에 valid 비트의 역할은 무엇인가?

1이면 페이지가 메모리 프레임에 존재. presence 비트라고도 함, 

11. 페이지 테이블의 항목을 구성하는 다음 필드의 용도를 기술하라.

(1) valid bit : 1이면 페이지가 메모리 프레임에 존재. presence 비트 라고도 함

(2) modified bit : 1이면 페이지가 적재된 후 수정되었음. dirty 비트 라고도 함

(3) reference bit : 1이면 페이지가 최근에 참조되었음

(4) protection bit : 'R'이면 읽기 전용 페이지, 'RW'이면 읽기 쓰기 모두 가능한 페이지

12. 페이지가 스왑-아웃될 때 페이지 테이블의 필드에서 일어나는 변화는?

④ valid bit : 1 -> 0, modified bit : 1 -> 0

13. 요구 페이징에서 페이지 폴트가 급격히 자주 발생하는 상황을 무엇이라고 부르는가?

② 스래싱

14. 다음은 시간 지역성과 공간 지역성 중 무엇에 대한 설명인가?

(1) 배열은 보통 순차적으로 액세스되므로, 현재 액세스하고 있는 배열의 다음 원소들이 가까운 미래에 액세스될 가능성이 매우 높다. 공간 지역성

(2) 프로그램 코드 역시 위에서 아래로 순차적으로 실행되므로, 현재 100 번지의 명령이 실행되고 있다면 곧 104 번지의 명령을 실행할 가능성이 매우 높다. 공간 지역성

(3) 프로그램 내에 지금 액세스되는 주소 영역(혹은 페이지)이 가까운 미래에 다시 액세스될 가능성이 크다. 시간 지역성

(4) 반복문의 실행 동안 코드나 데이터가 아주 짧은 시간 내에 다시 액세스될 가능성이 매우 높다. 시간 지역성

15. 다음 중 공간 지역성을 설명하는 것이 아닌 것은?

② 반복문의 실행 동안 코드나 데이터가 아주 짧은 시간 내에 다시 액세스될 가능성이 매우 높다

16. 다음 중 참조의 지역성을 훼손할 수 있는 것은?

② 1MB 크기의 큰 배열 사용

17. 다음 중 참조의 지역성을 기반으로 하는 컴퓨터 시스템의 정책이 아닌 것은?

③ 페이징 기법

18. 시스템을 관찰한 결과, 한 동안 잠잠하다가 일정 시간 페이지 폴트가 연이어 발생한 후 페이지 폴트가 다시 줄어든다. 여기서 페이지 폴트가 연이어 발생하는 상황을 가장 가깝게 설명한 것은?

① 작업 집합에 포함되는 페이지가 적재되고 있다

19. 시스템을 관찰한 결과, 한 동안 잠잠하다가 일정 시간 페이지 폴트가 연이어 발생한 후 페이지 폴트가 다시 줄어든다. 여기서 페이지 폴트가 연이어 발생하는 상황으로 예상할 수 없는 것은?

④ 스래싱이 발생하고 있다

20. 시스템 운영자가 스래싱이 발생하고 있음을 탐지하기 위해 필요한 정보는?

① CPU 활용률과 입출력 비율의 변화

21. DOM이 동시에 실행되는 프로세스의 개수라고 할 때, 스래싱이 발생하는 것이라고 판단할 수 있는 상황은?

② DOM 증가에 따른 CPU 활용률의 갑작스런 감소

22. 스래싱이 발생하는 원인은 무엇인가?

① 메모리에 적재한 프로세스의 개수가 과다함

23. 다음 그래프는 무엇을 보여주고 있는지 간단히 설명하라.

동시에 실행되는 프로세스의 수에 따라 스래싱이 발생하는 상황을 보여준다. 동시에 실행되는 프로세스의 수가 증가할 때 CPU 활용률이 높아지는 것이 컴퓨터 시스템의 정상적인 모습이지만, 프로세스의 수가 더 증가하면 프로세스당 메모리량이 줄어들어 페이지 폴트가 급격히 증가하고 이로 인해 입출력 작업이 증가하며, CPU는 입출력 작업의 완료를 기다리느라 정상적인 프로그램을 실행하지 못하여 오히려 CPU 활용률이 떨어진다. 이러한 현상을 스래싱이라고 한다. M 시점부터 스래싱이 발생하기 시작한다.

24. 다음 그림에 대한 설명으로 옳은 것을 모두 골라라?

① A 영역은 매우 정상적인 시스템의 모습이다

② B 영역에서 스래싱이 발생하고 있다

③ 동시에 실행되는 프로세스의 수가 M보다 커지면 과도한 디스크 입출력이 발생한다

④ 이 그래프에서 B의 현상이 발생하는 원인은 프로세스 당 메모리가 부족하기 때문이다

⑤ 이 그래프의 B 부분에는 페이지 폴트가 심각하게 발생한다

25. 가상 메모리 기법에서는 프로세스의 모든 페이지를 메모리 프레임에 적재해두지 않는다. 그러면 프로세스 당 몇 개의 페이지를 메모리 프레임이 할당하는 것이 적당한가?

작업 집합을 포함할 만큼의 페이지

26. 페이지 교체 알고리즘의 목표는 무엇인가?

현재 작업 집합에 포함되지 않거나 가까운 미래에 참조되지 않을 페이지를 희생 페이지로 선택하여 페이지 폴트의 횟수를 줄이는 것이다

27. 교체되기로 선택된 페이지를 무엇이라고 부르는가?

① 희생 페이지

28. 다음 중 가장 비현실적인 페이지 교체 알고리즘은?

① 최적 교체 알고리즘

29. 다음 중 참조의 지역성이 전혀 반영되지 않는 페이지 교체 알고리즘은?

② FIFO

30. 페이지 교체 알고리즘을 평가하는 잣대로 가장 적합한 것은?

① 페이지 폴트 횟수

31. Clock 페이지 교체 알고리즘을 설명한 것 중 틀린 것은?

② 페이지가 액세스될 때 마다 해당 메모리 프레임에 만들어둔 참조 비트를 0로 만든다

32. 희생 페이지를 찾기 위해 현재 적재된 페이지들을 검색하는 시간이 가장 빠른 것은?

④ 최적 교체 알고리즘

33. 응용프로그램은 컴파일 과정에서 코드와 데이터로 분리되어 실핼 파일이 구성된다. 아래는 응용프로그램을 구성하는 여러 페이지 중에서 일부이다.

(1) main() 함수의 for문이 실행되는 동안 형성되는 작업 집합을 페이지 순서대로 나열하라.

페이지 0 → 페이지 7(변수 i 액세스) → 페이지 3(함수 f() 코드 실행) → 페이지 9(변수 j 액세스) → 페이지 6(배열 n[] 액세스)

(2) 페이지 0만 적재된 상태에서 응용프로그램이 실행을 시작한다. 다른 페이지들일 적재되지 않았지만 일단 적재되면 실행이 끝날 때 까지 스왑-아웃되지 않는다고 가정하자. 이 프로그램이 실행되는 동안 페이지 폴트가 발생하지 않는 경우는?

④ 함수 f()의 for 문에서 sum += n[j]의 실행 시 sum 변수 액세스

sum 변수는 페이지 7에 존재하는데, 함수 f()가 실행될 때 변수 i를 액세스하기 위해 페이지 7이 적재되어 있으므로 sum 변수를 액세스할 때 페이지 폴트가 발생하지 않는다

생능출판사 명품 운영체제

본 연습문제들은 작성자 본인이 푼것이라 틀릴 수 도 있습니다.

[개념체크]

1. 다음은 페이징 메모리 관리에 대해 기술하는 문장이다. 보기에서 골라 빈칸을 채워라.

페이징은 프로세스의 주소 공간을 ( 페이지 )라는 ( 고정 ) 크기로 나누고 ( 물리 메모리 ) 역시 ( 페이지 ) 크기와 동일한 크기로 나누고 이를 ( 프레임 ) 이라고 부르며, 프로세스의 각 ( 페이지 ) 를 임의의 빈 ( 프레임 ) 에 할당하는 메모리 관리 기법이다.

2. 프로세스가 실행될 때 변수의 물리주소를 알아내기 위해 사용하는 것은?

① 페이지 테이블

3. 32비트의 주소 체계에서 페이지의 크기가 4KB라면, 한 프로세스 당 페이지 테이블의 크기는 얼마인가?

② 4MB

4. 페이지 테이블에 들어 있는 항목으로 적당한 것은?

④ 페이지의 물리 주소와 페이지 크기, 페이지의 논리 주소, 그리고 프로세스 번호 

---> 1번으로 수정

5. 페이지 테이블에 대한 설명으로 틀린 것은?

① 스레드마다 고유한 페이지 테이블이 사용된다

6. 논리 주소를 물리 주소로 바꿀 때 사용되지 않는 것은?

④ PCB

7. 페이지 테이블에 대한 설명 중 틀린 것은?

④ 페이지 테이블은 시스템 전체에 하나 있으며 커널 공간에 저장된다

8. 논리 주소를 물리 주소로 바꿀 때 사용되지 않는 것은?

② PC 레지스터

9. 32비트 주소 체계에서 한 페이지의 크기가 4KB일 때, 논리 주소 0x98761234 번지는 몇 번째 페이지의 몇 번째 바이트에 대한 주소인가(정확한 답 사례 : 0x###페이지의 0x###바이트)

0x98761페이지의 0x234바이트

10. 페이징 기법과 세그먼테이션 기법을 비교한 것으로 틀린 것은?

③ 세그먼테이션은 단편화가 적기 때문에 메모리 활용 면에서 페이징보다 우수하다

11. 페이지 테이블은 어디에 존재하는가?

① 메인 메모리

12. 페이징에서 프로세스의 논리 주소는?

① [페이지 번호]

---> 2번으로 수정

13. 32비트 주소 체계에서 한 페이지가 2KB일 때, 다음 32비트의 논리 주소는 몇 번째 페이지의 볓 번째 바이트에 대한 주소인가?

페이지 3의 15번째 바이트

14. 32비트 주소 체계에서 한 페이지의 크기가 4KB일 때, 다음 32비트의 논리 주소에 해당하는 물리 주소는(그림에서의 논리 주소와 프레임 번호는 16진수임)?

0x00022008

15. 페이징 메모리 관리 기법은 페이지 테이블로 인해 2가지 성능 이슈가 있다. 이 둘을 골라라?

① 페이지 테이블의 낭비

③ CPU의 메모리 액세스 시 2번의 물리 메모리 액세스로 인한 실행 속도 저하

16. TLB는 어떤 문제점을 해결하기 위한 것인가?

③ 물리 메모리의 액세스 횟수

17. TLB는 일반적으로 어디에 존재하는가?

① CPU 패키지의 MMU 장치 내에

18. TLB의 역할은 무엇인가?

③ 물리 메모리의 빠른 액세스

19. TLB는 고가의 장치이므로 TLB 크기는 페이지 테이블의 약 1/1000 수준이다. 이렇게 적은 크기로 논리 주소를 물리주소로 바꾸는데 효율적인 이유는 무엇인가?

프로그램이 가진 참조의 지역성 때문이다. 참조의 지역성은 지금 참조된 프로그램의 코드나 데이터가 가까운 시간 내에 다시 참조되거나 지금 참조되는 메모리 번지에 가까운 번지가 가까운 시간 내에 다시 참조되는 경향성이다. 그러므로 최근에 참조한 페이지들의 프레임 번호를 TLB에 저장하여 기억하면 동일한 페이지들이 한 동안 계속 참조될 가능성이 높으며, 하나의 TLB 항목이 한 페이지에서의 반복된 참조 시에 활용되므로 많지 않은 개수의 TLB 항목으로도 주소 변환 시 충분한 TLB 히트율을 달성한다.

20. 역 페이지 테이블과 멀티레벨 페이지 테이블 기법은 페이지 테이블의 어떤 문제를 개선하기 위한 것인가

② 페이지 테이블의 낭비 개선

21. 역 페이지 테이블을 사용할 때 역 페이지 테이블의 항목은 어떻게 구성되는가?

③ [프로레스 번호, 페이지 번호]

저번에 settings.py 의 ALLOWED_HOSTS 에 고정아이피를 추가해 서버를 구동했다. 하지만 이제 로컬서버를 구동해 파이보에 들어가면 오류가 발생한다. ALLOWED_HOSTS에 고정아이피를 등록했기 때문에 localhost 로 동작하는 로컬서버는 오류가 발생하는 것이다. 이 오류를 해결하려면 간단하게 ALLOWED_HOSTS 에 등록한 고정 아이피를 제거하면 된다. 하지만 로컬서버가 아닌 서버는 다시 오류가 발생한다. 이를 해결하기 위해 로컬환경과 서버환경을 구분해 줘야한다.

먼저 projects\mysite\config 위치에 settings 디렉토리를 생성해주자.

그리고 settings.py 파일을 settings 디렉토리에 base.py 라는 이름으로 이동시키자.

mv settings.py settings/base.py 명령어로 settings/base.py 로 이름을 변경해 옮긴 후. 옮긴 base.py 를 사진과 같이 수정해준다.

.parent 를 하나 더 적어준 이유는. 원래 settings.py 파일의 위치는 /projects/mysite/config 인데 /projects/mysite/config/settings 로 하나 더 깊어졌기 때문이다. /projects/mysite/config/settings/base.py 에서 총 3번의 .parent 가 사용되었으므로 BASE_DIR은 결국 /projects/mysite 인 것이다.

로컬환경을 담당하는 local.py 를 새로만들어 작성해준다.

projects\mysite\config\settings\local.py 를 만들어준다.

from .base import * 은 base.py 의 모든 내용을 사용한다는 의미이고, ALLOWED_HOSTS 는 로컬환경에 맞게 항목을 비워놓은 것이다. 

로컬환경은 설정했으니 서버 환경을 담당할 파일도 만들어 줘야한다.

projects\mysite\config\settings\prod.py 파일을 새로 만들어주고 다음과 같이 작성해주자.

이제 로컬서버를 구동해보자. 

오류가 발생한다. 이제는 로컬환경과 서버환경을 구분지어서 구동시켜줘야하기 때문이다. 먼저 로컬환경을 구동시키려면

python manage.py runserver --settings=config.settings.local 이라고해야 로컬환경을 구동시킬수 있다.

python manage.py runserver 뒤에 --settings=config.settings.local 이라는 옵션을 주었다. --settings 옵션은 장고서버가 읽어야할 설정파일을 지정하는 옵션이다. 그 뒤에적힌 명령어는 config\settings\local.py 를 읽으라는 뜻이다.

그렇다면 서버환경을 구동할때는

python manage.py runserver --settings=config.settings.prod 라고 해야한다. 서버 환경을 구동해서 파이보에 접속해보면 오류가 발생한다. 서버환경으로 구동하는. 파일 prod.py 에는 ALLOWED_HOSTS 에 서버의 고정아이피가 등록되어있기 때문이다.

이번엔 DJANGO_SETTINGS_MODULE 환경변수를 이용해보자. 이 환경변수는 장고 서버 실행 시 사용하는 --settings=config.settings.local 옵션을 대신하는 환경변수이다. DJANGO_SETTINGS_MODULE 환경변수를 settings=config.settings.local 로 설정해주면 python manage.py runserver 를 했을때 자동으로 환경변수를 찾아 뒤에 옵션을 안붙여도 로컬환경으로 구동이 된다. 이것들을 설정해주자.

\Users\<사용자명>\.zshrc 파일을 수정해 alias 를 추가해주자.

파일 수정은 vi 로 수정했다.

서버환경도 커밋하자.

그리고 AWS 터미널에 접속하여 올린 파일들을 내려받자.

AWS 터미널에 접속 후 가상환경에 진입 후 git 을 pull 하자. 그 후 

--settings=config.settings.prod 옵션을 추가해 서버를 구동하고 테스트를 해보면 잘 작동한다.

서버환경도 옵션을 추가할 필요없이 자동으로 작동하게 변경해보자. 

\home\ubuntu\.profile 파일을 vi 편집기로 수정해보자.

이렇게 .profile 파일을 수정하고 터미널을 종료후 다시 켜서 아무데서나 mysite 를 입력하면 자동으로 가상환경으로 진입한다. 그리고 서버구동시 옵션을 추가할 필요도 없어진다.

AWS 라이트세일로 서버를 생성했으니 서버에 파이보를 설치해 오픈해보자. 먼저 SSH를 사용해 서버에 접속하자.

접속하면

호스트 명이 ip-172-26-3-166 으로 되어있는데 sudo hostnamectl set-hostaname <원하는이름> 명령으로 바꿀수 있다.

바꾼 후 에는 sudo reboot 명령으로 재시작 하자.

그 후 서버 시간설정을  바꾸자.

date 명령을 해보면 시간이 UTC 시간이 출력된다. 이것을 sudo ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime  명령을 하면 date 명령을 해 다시 시간을 확인해보면 KST 로 변경된것을 알 수 있다.

장고를 사용하려면 파이썬이 설치되어 있어야한다. python 명령어를 입력해 파이썬이 설치되어있는지 확인해보자.

python 을 치면 python3 를 입력해보라는 말이 나온다. python3 명령을 해보면 잘 설치 되어있는것으로 나온다. 잘 설치되어 있는것을 알았으니 exit() 를 쳐 파이썬 셸을 종료하자.

가상환경을 설치하기 전에 일단 sudo apt update 명령을 하자.

우분투 패키지를 최신으로 업그레이드 해야 가상환경을 설치할 수 있다.

그 후 sudo apt install python3-venv 명령을 하자.

설치가 진행되는데 확인 질문들은 모두 Y 를 눌러 진행하자.

설치를 다 진행한 후 홈디렉토리(/home/ubuntu) 하위에 파이보가 필요로 하는 projects, venvs 디렉토리를 생성해주자. ls 명령어로 디렉토리가 잘 생성되었는지 확인해보자.

그 후 새로 만든 venvs 폴더로 이동해 장고 가상환경을 생성하자.

python3 -m venv mysite 명령을 한 후 기다리면 된다. 그리고 만든 가상 환경에 진입해 보자.

mysite 하위 bin 디렉토리로 진입 후 . activate 혹은 source activate 명령어를 입력해 가상환경으로 진입하자.

진입한 가상환경에서 wheel, django, markdown 패키지를 순서대로 설치해 주자.

설치를 다 진행한 후 파이보 관련 파일을 설치하자. 파이보 관련파일은 깃허브 원격 저장소에 저장했다. 서버에서 깃을 이용해 파이보 관련 파일을 내려받자.

일단 깃허브에 저장한 원격저장소 URL 을 복사하자.

주소 복사 후 cd ~/projects 명령으로 ~/projects 디렉토리로 이동하자.

~/projects 위치에서 git clone <깃허브 원격저장소 URL> mysite 명령을 하면 자동으로 내려받아진다. 그 후 ls 명령을해 mysite 디렉토리가 생성되었는지 확인하자.

생성된 mysite 폴더로 이동하자.

이동한 후 python manage.py runserver 로 서버를 실행시키면 python manage.py migare 명령을 수행하라는 오류가 나온다.

깃허브에는 .gitignore 에 의해 db.sqlite3 파일이 저장되지 않았기 때문이다. 하지만 데이터베이스를 생성하기 위한 작업 파일들은 pybo/makemigrations 디렉토리에 존재하므로 makemigrations 명령을 할 필요 없이 python manage.py migrate 명령으로 데이터베이스를 생성할 수 있다. CONTROL-C 로 장고 서버를 종료 후 python manage.py migrate 명령을 하자. 그렇게하면 db.sqlite3 파일이 생성된다.

migrate 를 했다면 다시 서버를 구동하는데 이번엔 python manage.py runserver 0:8000 명령으로 서버를 구동해보자.

0의 의미는 외부에서 이 서버에 접속할 수 있도록 IP를 개방한다는 의미이고 :8000 은 8000번 포트로 접속을 허용한다는 의미이다.

서버를 시작 후 http://<고정 IP> 를 입력하면 (ex : http://3.38.64.56)

이러한 오류페이지가 나온다. 장고 서버를 외부에 서비스 하려면 settings.py 파일의 ALLOWED_HOSTS 항목을 설정해줘야 하는데 설정되어있지 않아서 발생하는 오류다. 장고의 ALLOWED_HOSTS 는 보안과 관련된 항목으로 장고 서버가 실행가능한 호스트를 등록하는 설정 항목이다. 호스트 등록을 위해 내 PC의 settings.py 파일을 수정하자.

ALLOWED_HOSTS 에 고정 IP를 입력해주자. 변경 사항을 서버에 적용하기 위해 먼저 파일을 깃허브에 저장 후 다시 서버에서 그 파일을 다운받아야 한다. 

파이참 터미널에서

git add *

git commit -m "ALLOWED_HOSTS 변경"

git push 명령을 순서대로 하자.

깃허브에 정상적으로 업로드 했다.

그 후 터미널에서 ssh -i mysite.pem ubuntu@고정IP 명령어로 AWS 터미널로 들어가 git pull 명령을해 깃허브에서 다운로드하자.

~/projects/mysite 위치에서 git pull을 하자. git config credential.helper store 를 하면 깃허브인증을 생략할 수 있다. 이제 서버를 다시 시작해보자. 이 절차들은 mysite 가상환경에서 진행되어야한다.

서버를 재 시작 후 http://고정IP:8000에 접속해보자.

드디어 서버가 파이보를 오픈했다.

이제 누구나 웹브라우저에 http://3.38.64.56:8000 을 입력하면 내가만든 파이보에 접속할 수 있다!!

AWS 서버에 접속하기 위해서 고정IP 와 방화벽 해제가 필요하다. 고정 IP는 말그대로 IP가 변하지 않고 고정된 IP 이다. 

먼저 AWS 라이트세일의 메인화면에서 네트워킹 탭을 눌러 고정 IP 생성을 누르자.

버튼을 누르면 

인스턴스 선택에서 Ubuntu-1 을 선택 후 생성 버튼을 누르자.

그렇게 하면 고정 IP주소가 생성된다.

파이보 서비스의 기본 포트 번호가 8000이다. 외부에서 8000번 포트로 접속하려면 방화벽 해제 작업을 해야 한다.

AWS 메인화면에서 인스턴스 탭에서 Ubuntu-1 을 눌러보자.

그 후 네트워킹 탭에서 아래 [ + 규칙추가 ] 버튼을 누르자.

포트 또는 범위에 8000을 누른 후 생성을 누르자. 이렇게 하면 8000 포트의 방화벽 해제를 했으므로 외부에서 고정 IP 의 8000 포트로 접속이 가능해진다.

이제 파이보를 서버에 적용해야 한다. 서버에 접속하여 프로그램을 설치하고 환경 설정을 진행하자. 서버 작업을 위한 도구 SSH 를 설치해보자. SSH 는 네트워크 상의 다른 컴퓨터에 로그인하거나 원격 시스템(서버)의 명령을 수행하기 위한 프로토콜(기본포트 : 22 번).

먼저 SSH 프로그램으로 서버에 접속하기 위해서 AWS의 계정 프라이빗 키가 필요하다.

우 상단에 계정 버튼을 누르면 나오는 화면에서 SSH키 탭에서 아래에 있는 버튼을 눌러 프라이빗 키를 다운로드하자.

그리고 그 키는 .../vens 로 이동후 이름을 mysite.pem 으로 바꾸자.

그리고 터미널을 열어 .../vens 위치까지 이동 후 chmod 400 mysite.pem 명령을 해주자.

마지막으로  ssh -i mysite.pem ubuntu@본인의 고정 IP 주소 를 입력하면

서버에 접속이 된다. 이제 서버에 접속한 터미널을 이용해 서버작업을 할 수 있다.

우리가 지금까지 제작한 파이보를 누구나 사용할 수 있게 하려면 서버를 열어야 한다. 서버를 위해 장비를 사고 설치하고 관리하는데에 많은 시간과 돈이 필요하지만 요새는 클라우드 시스템으로 서버를 이용하면 모든 절차가 생략된다. 이번에는 Amazon Web Service, AWS 를 사용할 것이다. AWS는 조금 비싸지만 AWS Lightsail 로 저렴하게 서버를 구성해보자.

AWS 라이트세일은 아마존에서 운영하는 웹서비스 특화 클라우스 서비스다. 그리고 AWS 라이트세일 첫 3개월 무료이기 때문에 이것으로 서버를 열어보자. 먼저 AWS 에 가입해보자. 가입할 때 영문주소를 써야하는데 이 사이트에서 영문주소를 번역해서 가입하자. 

http://juso.go.kr 

가입할 때 Support 플랜을 선택할 때 기본지원 - 무료 플랜을 선택하자.

가입한 후 https://lightsail.aws.amazon.com 

AWS 라이트세일에 로그인하자.

오른쪽 하단에 English 를 눌러 한국어로 바꾸자. 그 후 인스턴스 생성을 눌러보자. 

플랫폼 Linux/Unix 를 선택하고 OS 전용을 누른후 Ubuntu 를 선택후 

5달러 플랜을 선택하자. 3.5 달러 플랜은 메모리가 부족하여 적당하지 않다.

이름을 변경해도 되고 Ubuntu-1 로 냅둬도 된다. 마지막으로 인스턴스 생성을 누르자.

생성을 누르면 대기중이다. 시간이 지나면 

실행중 으로 바뀌면 서버가 생성된것이다.