Linux 사후 설치 단계

Linux 사후 설치 단계 (Linux post-installation steps for Docker Engine)

이 선택적 사후 설치 절차는 Linux 호스트 머신이 Docker와 더 잘 동작하도록 구성하는 방법을 설명해요.

출처: 문서

본문

비-루트 사용자로 Docker 관리하기 (Manage Docker as a non-root user)

Docker 데몬은 TCP 포트가 아닌 Unix 소켓에 바인드돼요. 기본적으로 Unix 소켓을 소유하는 것은 root 사용자이며, 다른 사용자는 sudo를 사용해서만 접근할 수 있어요. Docker 데몬은 항상 root 사용자로 실행돼요.

Docker 데몬이 시작되면 docker 그룹의 구성원이 접근할 수 있는 Unix 소켓을 만들어요. 일부 Linux 배포판에서는 패키지 매니저로 Docker Engine을 설치할 때 시스템이 이 그룹을 자동으로 만들어요. 그 경우 그룹을 수동으로 만들 필요가 없어요.

Docker 데몬이 root로 실행되는 동안 sudo 없이 docker 명령을 실행하는 두 가지 방법이 있어요:

로그인 세션 전반에 걸친 접근을 위해 사용자를 docker 그룹에 추가.
비밀번호 보호된 Docker 지원 셸에 들어가 주문형으로 docker 그룹 접근.

Warning docker 그룹은 사용자에게 root 수준 특권을 부여해요. 이 것이 시스템 보안에 어떤 영향을 주는지에 대한 자세한 내용은 Docker Daemon Attack Surface를 참고하세요.

Note root 특권 없이 Docker를 실행하려면 비-루트 사용자로 Docker 데몬 실행(루트리스 모드)을 참고하세요.

사용자를 `docker` 그룹에 추가하기 (Add your user to the `docker` group)

docker 그룹을 만들고 사용자를 추가하려면:

docker 그룹을 만들어요.

$ sudo groupadd docker

사용자를 docker 그룹에 추가해요.

$ sudo usermod -aG docker $USER

그룹 구성원 자격이 재평가되도록 로그아웃하고 다시 로그인해요.

가상 머신에서 Linux를 실행 중이라면 변경이 적용되도록 가상 머신을 재시작해야 할 수도 있어요.

또한 다음 명령을 실행해 그룹 변경을 활성화할 수도 있어요:

$ newgrp docker

sudo 없이 docker 명령을 실행할 수 있는지 확인해요.

$ docker run hello-world

이 명령은 테스트 이미지를 다운로드해 컨테이너에서 실행해요. 컨테이너가 실행되면 메시지를 출력하고 종료해요.

사용자를 docker 그룹에 추가하기 전에 sudo로 Docker CLI 명령을 처음 실행했다면 다음 오류가 보일 수 있어요:

WARNING: Error loading config file: /home/user/.docker/config.json -
stat /home/user/.docker/config.json: permission denied

이 오류는 이전에 sudo 명령을 사용했기 때문에 ~/.docker/ 디렉토리의 권한 설정이 올바르지 않음을 나타내요.

이 문제를 해결하려면 ~/.docker/ 디렉토리를 제거하거나(자동으로 다시 생성되지만 사용자 지정 설정은 잃음), 다음 명령으로 그 소유권과 권한을 변경해요:

$ sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
$ sudo chmod g+rwx "$HOME/.docker" -R

주문형으로 `docker` 그룹 접근하기 (Access the `docker` group on demand)

그룹 비밀번호는 레거시 Unix 접근 제어 메커니즘이지만, 단일 사용자 워크스테이션에서 Docker 접근을 게이팅하는 데 유용할 수 있어요. sudo와 마찬가지로 이 방법은 특권 접근 전에 명시적 비밀번호 단계를 추가해요. sudo docker를 실행하는 것과 달리 newgrp은 Docker CLI를 사용자 ID 아래에서 계속 실행하고 셸의 기본 그룹을 통해 접근을 부여하므로, CLI가 root로 자체 구성을 접근하지 않아요.

docker 그룹의 영구 구성원 자격은 로그인 세션의 모든 프로세스에 Docker 소켓 접근을 부여해요. Docker 지원 셸과 그 자손들은 Docker 소켓 접근을 상속해요. 이는 로그인 세션의 다른 곳에서 실행되는 애플리케이션의 주변(ambient) 접근을 줄여요. 이 접근을 구성하려면 사용자를 그룹에서 제외시키고, 그룹 비밀번호를 설정하고, newgrp으로 Docker 지원 셸을 시작해요.

Warning 그룹 비밀번호는 Docker 소켓에 대한 주변 접근을 줄이지만, 접근이 인가된 후 부여되는 root 수준 특권은 줄이지 않아요. 그룹 비밀번호는 공유 비밀(shared secret)이기도 해서 사용자별 책임을 제공하지 않아요. 이 방법은 사용자로 실행되는 악성 코드에 대한 보안 경계가 아니에요. 그런 코드는 사용자가 나중에 Docker 지원 셸에서 사용하는 사용자 쓰기 가능한 셸 구성, 명령, 스크립트를 수정하고, 인증 후 Docker 접근을 얻을 수 있어요. 신뢰할 수 없는 코드를 담거나 손상된 로그인 세션을 보호하는 데 그룹 비밀번호에 의존하지 마세요. 이 구성은 단일 사용자 워크스테이션에 가장 적합해요. 더 강한 격리를 위해서는 루트리스 모드를 사용하거나 가상 머신에서 Docker를 실행하세요.

이 절차는 gpasswd와 newgrp이 필요해요. 이 명령들의 패키지 이름은 Linux 배포판에 따라 달라요. 두 명령이 모두 사용 가능한지 확인해요:

$ command -v gpasswd newgrp
/usr/bin/gpasswd
/usr/bin/newgrp

Docker 접근에 비밀번호를 요구하려면:

존재하지 않으면 docker 그룹을 만들어요:

$ sudo groupadd --force docker

--force 옵션은 그룹이 이미 존재할 때 명령이 성공하도록 해요.

사용자가 docker 그룹의 구성원이면 그 구성원 자격을 제거해요:

$ sudo gpasswd --delete "$USER" docker

데스크톱 또는 SSH 세션에서 완전히 로그아웃한 다음 다시 로그인해요. 그룹 구성원 자격은 기존 프로세스의 자격 증명에 남아 있으므로 새 터미널을 여는 것만으로는 충분하지 않아요.

계속 전에 그룹 목록에 docker가 없는지 확인해요:

$ id -nG
user wheel

그룹 목록은 시스템에 따라 다르지만 docker를 포함해서는 안 돼요.

docker 그룹에 전용 비밀번호를 설정해요:

$ sudo gpasswd docker
Changing the password for group docker
New Password:
Re-enter new password:

사용자를 그룹에 다시 추가하지 마세요. 그룹 구성원으로 구성된 사용자는 그룹 비밀번호를 입력하지 않고 newgrp을 사용할 수 있어요.

docker를 기본 그룹으로 하는 자식 셸을 시작해요:

$ newgrp docker
Password:

셸이 여전히 사용자 ID를 사용하고 docker를 기본 그룹으로 가지는지 확인한 다음 Docker 접근을 테스트해요:

$ id -un
user
$ id -gn
docker
$ docker run --rm hello-world

이 셸에서 시작된 명령과 애플리케이션은 Docker 소켓 접근을 상속해요. 셸 밖에서 이미 실행 중이던 애플리케이션은 접근을 얻지 못해요.

Caution 이 셸에서 만든 파일과 디렉토리는 보통 docker를 그룹 소유자로 가져요. 이 셸을 Docker 관련 명령에만 사용하거나, 만든 파일의 그룹 소유권을 확인하세요.

작업을 마치면 Docker 지원 셸을 종료해요:

$ exit

원래 셸의 그룹 목록에 docker가 더 이상 없는지 확인해요:

$ id -nG
user wheel

Caution 셸을 종료해도 셸 안에서 시작된 백그라운드, 분리(detached), 데몬화된 프로세스의 접근은 취소되지 않아요. 그 프로세스들은 종료될 때까지 docker 그룹을 유지해요.

그룹 비밀번호를 바꾸려면 sudo gpasswd docker를 다시 실행해요.

비밀번호 기반 진입 비활성화하기 (Disable password-based entry)

공유 비밀번호 사용을 중지하고 구성된 그룹 구성원 자격을 요구하려면 다음을 실행해요:

$ sudo gpasswd --restrict docker

이것은 비밀번호 게이팅 설정을 되돌려요. 이후에는 docker 그룹의 구성원으로 구성된 사용자만 들어갈 수 있어요. 이 변경은 새 인가 시도에 영향을 주며, 기존 Docker 지원 셸이나 그 자손 프로세스를 종료하지 않아요.

gpasswd는 로컬 /etc/group과 /etc/gshadow 파일을 관리해요. LDAP, NIS 또는 다른 ID 서비스를 사용하는 시스템은 그 서비스의 그룹 관리 메커니즘이 필요해요.

systemd로 부팅 시 Docker 시작 구성 (Configure Docker to start on boot with systemd)

많은 현대 Linux 배포판은 systemd를 사용해 시스템이 부팅될 때 시작할 서비스를 관리해요. Debian과 Ubuntu에서는 Docker 서비스가 기본적으로 부팅 시 시작돼요. systemd를 사용하는 다른 Linux 배포판에서 부팅 시 Docker와 containerd를 자동으로 시작하려면 다음 명령을 실행해요:

$ sudo systemctl enable docker.service
$ sudo systemctl enable containerd.service

이 동작을 중지하려면 대신 disable을 사용해요.

$ sudo systemctl disable docker.service
$ sudo systemctl disable containerd.service

systemd 유닛 파일을 사용해 시작 시 Docker 서비스를 구성할 수 있어요. 예를 들어 HTTP 프록시를 추가하거나, Docker 런타임 파일에 다른 디렉토리나 파티션을 설정하거나, 기타 사용자 지정을 할 수 있어요. 예시는 데몬이 프록시를 사용하도록 구성을 참고하세요.

기본 로깅 드라이버 구성 (Configure default logging driver)

Docker는 호스트에서 실행되는 모든 컨테이너의 로그 데이터를 수집하고 보기 위한 로깅 드라이버를 제공해요. 기본 로깅 드라이버인 json-file은 로그 데이터를 호스트 파일시스템의 JSON 형식 파일에 써요. 시간이 지나면 이 로그 파일은 크기가 커져 디스크 리소스의 고갈을 초래할 수 있어요.

로그 데이터에 디스크를 과도하게 사용하는 문제를 피하려면 다음 옵션 중 하나를 고려해요:

json-file 로깅 드라이버를 구성해 로그 회전을 켜요.
기본적으로 로그 회전을 수행하는 "local" 로깅 드라이버 같은 대체 로깅 드라이버를 사용해요.
원격 로그 수집기로 로그를 보내는 로깅 드라이버를 사용해요.

다음 단계 (Next steps)

Docker 시작하기를 살펴보고 이미지를 빌드하고 컨테이너화된 애플리케이션으로 실행하는 방법을 배워요.

Linux 사후 설치 단계