docker 스토리지 마이그레이션 문제 기록(docker root)

불과 며칠 전, 서버 중 하나에서 도커 스토리지(도커가 모든 컨테이너와 이미지 파일을 저장하는 디렉터리)를 별도의 섹션으로 옮기기로 결정했습니다.
용량이 더 커졌습니다. 그 일은 사소한 것처럼 보였고 문제를 예고하지도 않았습니다...

시작하자:

1. 애플리케이션의 모든 컨테이너를 중지하고 종료합니다.

docker-compose down

컨테이너가 많고 구성이 서로 다른 경우 다음을 수행할 수 있습니다.

docker rm -f $(docker ps -q)

2. docker 데몬을 중지합니다.

systemctl stop docker

3. 디렉터리를 원하는 위치로 이동합니다.

cp -r /var/lib/docker /docker/data/storage

4. docker 데몬에게 새 디렉터리를 찾도록 지시합니다. 여러 가지 옵션이 있습니다. -g 플래그를 사용하여 데몬을 새 경로로 지정하거나 우리가 사용한 systemd 구성을 사용합니다. 또는 심볼릭 링크. 이에 대해 너무 자세히 설명하지는 않겠습니다. 인터넷에 나와 있습니다. 가득한 도커 루트를 새 위치로 이동하는 방법에 대한 매뉴얼입니다.

5. docker 데몬을 시작하고 올바른 위치에 있는지 확인합니다.

systemctl status docker

출력 라인 중 하나에서 다음을 확인해야 합니다.

├─19493 /usr/bin/dockerd --data-root=/docker/data/storage

옵션이 데몬에 전달되었는지 확인했으니 이제 적용되었는지 확인해 보겠습니다. (감사합니다. 잉크비지터68sl)!

docker info | awk '/Root Dir/ {print $NF}' 

6. 애플리케이션을 시작해 보겠습니다.

docker-compose up -d

7. 확인

그리고 여기서 재미가 시작됩니다. DBMS, MQ, 모든 것이 괜찮습니다! 데이터베이스는 손상되지 않았으며 nginx를 제외하고 모든 것이 작동합니다. 우리는 Kerberos와 창녀를 사용한 자체 nginx 빌드를 가지고 있습니다. 그리고 컨테이너 로그를 보면 /var/tmp에 쓸 수 없는 것으로 나타났습니다. 권한이 거부되었습니다. 관자놀이를 손가락으로 주무르며 상황을 분석해본다... 이게 어떻게 가능할까? Docker 이미지는 변경되지 않았습니다. 방금 디렉토리를 옮겼습니다. 항상 작동했고 여기에 있습니다... 실험을 위해 손으로 컨테이너에 들어가서 이 디렉토리에 대한 권한을 변경했습니다. 루트, 루트 755, 주었다 루트, 루트 777. 그리고 모든 것이 시작되었습니다... 내 머릿속에 생각이 들리기 시작했습니다. 일종의 말도 안되는 소리... 아마도 제가 뭔가를 고려하지 않았을 수도 있다고 생각했습니다...

나는 전송 중에 파일에 대한 액세스 권한이 마음에 들었다고 결정했습니다. docker 데몬인 애플리케이션을 중지하고 새 디렉터리를 삭제한 다음 다음을 사용하여 /var/lib/docker 디렉터리를 복사했습니다. rsync -a.

이제 모든 것이 괜찮은 것 같습니다. Docker 애플리케이션을 올려보겠습니다.

아아 그리고... 문제는 남았습니다... 눈이 꿈틀거렸습니다. 나는 서둘러 가상 머신의 콘솔로 가서 다양한 테스트를 실행했습니다. nginx 이미지가 있었고 컨테이너 내부로 올라갔습니다. 여기서 /var/tmp 디렉터리에 대한 권한은 루트, 루트 777입니다. 즉, 수동으로 설정해야 했던 것과 동일합니다. 하지만 이미지는 동일합니다!

xfs 파일 시스템은 모든 곳에서 사용되었습니다.

나는 명령을 사용하여 비교했다

docker inspect my-nginx:12345

모든 해시는 일대일로 동일합니다. 서버와 가상 머신 모두에서. 로컬 nginx 이미지를 삭제하고 여러 가지 이유로 동일한 시스템에 있는 레지스트리에서 다시 가져왔습니다. 그리고 문제는 똑같습니다. 이제 두 번째 눈이 꿈틀거리고 있습니다.

나는 "AAAAAAAAAA"라고 외치는 것 외에 내 머릿속에 어떤 생각이 들었는지 더 이상 기억하지 못합니다. 새벽 4시였으며 이미지 레이어 해싱의 원리를 이해하기 위해 Docker 소스 코드를 사용했습니다. 세 번째 에너지 드링크 캔을 열었습니다. 그리고 결국 해싱은 파일과 그 내용만 고려하지만 접근권한 없음! 즉, 알 수 없는 방식으로 우리의 권리가 상실되고, selinux가 비활성화되고, acl이 사용되지 않으며, 끈적한 비트가 없습니다.

로컬 이미지를 삭제하고 Docker 레지스트리에서도 이미지를 삭제한 후 다시 푸시했습니다. 그리고 모든 것이 작동했습니다. 전송 중에 로컬 이미지 내부와 레지스트리에 있는 이미지 내부 모두에서 권한이 손실된 것으로 나타났습니다. 내가 이미 말했듯이 여러 가지 이유로 같은 차에 위치했습니다. 결과적으로 하나의 디렉토리에 /var/lib/docker.

그리고 그들이 도커의 시선을 이전 디렉토리로 되돌리려 시도했는지 여부에 대한 질문을 예상했습니다. 아니요, 아쉽게도 상황이 허용하지 않았습니다. 네, 그리고 저는 정말로 그것을 알아내고 싶었습니다.

이 글을 쓴 후에는 문제에 대한 해결책이 분명해 보였지만, 분석 당시에는 그렇지 않은 것 같았습니다. 솔직히 구글링했는데 비슷한 상황은 못 찾았어요.

결과: 문제를 해결했지만 여전히 이유를 이해할 수 없습니다 =(

이 문제의 가능한 원인에 대해 알고 추측하는 사람이 있다면 댓글을 통해 여러분의 의견을 듣게 되어 매우 기쁠 것입니다!

출처 : habr.com