카테고리: troubleshooting
"troubleshooting" 로 분류된 글.
TROUBLESHOOTINGpem
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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에서 거부한 것
---pem 키로 ssh 접근 시 권한 문제가 발생하는 경우
pem 키에 권한이 너무 열려 있어 AWS 가 ssh 접근을 거부했다. chmod 400 으로 읽기 전용으로 바꿨다.
TROUBLESHOOTINGdocker
/ # 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"]
```docker 안에서 gitlab-runner exec가 작동하지 않는 문제
gitlab-runner v17 이상에서 exec 가 동작하지 않는다. v16.10.0 으로 내려서 해결했다.
TROUBLESHOOTINGgitlab-runner
🛠 해결책
명령어 변경
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`으로 표시됩니다.gitlab-runner가 연결하려 할 때 403 error
register 는 되는데 Checking for jobs 에서 403. 예전에 등록해 둔 runner 들이 config.toml 에 남아 함께 실행되던 것이 원인이라 파일을 지우고 다시 등록했다.
TROUBLESHOOTINGgitlab-runner
- 기본 Entrypoint와 CMD:
- Docker 이미지는 보통
ENTRYPOINT와CMD를 지정할 수 있습니다. ENTRYPOINT는 컨테이너가 실행될 때 무조건 실행되는 스크립트나 명령어를 정의합니다.CMD는ENTRYPOINT와 함께 전달될 추가 인자를 정의하거나,ENTRYPOINT가 없을 경우 기본 명령어로 사용됩니다.
- Docker 이미지는 보통
- 문제의 원인:
- GitLab Runner의 Docker 이미지는
ENTRYPOINT로 기본 동작이 정의되어 있습니다. 특정 상황에서는 이ENTRYPOINT스크립트가tail명령어를 사용하거나 잘못된 실행 환경을 유발할 수 있습니다. tail not found라는 오류는 컨테이너 내부에서tail명령어를 실행하려 했지만,tail이 설치되어 있지 않거나 경로 설정이 올바르지 않은 경우 발생합니다.
- GitLab Runner의 Docker 이미지는
entrypoint: [""]의 효과:entrypoint: [""]를 추가하면 Docker Compose는 기본 이미지를 사용할 때 지정된ENTRYPOINT를 비활성화합니다.- 이로 인해 컨테이너가 실행될 때
CMD또는command에서 지정한 명령만 실행됩니다.
gitlab-runner container에서 Command not found가 발생하는 문제
gitlab-runner 이미지의 기본 ENTRYPOINT 가 끼어들어 sh·bash·tail 이 먹지 않았다. entrypoint: [""] 로 비활성화했다.
TROUBLESHOOTINGgitlab-runner
stdin_open: true: - Docker Compose에서stdin_open: true를 설정하면 컨테이너의 표준 입력(stdin)을 열어줍니다. - 이는 Docker의i옵션과 동일하며, 컨테이너가 표준 입력을 지속적으로 대기하도록 만듭니다. 2.tty: true: -tty: true를 설정하면 컨테이너에 가상 터미널(tty)을 할당합니다. - 이는 Docker의t옵션과 동일하며, 인터랙티브 세션에서 터미널처럼 동작하게 만듭니다. 3. 결합된 효과: - 이 두 옵션을 함께 사용하면 컨테이너가 입력을 받을 수 있는 터미널 환경을 갖추게 되어, GitLab Runner가 사용자 입력을 정상적으로 처리할 수 있습니다. - 결과적으로panic: EOF오류가 발생하지 않고 필요한 설정 과정을 완료할 수 있습니다.
gitlab-runner에서 panic: EOF [recovered]가 발생하는 문제
컨테이너 안에서 gitlab-runner register 가 입력을 받지 못해 panic: EOF 로 죽었다. compose 에 stdin_open 과 tty 를 켜 인터랙티브로 띄웠다.
TROUBLESHOOTINGgitlab-runner
- 버전을 v14으로 낮춰서 빌드를 진행하였고, 성공함
- 자료들을 찾아본 결과 mediatype문제는 거의 최신 버전을 제대로 지원하지 못해 생기는 문제인 것 같다. 버전을 바꿔서 시도해보자.
📚 Reference
gitlab-runner 상에서 docker 빌드가 안되는 문제
gitlab-runner 최신 이미지가 manifest mediatype 을 제대로 지원하지 못해 빌드가 깨졌다. 이미지 버전을 v14 로 낮춰 해결.
TROUBLESHOOTINGdocker
- 첫 시도는
docker-compose build --no-cache명령어를 통해 기존의 cache를 모두 날리고.dockerignore에node_modules를 추가한 뒤 다시 빌드를 진행- 하지만 똑같은 문제가 발생하였음
- 두 번째 시도로
node_modules와package-lock.json를 삭제하고 처음 시도했던 방식으로 빌드를 진행- 이 경우 정상적으로 빌드가 진행되었음
- 새로운 npm 환경을 가지고 왔을 때는
node_modules와package-lock.json를 삭제하고 다시 설치해보는 시도를 해봐야겠다. - 다른 곳에서 가지고 온 module 파일과 같은 환경 파일의 권한이 잘못 설정되어 있을 수 있다.
📚 Reference
docker 빌드 시 권한 문제로 install이 안되는 문제
docker-compose build 가 archive/tar: unknown file mode 로 실패. 다른 환경에서 가져온 node_modules 의 권한이 문제라 package-lock.json 과 함께 지우고 다시 설치했다.