Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

파이썬 - WSGI를 만족하는 최소한의 구현 코드 및 PyCharm에서의 디버깅 방법

uwsgi나 gunicorn이,

파이썬 - 윈도우 환경에서 개발한 Django 앱을 WSL 환경의 uwsgi를 이용해 실행
; https://www.sysnet.pe.kr/2/0/12772

파이썬 - 윈도우 환경에서 개발한 Django 앱을 WSL 환경의 gunicorn을 이용해 실행
; https://www.sysnet.pe.kr/2/0/12775

Django App을 동일하게 실행시킬 수 있는 건 2개의 응용 프로그램 사이에 WSGI라는 공통 규약이 있기 때문입니다.

PEP 333 -- Python Web Server Gateway Interface v1.0
; https://www.python.org/dev/peps/pep-0333/

PEP 3333 -- Python Web Server Gateway Interface v1.0.1
; https://www.python.org/dev/peps/pep-3333/

그렇다는 건, 꼭 Django를 사용하지 않더라도 저 WSGI 규약만 맞춰주면 우리가 만든 앱을 uwsgi/gunicorn을 이용해 동일하게 실행시킬 수 있다는 것을 의미합니다.

실제로 "PEP 3333 -- Python Web Server Gateway Interface v1.0.1" 문서에 실린 코드가 바로 WSGI 규약을 만족하는 최소한의 구현 코드입니다.

# main.py

HELLO_WORLD = b"Hello world!\n"


def simple_app(environ, start_response):
    """Simplest possible application object"""
    status = '200 OK'
    response_headers = [('Content-type', 'text/plain')]
    start_response(status, response_headers)
    return [HELLO_WORLD]


application = simple_app

(닷넷과 비교하면 ASP.NET의 Route-to-code 방식과 유사합니다. ^^)

저렇게만 만들어 두면 이제 다음과 같이 gunicorn을 사용해 실행하는 것이 가능합니다.

$ gunicorn --bind 0.0.0.0:18090 main
[2021-08-18 18:14:02 +0900] [1670] [INFO] Starting gunicorn 20.0.4
[2021-08-18 18:14:02 +0900] [1670] [INFO] Listening at: http://0.0.0.0:18090 (1670)
[2021-08-18 18:14:02 +0900] [1670] [INFO] Using worker: sync
[2021-08-18 18:14:02 +0900] [1672] [INFO] Booting worker with pid: 1672

즉, uwsgi/gunicorn은 파이썬 애플리케이션으로부터 무조건 "application" 전역 변수에 설정된 웹 프레임워크 인스턴스를 받아와 Request/Response 처리를 넘겨주는 것입니다. 사실 여기서 application은 기본값에 불과하므로 이것을 정의하지 않는다면 다음과 같이 직접 simple_app을 지정하는 것도 가능합니다.

$ gunicorn --bind 0.0.0.0:18090 main:simple_app

어쨌든 이렇게 준비를 마쳤으면, 웹 브라우저에서 "http://localhost:18090"으로 접속해 "Hello world!"라는 문자열을 볼 수 있습니다.




그런데, 저렇게 구현한 코드를 어떻게 디버깅해야 하는 걸까요? 가령, PyCharm IDE 같은 환경에서 main.py의 simple_app 함수를 실행하는 순간 디버깅하고 싶으면 어떻게 해야 하냐는 것입니다.

(Visual Studio를 사용하는) 윈도우 개발자라면 이런 경우 시작 프로세스를 "gunicorn"으로, 명령행 인자에 "--bind 0.0.0.0:18090 main"으로 지정하고 F5 키를 누르면 실행 시 디버깅이 될 것이라는... 사용자 경험을 가지고 있습니다.

하지만, PyCharm의 경우에는 무조건 "Python Interpreter"의 'python'이 시작 프로세스로 지정돼 있어야 하고 이후의 명령행을 지정하는 식입니다. 이로 인해 시작 프로세스가 gunicorn/uwsgi라면 디버깅이 안 되는 것입니다.

이런 때 사용할 수 있는 서버가 바로 wsgiref입니다.

wsgiref — WSGI Utilities and Reference Implementation
; https://docs.python.org/3/library/wsgiref.html#module-wsgiref.simple_server

따라서 위의 문서에 나온 예제 코드에 따라 다음과 같이 간단하게 (uwsgi/gunicorn을 대체하는) Web Server를 python 코드로 완성할 수 있습니다.

# runserver.py

from wsgiref.validate import validator
from wsgiref.simple_server import make_server
import main

validator_app = validator(main.simple_app)

with make_server('', 18090, validator_app) as httpd:
    print("Listening on port 18090....")
    httpd.serve_forever()

