따라서 Redis를 다중화하고, Fail-over 할수 있는 방법이 필요하다고 생각했다.

사실상 Cache에 올라가는 내용은 API에서 받거나, DB에서 받는 내용이므로 운영/개발계 모두 동일한 내용을 Fork해도 된다고 생각했다. 이후 필요할경우 세션에 대한 부분을 Redis내부에서 분류하여서 변경하지 않을예정

master-slave 구성

master-slave 구성은 간단하다. 기존의 글 에서 redis.conf 파일에 아래 한줄만 추가해주면 된다.

...
slaveof [IP주소] [포트번호]
...

이후 redis-cli에서 info replication을 통해 아래와 같이 'master:link_status'를 확인해보면 된다.

Master에서는 같은 명령어가 아래와 같이 보인다. slave에 대하여 slave를 할 수 있는데, 그렇게 2단계에 걸친 slave된 노드들은 여기서 보이지 않는다.

Redis-sentinel 구성

bitnami에서 제공하는 redis-sentienl을 사용할 예정. sentinel에서 slave를 master로 승격하는 투표를 하는데, 이 투표의 기준선이 '쿼럼'이라고 보면된다. 쿼럼이 2이상이여야하기 때문에 sentienl구성은 sentinel 노드가 2개 이상이여한다. 하드웨어적으로 아예 분리된 상태에서 3개여야 HA구성의 의미가 있다. 자세한 설정은 아래를 참고하자 https://hub.docker.com/r/bitnami/redis-sentinel/

-v 폴더내의 아래 파일이 있어야한다. 따라서 아래 기준으로 아래 폴더가 있어야한다. 또한 파일에 대한 권한이 있어야한다.

chmod -R 777 /var/myredis/persistence/
/var/myredis/persistence/redis-sentinel/conf/sentinel.conf

 docker run -d \
  -e REDIS_MASTER_HOST=[Master의 IP주소] \
  -e REDIS_MASTER_PORT_NUMBER=6379 \
  -v /var/myredis/persistence:/bitnami \
  -p 26379:26379 \
  --network redis-net \
  --name redis_sentinel \
  --restart=always \
  bitnami/redis-sentinel:latest

docker exec -it redis_sentinel redis-cli -p 26379 

그런데.. slave에서는 sentienl이 있다고 나오지만, master에서는 sentinel이 Master node의 1개라고 나온다. Master는 Oracle Cloud에 있고, slave 2개는 내 Local망에 있기 때문이다. NAT 설정을 해줘야한다.

1. 각 User와 1:1 매칭이고 유효기간이 없다 -> Token이 탈취되면 안된다.
2. Database에 Token을 가진 유저를 매칭해야한다.

JWT (JSON Web Token)

데이터베이스를 조회하지 않아도, 로직만으로 인증이 가능하다.

Format :헤더.내용.서명 서버에서 토큰 발급시에 비밀키(settings.py에 있는 비밀키 혹은 원하는 비밀키)로 서명을 하고, 발급시간을 저장. 서명은 암호화가 아니다.

Claim : 담는 정보의 한 조각. "Key/Value"의 형식.

비밀키 : settings.SECRET_KEY를 활용하거나, JWT_SECRET_KEY 설정을 합니다. 갱신 : Token 유효기간 내에 갱신하거나, username/password를 통해 재인증해야함. 이미 발급된 token을 폐기하는것은 불가능함.

djangorestframework-simplejwt를 사용하자.

원래 있던 djangorestframework-jwt는 프로젝트가 종료되어 해당 지원이 종료되었다. 이를 이어받아 계속 maintaining하고있는 simplejwt를 사용하자.

pip install djangorestframwork-simplejwt

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'rest_framework.authentication.SessionAuthentication',
        # 'rest_framework.authentication.TokenAuthentication', #Token인증을 사용하지 않을시 빼버리는게 낫다. 성능에 영향을 주기때문.
        'rest_framework_jwt.authentication.JSONWebTokenAuthentication',
    ],

 from rest_framework_simplejwt.views import (
    TokenObtainPairView,
    TokenRefreshView,
    TokenVerifyView,
)

