Ubuntu에 Docker를 설치하는 가장 좋은 방법은 무엇입니까?

대부분의 개발자와 서버에서는 Docker의 공식 APT 저장소에서 Docker Engine을 설치해야 합니다. 이 저장소는 최신 릴리스, Compose 플러그인, Buildx를 제공하며 일반적인 업그레이드 경로를 지원합니다. 배포판 통합이 최신 버전보다 우선하는 경우에만 Ubuntu의 docker.io 패키지를 사용하십시오.

Ubuntu에서 docker.io와 docker-ce의 차이점은 무엇인가요?

docker.io는 Universe 저장소에서 Ubuntu가 유지 관리하는 패키지의 반면, docker-ce는 Docker의 공식 APT 저장소에서 제공되며 업스트림 패키징을 사용하고 기능 업데이트 속도가 빠릅니다. 둘 다 Docker 엔진을 실행하지만, 버전 업데이트 주기, 패키지 이름, 업그레이드 동작에서 차이가 있습니다.

유비누트에서 스냅을 통해 도커를 설치해야 하나요?

Snap을 사용하여 소프트웨어를 의도적으로 관리하고 snap 스타일의 자동 업데이트 및 격리(confinement) 동작을 수용하는 경우에만 해당됩니다. 개발 및 서버 워크로드의 경우, 공식 APT 리포지토리가 일반적으로 더 예측 가능하며 대부분의 Docker 문서와 호환됩니다.

Ubuntu에서 sudo 없이 Docker를 실행하려면 어떻게 해야 하나요?

usermod -aG docker $USER 명령어로 docker 그룹에 사용자를 추가한 후, 로그아웃했다가 다시 로그인하거나 newgrp docker 를 실행하세요. docker 그룹 멤버십은 데몬 소켓을 통해 호스트에 루트(root)와 동등한 제어 권한을 부여한다는 점을 유의하십시오.

루트리스 도커(Rootless Docker)란 무엇이며, 언제 사용해야 할까요?

Rootless Docker는 데몬과 컨테이너를 루트 권한이 아닌 일반 사용자로 실행하여 데몬 수준의 권한 상승 위험을 줄입니다. 공유 머신이나 더 엄격한 사용자 격리가 필요한 경우 사용하되, privileged 컨테이너, 낮은 포트, 호스트 네트워킹 사용 시 일부 호환성 제한이 있을 수 있음을 유의하십시오.

docker compose를 사용해야 할까요, 아니면 docker-compose를 사용해야 할까요?

docker-compose-plugin과 함께 설치되는 최신 CLI 플러그인인 docker compose를 사용하십시오. 구버전 docker-compose 독립 실행형 명령어는 레거시 문서 및 오래된 시스템에 해당합니다.

우분투에 도커 설치: APT, 스냅, 루트리스 — 2026 완전 가이드

Ubuntu에서 적절한 Docker 설치 경로를 선택하세요.

Page content

Ubuntu에 Docker를 설치하는 것은 간단해 보이지만, 실제로는 동일한 명령어 이름을 놓고 경쟁하는 여러 Docker 관련 옵션들이 존재합니다. 각 옵션은 패키징, 업그레이드 동작, 보안 영향 측면에서 차이가 있습니다.

이 가이드는 모든 주요 설치 경로를 비교하여 사용자의 환경에 적합한 것을 선택할 수 있도록 도와줍니다.

사용자가 마주칠 수 있는 옵션들은 다음과 같습니다.

Ubuntu 리포지토리에서 제공하는 docker.io
Docker 공식 APT 리포지토리에서 제공하는 docker-ce
Snap을 통한 Docker
Docker Desktop
수동으로 다운로드한 .deb 패키지
Docker 편의 스크립트(Convenience Script)
루트리스(Rootless) Docker

docker workplace