이제 PyCharm의 "Run/Debug Configuration"에서 "Script path"를 "...[프로젝트 경로]...\runserver.py"로 지정하고 실행하면 simple_app의 코드에 BP를 걸고 디버깅을 할 수 있습니다. (PyCharm과 관련한 디버깅 방법은 이후로도 쭉 소개하겠습니다. ^^)

아울러 아래의 글들도 참고하시고. ^^

Quickstart uwsgi
; https://brunch.co.kr/@ddangdol/8

wsgi를 왜 쓰나요
; https://uiandwe.tistory.com/1268

[python] 서버의 기본 동작 방식
; https://uiandwe.tistory.com/1240




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]


donaricano-btn



[최초 등록일: ]
[최종 수정일: 8/20/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 쓴 사람
 



2021-08-24 10시16분
정성태

1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12887정성태12/21/2021349오류 유형: 777. OpenCVSharp4를 사용한 프로그램 실행 시 "The type initializer for 'OpenCvSharp.Internal.NativeMethods' threw an exception." 예외 발생
12886정성태12/20/2021384스크립트: 37. 파이썬 - uwsgi의 --enable-threads 옵션
12885정성태12/20/2021124오류 유형: 776. uwsgi-plugin-python3 환경에서 MySQLdb 사용 환경
12884정성태12/20/2021211개발 환경 구성: 620. Windows 10+에서 WMI root/Microsoft/Windows/WindowsUpdate 네임스페이스 제거
12883정성태12/19/2021144오류 유형: 775. uwsgi-plugin-python3 환경에서 "ModuleNotFoundError: No module named 'django'" 오류 발생
12882정성태12/18/2021252개발 환경 구성: 619. Windows Server에서 WSL을 위한 리눅스 배포본을 설치하는 방법
12881정성태12/17/2021168개발 환경 구성: 618. WSL Ubuntu 20.04에서 파이썬을 위한 uwsgi 설치 방법 (2)
12880정성태12/16/2021256VS.NET IDE: 170. Visual Studio에서 .NET Core/5+ 역어셈블 소스코드 확인하는 방법
12879정성태12/16/2021337오류 유형: 774. Windows Server 2022 + docker desktop 설치 시 WSL 2로 선택한 경우 "Failed to deploy distro docker-desktop to ..." 오류 발생
12878정성태12/15/2021376개발 환경 구성: 617. 윈도우 WSL 환경에서 같은 종류의 리눅스를 다중으로 설치하는 방법
12877정성태12/15/2021251스크립트: 36. 파이썬 - pymysql 기본 예제 코드
12876정성태12/14/2021198개발 환경 구성: 616. Custom Sources를 이용한 Azure Monitor Metric 만들기
12875정성태12/13/2021182스크립트: 35. python - time.sleep(...) 호출 시 hang이 걸리는 듯한 문제
12874정성태12/13/2021191오류 유형: 773. shell script 실행 시 "$'\r': command not found" 오류
12873정성태12/12/2021208오류 유형: 772. 리눅스 - PATH에 등록했는데도 "command not found"가 나온다면?
12872정성태12/12/2021313개발 환경 구성: 615. GoLang과 Python 빌드가 모두 가능한 docker 이미지 만들기
12871정성태12/12/2021289오류 유형: 771. docker: Error response from daemon: OCI runtime create failed
12870정성태12/9/2021234개발 환경 구성: 614. 파이썬 - PyPI 패키지 만들기 (4) package_data 옵션
12869정성태12/8/2021272개발 환경 구성: 613. git clone 실행 시 fingerprint 묻는 단계를 생략하는 방법
12868정성태12/7/2021192오류 유형: 770. twine 업로드 시 "HTTPError: 400 Bad Request ..." 오류
12867정성태12/7/2021213개발 환경 구성: 612. 파이썬 - PyPI 패키지 만들기 (3) entry_points 옵션
12866정성태12/7/2021480오류 유형: 769. "docker build ..." 시 "failed to solve with frontend dockerfile.v0: failed to read dockerfile ..." 오류
12865정성태12/6/2021224개발 환경 구성: 611. 파이썬 - PyPI 패키지 만들기 (2) long_description, cmdclass 옵션
12864정성태12/6/2021181Linux: 46. WSL 환경에서 find 명령을 사용해 파일을 찾는 방법
12863정성태12/4/2021231개발 환경 구성: 610. 파이썬 - PyPI 패키지 만들기
12862정성태12/3/2021204오류 유형: 768. Golang - 빌드 시 "cmd/go: unsupported GOOS/GOARCH pair linux /amd64" 오류
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...