urlpatterns += [
    path('token/', TokenObtainPairView.as_view(), name='token_obtain_pair'),
    path('token/refresh/', TokenRefreshView.as_view(), name='token_refresh'),
    path('token/verify/', TokenVerifyView.as_view(), name='token_verify'),
]

문제해결

셋업 자체는 어렵지 않았는데, 토큰 자체는 유효한데, 자꾸 시도를 하니 오류가 났다. 이유는... Http 헤더에 따옴표를 붙인것.. 나만... 해맸던거야?..

{
  "detail": "이 토큰은 모든 타입의 토큰에 대해 유효하지 않습니다",
  "code": "token_not_valid",
  "messages": [
    {
      "token_class": "AccessToken",
      "token_type": "access",
      "message": "유효하지 않거나 만료된 토큰"
    }
  ]
}

GET http://localhost:8000/[주소]
Accept: application/json
#성공
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNjk2MDU2NzQ3LCJpYXQiOjE2OTYwNTQ5NDcsImp0aSI6IjM5Y2IyNTgwYjMxYTQ1MjdhOGU5YzI3YTc3MDFjNjQyIiwidXNlcl9pZCI6MX0.Ek-tHvxJdxDnvgxJdxZRHN4Y9fyY4OBvEQwmTRgmDTM

#실패
Authorization: Bearer "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNjk2MDU2NzQ3LCJpYXQiOjE2OTYwNTQ5NDcsImp0aSI6IjM5Y2IyNTgwYjMxYTQ1MjdhOGU5YzI3YTc3MDFjNjQyIiwidXNlcl9pZCI6MX0.Ek-tHvxJdxDnvgxJdxZRHN4Y9fyY4OBvEQwmTRgmDTM"

• SessionAuthentication : rest_framework.authentication.SesstionAuthentication 웹과 장고가 같은 호스트를 쓴다면 사용 가능. 하지만 외부 서비스/앱에서는 사용불가
• BasicAuthetication : rest_framework.authentication.BasicAuthentication 외부 서비스/앱에서 매번 username/password를 넘기는건 무서운 일
• TokenAuthentication : 초기에 username/password로 Token을 발급받고, 이 Token을 API요청에 담아서 인증처리

Token을 생성받는 방법

1. ObatainAuthToekn 뷰를 통한 획득 및 생성 -> URL Mapping필요

rest_framework/authtoken/views.py에 있음. 
class ObtainAuthToekn(APIView):
    def post(self, request, *args, **kwargs): 
    ....

from rest_framework.authtoken.views import obtain_auth_token

urlpatterns += [
    path(r'api-token-auth/', obtain_auth_token),
]

settings.py

INSTALLED_APPS=[
    ...
    'rest_framework',    # Third Apps
    'rest_framework.authtoken',
]

REST_FRAMEWORK = {

    'DEFAULT_AUTHENTICATION_CLASSES': [
        'rest_framework.authentication.SessionAuthentication',
        'rest_framework.authentication.TokenAuthentication',
    ],
    }

이후 Migration을 통해 기본 User모델에 Token 필드를 만들어야한다.

2. Signal을 통한 자동생성

@receiver(post_save, sender=settings.AUTH_USER_MODEL)
def create_auth_token(sender, instance=None, created=False, **kwards):
    if created:
        Token.objects.create(user=instance)

3. Management 명령을 통한 생성

python3 manage.py drf_create_token <username>

python3 manage.py drf_create_token -r <username>

Token과 loginRequiredMixin은 같이 사용이 불가능하다!?