이들 모두 컨테이너 도구를 제공하지만, 서로 대체할 수 있는 패키지는 아닙니다. 최적의 선택은 머신이 개발자 워크스테이션인지, CI 러너인지, 소형 서버인지, 셀프 호스팅 박스인지, 아니면 프로덕션 호스트인지에 따라 달라집니다. 제 기본 추천은 차분하지만 확실합니다. 대부분의 일반 Ubuntu 머신을 사용하는 기술 사용자에게는 Docker 공식 APT 리포지토리에서 Docker Engine을 설치하는 것을 권장합니다. 분산 통합이 업스트림 Docker 패키징보다 더 중요한 경우에만 Ubuntu의 docker.io를 사용하세요. Snap 패키지는 의도적으로 Snap 동작을 원하고 그 한계를 이해하는 경우를 제외하고는 피하는 것이 좋습니다. 루트리스 Docker는 알아두는 가치가 있지만, 모든 머신의 기본값으로 자동으로 선택해야 할 것은 아닙니다.

이 가이드는 이러한 트레이드오프를 설명하고, 설치 후 보안을 다루며, 각 방법에 대해 깔끔한 설치 경로를 제공합니다. Docker Engine이 실행되면, Docker Cheatsheet가 일상적인 명령어 참조가 되며, Docker Compose Cheatsheet은 다중 컨테이너 설정을 다룹니다. 이 두 가지는 Developer Tools: The Complete Guide to Modern Development Workflows에서 Git, VS Code, CI/CD 가이드와 함께 제공됩니다.

빠른 추천

아래 표는 일반적인 시나리오에 적합한 설치 경로를 요약합니다.

사용 사례	권장 설치 방법
개발자 워크스테이션	Docker 공식 APT 리포지토리
CI 러너	Docker 공식 APT 리포지토리, 필요 시 버전 고정
소형 셀프 호스팅 서버	Docker 공식 APT 리포지토리
프로덕션 서버	Docker 공식 APT 리포지토리, 통제된 업그레이드
Ubuntu 전용 보수적인 시스템	Ubuntu `docker.io` 패키지
빠른 데스크톱 실험	Docker Desktop 또는 공식 APT 리포지토리
Snap 관리 Ubuntu 설정	Docker Snap, 주의하여 사용
강력한 비루트 데몬 요구 사항	루트리스 Docker
격리된 호스트(Air-gapped host)	수동 `.deb` 패키지 또는 내부 미러

특별한 이유가 없다면 Docker 공식 APT 리포지토리가 기본값입니다.

설치되는 구성 요소

일반적인 Docker Engine 설정에는 여러 구성 요소가 포함됩니다:

Docker 데몬: dockerd
Docker CLI: docker
컨테이너 런타임: containerd
저레벨 런타임: runc
Buildx 플러그인: docker buildx
Compose 플러그인: docker compose

현대적인 Docker Compose는 일반적으로 Docker CLI 플러그인으로 설치됩니다. 즉, 명령어는 다음과 같습니다:

docker compose version

다음은 아닙니다:

docker-compose version

구식 docker-compose 명령어는 여전히 구식 가이드와 시스템에 존재하지만, 새로운 Ubuntu 설정에서는 일반적으로 Compose 플러그인을 사용해야 합니다.

옵션 1: Docker 공식 APT 리포지토리에서 Docker 설치

이는 대부분의 개발자와 DevOps 사용자에게 가장 좋은 기본값입니다. Docker의 업스트림 패키징, 최신 Docker Engine 릴리스, Buildx, Compose 플러그인 및 일반적인 APT 업그레이드 경로를 제공합니다.

먼저 충돌하는 패키지 제거

Docker CE를 설치하기 전에 공식 Docker 패키지와 충돌할 수 있는 패키지를 제거하십시오.

sudo apt remove docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc

APT에서 일부 패키지가 설치되지 않았다고 표시되는 것은 괜찮습니다.

이 명령어는 /var/lib/docker 아래에 저장된 Docker 이미지, 컨테이너, 볼륨 또는 네트워크를 제거하지 않습니다. 깨끗한 리셋을 원한다면 이는 별도의 단계이며 신중하게 수행해야 합니다.

