카테고리: troubleshooting

• 위 현상이 나타날 수 있는 이유
  • 토크나이저 설정 오류:
    • 문제: 사용하는 토크나이저가 예상과 다르게 token_type_ids를 생성하고 있을 수 있습니다. 예를 들어, 토크나이저가 질의-응답 모델처럼 두 개 이상의 세그먼트를 처리하도록 설정되어 있거나, 잘못된 매개변수가 사용되었을 수 있습니다.
    • 해결 방법:
      • 토크나이저의 설정과 사용법을 다시 확인합니다. 특히 encode_plus 또는 __call__ 메서드의 매개변수를 주의 깊게 살펴보아야 합니다.
      • 단일 문장 분류와 같은 작업에서는 token_type_ids가 실제로 필요하지 않으므로, 토크나이저에서 이를 생성하지 않도록 설정하거나, 생성된 값을 무시해야 합니다.
      • encodings['token_type_ids'] = torch.zeros_like(encodings['input_ids']) 이 코드를 통해 모든 토큰 id를 0으로 설정하면, 위 문제를 회피할 수 있습니다.
  • 입력 데이터 형태 오류:
    • 문제: 입력 데이터가 토크나이저가 예상하는 형태와 다를 수 있습니다. 예를 들어, 질의-응답 쌍과 같은 형태의 데이터가 단일 문장으로 처리되고 있을 수 있습니다.
    • 해결 방법:
      • 입력 데이터의 형태를 확인하고, 토크나이저가 데이터를 올바르게 처리할 수 있도록 데이터를 조정합니다.
      • 문제가 되는 특정 데이터의 형태를 확인하는 것이 중요합니다.
  • 모델 또는 라이브러리 문제:
    • 문제: 드물게 모델 자체 또는 사용하는 라이브러리에 오류가 있을 수 있습니다.
    • 해결 방법:
      • 사용하는 모델과 라이브러리의 버전을 확인하고, 최신 버전으로 업데이트하거나 다른 버전으로 시도해 봅니다.
      • 허깅페이스와 같은 유명한 모델은, 버전 업데이트가 빠른 편입니다. 가능한 최신버전을 이용하는게 좋습니다.
  • 패딩의 문제점:
    • 문제: 패딩 과정에서 일부 토큰 타입 ID가 원하지 않는 값으로 설정될 수 있습니다.
    • 해결 방법:
      • 패딩 설정과 방식을 확인하고, 필요에 따라 패딩 마스크를 사용하여 패딩된 토큰을 모델이 무시하도록 합니다.

    ...
    		stages {
            stage('Checkout Code') {
                steps {
                    // 내장 checkout 단계를 사용합니다. Jenkins가 모든 것을 처리하도록 합니다.
                    checkout([$class: 'GitSCM',
                              branches: [[name: '*/release']], // 또는 '*/main' 등
                              extensions: [],
                              userRemoteConfigs: [[credentialsId: 'gitlab-token',
                                                   url: 'gitlab-url']]])
                }
            }
    ...
    ```

...
dev-backend   |     connection.connect()
dev-backend   |     ~~~~~~~~~~~~~~~~~~^^
dev-backend   |   File "/usr/local/lib/python3.13/site-packages/redis/connection.py", line 363, in connect
dev-backend   |     raise ConnectionError(self._error_message(e))
dev-backend   | redis.exceptions.ConnectionError: Error 111 connecting to 127.0.0.1:6379. Connection refused.

• redis가 docker에 제대로 연결되지 않아 발생하는 문제
  • 127.0.0.1은 local에서 사용하는 것이므로 docker에 맞게 바꿔줄 필요가 있음

    ...
    CMD ["cp", "-r", "/app/dist", "/app/frontend_build"]
    ```

- volume mount를 할 때 local의 상태가 덮어 쓰기 된다는 것을 명심하자
---

# 📚 Reference

    ...
    build_backend:
      tags:
        - backend-runner
      script:
        - cd Backend
        - docker build -t $IMAGE_BACKEND:$TAG -f Dockerfile.dev .
        - docker push $IMAGE_BACKEND:$TAG
      only:
        - develop
        - master
    
    build_frontend:
      tags:
        - frontend-runner
      script:
        - cd Frontend
        - docker build -t $IMAGE_FRONTEND:$TAG -f Dockerfile.dev .
        - docker push $IMAGE_FRONTEND:$TAG
      only:
        - develop
        - master
    ...
    ```

• 분명 conda activate 이후 가상환경 안에서 pip install을 통해 모듈을 설치했음에도 불구하고 not found module이 발생하는 경우가 있다.

• pip의 경로를 확인해보면 conda 환경의 경로가 아님을 확인할 수 있다. 이 때문에 global 환경에 설치가 되어 가상환경 내에서 사용할 수 없었던 것

    $ which pip
    /home/user/.local/bin/pip
    ```

- pip를 현재 가상환경의 것으로 사용하도록 명시한다.

```bash
    python -m pip install <module_name>
    ```

# 📚 Reference

    server {
        listen 80;
        server_name momoso106.duckdns.org;
    
        location /.well-known/acme-challenge/ {
            root /var/www/certbot;
        }
    
        location / {
            return 301 https://$host$request_uri;
        }
    }
    
    server {
        listen 443 ssl; // 이게 문제임
        server_name momoso106.duckdns.org;
    
        location / {
            root /app/frontend/build;
            index index.html;
            try_files $uri /index.html;
        }
    
        location /api/ {
            proxy_pass http://backend:8000/;
            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 https;
        }
    
        location /openvidu/ {
            proxy_pass https://openvidu:4443/;
            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 https;
            proxy_ssl_verify off;
        }
    }
    
    ```

• webpack@4.47.0과 webpack-cli@5.1.4 간의 의존성 충돌 문제이다. webpack-cli@5.x.x는 webpack@5.x.x를 필요로 하지만, 현재 프로젝트에서는 webpack@4.47.0이 사용되고 있기 때문.

• 일단 webpack의 버전을 5로 올려줬다.

    npm install webpack@5 --save-dev
    ```

- 추후에 front 담당자와 확실히 정하면 될 거 같다.
---

# 📚 Reference

    ...
      frontend:
        build: ./Frontend
        environment:
          - CHOKIDAR_USEPOLLING=true  # 파일 변경 감지를 위한 설정
        ports:
          - "3000:3000"
        volumes:
          - ./Frontend:/app  # 로컬 파일 시스템을 컨테이너에 마운트
          - /app/node_modules  # 로컬의 node_modules가 container 내에 적용되지 않도록
        networks:
          - app_network
    ...
    ```

- 해결하기 까지 정말 오래 걸렸다. node_modules를 지우고 하더라고 한 번만 잘 되고 계속 안됐었는데 mount된 volume에 local 파일이 영향을 줘서 생기는 문제라고는 생각을 못했다.
- 어찌 보면 기본적인 compose 작성법일 수 있는데 기초 공부가 조금 부족하지 않았나 반성하게 되는 계기가 되었다.
---