Token은 rest_framework에서 지원하고, loginRequriedMixin은 Django에서 지원하는 것이라 서로가 호환이 안되어, Token을 제공했음에도 불구하고 로그인화면을 리턴해버림. 역시 스택오버플로우에는 같은 질문이 있었고, 그걸 해결해준 사람이 있었다.

간단하지만 명료하다. Token이 있으면 loginRequiredMixin을 무시하고, 해당 Token에 대한 인증을 ViewSet에서 수행한다. DRF와 Django의 구현이 다르고, Template과 RESTfulAPI 모두를 사용하게되면 계속 겪게될 문제이니 잘 참고하자.

views.py
from django.contrib.auth.mixins import LoginRequiredMixin
from rest_framework.authentication import SessionAuthentication, TokenAuthentication

class TokenLoginRequiredMixin(LoginRequiredMixin):
    def dispatch(self, request, *args, **kwargs):
        """If token was provided, ignore authenticated status."""
        http_auth = request.META.get("HTTP_AUTHORIZATION")
        if http_auth and "Token" in http_auth:
            pass
        elif not request.user.is_authenticated:
            return self.handle_no_permission()
        return super(LoginRequiredMixin, self).dispatch(
            request, *args, **kwargs)

class MybookWishListViewSet(TokenLoginRequiredMixin, viewsets.ViewSet):
    login_url = f'{settings.FORCE_SCRIPT_NAME}/accounts/login'
    authentication_classes = [
        SessionAuthentication,
        TokenAuthentication,
        ]

용어 정리

• Rate : 지정 기간 내에 허용할 최대 호출 횟수
• Scope : 각 Rate에 대한 별칭 (alias)
• Throttle : 특정 조건 하에 최대 호출횟수를 결정하는 로직이 구현된 클래스

기본 제공 Throttle

• AnonRateThrottle : 인증요청에는 제한을 두지 않고, 비읹으 요청에는 IP단위로 횟수 제한 scope : 'anon'
• UserRateThrottle : 인증에는 유저단위로 횟수를 제한하고, 비인증 요청에는 IP단위로 횟수제한 scope : 'user'
• ScopedRateThrottle : 인증 요청에는 유저단위로 횟수를 제한하고, 비인증 요청에는 IP단위로 횟수 제한. 각 APIView 내에 throttle_scope 설정을 익어 APIView별로 서로 다른 Scope 적용.

설정 예시

settings.py
REST_FRAMEWORK = {
    'DEFAULT_THROTTLE_CLASSES' : [
        'rest_framework.throttling.UserRateThrottle',
    ],
    'DEFAULT_THROTTLE_RATES' : {
        'user' : '10/day',     
                # Rate는 숫자/간격으로 간격은 첫글자만 사용. 
                # d,day,ddd 모두 Day, s,m,h,d가 가능 
    }
}

views.py
from rest_framework.throttling import AnonRateThrottle

class PostViewSet(ViewSet):
    throttle_classes = AnonRateThrottle

최대 호출 횟수 제한을 넘긴다면?

429 Too many Requests 응답. 예외 메시지에 API 활용이 가능한 시점을 알려준다.

1. PageNumberPagination : page/pagesize인자를 통한 페이징 처리
2. LimitoffsetPagination : offset/limit 인자를 통한 페이징 처리 (몇번째부터 몇번까지)

PageNumberPagination

settings.py
REST_FRAMEWORK = {
    "PAGE_SIZE" : 10,
    "DEFAULT_PAGINATION_CLASS": 'rest_framework.pagination.PageNumberPagination',
    } #Settings.py의 디폴트 전역설정 


from rest_framework.pagination import PageNumberPagination

class MyPageNumberPagination(PageNumberPagination):
    page_size = 20 #내가 원하는 사이즈로 지정. 

class APIViewWithpage(APIview):
    pagination_class = PageNumberPagination

class PostListAPIView(generics.ListAPIView):
    queryset = Post.obejects.all()

    def get_queryset(self):
        q = self.request.query_params.get('q', '')
        qs = super().get_queryset()
        if q:
            qs = qs.filter(titled__icontains=q)
        return qs

