무슨 내용이야?

도커 호스트 컴퓨터와 상호 작용하는 도커 컨테이너를 사용할 때의 다소 기술적인 문제에 관한 것입니다. 일반적으로 컨테이너 내부의 호스트 파일 시스템을 사용하는 것과 관련이 있습니다.
이는 특히 재현 가능한 연구 맥락에서 발생합니다.
저는 이 문제를 해결하는 데 도움이 되는 오픈소스 유틸리티를 개발했습니다.

실행 환경으로서의 도커 컨테이너

도커 컨테이너의 초기 및 주요 사용 사례: 일부 네트워크 포트를 사용하여 호스트 시스템과만 상호 작용하는 자체 포함 애플리케이션입니다.
웹 애플리케이션을 생각해 보세요. 도커 컨테이너에는 일반적으로 웹 서버와 웹 애플리케이션이 포함되어 있으며, 예를 들어 포트 80(컨테이너 내부)에서 실행됩니다. 그런 다음 컨테이너 내부 포트 80을 호스트 포트(예: 8000)에 바인딩하여 컨테이너가 호스트에서 실행됩니다.
그런 다음 컨테이너화된 앱과 호스트 시스템 간의 유일한 상호 작용은 이 바인딩된 네트워크 포트를 통해서입니다.

실행 환경으로서의 컨테이너는 완전히 다릅니다.

• 애플리케이션을 컨테이너화하는 대신 컨테이너화되는 것은 애플리케이션 빌드 시스템입니다.
  • 컴파일러, IDE, 노트북 엔진, Quarto 출판 시스템 등이 될 수 있습니다...
• 목표는 다음과 같습니다.
  • 표준을 갖고 설치 및 공유가 쉬운 환경
    • 고정 버전의 R, Python 및 수많은 외부 패키지가 포함된 복잡한 빌드 환경을 상상해 보세요. 올바른 버전으로 모든 것을 설치하는 것은 매우 어렵고 시간이 많이 걸리는 작업일 수 있습니다. 이미 설치되고 사전 구성된 모든 항목이 포함된 도커 이미지를 공유하면 시간이 크게 절약됩니다.
  • 재현 가능한 환경을 갖기 위해
    • 이를 사용하면 동일한 제어 환경을 사용하므로 일부 분석 결과를 재현할 수 있습니다.
    • 버그를 쉽게 재현할 수도 있으며, 이것이 버그 수정의 첫 번째 단계입니다.

그러나 이러한 실행 환경을 사용하려면 해당 컨테이너가 호스트 시스템, 특히 호스트 사용자 파일 시스템에 액세스할 수 있어야 합니다.

도커 컨테이너 및 호스트 파일 시스템

IDE를 컨테이너화했다고 가정합니다. Rstudio.
Rstudio는 Docker 컨테이너 내부에 설치되어 실행되지만 프로젝트 폴더의 파일을 읽고 편집해야 합니다.

이를 위해 docker run --volume 옵션을 사용하여 프로젝트 폴더(호스트 ​​파일 시스템)를 바인딩 마운트합니다.
그러면 Docker 컨테이너 내에서 파일에 액세스할 수 있습니다.

이제 문제는 파일 권한입니다. 호스트 사용자의 사용자 ID가 1001이고 컨테이너에서 Rsudio 프로세스를 소유한 사용자가 0(루트) 또는 1002

컨테이너 사용자가 루트인 경우 파일을 읽는 데 문제가 없습니다.
그러나 일부 기존 파일을 편집하고 새 파일(예: pdf, html)을 생성하자마자 이러한 파일은 호스트 파일 시스템의 루트 에도 속하게 됩니다!.
이는 루트에 속하므로 로컬 호스트 사용자가 이를 사용하거나 삭제할 수 없음을 의미합니다.

이제 컨테이너 사용자 ID가 1002인 경우 Rstudio가 파일을 읽거나 편집하거나 새 파일을 생성하지 못할 수 있습니다.
가능하더라도 매우 허용적인 권한을 설정하면 로컬 호스트 사용자가 해당 권한을 사용하지 못할 수도 있습니다.

물론 이 문제를 해결하는 무차별 대입 방법 중 하나는 호스트 컴퓨터와 도커 컨테이너 모두에서 루트로 실행하는 것입니다. 이는 항상 가능한 것은 아니며 몇 가지 명백하고 중요한 보안 문제를 야기합니다.

파일 소유자 문제 해결 1부: docker run --user 옵션

