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 작성법일 수 있는데 기초 공부가 조금 부족하지 않았나 반성하게 되는 계기가 되었다.
---

    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    Permissions 0644 for 'amazonec2.pem' are too open.
    It is recommended that your private key files are NOT accessible by others.
    This private key will be ignored.
    bad permissions: ignore key: amazonec2.pem
    Permission denied (publickey).
    ```

- pem 파일에 너무 많은 권한이 부여되어 보안 상 AWS에서 거부한 것
---

/ # gitlab-runner exec shell build
Runtime platform                                    arch=amd64 os=linux pid=139 revision=66a723c3 version=17.5.0
FATAL: Command exec not found.

• gitlab-runner의 버전이 v17 이상인 경우 exec가 안되는 경우가 있다고 한다.

🛠 해결책

• gitlab-runner의 버전을 v16.10.0으로 내렸다.

    services:
      gitlab-runner:
        image: gitlab/gitlab-runner:v16.10.0
        container_name: gitlab_runner
        restart: always
        volumes:
          - ./gitlab-runner/config:/etc/gitlab-runner
          - /var/run/docker.sock:/var/run/docker.sock
          - ./entrypoint.sh:/entrypoint.sh
        environment:
          - RUNNER_NAME=my-runner
          - TZ=Asia/Seoul
          - CI_SERVER_URL=${CI_SERVER_URL}
          - REGISTRATION_TOKEN=${REGISTRATION_TOKEN}
          - RUNNER_EXECUTOR=${RUNNER_EXECUTOR}
        ports:
          - "9252:9252"
        entrypoint: ["tail", "-f", "dev/null"]
    ```

🛠 해결책

• 명령어 변경

    gitlab-runner register \
      --url "$CI_SERVER_URL"\
      --token "$REGISTRATION_TOKEN"\
      --listen-address ":9252" \
      --executor "docker"\
      --docker-image "alpine:latest"
    ```

- `config.toml`파일을 제거하고 다시 등록하니 403 발생 안됨

## 1. **`--registration-token`**

- *Runner를 등록(Register)**할 때 사용되는 **일회성 토큰**입니다.
- GitLab에서 새 Runner를 프로젝트, 그룹, 또는 인스턴스에 연결하기 위해 사용합니다.
- 이 토큰은 Runner를 등록한 뒤에는 더 이상 사용되지 않습니다.

- **프로젝트**나 **그룹**의 **Settings > CI/CD > Runners** 섹션에서 확인 가능합니다.
- 예: `Settings > CI/CD > Specific Runners`에서 `registration-token`으로 표시됩니다.

1. 기본 Entrypoint와 CMD:
   • Docker 이미지는 보통 ENTRYPOINT와 CMD를 지정할 수 있습니다.
   • ENTRYPOINT는 컨테이너가 실행될 때 무조건 실행되는 스크립트나 명령어를 정의합니다.
   • CMD는 ENTRYPOINT와 함께 전달될 추가 인자를 정의하거나, ENTRYPOINT가 없을 경우 기본 명령어로 사용됩니다.
2. 문제의 원인:
   • GitLab Runner의 Docker 이미지는 ENTRYPOINT로 기본 동작이 정의되어 있습니다. 특정 상황에서는 이 ENTRYPOINT 스크립트가 tail 명령어를 사용하거나 잘못된 실행 환경을 유발할 수 있습니다.
   • tail not found라는 오류는 컨테이너 내부에서 tail 명령어를 실행하려 했지만, tail이 설치되어 있지 않거나 경로 설정이 올바르지 않은 경우 발생합니다.
3. entrypoint: [""]의 효과:
   • entrypoint: [""]를 추가하면 Docker Compose는 기본 이미지를 사용할 때 지정된 ENTRYPOINT를 비활성화합니다.
   • 이로 인해 컨테이너가 실행될 때 CMD 또는 command에서 지정한 명령만 실행됩니다.

1. stdin_open: true: - Docker Compose에서 stdin_open: true를 설정하면 컨테이너의 표준 입력(stdin)을 열어줍니다. - 이는 Docker의 i 옵션과 동일하며, 컨테이너가 표준 입력을 지속적으로 대기하도록 만듭니다. 2. tty: true: - tty: true를 설정하면 컨테이너에 가상 터미널(tty)을 할당합니다. - 이는 Docker의 t 옵션과 동일하며, 인터랙티브 세션에서 터미널처럼 동작하게 만듭니다. 3. 결합된 효과: - 이 두 옵션을 함께 사용하면 컨테이너가 입력을 받을 수 있는 터미널 환경을 갖추게 되어, GitLab Runner가 사용자 입력을 정상적으로 처리할 수 있습니다. - 결과적으로 panic: EOF 오류가 발생하지 않고 필요한 설정 과정을 완료할 수 있습니다.