from rest_framework.filters import SearchFilter, OrderingFilter

class PostModelViewSet(viewsets.ModelViewSet):
    queryset = Post.objects.all()
    serializer_class = PostSerializer

    filter_backends = [SearchFilter, OrderingFilter]
    search_fields = ['message'] //문자열필드에만 가능.
    ordering_fields = ['id'] //지정하지않으면 Serializer의 모든 필드가 가능.
    ordering = ['id']

/myurl/?search=검색어&ordering=-pk /myurl/?search=검색어&ordering=-created_at, pk 등으로 사용가능.

Search_fields에서 사용 가능한 것들

DRF 공식문서

문자열 패턴

• "^" : Starts-with : ~로 시작
• '=' : Exact matched : 정확히 일치
• "@" : Full-Text Search : (단어/구문에 대한 검색.
• "$" : Regex search : 정규표현식

SD카드일때도 부팅이 될때가 있고 안될때가 있었는데

이때는..

전원을 확인한다.

USB-A의 경우 2.5A 이상을 출력하는경우가 드물다. 어댑터를 사용하지 않을경우 USB-C to C를 이용해서 충분한 출력을 제공하자.

SSD로 Cloning할때도 속도가 느렸는데, 전원어댑터를 제대로 끼우고 작동하니 빠름...... ㅂㄷㅂㄷ...

어떻게 읽어야할지 무언가 생소한 이 단어는, '샐러리'라고 보통 읽는듯 하다.

Why Celery?

Django에서는 View의 처리가 완료되어야 Render가 시작된다. 하지만 Heavy한 작업이 필요한 경우 View에서 작업이 지연된다면, 사용자가 응답받을때까지 시간이 지연된다. 따라서 비동기적으로 작업을 처리할 수 있는 방법이 필요하다.

What's role of Celery?

이러한 비동기적인 작업을 처리하는 방식에서, 작업(Job)을 만드는 발행자(Publisher)와 작업자(Worker)의 역활이 생긴다.

Django에서 Celery를 통해 작업(Job)을 발행하면, 이 작업은 작업대인 메시지 큐에 쌓인다. 이 메시지 큐로는 RabbitMQ 혹은 Redis가 사용된다.

작업자는 작업대(메시지큐)의 메시지(작업)을 소비하고, 메시지큐에 작업이 완료되었다는 표식을 남긴다. 이러한 과정을 도와주는 역활이 샐러리이다. 그중 작업대 역활을 하는 메시지 큐는 브로커라고 불린다.

왜 이번 프로젝트에서 Celery를 사용?

이번 프로젝트는 API 콜을 하는데, API의 응답속도가 빠르지 않았다. 따라서 정보를 DB에 저장해주어야 할 필요가 있었다. 비동기적 작업을 하지 않을경우 이러한 작업이 사용자에게 응답이 만들어 지기전 이루어져, 사용자의 응답은 느려지게된다.

따라서 아래의 프로세스를 통해 사용자경험을 극대화하려한다. Celery를 사용하지 않으면 View가 종료되기 전 5번이 실행되어야하며, 이러한 과정에서 DB의 병목 및 응답시간 증가가 해소될 것으로 보인다.

1.사용자 요청 2.사용자 요청에 대해 API Call 이전 보유여부 확인 2-1) 사용자 요청에 맞는 정보가 Cache에 있는가? 2-2) 사용자 요청에 맞는 정보가 DB에 있는가? 3.Caching/DB에 없으면 API Call을 통해 정보를 갱신한다. 4.받아온 정보를 재가공하여 사용자에게 전달한다. (View 종료) *5. 데이터가공, DB 저장 및 Cache를 위한 Celery 테스크를 발행한다. *

도움을 받은 글들 장고(Django)에서 셀러리(Celery) 사용하기 1편 Celery 공식 문서

Celery 설치하기

