요약하자면 제목과 같은 오류인데, python과 pipenv 버전 사이의 호환성 문제같아 보인다. python 3.7 기반의 가상환경을 만들었는데 오류에 3.8...이 나오길래 pipenv 버전과 파이썬 3.7 상호성에 문제가 있는지 공식문서를 확인해보았지만 문제는 없었다. 로컬과 가상환경의 Pipenv 버전을 각각 출력했더니 버전이 다르다. 로컬은 2023.10.20 인데 가상환경은 2023.11.15가 출력된다.

그래서 pip uninstall pipenv를 했더니 가상환경의 최신버전만 삭제되길래 직접 로컬버전의 경로를 입력해서 삭제하였다. 로컬과 가상환경의 pipenv버전을 통일시켰다.

우선. pipenv 경로확인 후 경로를 입력하여 아래와 같이 삭제.

which pipenv
<"pipenv 설치경로"> uninstall pipenv 

기존의 가상환경을 삭제하고 새로운 가상환경을 생성해서 접속한 후 pipenv lock을 처음과같이 시도했더니 같은 오류가 떴다. 로컬과 가상환경의 파이썬과 pipenv 버전은 동일하다. 캐쉬 문제도 아니다. Pipenv 2023.11.15와 파이썬 3.7의 호환 문제도 아니다. 마지막으로, 가상환경에서 pipenv와 파이썬의 경로를 출력해보았다. 출처 경로가 다르다는 것을 알 수 있었다. 오류에서 떴었던 3.8이 pipenv의 경로에 확인된다. 가상환경에 접속되어 있는 상태로 pipenv경로를 변경하고자 재설치를 하였다.

pip install pipenv

pipenv와 python의 경로가 '.../virtualenvs/..'로 아래와 같이 통일되었다. 그리고 pipenv install을 입력하였더니 오류없이 pipfile.lock이 생성되었다. 문제가 해결되었다.

Conclusion

가상환경에서의 Pipenv와 Python의 경로가 같아야한다. python 및 pipenv가 여러 개 설치되어 있지는 않은지, 어떤 버전을 사용하고 있는지 확인한다.

pipenv 공식문서

Python으로 작성된 패키지 소프트웨어를 설치 및 관리하는 패키지 관리 시스템

Pipenv

Python 언어를 위한 가상환경 관리 도구로서 가상환경을 만들고 관리한다. Pipfile을 이용하여 프로젝트에 필요한 패키지 관리.

1. pipenv 설치

pip install pipenv

2. 가상환경 만들기

pipenv --python <version number>        

3. 가상환경 실행

pipenv shell

4. 프로젝트의 패키지 설치 후 pipfile 및 pipfile.lock 생성.

1) requirements.txt가 존재하지 않는 경우. -> 가상환경에 직접 패키지 일일이 설치 후 requirements.txt를 생성. 그 다음, 바로 하단의 2) 명령어를 입력한다.

pipenv install <package name>
pip freeze > requirements.txt

2) requirements.txt가 이미 존재하는 경우. -> requirements.txt에 적혀있는 패키지를 가상환경에 설치한 후 pipfile과 pipfile.lock을 생성.** 위의 3번과 같이 가상환경을 실행할 경우 이 단계가 필요없이 가상환경에서 requirements.txt를 알아서 인식하여 자동으로 pipfile을 만들기도 한다. 이 같은 경우로 진행될 경우, "pipenv install" 및 "pipenv lock"을 입력하여 pipfile.lock만 생성해주면 끝난다. **

pipenv install -r requirements.txt

상단의 내용은 pipenv 생성과 초기 세팅방법이다. 나중에 패키지를 따로 더 설치할 시 pipenv.lock를 업데이트 해야 한다.

pipenv install <package name>
pipenv lock

React에서 face-api.js의 얼굴탐지 코드를 불러올 시 제목과 같은 에러가 뜬다. 에러를 일으키는 코드는 다음과 같다.

  //Load Face-detection models from './public/models.'
   const MODEL_URL = process.env.PUBLIC_URL + '/models';

      Promise.all([
        faceapi.nets.tinyFaceDetector.loadFromUri(MODEL_URL),
        faceapi.nets.faceLandmark68Net.loadFromUri(MODEL_URL),
        faceapi.nets.faceRecognitionNet.loadFromUri(MODEL_URL),
        faceapi.nets.faceExpressionNet.loadFromUri(MODEL_URL),
      ]).then(setModelsLoaded(true));
    }

Solution

위와같이 깃헙에서 face-api를 다운로드 받지말고 face-api 깃헙 url를 아래와 같이 직접 입력한다.

github의 '.json'파일의 내용을 URI로 불러올 시 링크의 수정이 필요하다.

e.g.

