Honsal's Dailylife

GitLab Runner for Windows에서 filename too long 문제 발생 Filename To Long… Electron 관련 프로젝트가 자동으로 배포되도록 파이프라인을 구성했다. 리눅스 쪽 러너에서는 문제가 없는데 Windows 러너쪽에서 계속 실패를 하여 로그를 확인해보니 filename too long 에러가 발생하고 있었다. 원인이 되는 경로는 node_modules/* 쪽이었는데 이걸 뭐 어떻게 건드릴 수 있는 상황이 아닌 건 둘째 치더라도, 현재 레지스트리에서 긴 파일 경로를 허용 해놓은 상태인데 이게 왜 뜨는지 알 수가 없었다. git config 원인은 엉뚱하게도 git 설정에 있었다. 발견했을 때는 황당했는데, 아무래도 내부적으로 git 관련 커맨드를 사용하는 게 아닌가 싶다. core.longpaths 이 증상을 해결하는 데 내가 사용한 방법은 core.longpaths 를 true 로 설정하는 것이다. git config --system core.longpaths true 위 명령어를 관리자 권한의 파워쉘에서 실행한 뒤 실패한 Job을 재가동하니 정상적으로 작동했다.

GitLab의 이름이 변경된 프로젝트로 계속 리다이렉트될 때 주의 들어가기 앞서, 이 글은 GitLab 호스팅이 아닌 GitLab 설치형 또는 옴니버스 기준으로 작성됨을 알린다. 리포지토리 이름 및 경로 변경 GitLab에서는 리포지토리의 이름을 바꾸거나 경로를 바꿀 수 있다. 이름만 바꾼다고 경로까지 바뀌지는 않고, 각각 따로 바꿀 수 있다. 리포지토리 이름 변경 리포지토리의 이름을 변경하려면 리포지토리의 Settings - General 로 이동하여 Naming, topics, avatar 섹션을 열고 Project Name 을 변경하면 된다. 리포지토리 이름 변경 리포지토리 경로 변경 하지만 리포지토리 이름을 변경한다고 해서 리포지토리 경로가 바뀌진 않는다. 예를 들어 기존에 https://honsal.io/honsals/HsStringTools 경로로 접근할 수 있었던 리포지토리의 이름을 HsStringTools 에서 HsStringToolsLegacy 로 변경한다고 해서 URL이 https://honsal.io/honsals/HsStringToolsLegacy 로 변경되지는 않는다는 말이다. 이걸 변경하려면 마찬가지로 Settings - General 로 이동하되 이번엔 Advanced 섹션에서 작업해야 한다. 경로 변경 경로 변경은 Change path 버튼을 누르면 적용된다. 리다이렉트 문제 내 생각에 대부분의 상황에서는 이렇게 하고 나서 아예 잊어버려도 아무런 문제가 없을 것이다. 심지어 기존 프로젝트 구성원에게 경로가 바뀌었으니 URL을 다르게 적용하라고 말하지 않아도 아무런 문제가 없을 것이다. 왜냐하면 GitLab이 (GitHub이 그렇듯이) 변경되기 전 경로를 자동으로 변경 후 URL로 리다이렉트 하기 때문이다. 문제는 리다이렉트하지 말아야 할 때 하지만 내 경우에는 이게 문제가 되었다. 이 GitLab 인스턴스는 ...

gitlab-runner에서 x509 Failed to Verify Certificate 문제 tls: failed to verify certificate: x509: certificate signed by unknown authority 이것저것 일을 처리하다가 Let’s Encrypt 일주일 갱신 제한에 걸려버려서 ZeroSSL을 사용하는 도중 발생한 문제이다. GitLab을 복원하고 암호화된 토큰을 리셋한 뒤 다시 러너를 등록하는 도중 위와 같은 메세지가 나타났다. 1 만약 self-signed 인증서를 사용하다가 발생한 문제라면 이 포스트가 아니라 공식 문서 를 확인하기 바란다. 이 글은 올바른 인증서를 사용했음에도 러너에서 위와 같은 메세지가 뜰 때의 해결 방법 이다. --tls-ca-file 옵션 해결 방법은 간단하다. gitlab-runner register 단계에서 --tls-ca-file 옵션을 사용해 인증서를 넘겨주면 된다. gitlab-runner register [ .. . ] --tls-ca-file < crt path > Linux 기반 러너는 register 명령을 실행할 때, Windows 기반 러너는 등록하고 실행 중에 뜬다. ↩︎

GitLab Runner 아티팩트 생성 불가 문제 파이프라인 아티팩트 생성 불가 문제 Errno::ENOENT (No such file or directory @ apply2files - /var/opt/gitlab/gitlab-rails/shared/artifacts/tmp/work/... bind-mount 를 WSL2 Ubuntu Distro 내부에서 윈도우 NTFS 시스템으로 옮긴 뒤부터 발생한 문제다. 파이프라인이 계속해서 실패하기에 로그를 살펴보니 위와 같은 문제가 발생하고 있었다. 위 오류 메세지를 살펴보면 즉 아티팩트를 업로드할 경로가 없다는 얘기인데… 실제로는 멀쩡히 잘 존재한다. 바인드 마운트 문제 우분투 디스트로 내부에서는 문제가 없다가 NTFS 파일 시스템으로 옮긴 뒤 문제가 발생하였으므로 바인드 문제라 추정하였다. 처음엔 어떻게든 ACL을 변경하면 되지 않을까 하였으나 그런 방법으로는 해결할 수 없었고, 결국 바인드 마운트 대신 볼륨 마운트 를 사용해 해결하기로 했다. 볼륨 마운트 services : gitlab : # ... volumes : - gitlab - data : /var/opt/gitlab volumes : gitlab-data : 위처럼 볼륨 마운트로 사용하니 정상적으로 작동한다. 주의 할 점은, 볼륨 마운트로 변환 시 기존 데이터가 전부 날아가게 된다. 따라서 꼭 백업을 먼저 진행하고 변환하기 바란다.

Docker WSL2에서 gitlab 컨테이너 사용 중 dev shm 용량 문제 발생 Docker/WSL2, GitLab Container 내 OS는 Windows 11 22H2이다. 윈도우 10 시절부터 Docker for Windows를 사용해왔고, WSL2가 나왔을 때 굉장한 성능 향상에 반해 바로 Hyper-V 기반에서 WSL2 기반으로 갈아탄 뒤 지금까지 쭉 써오고 있다. GitLab 컨테이너는 GitLab 을 직접 호스트할 수 있게 해주는 컨테이너이다. 깃랩은 깃헙처럼 자체 웹 사이트도 존재하지만 필요한 사람은 Self-hosted 인스턴스를 구축해 사용할 수 있는데, 리눅스에 직접 설치할 수도 있고 도커에 설치할 수도 있다. 나는 WSL에 직접 설치하려 했었으나 여러 이유로 실패하고 1 , 잠깐 다녔던 회사의 방식처럼 NAS를 하나 구비해서 쓸까 하다가 돈 낭비라는 생각이 들어 최종적으로 도커 컨테이너 방식에 안착했다. 로그 스팸, 접속 불안정 그렇게 몇 년간 잘 쓰다가 며칠 전 부터 갑자기 때때로 내 깃랩 사이트에 접속할 수 없는 문제가 발생했다. 특이 사항으로는 처음 하룻동안은 아예 예고없이 Docker for Windows 자체가 크래시 됐었다. 2 위 문제를 해결하는 과정에서 깃랩 컨테이너 뿐 아니라 Docker for Windows 자체를 재시작했고, 이 때문인지 그 날은 문제 없이 잘 사용했다. 엄청나게 많은 WARN/DEBUG 로그 스팸 그러던 중 오늘 다시 비슷한 증상이 발생했다. 이번엔 Docker for Windows가 꺼지거나 하진 않았으나, 사이트에 여러 문제가 발생했다. 일단 어떤 페이지이든지 한 번에 들어가지는 법이 없었다. 응답이 느린 것은 아니지만, 500 에러나 422 에러 등 여러 에러 페이지가 반복해서 출력되었고, 혹시나 하는 마음에 Push/Pull을 해봤으나 역시나 5번 시도해야 한 번 성공할까 말까 하는 수준이었다. 뭔가 문제가 있다고 생각한 나는 컨테이너 ...

참고: https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47922#note_117669498 백업과 복원은 항상 신중하게 본격적인 글을 적기에 앞서, 당연한 내용이지만 다시 한번 강조합니다. 어떠한 중요한 데이터를 백업하고 복원할 때는 항상 빠진게 없는지 신중하게 하시길 바랍니다. 방금 저는 GitLab CI/CD를 구현하려다가 일이 꼬여서 컨테이너를 날리고 Docker for Windows를 재설치해야만 했습니다. 그래서 docker-exec -it gitlab gitlab-backup backup 명령어로 백업을 진행한 뒤, 백업된 .tar 파일을 안전하게 보관한 뒤에 gitlab.rb 파일도 따로 보관했습니다. 그러나, 마음이 급해서 보고도 놓친 것이 있었습니다. gitlab-backup 명령어로 백업이 완료되면 친절하게 gitlab.rb 와 gitlab-secrets.json 은 사적인 파일이니 꼭 따로 백업하라고 알려줍니다. 저는 그걸 보고도 무시해버린 것이죠. 지금 와서 다시 생각하면 정말 어이가 없습니다. 그러니 여러분은 백업과 복원을 진행하실 때 항상 신중히, 빼먹는 것이 없도록 하시기 바랍니다. gitlab-secrets.json이 없으면 생기는 상황 위에 적었다시피, 저는 CI/CD 기능을 사용하기 위해 이러한 일련의 삽질을 하는 중이었습니다. 그래서 재설치도 하고 복원도 했으니 신나는 마음으로 설정을 위해 프로젝트 CI/CD 페이지에 들어갔죠. 하지만 보이는 것은 500 에러 화면 뿐이었습니다. 뭐지? 인스턴스가 시작되자마자 페이지에 들어와서 뭐가 로딩이 덜 됐나? 하는 어리석은 생각을 하며 새로고침을 계속 해봤으나 여전히 보이는 화면은 500… 여기서부터 뭔가 잘못됐다고 느끼기 시작했습니다. 갓-구글 생각보다 원인은 쉽게 찾을 수 있었습니다. 구글에 gitlab ci cd 500 이라고 검색하고 나온 상위 문서 몇 개 중에 backup/restore 관련 문제일 수 ...