기존에는 Django와 결합된 별도의 패키지를 설치해야했지만, 이제는 Celery Stand-only로 설치가능하다.

pip install celery
pip install redis
pip install django-celery-beat
pip install django-celery-results 

django-celery-beat는 특정한 기간마다 작업이 실행하게하는 인터페이스,
django-celery-results는 작업결과를 알려줍니다. 

Celery 공식문서 - Django와 사용하기

Settings.py 설정

settings.py에서 아래 설정을 추가합니다.

INSTALLED_APPS = [
    ....
    'django_celery_beat',
    'django_celery_results',
    ...
]


# Celery
CELERY_ALWAYS_EAGER = True
CELERY_BROKER_URL = 'redis://localhost:6379'
CELERY_RESULT_BACKEND = 'redis://localhost:6379'
CELERY_ACCEPT_CONTENT = ['application/json']
CELERY_TAST_SERIALIZER = 'json'
CELERY_RESULT_SERIALIZER = 'json'
CELERY_TIMEZONE = 'Asia/Seoul'

celery.py 생성

Settings.py가 있는 프로젝트 (App이 아님!) 폴더에 생성해야합니다.

- proj/
  - manage.py
  - proj/ <이 폴더의 하위폴더!
    - __init__.py
    - settings.py
    - urls.py

import os

from celery import Celery

# Set the default Django settings module for the 'celery' program.
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'proj.settings')

app = Celery('proj')

# Using a string here means the worker doesn't have to serialize
# the configuration object to child processes.
# - namespace='CELERY' means all celery-related configuration keys
#   should have a `CELERY_` prefix.
app.config_from_object('django.conf:settings', namespace='CELERY')

# Load task modules from all registered Django apps.
app.autodiscover_tasks()


@app.task(bind=True, ignore_result=True)
def debug_task(self):
    print(f'Request: {self.request!r}')

proj/proj/__init__.py:
from .celery import app as celery_app

__all__ = ('celery_app',)

celery 구동 확인하기

celery -A proj worker -l INFO

manage.py가 있는 폴더에서 실행해야합니다. 그렇지 않는다면 Module 'proj' has no attribute 'celery' 같은 에러가 나옵니다.

잘 되었다면, python3 maange.py shell을 통해 날린 add 명령이 잘 동작해야합니다.

REDIS 확인하기

REDIS CLI를 통해 어떻게 명령이 들어갔는지 확인해봅시다. REDIS 설정하기를 통해 설정한 Docker Redis 기반입니다.

docker run -it --network redis-net --rm redis redis-cli -h django_redis

scan 0 
KEYS *을 사용하는 방법도 있지만, Redis는 Single-Thread 기반이여서, 재귀적으로 호출하는 scan0 를 사용하는것을 권장합니다. 

GET [내가 찾은 celery task 키]  

값이 잘 들어간 것을 확인할 수 있습니다.

ignore_result 사용하기

res = add.apply_async((1,2), ignore_result=True)
res.get()
res = add.apply_async((9,10))
res.get()

실제 실행결과는 아래와 같습니다.

Celery는 잘 실행을 했지만, 해당 결과값에 대해 저장을 하지 않으므로 값은 Redis에 남지 않습니다.

실제로 마지막에 실행한 0b89로 끝나는 Task만 Redis에 남아있습니다.

아래의 글을 참고하였습니다. [Redis] 도커(Docker)로 Redis 설치하기 [Django SEO] 더 빠르게! - Cache와 압축

redis 내부의 데이터를 보기위하여, redis-net 네트워크 구성

docker network create redis-net

redis 컨테이너 생성

docker run -d --name django_redis \
            --network redis-net \
            -p 6379:6379 \
            redis redis-server

docker run -d --name django_redis \
            -v /var/myredis:/usr/local/etc/redis \
            -v /var/myredis/data:/data \
            --network redis-net \
            -p 6379:6379 \
            redis redis-server \
            /usr/local/etc/redis/redis.conf #컨테이너 내부에서의 conf 주소.

