Honsal's Dailylife

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 : 위처럼 볼륨 마운트로 사용하니 정상적으로 작동한다. 주의 할 점은, 볼륨 마운트로 변환 시 기존 데이터가 전부 날아가게 된다. 따라서 꼭 백업을 먼저 진행하고 변환하기 바란다.

WSL, Docker Desktop 관련 Distro의 크기 줄이기 1테라도 부족해 지금도 가난하지만 더 가난했던 어린 시절, 컴퓨터는 무조건 중고였던 때에는 40GB, 20GB, 심지어 4GB 하드 디스크를 사용했던 적도 있다. 특히 4GB짜리를 사용할 때엔 초등학교 4학년이었는데, 당시 재밌게 즐겼던 워록 이라는 FPS 게임을 설치하기 위해 크레이지 아케이드 , 서든어택 을 지우고 시스템 드라이브에서 필요 없다고 판단되는 폴더들을 최대한 지운 뒤 1 당시 시골 깡촌에서 ADSL 회선의 느려터진 초당 120KBps로 600MB 가까이 되는 워록 설치 파일을 받고, 또 그걸 설치하고 실행하고 하는 생 쇼를 했었다. 시간이 지나 현재 1테라 NVMe SSD 3개, 512GB SSD 한 개, 2테라 하드디스크 한 개를 합해 총 5.5TB를 굴리고 있는 입장에서 보면 말도 안 되는 짓거리이긴 하나, 4GB 하드를 사용한 기간은 길지 않았고 어차피 게임 한두개에 어도비 플래시 MX 또는 8, 포토샵, Visual Studio 2008을 설치하기만 했으면 됐기에 큰 문제는 아니었다. 그러나 이제는 문제가 된다. 5.5TB도 부족하기 때문이다. 심지어 어디 한 곳에 쏠려 있으면 분산이라도 시키겠는데, 용도별로 딱 딱 정리된 상태가 이렇다. 각 디스크에 많아야 200GB 여유가 있고, 평균 100GB정도 여유가 있다. 용량이 왜 이리 부족할까 근 10년간 쌓인 용량이기에 한 번은 도대체 뭐가 들어있어서 이렇게 용량이 부족할까 하여 TreeSize 툴로 분석을 해봤다. 당시 C드라이브는 일단 Visual Studio 2019 가 100기가바이트를 넘게 차지했고, Adobe, Cocos, Unity, Unreal, … 등과 NuGet package cache , ReSharper cache , WSL Ubuntu distro , Docker Distro , … 아무튼 많았다. 다른 드라이브는 주로 개발에 필요한 라이브러리들,...

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 관련 문제일 수 ...

작년 말, Gitlab 커뮤니티 에디션에 푹 빠지게 돼 이걸 어떻게 설치할까 고민하다가, Docker를 이 참에 한 번 써보자! 하고서 사용한지 벌써 1년이 넘었습니다. 윈도우 10 인사이더 프리뷰 버전까지 사용하면서 WSL 2 위에서 우분투를 돌리고, 해당 우분투 Distro를 엔진으로 도커를 돌리고, 그 도커 위에서 Gitlab을 돌리는, 얘기만 들으면 복잡하게 들릴 수도 있는 작업을 했습니다. 전체적으로 만족스럽지만, 1년 전이나 지금이나 자잘한 문제들, 예를 들어 Docker for Windows를 업데이트 하면 Gitlab 데이터가 전부 날라간다거나, vmmem이 하늘 높은 줄 모르고 치솟아 24기가바이트를 먹고 있다는 등의 문제가 발생하기도 합니다. 그리고 오늘도 어김없이 발생한 문제가 있습니다. 바로 아래와 같은 문제였습니다. 정확한 발생 원인을 찾을 수 없는 docker-credential-desktop.exe 관련 문제 사용 초기에만 해도 이런 문제가 발생하면 매우 당황하기도 하고 분노하기도 했지만, 이젠 그냥 아 그렇구나… 정도로 넘기고 해결 방법을 찾게 되더라고요. 다만, 바로 어제까지만 해도 잘 돌던 도커가 왜 docker-compose up 또는 docker-compose-down**을 사용하려고 하면 이런 문제가 발생하는지에 대한 원인은 여전히 불명입니다. 며칠 전, 윈도우 10 20H2 버전으로 업데이트가 있었고, 그보다 좀 전에는 약 1년간 괴롭혀오던 윈도우 자격 증명 관리자 문제를 해결한 적이 있었고, 또 좀 전에는 Docker for Windows 업데이트가 있었기 때문에, 정확히 무엇 때문에 발생한 것인지는 알 수 없습니다… 만 해결 방법 해결 방법은 존재합니다. 심지어 아주 쉽습니다. 위 이미지와 같은 문제가 발생했다면 분명 WSL 상의 리눅스 Distro에서 Docker for Windows를 사용해 도커를 돌리시고 계실 겁니다. 그렇다면 해당 Distro를 여시고, ~/.docker...