Docker 공식 APT 리포지토리 추가

전제 조건 설치:

sudo apt update
sudo apt install ca-certificates curl

키링 디렉토리 생성:

sudo install -m 0755 -d /etc/apt/keyrings

Docker 리포지토리 키 다운로드:

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc

APT가 키를 읽도록 허용:

sudo chmod a+r /etc/apt/keyrings/docker.asc

deb822 .sources 형식을 사용하여 Docker 리포지토리 추가:

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

APT 메타데이터 업데이트:

sudo apt update

Docker Engine, Buildx, Compose 설치

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

서비스 확인:

sudo systemctl status docker

실행 중이 아닌 경우:

sudo systemctl start docker

설치 확인:

sudo docker run hello-world

버전 확인:

docker --version
docker buildx version
docker compose version

이 시점에서 Docker는 작동하지만, 아래 설치 후 섹션에서 비루트(rootless) 접근을 구성하지 않는 한 대부분의 명령어에 여전히 sudo가 필요합니다.

옵션 2: Ubuntu 리포지토리에서 Docker 설치

Ubuntu는 docker.io 패키지를 제공하며, 다음 명령어로 설치할 수 있습니다:

sudo apt update
sudo apt install docker.io docker-compose-v2

Docker 시작 및 활성화:

sudo systemctl enable --now docker

확인:

sudo docker run hello-world

Ubuntu `docker.io`가 적합한 경우

Ubuntu 패키지는 다음과 같은 경우에 좋은 선택이 될 수 있습니다:

Ubuntu가 관리하는 패키지를 선호하는 경우.
Ubuntu의 릴리스 프로세스와 일치하는 버전을 원하는 경우.
표준 리포지토리로 많은 Ubuntu 호스트를 관리하는 경우.
최신 업스트림 Docker 릴리스가 필요하지 않은 경우.
타사 APT 소스를 줄이고 싶은 경우.

이는 합리적인 선택입니다. “잘못된” 선택은 아닙니다.

Ubuntu `docker.io`가 이상적이지 않은 경우

다음과 같은 경우에는 Docker 공식 리포지토리를 사용하세요:

최신 업스트림 Docker Engine을 원하는 경우.
Docker 자체 문서를 따르고 싶은 경우.
최신 Buildx 및 Compose 동작에 의존하는 경우.
Docker CE 패키지 이름을 원하는 경우.
업스트림 Docker 문서에 대해 문제를 디버깅하는 경우.
배포 간에 예측 가능한 Docker 버전 패리티가 필요한 경우.

제 편향: 개발자 머신 및 컨테이너 중심 호스트에는 Docker 공식 APT 리포지토리를 사용하세요. 보수적인 Ubuntu 관리 머신의 경우 docker.io가 허용됩니다.

옵션 3: Snap을 사용하여 Docker 설치

Docker snap은 단일 명령어로 설치되지만, 단순함이 항상 서버 또는 개발 머신에서 예측 가능한 동작을 의미하는 것은 아닙니다.

sudo snap install docker

Snap 패키지는 자체 패키징 모델, 업데이트 동작, 격리 가정 및 파일 시스템 레이아웃을 가지고 있습니다. 이는 많은 데스크톱 앱에게는 괜찮지만, Docker Engine은 이미 시스템 레벨 컨테이너 런타임이므로 추가적인 Snap 레이어는 사용자를 놀라게 할 수 있습니다. 다른 소프트웨어를 Snap으로 관리한다면, Snap Package Manager Cheatsheet는 채널, 격리 및 업데이트 동작에 대해 더 자세히 설명합니다.

Docker Snap이 적합한 경우

Docker Snap은 다음과 같은 경우에 합리적일 수 있습니다:

의도적으로 소프트웨어를 Snap으로 관리하는 경우.
Ubuntu Core 또는 Snap 중심 환경을 사용하는 경우.
snap 스타일의 자동 업데이트를 원하는 경우.
실험 중이며 Docker의 업스트림 APT 지침과 일치하는지 신경 쓰지 않는 경우.

일반적으로 Docker Snap을 피하는 이유

개발 및 서버 용도로 Docker snap을 일반적으로 피하는 이유는 다음과 같습니다:

대부분의 Docker 문서는 표준 Docker Engine 레이아웃을 가정합니다.
문제 해결 경로는 APT 설치와 다를 수 있습니다.
서비스 관리가 덜 투명하게 느껴질 수 있습니다.
Snap 자동 업데이트는 인프라 소프트웨어에 불편할 수 있습니다.
일부 바인드 마운트, 소켓 및 호스트 통합 세부 사항이 놀라게 할 수 있습니다.

Docker가 워크플로우의 중심이라면, 표면적으로 유혹적인 Snap 설치처럼 보일지라도 인프라처럼 설치하는 것이 좋습니다.

옵션 4: 수동 `.deb` 패키지에서 Docker 설치

수동 .deb 설치는 다음과 같은 경우에 유용합니다:

머신이 외부 APT 리포지토리를 사용할 수 없는 경우.
오프라인 설치 프로세스를 구축하는 경우.
내부적으로 패키지를 미러링하는 경우.
엄격한 변경 통제가 필요한 경우.

트레이드오프는 유지 관리이며, 업그레이드할 때마다 새 패키지를 수동으로 다운로드하고 설치해야 합니다.

수동 설치에는 일반적으로 다음 패키지가 필요합니다:

containerd.io
docker-ce
docker-ce-cli
docker-buildx-plugin
docker-compose-plugin

다음 명령어로 설치:

sudo dpkg -i ./containerd.io_*.deb \
  ./docker-ce_*.deb \
  ./docker-ce-cli_*.deb \
  ./docker-buildx-plugin_*.deb \
  ./docker-compose-plugin_*.deb

필요시 누락된 종속성 수정:

sudo apt --fix-broken install

확인:

sudo systemctl status docker
sudo docker run hello-world

수동 .deb 설치는 제 첫 번째 선택은 아니지만, 명시적인 패키지 승인이 편의성보다 중요한 통제되거나 격리된 환경에서는 여전히 유효합니다.

옵션 5: Docker 편의 스크립트 사용

Docker는 편의 스크립트를 제공합니다:

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

무엇을 할지 미리 확인:

sudo sh get-docker.sh --dry-run

편의 스크립트는 일회성 테스트 머신, 데모, 실험실 및 폐기 환경에 유용하지만 프로덕션 시스템의 주요 설치 방법으로 사용하지 않습니다. 리포지토리를 구성하고 패키지를 비대화 방식으로 설치하는 스크립트는 편리하지만, 장기적인 인프라는 명시적이고 검토 가능한 단계를 deserves합니다. 따라서 프로덕션 호스트의 경우 APT 리포지토리 방법을 직접 사용하세요.

Ubuntu에서 Docker Desktop vs Docker Engine

Linux용 Docker Desktop은 Docker Engine과 다른 제품입니다. Docker Engine은 대부분의 Linux 서버 사용자가 기대하는 서버 측 런타임 및 CLI 워크플로우인 반면, Docker Desktop은 GUI, 데스크톱 통합 및 macOS 및 Windows Docker 사용에 더 가까운 제품 경험을 추가합니다.

다음과 같은 경우 Docker Desktop 사용:

그래픽 Docker 경험을 원하는 경우.
데스크톱 기능을 원하는 경우.
Docker Desktop을 표준화하는 팀과 일치하는 경우.
추가 레이어를 신경 쓰지 않는 경우.

다음과 같은 경우 Docker Engine 사용:

서버를 실행 중인 경우.
간단한 Linux 네이티브 런타임을 원하는 경우.
systemd 관리 서비스를 선호하는 경우.
CI, DevOps 또는 셀프 호스팅 인프라를 구축하는 경우.
GUI가 필요하지 않은 경우.

