인스턴스 재시작 한 번에 빌드가 전부 깨졌다 (Docker 권한 트러블슈팅편)

이전 글: Oracle A1 "자리 없습니다" 에러 극복기 — 링크는 실제 발행 후 URL과 일치하는지 확인해주세요.

증상: Firebase App Distribution 배포가 전부 실패

Oracle A1 인스턴스를 재부팅할 일이 있었다. 재부팅 자체는 문제없이 끝났고, systemd가 러너들도 알아서 잘 띄웠다. 그런데 다음 배포에서 Firebase App Distribution으로 앱을 올리는 워크플로우가 줄줄이 실패하기 시작했다.

에러 로그를 까보니 Docker 관련 권한 에러였다. 러너 컨테이너 안에서 Docker 소켓(/var/run/docker.sock)에 접근하지 못하는 상황이었다.

원인: 재시작 후 docker 그룹 GID가 세션에 반영되지 않음

이 러너들은 컨테이너 내부에서 호스트의 Docker 소켓을 바인드 마운트해서 쓰는 구조다 (Docker-in-Docker 대신 소켓 공유 방식). 컨테이너 안의 러너 유저가 docker 그룹에 속해 있어야 소켓에 접근할 수 있는데, 문제는 이거였다.

컨테이너가 시작될 때 러너 유저를 docker 그룹에 넣는 로직이 있었는데
인스턴스 재시작 후 컨테이너가 재생성되는 과정에서 이 그룹 가입이 제대로 적용되지 않고 셸에 반영이 안 된 상태로 프로세스가 떠버림

즉, 유저는 docker 그룹에 "속해 있지만" 현재 실행 중인 셸/프로세스의 그룹 컨텍스트에는 반영이 안 된 상태였다.

해결: exec sg docker

리눅스에서 그룹 멤버십 변경은 현재 로그인 세션에는 즉시 반영되지 않는다. 새로 로그인하거나, 아니면 sg(switch group) 명령으로 새 그룹 컨텍스트의 셸을 띄워야 한다.

컨테이너 엔트리포인트 스크립트에 핵심 아이디어만 반영하면 다음과 같다.

# entrypoint.sh (핵심 로직만, 전문은 발행 전 직접 붙여넣을 것)

usermod -aG docker "$RUNNER_USER"

# 그룹 변경 사항을 현재 세션에 즉시 반영시켜 실행
exec sg docker -c "/opt/github-runner/run-runner.sh"

usermod -aG docker만 실행하고 바로 이어서 러너 스크립트를 실행하면, 그 프로세스는 여전히 예전 그룹 컨텍스트로 돈다. exec sg docker -c "..."로 감싸줘야 새 그룹이 적용된 상태로 프로세스가 교체된다.

적용 범위: 컨테이너 4개 + 소스 이미지

이 문제는 프로젝트별로 떠 있던 러너 컨테이너 전부에서 동일하게 발생했다.

github-runner-appler
github-runner-devy-workspace
github-runner-alterai
github-runner-pixaloom

네 컨테이너에 각각 핫픽스를 적용한 뒤, 근본적으로는 my-github-runner 이미지의 Dockerfile/엔트리포인트 자체를 고쳐서 다음 빌드부터는 이 문제가 재발하지 않도록 했다.

정리 & 교훈

Docker 소켓을 바인드 마운트해서 쓰는 컨테이너는 "그룹에 추가"와 "그룹이 적용된 상태로 실행"이 별개라는 걸 항상 염두에 둬야 한다
usermod -aG 이후 같은 세션에서 바로 권한을 쓰려면 exec sg <group> -c "..." 또는 재로그인이 필요
이런 종류의 버그는 평소엔 안 보이다가 인스턴스/컨테이너가 재생성되는 시점(재부팅, 재배포)에만 튀어나오는 특징이 있어서 재현이 까다롭다. 이번 기회에 컨테이너 재시작을 정기적으로 한 번씩 테스트해보는 습관을 들이기로 했다.

[핵심요약] Docker 그룹 권한, 재부팅마다 안 먹던 이유

LIST