/usr/local/etc/redis/redis.conf의 conf 파일로 Redis 설정을 당겨올 수 있다. redis 공식 conf 문서

cache로 사용하기위한 redis.conf

appendonly yes
appendfilename "redis_appendonly.aof"
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
stop-writes-on-bgsave-error no
maxmemory 500mb
maxmemory-policy allkeys-lru

AOF 방식으로 저장한다. [기본적으로 32bit일경우 maxmemory는 3GB로 설정되며, 64bit는 무한으로 설정된다.] (https://redis.io/docs/reference/eviction/)

redis CLi로 접속하기

docker run -it --network redis-net --rm redis redis-cli -h django_redis

django-redis 설치

pip install django-redis

Settings.py 설정

BACKEND': 'redis_cache.RedisCache'를 설정할 경우 django.core.cache.backends.base.InvalidCacheBackendError: Could not find backend 'redis_cache.RedisCache': No module named 'redis_cache' 에러가 뜨게 됩니다. django_redis 패키지 내의 모듈이여야합니다.

settings.py

CACHES = {
    'default': {
        'BACKEND': 'redis_cache.RedisCache',
        'LOCATION': 'localhost:6379',
    },
}

export POSTGRES_PASSWORD='my_password'
echo $POSTGRES_PASSWORD

/var/lib/postgresql/data (Local 머신의 Postgresql 저장소) 생성

Docker 배포

#! /bin/bash

docker run -d -p 5432:5432 \
    --name postgres \
    --restart=always \
    -v /var/lib/postgresql/data:/var/lib/postgresql/data \
    -e POSTGRES_PASSWORD=$POSTGRES_PASSWORD \
     postgres

Postgres 접속

docker exec --it postgres bash

psql 접속

psql -U postgres

DATABASE 생성

CREATE DATABASE [my_service];

\l 을 통해 my_service 생성을 확인할 수 있다.

USER 생성 및 권한부여

CREATE USER [my_user_name] WITH PASSWORD 'password'; 
-- 해당 'password'부분은 따옴표로 감싸져있어야한다. 
ALTER ROLE [my_user_name] set client_encoding to 'utf-8';
ALTER ROLE [my_user_name] set timezone to 'Asia/Seoul';
ALTER ROLE [my_user_name] SET default_transaction_isolation TO 'read committed'
grant all privileges on database [my_service] to [my_user_name];

--Postgresql 15부터 public schema에 대한 권한도 줘야하며, DB의 owner가 되어야한다. 
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO [my_user_name];
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO [my_user_name];

setttings.py 셋팅

settings.py
import os
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': [my_service],
        'USER': [my_user_name],
        'PASSWORD': os.environ.get('POSTGRES_PASSWORD'),
        'HOST' : `localhost`,
        'PORT' : '5432',
    }
}

postgresql 드라이버 설치

pip install psycopg2

permission denied for schema public 해결

python3 manage.py migrate