github.com/..../face-api.js/blob/master/weights/..json

위의 URI를 다음과 같이 수정한다. 하단의 솔루션 코드 참고.

githubusercontent.com/..../face-api.js/master/weights/..json

const detectionOptions = {
    withLandmarks: true,
    withDescriptors: true,
    minConfidence: 0.5,
    MODEL_URLS: {
      Mobilenetv1Model:
        "https://raw.githubusercontent.com/ml5js/ml5-data-and-models/main/models/faceapi/ssd_mobilenetv1_model-weights_manifest.json",
      FaceExpressionModel:
        "https://raw.githubusercontent.com/justadudewhohacks/face-api.js/master/weights/face_expression_model-weights_manifest.json",
      TinyFaceLandmarkModel:
        // "https://raw.githubusercontent.com/justadudewhohacks/face-api.js/master/weights/face_landmark_68_model-weights_manifest.json",
        "https://raw.githubusercontent.com/justadudewhohacks/face-api.js/master/weights/tiny_face_detector_model-weights_manifest.json",
      FaceLandmark68TinyNet:
        "https://raw.githubusercontent.com/justadudewhohacks/face-api.js/master/weights/face_landmark_68_model-weights_manifest.json",
      FaceRecognitionModel:
        "https://raw.githubusercontent.com/justadudewhohacks/face-api.js/master/weights/face_recognition_model-weights_manifest.json",
    },
  };

  useEffect(() => {
    const loadModels = async () => {
      try {
        await Promise.all([
          faceapi.nets.ssdMobilenetv1.loadFromUri(detectionOptions.MODEL_URLS.Mobilenetv1Model),
          faceapi.nets.tinyFaceDetector.loadFromUri(
            detectionOptions.MODEL_URLS.TinyFaceLandmarkModel
          ),
          faceapi.nets.faceLandmark68Net.loadFromUri(
            detectionOptions.MODEL_URLS.FaceLandmark68TinyNet
          ),
          faceapi.nets.faceRecognitionNet.loadFromUri(
            detectionOptions.MODEL_URLS.FaceRecognitionModel
          ),
          faceapi.nets.faceExpressionNet.loadFromUri(
            detectionOptions.MODEL_URLS.FaceExpressionModel
          ),
        ]);

만약 상단처럼 코드를 수정했음에도 같은 오류가 뜨는 경우가 있다. 한번에 여러개의 모델을 불러올 시 리소스 로드에 과부하가 걸려서 그런 듯 싶다. 이럴 땐 promise.all 대신 하단처럼 모델을 각각 불러오면 해결된다.

    // 'prommise.all' often makes loading stucked due to heavy resource load. try to load models one by one.
    await faceapi.nets.tinyFaceDetector.loadFromUri(
      detectionOptions.MODEL_URLS.TinyFaceLandmarkModel
    );
    // extracting data like face position, shape, and texture.
    await faceapi.nets.faceLandmark68Net.loadFromUri(
      detectionOptions.MODEL_URLS.FaceLandmark68TinyNet
    );
    // comparing facial features with existing data from the database.
    await faceapi.nets.faceRecognitionNet.loadFromUri(
      detectionOptions.MODEL_URLS.FaceRecognitionModel
    );
    await faceapi.nets.faceExpressionNet.loadFromUri(
      detectionOptions.MODEL_URLS.FaceExpressionModel
    );

References

face-api.js How to load face-api.js How to use face-api.js

도커 이미지를 만드는 데 다음과 같은 오류가 뜬다.:

Tons of lines of errors. But the below is a parts of them:
79.55 [pipenv.exceptions.InstallError]:       [end of output]
79.55 [pipenv.exceptions.InstallError]:   
79.55 [pipenv.exceptions.InstallError]:   note: This error originates from a subprocess, and is likely not a problem with pip.
79.55 [pipenv.exceptions.InstallError]:   ERROR: Failed building wheel for dlib
79.55 [pipenv.exceptions.InstallError]: ERROR: Could not build wheels for dlib, which is required to install pyproject.toml-based projects
79.55 ERROR: Couldn't install package: {}
79.55  Package installation failed...
79.56 /usr/local/lib/python3.7/subprocess.py:883: ResourceWarning: subprocess 50 is still running
79.56   ResourceWarning, source=self)
79.56 ResourceWarning: Enable tracemalloc to get the object allocation traceback
79.56 sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name=4 encoding='utf-8'>
79.56 ResourceWarning: Enable tracemalloc to get the object allocation traceback
79.56 sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name=7 encoding='utf-8'>
79.56 ResourceWarning: Enable tracemalloc to get the object allocation traceback
------
failed to solve: process "/bin/sh -c cd /app/Backend && pipenv install --deploy" did no

Troubleshooting steps:

오류 메시지에 dlib이 있는 걸 보니 dlib이 실행되기 위해서 도커 이미지 빌드 시에 반드시 설치해야 할 패키지가 있는 듯 싶다.

Solutions:

하단의 코드를 Dockerfile에 추가한다.

RUN apt-get update && \
    apt-get install -y \
    build-essential \
    cmake \
    libopenblas-dev \
    liblapack-dev \
    libx11-dev \
    libgtk-3-dev \
    python3-dev \
    python3-pip \
    python3-numpy \
    && rm -rf /var/lib/apt/lists/*

*리버스 프록시의 역할과 정적파일을 처리하는 웹 서버. *

리버스 프록시란? 외부 클라이언트에서 서버로 접근 시, 내부 서버로 접근할 수 있게 해주는 중개자 역할.

Problem

VM에 백엔드 서버가 돌아가고 있다. 백엔드 서버를 SSL화 하기 위하여 Nginx와 Letsencrypt를 사용하였다. nginx와 Letsencrypt를 VM에 설치하고 실행하였지만 포트 충돌이 발생하였다. 결국 nginx를 VM에 직접 설치하는 게 아닌 Nginx가 도커화 된 이미지를 VM에 직접 실행시키기로 하였다. Nginx 이미지가 Letsencrypt의 SSL 인증서를 인식하여 SSL 설정을 하기까지 제목과 같은 오류가 떴고 삽질과정과 해결방법은 다음과 같다:

Troubleshooting process & Solution

우선, VM의 네트워크 방화벽 설정에는 문제가 없다는 걸 확인 후 'nginx -t'로 syntax오류를 점검하였지만 정상이었다. 'error.log'를 출력하고자 하였지만 아무것도 뜨지 않았다. SSL 점검해주는 온라인 사이트에 주소를 입력한 결과, SSL 인증서를 nginx가 전혀 인식하지 못하는 걸 발견하였다. nginx 설정 코드와 SSL인증서 인식의 문제로 보인다. SSL Test tool

1. Letsencrypt SSL은 '/etc/letsencrypt/live/your_domain_name/'에 저장되어 있다. ls -la으로 symbolic link를 확인. 결국 파일 하나하나를 복붙하였다.

sudo cp /etc/letsencrypt/archive/your_domain_name/cert1.pem /etc/docker_certs/
sudo cp /etc/letsencrypt/archive/your_domain_name/privkey1.pem /etc/docker_certs/
sudo cp /etc/letsencrypt/archive/your_domain_name/chain1.pem /etc/docker_certs/
sudo cp /etc/letsencrypt/archive/your_domain_name/fullchain1.pem /etc/docker_certs/

2. 'docker-compose.yml'의 'Volumes:"에 위의 경로를 마운트한다. 도커 이미지 실행 시 도커가 컨테이너 내부에 디렉토리를 ':'의 오른쪽 경로와 같이 만들고 ':' 왼쪽의 경로에 존재하는 데이터를 도커가 만든 그 경로에 복붙하겠다는 뜻이다. 오른쪽의 경로는 Dockerfile에 설정해 놓은 경로이다. Docker 이미지가 실행될 때 만들어질 오른쪽의 경로에 '/etc/docker_certs'의 내용을 복사한다.

/etc/docker_certs:/etc/nginx/ssl

3. SSL파일이 위의 경로에 존재하는지 확인한다.

docker exec -it <nginx-container-name> ls -l /etc/docker_certs

4. nginx 설정과 관련된 코드를 의심한 만큼 nginx 컨테이너의 default.conf파일을 확인한다. nginx를 설치할 때 기본으로 설정되어 있는 코드 외에 SSL 코드는 없었다.

docker exec -it <nginx-container-name> cat /etc/nginx/conf.d/default.conf

5. default.conf 외의 ssl코드가 있을만한 .conf파일을 찾던 과정에 'nginx.conf'파일을 발견하였다. 'include...'에 있는 '../conf.d/' 디렉토리에 SSL코드가 들어있는지 확인한다.

include /etc/nginx/conf.d/*.conf;

6. SSL코드가 들어있는 파일이 없다. docker-compose.yml에 nginx 설정관련 코드의 볼륨 마운트가 없었기에 nginx container 내부에 SSL설정 코드가 존재하지 않다는 걸 깨달았다. Server블락이 들어있도록 미리 커스텀 해놓았던 VM 홈 디렉토리에 있는 'nginx.conf'를 'docker-compose.yml'에 추가하였다.

...
services:
  nginx:
    volumes:
     ./nginx.conf:/etc/nginx/nginx.conf

7. 컨테이너를 실행시켜 보니 './nginx.conf'파일에 'server' 블락이 존재해서는 안 된다고 나온다. 이를 해결하기 위하여 'server' 블락을 옮겨놓을 'tryon.conf' 파일을 VM 홈 디렉토리에 새로 만든다.'nginx.conf'파일의 'Server' 블락을 tryon.conf에 복사한다.

tryon.conf

server {
    # Redirect all HTTP traffic to HTTPS
    listen 80;
    server_name <your_domain_name_or_IP>;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name <your_domain_name_or_IP>;

    ssl_certificate /etc/nginx/ssl/fullchain1.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey1.pem;

    # Strong SSL Settings
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers off;
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions
    ssl_session_tickets off;

    # Add headers to serve security related headers
    add_header Strict-Transport-Security "max-age=63072000" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "DENY" always;
    add_header X-XSS-Protection "1; mode=block" always;
    # Forward all requests to Django application running in a Docker container named 'django' on port 8000.
    location / {
        # add_header 'Access-Control-Allow-Origin'.
        proxy_pass http://<"service name in docker-compose.yml">:8000; //One of services in docker-compose.yml
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    # The path inside the Nginx container to the static files.
    location /static/ {
        alias /usr/share/nginx/html/static/;
    }
    # The path inside the Nginx container to the media files. 
    location /media/ {
        alias /usr/share/nginx/html/media/;
    }
}

8. docker-compose.yml에 ssl관련 코드가 들어있는 tryon.conf를 볼륨 마운트한다. 아래 코드의 "마운트"를 쉽게 설명하자면 현재경로에 있는 tryon.conf 란 서브 디렉토리의 내용물을 컨테이너를 생성할 때 컨테이너의 내부경로인 '/etc/nginx/conf.d/tryon.conf'에 복사붙여넣기 하겠다는 말이다.

...
  nginx:
    volumes:
      - ./tryon.conf:/etc/nginx/conf.d/tryon.conf

이로서, Nginx를 설치할 때 기본으로 깔려있는 'nginx.conf'에 'include /etc/nginx/conf.d/*.conf'가 존재하기에 nginx 컨테이너를 실행할 시 '/etc/nginx/conf.d/tryon.conf'가 적용된다. 이로서 SSL인증 문제가 해결되었다..

Conclusion

도커 컨테이너 실행 시 볼륨 마운트는 컨테이너 내부구조 구축과 그에 따른 SSL인증을 위해서도 아주 중요하다.

도커 이미지를 실행 후 docker logs 를 출력하였더니 제목과 같은 에러가 뜬다. 'docker-compose.yml', Dockerfile은 다음과 같다.

Dockerfile

 ...
  services:
    django:
     volumes:
      - .:/app
      - tryon_static_volume:/app/static
      - tryon_media_volume:/app/media
    nginx:
     volumes:
      - tryon_static_volume:/app/static
      - tryon_media_volume:/app/media
      - /etc/docker_certs:/etc/nginx/ssl
      ...

docker-compose.yml

...
# Set the working directory inside the Django container.
WORKDIR /app

# Install system dependencies
RUN apt-get update
..
# Copy the requirements file to the container
COPY requirements.txt /app/

# Install Python dependencies
RUN pip install -r requirements.txt

# Copy the Django application files to the container
COPY . /app/

# Set the working directory to where manage.py is located
WORKDIR /app/Backend/tryon

# Set a default port in case one isn't provided
ENV PORT=8000
# Collect static files
RUN python manage.py collectstatic --noinput

# Document that the service listens on port 8000.
EXPOSE 8000  

# Start the application
CMD gunicorn tryon.wsgi:application --bind 0.0.0.0:$PORT

Troubleshooting steps

settings.py의 'INSTALLED_APPS' 부분에 장고 프로젝트 이름이 동일하게 설정되어 있는지 확인하였다. 또한, 'requirements.txt' 대신 'pipfile'을 사용하여 파이썬 의존성을 설치하였다. 문제를 해결하는 도중 발생한 별개의 오류에 대해선 아래의 링크에 정리를 해 놓았다. Dlib error

Solution

Python이 장고 프로젝트를 인식 못하는 문제이다. Dockerfile 을 아래와 같이 수정하였다. 장고 프로젝트 파일을 컨테이너에 복사하고 장고 프로젝트 파일의 위치를 알려주기 위하여 PYTHONPATH 변수를 아래와 같이 추가하였다. 또한 'Pipenv run..'을 사용하여 이 변수가 적용된 환경에서 프로젝트를 실행하도록 하였다.

docker-compose.yml

 ...
FROM python:3.7-slim

# Install Pipenv
RUN pip install pipenv

# Copy Pipfile and Pipfile.lock
COPY Backend/Pipfile /app/Backend/
COPY Backend/Pipfile.lock /app/Backend/

# Install Python dependencies from Pipfile into the container's environment.
# '--deploy' ensures that 'Pipfile.lock' is up to date.
RUN cd /app/Backend && pipenv install --deploy

# Copy the Django application files to the container
COPY Backend/tryon /app/Backend/tryon

# Set environment variables so that Python can find Django project.
# When 'pipenv run..' starts app as below, the variables should be already set and applied. 
ENV PORT=8000 \
    PYTHONPATH=/app/Backend/tryon \
    DJANGO_SETTINGS_MODULE=tryon.settings

# Document that the service listens on port 8000.
EXPOSE 8000  

# Set the working directory to where manage.py is located
# WORKDIR /app/Backend/tryon

# Collect static files
RUN cd /app/Backend/tryon && pipenv run python manage.py collectstatic --noinput

# Start the application. Ensure that the application is accessible from outside the container.
# CMD is executed once container is started from the resulting image.
# 'Pipenv run' runs the command in the context of the environment set up by 'pipenv.'
CMD cd /app/Backend/tryon && pipenv run gunicorn tryon.wsgi:application --bind 0.0.0.0:$PORT

Dockerfile

...
 volumes:
      - .:/app
      # The path on the right is set based on where Django files are copied to the container, for which Dockerfile is reponsible.
      - tryon_static_volume:/app/Backend/tryon/static
      - tryon_media_volume:/app/Backend/tryon/media

Follow-Up Actions

워낙 장고 프로젝트 디렉토리가 복잡하다 보니 구조가 헷갈려서 경로를 잘못 입력하곤 했었다. 다음부터는 프로젝트 디렉토리 구조를 미리 문서화 해야겠다.

도커란?

애플리케이션과 그에 필요한 모든 것(e.g.환경설정, 라이브러리, 시스템 툴, 등) 을 패키징하여 어느 환경이든 개발, 배포 및 구동을 쉽게 하도록 도와주는 툴.

Docker 실행하기(아래의 2가지 방법 모두 Dockerfile은 필수)

1. 도커 이미지 만들기 ("."는 현재 위치한 디렉토리 위치에서 도커파일을 찾게 한다.)

*1) * Dockerfile만을 이용한 대표적인 이미지 빌드 방식.

docker build -f <도커파일 이름> -t <원하는 도커 이미지 이름> .

• Dockerfile 예시(예시 백엔드는 장고):

  FROM python:3.7-slim
  

Set the working directory inside the container.

WORKDIR /app

Install system dependencies

RUN apt-get update RUN apt install... RUN apt-get install -y cmake

Install Pipenv.

RUN pip install pipenv

Copy Pipfile and Pipfile.lock

COPY.. /app/Backend/

RUN .....

Document that the service listens on port 8000.

EXPOSE 8000

Set the working directory to where manage.py is located

WORKDIR /app/Backend/..

Collect static files

RUN cd /app/Backend/..&& pipenv run python manage.py collectstatic --noinput

Set a default port in case one isn't provided

ENV PORT=8000

Start the application. Ensure that the application is accessible from outside the container.

CMD cd /app/Backend/..&& pipenv run gunicorn ..wsgi:application --bind 0.0.0.0:$PORT

**2) docker-compose.yml** 을 만들어 아래의 예시와 같이 어떤 서비스를 어떻게 빌드할 지 코드를 짠 후 아래의 명령어를 입력한다. 다수의 컨테이너를 만들경우 추천.

docker-compose build <docker-compose.yml의 services 중 하나>

+ docker-compose.yml 예시:

version: '3' services: django: build: context: . dockerfile: Dockerfile image: ...... expose: - "8000" ports: - "8000:8000" volumes: # mount 'tryon_..' from this project to '/app/..' inside the container. The work directory of container is defined Dockerfile. - tryon_static_volume:/app/.. - tryon_media_volume:/app/.. # environment: # - PYTHONPATH=/app/Backend # - DJANGO_SETTINGS_MODULE=project.project.settings nginx: build: context: . dockerfile: Dockerfile-nginx image: ..... ports: - "80:80" - "443:443" volumes: - ...static_volume:/usr/share/nginx/html/static - ...media_volume:/usr/share/nginx/html/media .... volumes: tryon_static_volume: tryon_media_volume:

위의 docker-compose.yml의 경우 'Volumes'를 설정해야 컨테이너의 파일 시스템을 별개의 컨테이너 및 로컬 호스트 간에 공유할 수 있다.

#### 2. 도커 이미지 태그하기

docker tag <위에서 만든 이미지 이름> "gcr.io/<"project ID">/<"태그하고자 하는 도커 이미지 이름">:<"이미지 식별 버전">

<br/>

#### 3. VM에 SSH 접속.
#### 4. Google cloud의 Container registry에 있는 도커 이미지를 가져온다.

docker pull gcr.io/<"project ID">/<"도커 이미지 이름">:<"이미지 식별 버전">

#### 5. 도커 이미지 실행시키기.
**1) Dockerfile 만을 이용하여 빌드된 이미지일 경우**

docker run -d --name <"원하는 도커 컨테이너 이름"> gcr.io/<"project ID">/<"도커 이미지 이름">:<"이미지 식별 버전">

**2) docker-compose.yml, Dockerfile을 이용하여 만들어진 이미지일 경우**

docker-compose up -d

**OR**

docker-compose up <docker-compose.yml에 짜여진 서비스 이름> -d

docker-compose up --build -d

#### 6. 실행되고 있는 도커 컨테이너 중단.

docker stop < 컨테이너 이름>

docker-compose down

<br/>

---
### 그 외 Docker 명령어  
#### 6. 컨테이너 로그 확인

docker logs

#### 7. 현재 돌아가고 있는 컨테이너 프로세스 리스트의 상태 출력

docker ps

#### 8. 오류로 인해 돌아가지 않는 컨테이너 리스트 출력

docker ps -a

#### 7. 컨데이터에 접속하기. 

docker exec -it /bin/sh ```

Django 서버와 Nginx를 도커 컨데이너화 하여 GCE(Google Compute Engine) VM에 호스팅 하였다. 그러나 VM 외부 IP주소로 서버 접속이 불가하였다.

Troubleshooting & Solution

1. Docker 컨테이너가 돌아가고 있는 지 확인.

 docker ps

2. 도커 로그 확인.

docker logs <  도커 컨테이너 이름 >

3 nginx.conf 코드 재검토 -> syntax error가 없음을 확인.

 nginx -t

4 Firewall의 HTTP/HTTPS 포트가 Docker 컨테이너의 포트와 같은지 확인.

5 Firewall HTTP와 도커의 포트를 8000에서 80으로 변경.

6 "Cannot be reached" 오류는 사라졌지만 "Welcome to Nginx" 메시지만 뜸.

7 장고와 Nginx 도커 컨데이너가 같은 네트워크 상에 있음을 확인.

 - docker network ls
 - docker network inspect < network name >

-> "bridge"라는 같은 네트워크 상에 존재함을 확인.

8. VM의 도커 컨테이너 내부에 접속.

docker exec -it < container name > /bin/bash

9. "/etc/nginx/conf.d/" 폴더를 확인한 결과 내가 만든 "nginx.conf" 파일내용이 보이지 않음. "default.conf"라는 기본 설정된 코드만 보인다. "nginx.conf" 파일이 제대로 적용되지 않은 듯 하다.

10. "default.conf"를 다른 이름으로 수정하고 "nginx.conf"의 코드를 새로 만든 "default.conf"에 복사 후 붙여넣기 하였다.

11. "nginx -t"로 syntax error 수정 후 새로고침을 함으로서 문제를 해결하였다.

nginx -s reload

Conclusion

"Welcome to Nginx" 메시지가 화면에 보일 시 본인이 커스텀화 해놓은 nginx 설정 파일이 기본으로 nginx에 내재되어 있는 "default.conf"를 오버라이딩 하지 못함으로서 일어나는 문제다. -> "default.conf"를 수정. "Cannot be reached" 로 접속이 아예 불가할 시 네트워크 설정을 재검토하자.

리포지토리를 처음 만들 경우

1. 로컬 리포지토리를 만들 폴더에 터미널로 접속해서 다음을 입력한다.**

  >  git init

2. 깃헙 프로필에서 1번의 폴더와 연동할 리포지토리를 만들고 (만들 시 기본적인 .gitignore, README.md도 자동생성되게 한다) 주소를 복사한다.
3. 2번과 연동하기 위하여 터미널에 다음을 입력한다.

git remote add origin <2번에서 복사한 깃헙 프로필 리포지토리 주소> 텍스트

*4. 2번에서 만든 파일에 대한 정보를(변경사항) 받아온다. *

git fetch origin

5. 2번에서 발생한 변경사항을 로컬 리포지토리에 입력 및 동기화한다.

git merge origin/main

보통 fetch 및 merge 대신 pull를 많이 사용하지만 pull를 사용할 시 오류가 너무 자주 발생하였다. 대안책으로 merge를 사용하면 오류가 없다. 위의 merge대신 rebase를 해도된다. 'merge'대신 'rebase'를 입력하면 된다. 깃헙의 기본 작동방식인 merge에 익숙하기에 merge를 택했다.

만약 로컬 리포지토리에 변경사항(파일 수정, 추가, 삭제 등)이 전혀 없었다면 이대로 끝내면 된다. 하지만 난 2번에서 만든 파일들 외에도 로컬 리포지토리에서 파일수정을 하였기에 아래의 단계가 불가피했다. *로컬 리포지토리에서의 수정사항을 리모트 저장소 (편의 상 리포지토리를 리포 및 저장소라고 하겠다)에 푸쉬 즉, 동기화해야 하기 때문이다. *

** 6. 로컬 저장소의 수정 된 코드를 리모트 저장소에 푸쉬.**

git add . git commit -m "your commit message here" (변경사항 내용) git push origin main

로컬과 리모트 저장소의 동기화가 요류없이 완료되었다. 위의 단계를 모두 완료한 이후 추후 로컬 저장소만 수정을 하고 리모트는 수정된 사항이 없을 때 6번만 로컬 저장소에서 시행하면 끝이다. 이 경우가 아닌, 리모트와 로컬 저장소를 둘 다 수정하게 될 시 다음을 실행한다.

생성 및 동기화 되어있는 로컬/리모트 저장소를 수정했을 경우

위의 4번을 실행한 후 다음을 터미널에 입력한다.

git stash

'stash' 없이 git add와 commit및 merge를 하게 되면 5번을 실행 시 merge오류가 발생한다. git은 리모트와 로컬 저장소의 코드가 동일하다는 전제하에 작동하기 때문이다. stash는 로컬 저장소의 변경사항을 바로 적용하지 않고 보류하여 따로 저장해둔다. 위의 명령어를 입력하면 git status 에 출력되어 있었던 변경사항이 사라진다. stash로 임시저장 하였기 때문이다.

git stash pop

다음으로, 위의 git add 부터 git push 코드까지 입력한다. 리모트 저장소의 수정내용은 로컬에 머지가 되고 로컬의 수정내용은 리모트 저장소에 푸쉬가 완료된다. 앞서 말했듯이 로컬과 리모트 저장소의 커밋 진행현황이 같아야 리모트 저장소로 푸쉬가 가능하니 반드시 리모트 저장소의 변경내용을 우선적으로 머지한 뒤 푸쉬를 해야한다. 다음의 명령어를 터미널에 입력하면 커밋 진행 현황을 알 수 있다. 두 저장소의 커밋현황을 비교해보면 두 저장소가 동기화가 잘 되고 있는지 알 수 있다.

로컬 저장소 커밋 진행현황

git log --oneline

리모트 저장소 커밋 진행현황

git log --oneline origin/main

Package를 설치하다보면 반드시 설치 중 다양한 오류를 마주치게 된다. 예를 들어, 'agoliasearch,' 'firebase-admin'을 설치하는 도중에 기존에 있던 패키지와의 충돌 및 버전 문제로 설치를 더 이상 진행할 수 없다는 오류 몇 가지를 겪게 된다:

*오류 1 *

'Cannot resolve <'package name'>

오류 2(대표적인 오류)

다수의 패키지 호환 오류와 함께 '--legacy-peer-deps' 및 'npm audit fix'를 권장. 이 두 가지 장애를 연속으로 마주쳤고 아래와 같은 시도를 했었다.

Solution

1. 콘솔에 나온대로 시행한다. 예를 들어, 콘솔에서 --legacy-peer-deps을 권장할 시,

npm install <'package name'> --legacy-peer-deps

이외에 만약, 'npm audit fix'를 실행해보라고 권장한다면 그대로 입력한다. 그래도 해결이 안될 시 다음을 시행한다.

2. Clear the npm cache (해결이 안될 시 3번 시행):

   npm cache clean --force

3. Delete node_modules and package-lock.json:

rm -rf node_modules package-lock.json

4. Install the dependencies (3번 이후 반드시 실행):

npm install

5. 수동으로 직접 패키지 설치 (위 방법으로 해결이 안될 시 시행)

package.json에 리스트 된 패키지 버전을 확인하며 그 버전에 맞는 패키지를 직접 수동으로 설치한다. (e.g. npm install <'package name'>@<'version'>

Expo 프로젝트를 퍼블리쉬 하기 위해서 서버 주소를 로컬에서 pythonanywhere 서버로 이전하려고 한다.

ATTEMPTS:

react-native-dotenv 패키지를 설치하여 dotenv를 사용하려 하였더니 아래와 같은 에러가 뜬다.

SOLUTION:

dotenv를 사용하려면 Node.js에 내재된 모듈이 필요한데 Expo에는 내재되어 있지 않기 때문에 에러가 뜬다. React Native의 전역변수인 _ _DEV _ _를 아래와 같이 사용하면 해결된다.

*1. 프로젝트의 최상위 폴더(Root directory)에 config.js 파일을 만든다. * config.js

// A server url will be allocated depending on whether you are in dev or production mode.
const SERVER_URL = __DEV__ ? 'http://localhost:8000/' : 'https://<your-username>.pythonanywhere.com/';
export { SERVER_URL };

** 2. 로컬서버 주소를 아래와 같이 대체한다. 예를 들어 로컬서버 주소가 http://localhost:8000/buy 라고 가정하면 이를 SERVER_URL + 'buy'로 대체하면 된다.**

import { SERVER_URL } from './config';

// Replace Local server address as below.
fetch(SERVER_URL + 'endpoint');

Cookie

브라우저가 서버로부터 받은 쿠키(사용자 정보)를 사용자의 웹 부라우저에 저장함. 웹 브라우저가 종료되면 삭제되지만, 만료 날짜를 정해둘 시 만료일에 삭제된다.

Session

서버로부터 응답받은 세션 ID가 담긴 쿠키를 브라우저에 저장하고 이 쿠키를 통해 웹 서버간의 커뮤니케이션을 실행함(세션 ID는 서버에 저장된 사용자의 정보에 접근하기 위한 도구). 웹 브라우저가 종료되면 세션 쿠키는 삭제된다.

쿠키 생성 및 쿠키 유무 확인

views.py

def checkCookie(request):
    mycookie_value = request.COOKIES.get('mycookie')
    if mycookie_value == 'cookievalue':
        # Cookie exists and has the expected value
    else:
        # Cookie is not set or has a different value

def set_cookie(request):
    response = HttpResponse("Cookie Set!")
    response.set_cookie('mycookie', 'cookie_value')
    return response

쿠키 삭제

views.py

def deleteCookie(request):
    response = HttpResponse("Cookie Deleted!")
    response.delete_cookie('mycookie')
    return response

위의 함수를 실행시키면 서버에 있는 쿠키가 삭제되는데, *사용자의 부라우저에 있는 쿠키도 아래와 같이 삭제를 해야한다. *

client-side

  function clearCookie(name) {
    document.cookie = name + '=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;';
  }

Reference https://www.pythontutorial.net/django-tutorial/django-cookies/

Attempts:

파이썬을 재설치 및 장고 프로젝트의 settings.py에서 CORS_ALLOWED_ORIGINS 및 ALLOWED_HOSTS 에 해당 서버주소를 넣었지만 문제는 지속되었다.

Solution:

Pythonanywhere 공식사이트 https://blog.devgenius.io/django-tutorial-deploy-a-django-app-to-pythonanywhere-for-free-269ec4e7b263)

Things to remember:

• 프로젝트 폴더는 ** /home/<"username">/ ** 경로에 저장한다. (wsgi.py 참고)
• 가상환경은 /home/<"username">/.virtualenv/ 경로에 저장한다.

bash에서 zsh로 전환한 후 성공적으로 ohmyzsh를 설치하였다. 몇일 후 vscode에서 업데이트 여부를 묻길래 omz update를 실행하였다. 그 이후로 vscode에서 terminal 를 사용 시 반응속도가 현저히 느렸다. (로컬에 설치된 Iterm은 속도에 문제가 없다.)

Attempts:

ohmyzsh 재설치를 하였지만 개선이 없어 구글검색으로 얻은 몇가지 해결책을 실행했다.

Solution:

1. 터미널 로그 삭제

sudo rm -rf /private/var/log/asl/*.asl

2. vscode의 settings.json에 아래의 코드 삽입.

  "terminal.integrated.allowChords": false,
  "terminal.integrated.drawBoldTextInBrightColors": false,
  "terminal.integrated.experimentalLinkProvider": false,
  "terminal.integrated.rendererType": "auto"

아래와 같이 실행한 후 vscode 프로그램 창만 닫았다가 다시 열었을 땐 문제가 해결되지 않았다.
하지만, vscode를 완전히 종료(quit)한 후 Terminal 창을 새로 열었을 땐 속도가 대단히 빨라진 것을 체감하였다.

useEffect(() => {
        const getPopWindow = async () => {
            if (!popup) {
                try {
                    await navigator.mediaDevices.getUserMedia({ video: true }).then(
                        function success(stream) {

                        })
                        .catch(function (error) {
                            console.log(error);
                        }
                        )
                } catch (error) { console.log(error) }
            }
        }
        getPopWindow()
    }, [popup])

위와 같은 코드를 실행하였을 때 제목과 같은 에러 메시지가 뜬다.

Attempts:

내가 시도해 본 것은 다음과 같지만 오류는 그대로였다.

• chrome://flags -> Insecure origins treated as secure 란에 해당 웹 주소 입력하기.
• https로 웹 접속.
• 브라우저 캐시 삭제

Solution:

await navigator.mediaDevices.getUserMedia({ video: true })...

위 코드블락의 mediaDevices 부분을 삭제하고 다시 썼더니 오류가 해결되었다. 아마 코드 에디터 내의 캐시 문제가 아니였을까 싶다.