호스트 사용자 ID(여기서는 1001)가 무엇인지 미리 알 수 없기 때문에 사전 구성할 수 없습니다
도커 컨테이너 사용자의 사용자 ID입니다.

docker run는 이제 일부 제공된 사용자 ID를 사용하여 의사
사용자를 생성할 수 있는 --user 옵션을 제공합니다. 런타임에. 예를 들어 docker run --user 1001 ...은 프로세스
로 실행되는 docker 컨테이너를 생성합니다. 사용자 ID가 1001.

그럼 우리는 아직도 이 문제에 대해 무엇을 논의하고 있나요? 해결되지 않았나요?

동적으로 생성된 사용자에 대한 몇 가지 특징은 다음과 같습니다.

• 의사 사용자입니다
• 홈 디렉터리(/home/xxx)가 없습니다.
• /etc/passwd에는 나타나지 않습니다.
• 미리 구성할 수 없습니다. Bash 프로필, 일부 환경 변수, 애플리케이션 기본값 등...

이러한 문제를 해결할 수는 있지만 지루하고 실망스러울 수 있습니다.
우리가 정말로 원하는 것은 도커 컨테이너 사용자를 사전 구성하고 런타임...에서 사용자 ID

파일 소유자 문제 해결 2부: docker_userid_fixer 입력

docker_userid_fixer는 방금 제기한 사용자 ID 문제를 해결하기 위해 docker 진입점으로 사용하기 위한 오픈 소스 유틸리티입니다.

사용 방법을 살펴보겠습니다. 이를 docker ENTRYPOINT로 설정하고 어떤 사용자를 사용해야 하는지 지정하고 해당 사용자의 사용자 ID를 동적으로 수정합니다.

ENTRYPOINT ["/usr/local/bin/docker_userid_fixer","user1"]

정확하게 말하면:

• 대상 사용자는 docker_userid_fixer에 요청된 사용자입니다. 여기에서는 user1
• 요청된 사용자는 docker run에 의해 프로비저닝된 사용자입니다. 즉, (처음에) 첫 번째 프로세스(PID 1)를 소유한 사용자입니다.

그런 다음 컨테이너 런타임 생성 시 두 가지 옵션이 있습니다.

• 요청한 사용자 ID가 (이미) 대상 사용자 ID와 일치하면 아무것도 변경할 필요가 없습니다.
• 또는 그렇지 않습니다. 예를 들어, 요청된 사용자 ID는 1001이고, 대상 사용자 ID는 100입니다. 그런 다음 docker_userid_fixer는 컨테이너 기본 프로세스에서 직접 target 사용자 user1의 사용자 ID를 1000에서 1001로 수정합니다.

실제로는 이렇게 하면 문제가 해결됩니다.

• 컨테이너 사용자 ID를 수정할 필요가 없다면 일반적인 방식으로 docker run을 사용하세요(--user 옵션 없이).
• 또는 --user 옵션을 사용하면 요청한 사용자 ID로 기본 프로세스를 실행하는 것 외에도 사전 구성된 사용자를 요청한 사용자 ID로 수정하여 컨테이너가 의도한 사용자와 의도한 대로 실행되도록 합니다. 사용자 ID.

docker_userid_fixer 설정

여기에서 설정에 대한 지침을 찾을 수 있습니다.

하지만 다음과 같이 요약됩니다.

• 작은 실행 파일(17k) 빌드 또는 다운로드

• 도커 이미지에 복사합니다.

• setuid 루트로 실행 가능하게 만듭니다.

• 진입점으로 구성

잔혹한 세부 사항

몇 가지 짧은 메모를 넣었습니다 https://github.com/kforner/docker_userid_fixer#how-it-works
하지만 다른 말로 바꿔 보겠습니다.

구현의 핵심은 컨테이너에 있는 docker_userid_fixer 실행 파일의 setuid 루트입니다.
사용자 ID를 변경하려면 루트 권한이 필요하며 이 setuid는
에 대해서만 권한 있는 실행을 활성화합니다. docker_userid_fixer 프로그램은 아주 짧은 시간 동안만 실행됩니다.

필요한 경우 사용자 ID가 수정되자마자 docker_userid_fixer가 기본 프로세스를 전환합니다.
요청한 사용자(및 사용자 ID!)에.

이러한 주제(도커, 재현 가능한 연구, R 패키지 개발, 알고리즘, 성능 최적화, 병렬 처리...)에 관심이 있다면 주저하지 말고 저에게 연락하여 직업 및 비즈니스 기회에 대해 논의하세요.