django.db.migrations.exceptions.MigrationSchemaMissing: Unable to create the django_migrations table (permission denied for schema public
LINE 1: CREATE TABLE "django_migrations" ("id" bigserial NOT NULL PR...

https://stackoverflow.com/questions/74110708/postgres-15-permission-denied-for-schema-public

이유는 DB의 모든 권한은 주었다고 하더라도, DB의 'Owner'가 되어야 CREATE를 할 수 있게 변경되었다고 한다. 따라서 DB의 주인을 바꿔준다.

ALTER DATABASE [my_service] OWNER TO [my_user];

잘 된다. 오예.

serializer.save

1.DB에 저장한 관련 Instance를 리턴, .valiated과 kwargs 사전에 합친 데이터를 DB에 저장하려고함.

form과는 다르게 .save할때 바로 업데이트 할때 kwarg를 넘기면 됨 .instance를 줬을때는 update, 아니면 create

DRF의 valitedor

UniqueValidator 모델에 unique.True를 지정하면 모델 index로 자동으로 지정되며, Validator도 자동으로 작동한다.

DRFㅇ의 validator는 다른 Validator를 사용한다. (Form의 Validator와 다르다!) validate_필드명으로 유효성 검사 수행가능. class 기반 ViewSet등에서 perform_create 등으로 재정의할 수 있다.

class PostViewSet(ModelViewSet):
    queryset = Post.objects.all()
    serializer_class = PostSerializer

    def perform_create(self, serializer):
        author = self.request.user
        ip = self.request.META['REMOTE_ADDR']
        serializer.save(author=author, ip=ip) 

        #form에서는 .save(commit=False)를 통해 임시저장을 한후, 
        #추가필드에 대해 지정한 후 commit했으나, 
        #serializer는 kwargs로 전달하여 바로 commit이 가능하다. 

console.group("안녕하세요 테스트");
console.log("hello");
    console.group("하위그룹으로 나눌수 있습니다");
        console.log("하위그룹의 Log");
    console.groupEnd();
console.error("error");
console.warn("Warning");
console.info("info");
console.groupEnd("안녕하세요 테스트끝"); #GroupEnd에 적힌 내용은 반영되않습니다.

IE11 디버거에서도 잘 동작한다.

django에서는 url에 자동으로 접미사를 붙여주는 FORCE_SCRIPT_NAME라는 설정이 있다.

#settings.py
FORCE_SCRIPT_NAME = '/app'

이러면...될...거같지만... 앱은 접속이 되지만 css, js가 안뜰꺼다. (특히 DRF같이 third Party App들의 Static들이 404가 뜰것이다. FORCE_SCRIPT_NAME의 구현은 보지 못했지만, urls.py의 middleware처럼 작용하는것으로 보인다. 따라서 따라서 root Url의 urlpatterns에 아래를 추가해준다.

#urls.py
urlpatterns += static(settings.MEDIA_URL,
                      document_root=settings.MEDIA_ROOT)
urlpatterns += static(settings.STATIC_URL,
                      document_root=settings.STATIC_ROOT)

python manage.py collectstatic

이후에는 정적파일을 모아준다. 만세!

nginx는 현재 Https 포워딩을 위한 ssl 인증서가 탑재되어있고, 80번 포트로 응답이 오면 https로 승격한다.

아래의 예시는 Django에서 /app루트라는 하위 디렉토리를 8000번 포트에 리다이렉트하는 코드이다.

upstream code-server {
        server 192.168.0.9:8888;
}

map $remote_addr $internal_request {
        default 0;
        192.168.0.9/24 1;
}

server {
        client_max_body_size 10M; #엡서버 업로드 용량 확정
        location / {
                proxy_pass http://192.168.0.9:8888;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection upgrade;
                proxy_set_header Host $host;
                proxy_set_header Accept-Encoding gzip;

        }

        location /app/ {

                rewrite ^/app(/.*)$ $1 break;

                proxy_pass http://192.168.0.9:8000;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection upgrade;
                proxy_set_header Host $host;
                proxy_set_header Accept-Encoding gzip;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_redirect default;


        }

            listen [::]:443 ssl ipv6only=on; # managed by Certbot
            listen 443 ssl; # managed by Certbot
            ssl_certificate /etc/letsencrypt/live/[my_site]/fullchain.pem; # managed by Certbot
            ssl_certificate_key /etc/letsencrypt/live/[my_site]/privkey.pem; # managed by Certbot
            include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
            ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}



server {
    if ($host = [my_site]) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80 ;
        listen [::]:80 ;
    server_name [my_site];
    return 404; # managed by Certbot


}

rewrite를 통해 /app/뒤의 파라미터를 추출하고, redirect하면서 해당 파라미터를 8000번에 서비스하고 있는 앱에 넘겨준다.