고급 기술 블로그 독자를 위해, Docker Engine은 Linux 서버 및 CI 호스트에서 일반적으로 더 흥미로운 기본값입니다.

설치 후: Sudo 없이 Docker 실행

설치 후, 다음 명령어는 작동합니다:

sudo docker ps

하지만 다음 명령어는 실패할 수 있습니다:

docker ps

이는 Docker 데몬이 root가 소유한 Unix 소켓을 수신 대기하기 때문입니다. 일반적인 해결책은 사용자를 docker 그룹에 추가하는 것입니다.

필요시 그룹 생성:

sudo groupadd docker

사용자 추가:

sudo usermod -aG docker $USER

새 그룹 멤버십 적용:

newgrp docker

또는 로그아웃 후 다시 로그인.

테스트:

docker run hello-world

Docker 그룹에 대한 중요한 보안 참고 사항

docker 그룹은 무해한 편의 그룹이 아닙니다. Docker 데몬을 제어할 수 있는 사용자는 일반적으로 호스트에 root와 동등한 제어를 얻을 수 있으므로, 개인 개발자 머신에서는 종종 허용되지만 공유 서버에서는 심각한 접근 제어 결정입니다. docker 그룹의 멤버십을 관리자 접근처럼 취급하고, 너무 광범위하게 느껴진다면 루트리스 Docker를 고려하세요.

Ubuntu에서 루트리스 Docker

루트리스 Docker는 Docker 데몬과 컨테이너를 비루트(non-root) 사용자로 실행합니다. 이는 사용자를 docker 그룹에 추가하는 것과 동일하지 않습니다. docker 그룹의 경우 데몬은 여전히 root로 실행되지만, 루트리스 모드에서는 데몬 자체가 사용자로 실행됩니다.

루트리스 Docker가 적합한 경우

루트리스 Docker는 다음과 같은 경우에 유용합니다:

데몬 레벨의 root 위험을 줄이고 싶은 경우.
공유 개발 머신을 사용하는 경우.
사용자 소유의 컨테이너를 실행하는 경우.
모든 고급 네트워킹 및 저장소 기능이 필요하지 않은 경우.
실험적 워크로드에 더 안전한 기본값을 원하는 경우.

루트리스 Docker가 번거로울 수 있는 경우

루트리스 Docker는 다음과 같은 경우에 덜 편리할 수 있습니다:

privileged 컨테이너가 필요한 경우.
추가 설정 없이 낮은 포트 바인딩에 의존하는 경우.
일부 호스트 네트워킹 패턴이 필요한 경우.
rootful Docker와 동일한 동작을 기대하는 경우.
일반적인 Docker Engine 설치를 위한 가이드를 따르고 있는 경우.

루트리스 모드는 보안 태세는 개선하지만, 표준 rootful 설치에 비해 마찰이 없는 것은 아닙니다.

루트리스 Docker 설치

전제 조건 설치:

sudo apt update
sudo apt install uidmap

DEB 또는 APT 패키지로 Docker를 설치한 경우, 루트리스 설정 도구가 사용 가능해야 합니다:

dockerd-rootless-setuptool.sh install

rootful Docker가 이미 실행 중이고 루트리스 Docker만 원한다면 시스템 데몬을 비활성화하세요:

sudo systemctl disable --now docker.service docker.socket

rootful 소켓도 제거해야 할 수 있습니다:

sudo rm -f /var/run/docker.sock

루트리스 Docker 설치 후, 설정 도구는 일반적으로 셸 프로필에 추가할 환경 변수를 출력합니다. 다음과 비슷하게 보입니다:

export PATH=/usr/bin:$PATH
export DOCKER_HOST=unix:///run/user/1000/docker.sock

UID는 다를 수 있습니다. 설정 도구에서 정확한 출력을 확인하세요.

로그아웃 후에도 사용자 서비스가 실행되도록 lingering 활성화:

sudo loginctl enable-linger $USER

사용자 서비스 확인:

systemctl --user status docker

테스트 컨테이너 실행:

docker run hello-world

Rootful Docker vs Rootless Docker

주제	Rootful Docker	Rootless Docker
데몬 사용자	root	일반 사용자
명령어 편의성	높음	중간
호환성	가장 높음	좋음, 하지만 완벽하지 않음
보안 태세	기본값이 약함	기본값이 더 좋음
Privileged 컨테이너	지원됨	제한적
낮은 포트	간단함	추가 설정 필요
서버 사용	일반적	가능, 하지만 신중하게 계획
개발자 워크스테이션	일반적	보안 의식이 있는 사용자에게 좋음

제 실용적인 추천:

개인 개발 머신이나 간단한 서버에는 일반 rootful Docker를 사용하세요.
신뢰할 수 있는 사용자만 docker 그룹에 추가하세요.
사용자 격리가 중요한 경우 루트리스 Docker를 사용하세요.
docker 그룹을 보안 경계라고 가정하지 마세요.

부팅 시 Docker 활성화

Ubuntu에서 일반 패키지로 설치된 Docker는 일반적으로 자동으로 시작되지만, 새로 설치하거나 마이그레이션 후 확인하는 것이 좋습니다.

확인:

systemctl is-enabled docker
systemctl is-enabled containerd

필요시 수동 활성화:

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

지금 시작:

sudo systemctl start docker

자동 시작 비활성화:

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

루트리스 Docker의 경우 사용자 서비스를 사용하세요:

systemctl --user enable docker
systemctl --user start docker

필요시 lingering 활성화:

sudo loginctl enable-linger $USER

Docker Compose 설치 또는 확인

Docker 공식 APT 리포지토리의 경우, Compose를 플러그인으로 설치:

sudo apt update
sudo apt install docker-compose-plugin

확인:

docker compose version

Ubuntu 패키지를 설치한 경우:

sudo apt install docker-compose-v2

다음을 선호:

docker compose up -d

다음 구식 스타일보다:

docker-compose up -d

하이픈이 있는 docker-compose 명령어는 이전 독립형 Compose 시대에 속합니다. 많은 시스템에 여전히 있지만, 새로운 문서에서는 docker compose를 사용해야 합니다.

설치된 Docker 확인

머신을 인수하거나 깨진 설정을 디버깅할 때, 실제로 사용 중인 Docker 패키징을 식별하는 데 도움이 되는 명령어입니다.

Docker 바이너리 확인:

which docker

패키지 소유권 확인:

dpkg -S "$(which docker)"

Docker 관련 패키지 목록:

dpkg -l | grep -E 'docker|containerd|runc'

APT 정책 확인:

apt-cache policy docker-ce docker.io containerd.io docker-compose-plugin docker-compose-v2

Snap 확인:

snap list | grep docker

서비스 상태 확인:

systemctl status docker
systemctl status containerd

Docker 서버 세부 정보 확인:

docker info

docker info가 sudo 없이 실패하면 그룹 멤버십 확인:

groups

Ubuntu `docker.io`에서 Docker CE로 마이그레이션

Docker 중지:

sudo systemctl stop docker

Ubuntu 패키지 제거:

sudo apt remove docker.io docker-compose docker-compose-v2 docker-doc containerd runc

위 단계를 사용하여 Docker 공식 APT 리포지토리 추가.

Docker CE 설치:

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Docker 시작:

sudo systemctl start docker

기존 컨테이너 확인:

docker ps -a
docker images
docker volume ls

일반적으로 패키지 제거는 /var/lib/docker를 삭제하지 않으므로 이미지, 컨테이너 및 볼륨이 여전히 존재할 수 있습니다. 그래도 먼저 중요한 데이터를 백업하세요.

Docker Snap에서 Docker CE로 마이그레이션

먼저 존재하는 항목 검사:

snap list | grep docker
docker info

워크로드 중지 및 중요한 볼륨 또는 바인드 마운트 데이터 백업.

snap 제거:

sudo snap remove docker

그런 다음 공식 APT 리포지토리에서 Docker CE 설치.

데이터 위치에 주의하세요. Snap 패키지는 종종 다른 경로와 격리 규칙을 사용합니다. 마이그레이션 후 Docker Snap 데이터가 표준 /var/lib/docker 경로에 자동으로 나타날 것이라고 가정하지 마세요.

중요한 서비스의 경우, 패키지 소스를 전환하기 전에 데이터를 명시적으로 내보내거나 백업하세요.

APT로 Docker 버전 고정

프로덕션과 같은 시스템의 경우, 통제된 업그레이드가 필요할 수 있습니다.

사용 가능한 버전 목록:

apt list --all-versions docker-ce

특정 버전 설치:

VERSION_STRING="5:29.0.0-1~ubuntu.24.04~noble"

sudo apt install docker-ce=$VERSION_STRING \
  docker-ce-cli=$VERSION_STRING \
  containerd.io \
  docker-buildx-plugin \
  docker-compose-plugin

Docker 패키지 고정:

sudo apt-mark hold docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

나중에 고정 제거:

sudo apt-mark unhold docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

예측 가능한 변경 창이 필요할 때 이렇게 하세요. 개인 노트북의 경우 불필요할 수 있습니다.

방화벽 및 네트워킹 참고 사항

Docker는 컨테이너 네트워킹을 작동시키기 위해 패킷 필터링 규칙을 수정하므로, UFW, firewalld, nftables 또는 사용자 정의 방화벽 규칙을 사용하는 경우 중요합니다.

중요한 점:

게시된 Docker 포트는 단순한 UFW 기대치를 우회할 수 있습니다.
Docker는 iptables 통합을 사용합니다.
사용자 정의 규칙은 Docker 생성 체인을 고려해야 합니다.
서버 경화(hardening)는 실제 컨테이너 포트 매핑과 함께 테스트해야 합니다.
Docker가 게시한 포트를 ufw deny가 보호한다고 가정하지 마세요.

로컬 호스트가 아닌 다른 머신에서 노출된 포트를 테스트하세요.

예제:

docker run --rm -p 8080:80 nginx

그런 다음 다른 호스트에서:

curl http://server-ip:8080

서버에서 Docker 네트워킹은 설치 후 무시할 수 있는 구현 세부 사항이 아닌 보안 모델의 일부입니다.

일반적인 오류 및 수정

Docker 소켓 권한 거부

오류:

permission denied while trying to connect to the Docker daemon socket

수정 옵션:

sudo 사용:

sudo docker ps

또는 사용자를 docker 그룹에 추가:

sudo usermod -aG docker $USER
newgrp docker

docker 그룹은 실제로 root와 동등하므로, 그룹 멤버십을 privileged 접근 결정으로 취급하세요.

Docker 데몬 실행 중 아님

상태 확인:

sudo systemctl status docker

시작:

sudo systemctl start docker

로그 확인:

journalctl -u docker --no-pager -n 100

충돌하는 Docker 패키지

Docker CE 설치가 충돌로 인해 실패하면 구식 패키지를 제거하세요. Docker 리포지토리를 추가한 후 APT 자체가 나쁜 상태라면, 재시도하기 전에 Ubuntu APT troubleshooting for broken packages and GPG errors를 통해 해결하세요.

sudo apt remove docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc

그런 다음 재시도:

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Compose 명령어 찾을 수 없음

현대 Compose 확인:

docker compose version

플러그인 설치:

sudo apt install docker-compose-plugin

구식 명령어를 기대했다면:

docker-compose version

구식 문서를 따르고 있을 수 있습니다. 명령어를 docker compose로 업데이트하는 것을 선호하세요.

구식 root 소유 Docker 구성

