# BE
gunicorn - 아키텍처 설계
Gunicorn 아키텍처 설계 서버 모델 Gunicorn은 프리포크 워커 모델을 기반으로 합니다. 이 모델은 중앙 마스터 프로세스가 일련의 워커 프로세스를 관리하는 구조를 갖고 있습니다. 마스터 프로세스는 개별 클라이언트에 대해 아무것도 모르며 모든 요청과 응답은 워커 프로세스에서 완전히 처리됩니다. 마스터 마스터 프로세스는 다양한 프로세스 신호를 수신하고 그에 따라 반응하는 간단한 루프로 구성되어 있습니다. 이 루프는 TTIN, TTOU 및 CHLD와 같은 신호를 수신하여 실행 중인 워커 목록을 관리합니다. TTIN과 TTOU는 마스터에게 실행 중인 워커의 수를 증가 또는 감소시키라는 명령을 내립니다. CHLD는 자식 프로세스가 종료되었음을 나타내며 이 경우 마스터 프로세스는 자동으로 실패한 워커를 다시 시작합니다. 동기 워커 가장 기본적이고 기본 워커 유형은 한 번에 하나의 요청을 처리하는 동기 워커 클래스입니다. 이 모델은 오류가 최대 하나의 요청에만
gunicorn - 커스텀 어플리케이션
커스텀 애플리케이션 버전 19.0에서 새로 추가되었습니다. 때로는 Gunicorn을 WSGI 애플리케이션과 통합하고 싶을 때가 있습니다. 이 경우에는 gunicorn.app.base.BaseApplication을 상속할 수 있습니다. 다음은 매우 간단한 WSGI 앱을 생성하고 사용자 정의 애플리케이션으로 로드하는 예제입니다. 기존 WSGI 앱 직접 사용 필요한 경우 Gunicorn을 Python에서 직접 실행하여 런타임에 WSGI 호환 애플리케이션을 지정할 수 있습니다. 이는 롤링 배포 또는 PEX 파일을 사용하여 애플리케이션을 배포하는 경우 유용할 수 있으며, 앱과 Gunicorn을 동일한 PEX 파일에 번들로 포함할 수 있습니다. Gunicorn은 이러한 기능을 내장하고 있으며 gunicorn.app.wsgiapp이라는 이름으로 알려진 첫 번째 클래스 시민으로 사용됩니다. 이를 사용하여 Flask 또는 Django에서 생성된 것과 같은 WSGI 호환
gunicorn - 시그널 핸들링
시그널 핸들링 Gunicorn이 처리하는 시그널에 대한 간략한 설명입니다. 또한 Gunicorn과 워커 간에 통신하는 데 내부적으로 사용되는 시그널도 문서화합니다. 마스터 프로세스 QUIT, INT: 빠른 종료 TERM: 우아한 종료. 워커가 현재 요청을 완료할 때까지 대기하며 graceful_timeout까지 대기합니다. HUP: 구성을 다시 로드하고 새 구성으로 새 워커 프로세스를 시작하고 이전 워커를 우아하게 종료합니다. 응용 프로그램이 미리로드되지 않은 경우 ( preload_app 옵션 사용), Gunicorn은 또한 새 버전을 로드합니다. TTIN: 프로세스 수를 하나 증가시킵니다. `
gunicorn - 배포
Gunicorn 배포 Gunicorn을 프록시 서버 뒤에서 사용하는 것을 강력히 권장합니다. Nginx 구성 다양한 HTTP 프록시가 있지만, 기본 Gunicorn 워커를 사용할 때 느린 클라이언트를 버퍼링하는지 확인하는 경우 Nginx를 사용하는 것을 강력히 권장합니다. 다른 프록시 서버를 선택하는 경우 Gunicorn이 디닐 오브 서비스 공격에 취약해지지 않도록 느린 클라이언트를 버퍼링하도록 해야 합니다. 프록시가 제대로 작동하는지 확인하려면 Hey를 사용할 수 있습니다. Nginx를 사용하는 빠른 클라이언트를 위한 예제 구성 파일: nginx.conf: 스트리밍 요청/응답 또는 기타 고급 기능(Comet, Long polling, Web sockets 등)을 처리할 수 있도록 하려면 프록시 버퍼링을 비활성화해야
gunicorn - 설정 개요
설정 개요 Gunicorn은 설정 정보를 다섯 곳에서 읽습니다. Gunicorn은 먼저 일부 설정을 위해 환경 변수를 읽습니다. 설정에 대한 환경 변수를 먼저 읽습니다. 다음으로 Gunicorn은 프레임워크별 구성 파일에서 구성 정보를 읽습니다. 현재 이것은 Paster 응용 프로그램에만 영향을 미칩니다. 구성 정보의 세 번째 출처는 선택적 구성 파일인 gunicorn.conf.py로, 현재 작업 디렉토리에서 검색되거나 명령 줄 인수를 사용하여 지정됩니다. 이 구성 파일에 지정된 내용은 프레임워크별 설정을 무시합니다. 구성 정보의 네 번째 위치는 GUNICORNCMDARGS라는 환경 변수에 저장된 명령 줄 인수입니다
gunicorn - 실행하기
Gunicorn 실행하기 Gunicorn은 명령어를 사용하거나 Django, Pyramid, TurboGears와 같은 유명한 프레임워크와 통합하여 실행할 수 있습니다. Gunicorn을 프로덕션 환경에서 배포하는 방법은 Gunicorn 배포를 참조하세요. 명령어 Gunicorn을 설치하면 gunicorn이라는 커맨드 라인 스크립트에 접근할 수 있습니다. gunicorn 기본 사용법: 여기서 WSGIAPP은 $(MODULENAME):$(VARIABLE_NAME) 패턴입니다. 모듈 이름은 전체 점으로 구분된 경로일 수 있습니다. 변수 이름은 지정된 모듈에서 찾을 수 있는 WSGI 호출 가능 객체를 나타냅니다. 버전 20.1.0에서 변경: WSGI_APP은 [설정](https://docs.gunicorn.org/en/stable/settings.h
gunicorn-소개 및 설치
"Gunicorn 'Green Unicorn'은 UNIX용 Python WSGI HTTP 서버입니다. 이는 Ruby의 Unicorn 프로젝트에서 이식된 프리-포크 워커 모델입니다. Gunicorn 서버는 다양한 웹 프레임워크와 널리 호환되며 구현이 간단하며 서버 자원을 적게 사용하며 비교적 빠릅니다. 기능 WSGI, Django 및 Paster를 기본으로 지원 자동 워커 프로세스 관리 간단한 Python 구성 여러 워커 구성 확장성을 위한 다양한 서버 후크 Python 3.x >= 3.5와 호환됨" 설치 | 요구 사항: | Python 3.x >= 3.5 | | ------------- | --------------------- | Gu
EC2 서버 장애 대응하기 1 - AMI(Amazon Machine Image)
목적 AWS EC2를 이용하여 서버를 사용할 때, AMI를 미리 적용해둔다면 새로운 EC2를 기존 환경과 동일하고 빠르게 만들 수 있다. 실습 1. 서버에 올릴 프로젝트, EC2 생성 2. AMI 생성 (1) EC2 대시보드 > 작업 > 이미지 및 템플릿 > 이미지 생성 (2) 이미지 이름 및 설명 설정 재부팅 안함 활성화 시, 기존 서버가 재시작하지 않습니다.  site
Sites¶ django.contrib.sites에 대한 설정입니다. SITE_ID¶ 기본값: 정의되지 않음 django_site 데이터베이스 테이블에서 현재 사이트의 ID(정수)입니다. 이것은 응용 프로그램 데이터가 특정 사이트에 통합될 수 있도록 하며 하나의 데이터베이스가 여러 사이트의 콘텐츠를 관리할 수 있도록 합니다. [정적 파일](https://docs.dja
django-settings(7): Auth, messages, sessions
인증¶ django.contrib.auth에 대한 설정입니다. AUTHENTICATION_BACKENDS¶ 기본값: ['django.contrib.auth.backends.ModelBackend'] 사용자 인증을 시도할 때 사용할 인증 백엔드 클래스(문자열 형태)의 목록입니다. 자세한 내용은 [인증 백엔드 문서](https://docs.djangoproject.
django-core setting(6)
STORAGES¶ Django 4.2에서 새로 추가되었습니다. 기본값: Django에서 사용될 모든 스토리지 설정을 포함하는 딕셔너리입니다. 이는 스토리지 별칭을 개별 스토리지 옵션을 포함하는 딕셔너리로 매핑하는 내용을 포함하는 중첩된 딕셔너리입니다. 스토리지에는 선택한 임의의 별칭을 사용할 수 있습니다. 그러나 두 가지 특별한 의미를 가진 별칭이 있습니다: 파일 관리에 대한 default 별칭입니다. 'django.core.files.storage.FileSystemStorage'는 기본 스토리지 엔진입니다. 정적 파일 관리에 대한 `stat
django-core setting(5)
EMAIL_BACKEND¶ 기본값: 'django.core.mail.backends.smtp.EmailBackend' 이메일을 보내기 위해 사용할 백엔드입니다. 사용 가능한 백엔드 목록은 이메일 보내기를 참조하세요. EMAILFILEPATH¶ 기본값: 정의되지 않음 file 이메일 백엔드에서 출력 파일을 저장하는 데 사용되는 디렉토리입니다. `EMAIL_HOS
django-core settings(4)
EMAIL_BACKEND¶ 기본값: 'django.core.mail.backends.smtp.EmailBackend' 이메일을 보내기 위해 사용할 백엔드입니다. 사용 가능한 백엔드 목록은 이메일 보내기를 참조하세요. EMAILFILEPATH¶ 기본값: 정의되지 않음 file 이메일 백엔드에서 출력 파일을 저장하는 데 사용되는 디렉토리입니다. `EMAIL_HOS
django-settings(3)
DATAUPLOADMAXMEMORYSIZE¶ 기본값: 2621440 (즉, 2.5MB). 요청 본문이 SuspiciousOperation (RequestDataTooBig) 오류가 발생하기 전에 허용되는 최대 크기(바이트)입니다. 이 확인은 request.body나 request.POST에 액세스할 때 수행되며, 파일 업로드 데이터는 제외한 총 요청 크기에 대해 계산됩니다. 이를 체크하지 않으려면 None으로 설정할 수 있습니다. 비정상적으로 큰 폼 게시물을 받아들일 것으로 예상되는 응용 프로그램은 이 설정을 조정해야 합니다. 요청 데이터 양은 요청 처리와 GET 및 POST 딕셔너리를 채우는 데 필요한 메모리 양과 관련이 있습니다. 큰 요청은 확인되지 않으면 서비스 거부 공격 벡터로 사용될 수 있습니다. 웹
django-settings(2)-database
DATABASES¶ 기본값: {} (빈 딕셔너리) Django와 함께 사용할 모든 데이터베이스 설정을 포함하는 딕셔너리입니다. 이는 개별 데이터베이스의 옵션을 담고 있는 딕셔너리로 이루어진 중첩된 딕셔너리입니다. DATABASES 설정은 반드시 default 데이터베이스를 구성해야 합니다. 여러 개의 추가 데이터베이스도 지정할 수 있습니다. 가장 간단한 설정 파일은 SQLite를 사용하는 단일 데이터베이스 설정입니다. 다음과 같이 구성할 수 있습니다: MariaDB, MySQL, Oracle 또는 PostgreSQL과 같은 다른 데이터베이스 백엔드에 연결하는 경우 추가 연결 매개변수가 필요합니다. 다음은
디자인 시스템 네이밍 서포트 툴 개발기 - BE편 (개발부터 배포까지)
프로젝트의 시작 프로젝트의 시작은 디자이너의 제안에서 시작하였다. 프론트에 디자인 가이드를 전해줄 때 색깔과 사이즈 등 디자인 리소스(CSS)의 이름을 전해주는 방법에 대한 많은 고민이 있으셨다고 했다. 좀 더 직관적이면서 구조적인 네이밍 전달에 대해 고민하셨다. 원래는 스프레드 시트의 함수를 이용해 원하는 기능을 구현해볼려고 했으나. 생각보다 다양한 경우의 수와 복잡한 힘수로 개발을 제안하셨다! 사진과 같이 처음에 color를 선택했지만 다음 선택한 속성에 따라 연결 되어 나올수 있는 속성들이 달라진다. 그래서 개발을 시작전에 기술 스택을 고민했는데 마침 팀장님께서 MySQL개발을 통해 RDBMS에 대한 지식도 학습하길 원하셨기 때문에 `Node.j
DRF: Serializer Fields
Serializer fields > 각각의 폼 클래스의 필드는 데이터의 유효성을 검사하는 것뿐만 아니라 데이터를 "클린징"하여 일관된 형식으로 정규화하는 역할을 합니다. > > — Django 문서 직렬화기 필드는 원시 값과 내부 데이터 유형 간의 변환을 처리합니다. 또한 입력 값의 유효성을 검증하고, 부모 객체에서 값을 검색하거나 설정하는 데 사용됩니다. 참고: 직렬화기 필드는 fields.py에서 선언되지만 관례적으로 from rest_framework import serializers를 사용하여 가져오고 필드를 serializers. 형식
DRF: Serializers
시리얼라이저 > 시리얼라이저의 유용성을 확장하는 것은 우리가 다루고 싶어하는 주제입니다. 그러나 이것은 간단한 문제가 아니며, 심각한 설계 작업이 필요할 것입니다. > > — Russell Keith-Magee, Django 사용자 그룹 시리얼라이저는 쿼리셋과 모델 인스턴스와 같은 복잡한 데이터를 원시 Python 데이터 유형으로 변환하여 이를 간단하게 JSON, XML 또는 다른 콘텐츠 유형으로 렌더링할 수 있도록 해줍니다. 시리얼라이저는 역직렬화도 제공하여 구문 분석된 데이터를 먼저 유효성 검사한 후에 복잡한 유형으로 다시 변환할 수 있게 해줍니다. REST 프레임워크의 시리얼라이저는 Django의 `
애플로그인 구현 중 삽질한 EU
삽질 계기 웹뷰 형태의 앱 👉🏻 플러터 앱으로 변경하는 과정에서 애플 로그인 로직이 변경되어야 한다는 결론에 도달하게되었고, 로직을 변경하는 과정에서 여러 삽질을 하게 되었ㄷㅏ.. 애플 로그인 구현 과정 애플 로그인 구현에 있어서 아> 1. Apple Developer 사이트에서 애플 로그인 관련 설정 및 키 값 발급 > 2. 애플 로그인 로직 작성 애플 공식 문서를 보며 생각해본 플로우는 다음과 같았다. <img src = "https://velog.velcdn.com/images/odahyun/post/fb45f35e-c10e-4c23-b0ea-4fa7885e4099/image.png