그룹 접근을 설정하기 전에 sudo로 Docker를 실행했다면, 사용자 구성이 root에 의해 소유될 수 있습니다.

소유권 수정:

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

또는 필요하지 않으면 구성 제거:

sudo rm -rf "$HOME/.docker"

다시 생성됩니다.

루트리스 Docker 연결 실패

환경 확인:

echo "$DOCKER_HOST"

사용자 서비스 확인:

systemctl --user status docker

필요시 소켓 경로 설정:

export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock

정확함을 확인한 후 셸 프로필에 추가하세요.

Docker Engine 제거

Docker CE 패키지 제거:

sudo apt purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras

이미지, 컨테이너 및 볼륨을 정말 삭제하고 싶을 때만 Docker 데이터 제거:

sudo rm -rf /var/lib/docker
sudo rm -rf /var/lib/containerd

Docker 리포지토리 파일 제거:

sudo rm -f /etc/apt/sources.list.d/docker.sources
sudo rm -f /etc/apt/keyrings/docker.asc

APT 새로 고침:

sudo apt update

Docker Snap의 경우:

sudo snap remove docker

Ubuntu docker.io의 경우:

sudo apt purge docker.io docker-compose-v2

대부분의 Ubuntu 사용자에게 권장되는 설치 경로

대부분의 기술 Ubuntu 사용자에게, 다음은 깔끔한 경로입니다:

sudo apt remove docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc

sudo apt update
sudo apt install ca-certificates curl

sudo install -m 0755 -d /etc/apt/keyrings

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc

sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

sudo docker run hello-world

그런 다음 편의를 위한 그룹 접근 또는 더 긴밀한 격리를 위한 루트리스 Docker를 원하는지 결정:

sudo usermod -aG docker $USER
newgrp docker
docker run hello-world

최종 의견 기반 가이드라인

Ubuntu에서의 Docker 설치는 패키지 선택이 아닌 운영 선택입니다. 선택한 방법은 업그레이드, 보안 경계 및 호스트가 업스트림 Docker 문서와 얼마나 밀접하게 일치하는지에 영향을 미칩니다.

제 실용적인 규칙은 다음과 같습니다:

대부분의 개발자 및 DevOps 머신에는 Docker 공식 APT 리포지토리를 사용하세요.
업스트림 최신성보다 Ubuntu 리포지토리 일관성이 중요한 경우 Ubuntu docker.io를 사용하세요.
의도적으로 Snap 동작을 원하지 않는 한, 심각한 컨테이너 워크플로우에는 Docker Snap을 피하세요.
프로덕션 호스트에는 편의 스크립트를 피하세요.
구식 docker-compose가 아닌 현대 docker compose를 사용하세요.
docker 그룹을 privileged 접근으로 취급하세요.
사용자 격리가 중요한 경우 루트리스 Docker를 고려하세요.
프로덕션과 같은 시스템에서는 버전을 고정하세요.
서버에서 포트를 게시할 때 방화벽 동작을 테스트하세요.

가장 지루한 Docker 설치가 보통 가장 좋습니다: 공식 APT 리포지토리, 명시적 키링, Compose 플러그인, systemd 서비스, 이해된 권한 및 중간에 미스터리한 패키징 레이어가 없습니다. 엔진이 자리 잡으면, 셀프 호스팅 LLM 스택을 포함한 다중 서비스 워크로드가 자연스러운 다음 단계가 됩니다. 예를 들어, 컨테이너에서 로컬 모델을 실행하는 Ollama in Docker Compose를 참조하세요. 하나의 서버에서 재부팅을 통해 Compose 스택을 실행 상태로 유지하려면, Run Docker Compose as a Linux Service with systemd가 유닛 파일과 운영 습관을 안내합니다.

더 읽기

https://docs.docker.com/engine/install/ubuntu/ “Install Docker Engine on Ubuntu | Docker Docs”
https://packages.ubuntu.com/noble/docker.io “Ubuntu - Details of package docker.io in noble”