Rocky Linux 및 AlmaLinux에 Docker 설치 방법

Rocky Linux 및 AlmaLinux에 Docker 설치하기

Rocky Linux나 AlmaLinux에 Docker를 설치하려면 Docker의 공식 dnf 저장소를 추가하고, compose 플러그인과 함께 엔진을 설치한 뒤 서비스를 활성화해야 합니다. 이 과정은 4개의 명령어로 구성되며, 두 배포판 모두 Red Hat Enterprise Linux(RHEL)를 기반으로 재구축되어 패키지 구조를 공유하므로 동일하게 적용됩니다. CentOS Stream도 같은 방식으로 작동합니다.

설치 과정은 짧으므로, 이 가이드의 대부분은 Enterprise Linux(EL)가 Ubuntu와 다르게 동작하는 부분을 다룹니다. 이미지에 따라 Podman이 이미 docker 명령어를 점유하고 있을 수 있습니다. SELinux는 바인드 마운트된 파일에 올바른 레이블이 지정되지 않으면 접근을 차단합니다. Firewalld는 Docker가 게시한 포트를 필터링하지 않으므로, firewall-cmd에서는 아무것도 열려 있지 않다고 보고하더라도 컨테이너 포트는 인터넷에 노출될 수 있습니다.

get.docker.com에서 제공하는 Docker 편의 스크립트는 사용하지 마십시오. Docker 공식 문서에서도 프로덕션 환경에는 권장하지 않는다고 명시되어 있습니다. 이 스크립트는 사용자 동의 없이 저장소 설정을 재작성하며, 업그레이드를 위해 안전하게 재실행할 수 없습니다. 저장소를 직접 추가하면 dnf upgrade가 Docker를 시스템의 다른 모든 패키지와 동일하게 관리할 수 있습니다.

Podman이 이미 docker 명령에 응답하고 있습니까?

Rocky Linux와 AlmaLinux는 기본 저장소에 podman을 포함하고 있으며, 많은 VPS 이미지에 기본적으로 설치되어 있습니다. 일부 이미지는 한 걸음 더 나아가 podman-docker을 설치하는데, 이는 /usr/bin/docker에 podman을 호출하는 셸 스크립트를 배치합니다. 따라서 사용자가 입력하는 모든 docker 명령은 실제로는 podman을 실행하게 되며, Docker를 기준으로 작성된 가이드가 예상치 못한 결과를 출력하게 됩니다.

가장 먼저 확인할 수 있는 신호는 배너 메시지입니다. /usr/bin/docker 스크립트는 /etc/containers/nodocker 파일의 존재 여부를 확인하며, 해당 파일이 없을 경우 명령을 실행하기 전에 한 줄의 메시지를 출력합니다.

Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.

누군가 배너를 숨기기 위해 해당 파일을 생성했을 수도 있으므로 이 메시지만 전적으로 신뢰해서는 안 됩니다. 패키지 데이터베이스에 해당 바이너리를 소유한 패키지가 무엇인지 확인하십시오.

command -v docker
rpm -qf "$(command -v docker)"

podman-docker로 시작하는 결과가 나오면 podman이 응답하고 있는 것입니다. docker-ce-cli로 시작하는 결과가 나오면 실제 Docker가 설치된 것입니다. 만약 rpm -qf이 해당 파일을 소유한 패키지가 없다고 보고한다면, 누군가 수동으로 설치한 것이므로 스크립트를 신뢰하기 전에 내용을 먼저 읽어보아야 합니다.

Podman은 동일한 OCI 이미지를 실행하며 합리적인 선택지가 될 수 있습니다. Podman을 사용하려 한다면 여기서 멈추십시오. Docker Engine을 원한다면 먼저 충돌하는 패키지들을 제거해야 합니다. 다음은 RHEL용으로 Docker가 문서화한 목록입니다.

sudo dnf remove docker docker-client docker-client-latest docker-common \
  docker-latest docker-latest-logrotate docker-logrotate docker-engine podman runc

확인하기 전에 dnf가 삭제하려는 패키지 목록을 확인하십시오. 새로 설치한 VPS 이미지에서는 목록이 짧습니다. 이미 사용 중인 서버라면 podman을 제거할 때 cockpit-podman나 이에 의존하는 다른 도구까지 함께 삭제될 수 있습니다.

원칙적으로는 podman과 Docker를 함께 유지할 수 있습니다. podman-docker만 제거하여 docker 이름을 비우고, containerd.io 패키지가 대체하는 runc를 제거하는 방식입니다. 하지만 Docker 공식 문서에서는 podman을 충돌 패키지로 간주하므로, 이러한 구성은 Docker에서 지원하지 않습니다. 설치 과정에서 여전히 충돌이 보고된다면 위의 전체 제거 목록을 사용하십시오.

dnf config-manager를 사용하여 Docker 저장소 추가하기

Docker는 Enterprise Linux용 RPM을 download.docker.com에 배포합니다. 저장소 파일은 Rocky Linux와 AlmaLinux가 참조하는 CentOS 트리와 연결됩니다. 2026년 8월 확인 결과, Docker는 CentOS Stream 9 및 CentOS Stream 10에 대해 이 저장소를 공식 지원합니다.

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

dnf 버전 5부터는 --add-repo 인수가 제거되었으므로, 최신 릴리스에서는 두 번째 명령이 실패합니다. 설치된 버전을 확인한 후 적절한 명령어를 선택하십시오.

dnf --version

출력된 버전이 5.x라면 다음 하위 명령 형식을 사용하십시오.

sudo dnf config-manager addrepo --from-repofile=https://download.docker.com/linux/centos/docker-ce.repo

두 방식 모두 /etc/yum.repos.d/docker-ce.repo에 동일한 파일을 생성합니다. 잘못된 형식을 사용하면 조용히 오류가 발생하는 대신 알 수 없는 인수 오류가 발생하므로, 실수를 바로 인지할 수 있습니다.

해당 저장소 파일은 baseurl을 $releasever을 포함하는 경로로 설정하며, dnf는 릴리스 패키지에서 이 변수를 확장합니다. Rocky Linux와 AlmaLinux는 이를 메이저 버전 번호로 설정하므로 EL 9에서는 9, EL 10에서는 10이 됩니다. 이것이 바로 CentOS 저장소가 Rocky 시스템에서 올바르게 작동하는 이유입니다. 설치 전 확장된 경로를 확인하십시오.

sudo dnf repoinfo docker-ce-stable

Repo-baseurl 줄을 확인하십시오. 이 줄은 /9/x86_64/stable 또는 /10/x86_64/stable으로 끝나야 합니다. 만약 릴리스 설정에서 $releasever이 9.6과 같은 포인트 버전으로 지정되어 있다면, dnf가 메타데이터를 가져올 때 해당 URL에 대해 Status code: 404 오류를 보고합니다. 이 경우 /etc/yum.repos.d/docker-ce.repo을 편집하여 $releasever 부분을 메이저 버전 번호로 수정하십시오.

엔진 및 compose 플러그인 설치

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

다섯 개의 패키지가 각각의 역할을 수행합니다. docker-ce는 데몬인 dockerd입니다. docker-ce-cli는 사용자가 입력하는 docker 명령어입니다. containerd.io은 데몬이 구동하는 컨테이너 런타임입니다. docker-buildx-plugin은 이미지를 빌드합니다. docker-compose-plugin은 docker compose를 하위 명령어로 제공합니다.

이 패키지들은 하이픈이 포함된 docker-compose 바이너리를 설치하지 않습니다. 이는 2023년 7월에 수명이 종료된 Compose v1입니다. 하이픈을 포함하여 docker-compose을 호출하는 모든 항목은 공백을 사용하는 docker compose로 업데이트해야 합니다.

최초 설치 시 Docker의 서명 키를 가져오며 지문(fingerprint)을 표시합니다. 해당 키는 방금 추가한 저장소 파일의 gpgkey=https://download.docker.com/linux/centos/gpg에서 제공되므로, 수락하기 전에 dnf가 출력하는 지문과 해당 URL의 값을 비교하십시오.

자주 발생하는 실패 사례가 하나 있습니다. dnf가 containerd.io에 container-selinux가 필요하지만 제공하는 패키지가 없다고 보고한다면, AppStream 저장소가 비활성화된 상태입니다. dnf repolist을 실행하여 appstream이 목록에 있는지 확인하십시오. EL 9 및 EL 10에서는 해당 저장소에서 container-selinux을 제공하기 때문입니다.

Docker 시작 및 실행 확인

sudo systemctl enable --now docker
sudo systemctl status docker --no-pager
sudo docker run --rm hello-world

Docker의 RPM 패키지는 설치 후 데몬을 중지 및 비활성화 상태로 둡니다. 이것이 바로 이 단계가 Docker의 Ubuntu 페이지에는 없고 CentOS 페이지에만 있는 이유입니다. Ubuntu의 deb 패키지는 서비스를 자동으로 시작하기 때문입니다. enable 단계를 건너뛰면 Docker는 다음 재부팅 전까지만 실행되며, 재부팅 후에는 서비스가 내려가 모든 컨테이너도 함께 중단됩니다.

systemctl status 명령은 Active: active (running)을 출력해야 합니다. hello-world 컨테이너는 This message shows that your installation appears to be working correctly.을 출력하고 종료되어야 합니다. 만약 /var/run/docker.sock에서 권한 오류가 발생한다면 sudo를 누락한 것이며, 이는 아래의 docker 그룹 섹션에서 해결할 수 있습니다.

compose 플러그인은 별도의 패키지이므로 엔진이 정상 작동하더라도 누락될 수 있습니다. 따라서 별도로 확인해야 합니다.

docker compose version

정상적인 결과는 Docker Compose version v2.x.x과 같습니다. 재부팅 후 서비스를 복구하는 것은 데몬 활성화와는 별개의 문제이며, 재시작 정책(restart policies)이 부팅 시 Compose 서비스의 재시작 여부를 결정합니다.

바인드 마운트에서 권한 거부(permission denied)가 발생하는 이유는 무엇입니까?

Rocky Linux와 AlmaLinux는 기본적으로 SELinux(Security-Enhanced Linux)를 enforcing 모드로 실행합니다. getenforce 명령을 실행하여 이를 확인하십시오. 이 명령은 Enforcing을 출력합니다.

Docker 컨테이너는 SELinux 타입인 container_t로 실행되며, 이 타입은 container_file_t으로 레이블이 지정된 파일만 읽고 쓸 수 있습니다. 호스트에서 생성한 디렉터리는 상위 경로의 레이블을 그대로 상속받는데, 이는 container_file_t이 아닙니다. 호스트 측에서 소유자, 그룹, 모드가 올바르게 보이더라도 컨테이너 내부에서는 접근이 거부됩니다. 다음 세 가지 명령으로 이 현상을 재현할 수 있습니다.

sudo mkdir -p /srv/site
echo hello | sudo tee /srv/site/index.html
sudo docker run --rm -v /srv/site:/usr/share/nginx/html:ro nginx:alpine cat /usr/share/nginx/html/index.html

컨테이너는 다음과 같이 출력합니다.

cat: can't open '/usr/share/nginx/html/index.html': Permission denied

두 가지 명령으로 원인을 파악할 수 있습니다. ls -ldZ /srv/site는 레이블을 출력하는데, /srv 하위 경로의 경우 system_u:object_r:var_t:s0이며 container_file_t가 아닙니다. 이어서 sudo ausearch -m avc -ts recent은 커널의 감사 기록을 출력합니다. 여기에는 avc: denied { read }, container_t를 명시하는 scontext= 필드, 그리고 방금 확인한 디렉터리 레이블을 명시하는 tcontext= 필드가 포함되어 있습니다. 이 두 필드 간의 불일치가 문제의 핵심입니다.

해결 방법은 볼륨 인수에 접미사를 추가하는 것입니다. 그러면 Docker가 해당 경로의 레이블을 자동으로 다시 지정합니다.

sudo docker run --rm -v /srv/site:/usr/share/nginx/html:ro,z nginx:alpine cat /usr/share/nginx/html/index.html

소문자 :z은 콘텐츠를 공유 가능하도록 레이블을 다시 지정하므로, 여러 컨테이너가 동일한 디렉터리를 사용할 수 있습니다. 대문자 :Z는 이를 비공개 및 비공유 상태로 레이블을 다시 지정하여 하나의 컨테이너에 종속시킵니다. 이 경우 두 번째 컨테이너가 동일한 경로를 읽으려 하면 거부됩니다. 사이드카나 백업 컨테이너가 접근해야 하는 경우에는 :z을 사용하십시오. 단일 컨테이너가 소유하는 데이터베이스 디렉터리에는 :Z를 사용하십시오.

Docker 문서에는 반복해서 강조할 만한 경고가 있습니다. 레이블 재지정은 재귀적으로 수행되기 때문입니다. /home나 /usr과 같은 시스템 디렉터리를 :Z 옵션으로 바인드 마운트하면 "호스트 머신이 작동 불능 상태가 될 수 있으며, 호스트 머신 파일을 수동으로 다시 레이블링해야 할 수도 있습니다." 이러한 접미사는 컨테이너를 위해 직접 생성한 디렉터리에만 사용하고, 시스템 경로에는 절대 사용하지 마십시오.

Compose에서는 동일한 문자열 뒤에 접미사를 붙입니다.

services:
  web:
    image: nginx:alpine
    volumes:
      - /srv/site:/usr/share/nginx/html:ro,z

두 가지 제한 사항에 주의해야 합니다. --mount 플래그는 SELinux 레이블을 설정할 수 없으므로, 레이블이 필요한 경우에는 -v를 사용하십시오. 명명된 볼륨(Named volumes)은 Docker가 /var/lib/docker/volumes 하위에 생성하는 디렉터리에 직접 레이블을 지정하므로 접미사가 필요 없습니다.

SELinux를 끄지 마십시오. sudo setenforce 0은 1분 정도의 테스트 용도로만 사용하십시오. 만약 컨테이너가 정상 작동한다면 문제는 레이블에 있는 것이며, :z가 해결책입니다. 테스트 후에는 즉시 sudo setenforce 1으로 다시 켜십시오. Enterprise Linux에서 바인드 마운트 시 발생하는 permission denied는 컨테이너 내부에서 볼 때 동일해 보이는 두 가지 원인이 있습니다. 하나는 SELinux 레이블 문제이고, 다른 하나는 일반적인 숫자 기반 사용자 및 그룹 소유권 문제입니다. 이는 PUID 및 PGID 변수로 해결할 수 있습니다. ls -lnZ를 사용하면 모드, 숫자 기반 소유자, 레이블을 한 줄로 확인할 수 있으므로 어떤 문제를 해결해야 하는지 구분할 수 있습니다.

FAQ

firewalld는 닫혀 있는데 왜 게시된 포트에 접근할 수 있습니까?

firewalld는 Rocky Linux와 AlmaLinux의 기본 방화벽입니다. sudo systemctl is-active firewalld 명령으로 방화벽이 실행 중인지 확인하십시오. 이제 포트를 게시하고 firewalld가 무엇을 열려 있다고 판단하는지 확인합니다.

sudo docker run -d --name web -p 8080:80 nginx:alpine
sudo firewall-cmd --list-ports

firewall-cmd 명령은 빈 줄을 출력합니다. 다른 기기에서 curl -I http://YOUR_SERVER_IP:8080/ 명령을 실행하면 HTTP/1.1 200 OK 결과가 반환됩니다. 포트는 인터넷에 열려 있지만 방화벽은 아무것도 보고하지 않습니다.

원인은 패킷이 이동하는 경로에 있습니다. firewalld의 영역 규칙은 호스트 자체를 대상으로 하는 트래픽만 필터링합니다. 게시된 포트는 호스트를 대상으로 하지 않습니다. Docker는 패킷이 호스트의 입력 경로에 도달하기 전에 목적지를 컨테이너 주소로 다시 쓰는 DNAT(네트워크 주소 변환) 규칙을 설치하므로, 커널은 패킷을 로컬로 전달하는 대신 포워딩합니다. Docker는 브리지 인터페이스를 docker이라는 firewalld 영역에 배치하고 해당 영역의 대상을 ACCEPT로 설정하며, 모든 영역에서 docker 영역으로의 포워딩을 허용하는 docker-forwarding라는 포워딩 정책을 추가합니다. 따라서 사용자의 영역 규칙은 패킷을 전혀 볼 수 없습니다.

가장 깔끔한 해결책은 방화벽 규칙을 사용하지 않는 것입니다. 게시할 호스트 측 포트를 루프백 주소에 바인딩하고 그 앞에 리버스 프록시를 배치하십시오.

sudo docker rm -f web
sudo docker run -d --name web -p 127.0.0.1:8080:80 nginx:alpine
curl -I http://127.0.0.1:8080/

로컬에서 curl 명령을 실행하면 HTTP/1.1 200 OK가 반환되지만, 다른 기기에서 동일한 요청을 보내면 더 이상 연결되지 않습니다. -p 인수에 호스트 주소가 없으면 모든 인터페이스에 게시되므로, 단순히 -p 8080:80만 지정하는 것은 해당 서비스를 공개적으로 노출하겠다는 결정으로 간주해야 합니다.

특정 주소에서만 서비스에 접근할 수 있도록 제한해야 할 경우, Docker가 제공하는 체인을 사용하십시오. DOCKER-USER은 Docker 자체의 허용 규칙보다 먼저 처리되므로, 여기에 추가한 규칙은 Docker가 재시작되어 체인을 다시 작성하더라도 유지됩니다.

sudo iptables -I DOCKER-USER -i enp1s0 ! -s 203.0.113.10 -j DROP
sudo iptables -S DOCKER-USER

현재 EL 이미지들은 enp1s0이나 ens3와 같은 이름을 사용하므로, eth0을 가정하기보다 ip route show default에서 인터페이스 이름을 확인하십시오. Rocky 및 AlmaLinux에서 iptables 명령은 nftables 위의 호환성 계층이며, Docker의 체인은 이를 통해 확인할 수 있습니다. 이 방식으로 추가된 규칙은 저장하지 않으면 재부팅 후 사라지므로, 설정이 완료되면 systemd 유닛에 작성하십시오.

2025년에 출시된 Docker Engine 28.0은 인접한 보안 허점을 해결했습니다. 게시되지 않은 컨테이너 포트에 대한 직접적인 라우팅 접근은 이제 DOCKER 체인에서 차단됩니다. 이 변경 사항은 게시된 포트에는 영향을 미치지 않으므로, 최신 버전에서도 위 내용은 모두 유효합니다. 한 가지 운영 습관을 들이는 것이 좋습니다. sudo firewall-cmd --reload 명령을 실행한 후에는 게시된 포트를 다시 테스트하십시오. 응답이 중단되었다면 sudo systemctl restart docker 명령으로 Docker의 규칙을 다시 설치할 수 있습니다.

Ubuntu 관리자들도 다른 도구를 통해 동일한 문제에 직면하며, 자세한 내용은 게시된 Docker 포트가 ufw 규칙을 무시하는 이유를 참조하십시오. 두 경우 모두 NAT 경로가 원인이며, 앞단에 있는 방화벽의 종류만 다를 뿐입니다.

docker 그룹에 root가 아닌 사용자 추가하기

모든 docker 명령어 앞에 sudo를 입력하는 것은 번거로운 일이며, docker 그룹을 사용하면 이를 해결할 수 있습니다.

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

usermod -aG는 /etc/group를 수정하지만, 현재 셸은 이미 그룹 목록을 가지고 있으므로 새로운 셸을 실행하기 전까지는 변경 사항이 적용되지 않습니다. newgrp docker를 실행하면 그룹이 적용된 셸이 시작되므로 즉시 테스트할 수 있습니다. 새로운 SSH 세션은 자동으로 변경 사항을 반영합니다.

이 그룹이 부여하는 권한을 명확히 이해해야 합니다. 그룹 멤버가 되면 /var/run/docker.sock에 대한 쓰기 권한을 갖게 되며, 해당 소켓과 통신할 수 있는 모든 주체는 데몬에 호스트 파일 시스템을 마운트하는 컨테이너를 시작하도록 요청할 수 있습니다. 다음 명령어 하나로 그 의미를 확인할 수 있습니다.

docker run --rm -v /:/host alpine wc -l /host/etc/shadow

이 명령어는 sudo 권한이 없는 계정으로 root만 읽을 수 있는 파일을 읽어옵니다. Docker의 공식 설치 후 문서에서도 명시하듯, docker 그룹은 root와 동일한 권한을 부여합니다. 해당 계정에 sudo 권한을 부여할 의사가 있는 경우에만 계정을 그룹에 추가하십시오. 새로운 서버에 계정을 설정하는 중이라면, 나중에 처리하기보다 VPS에서의 최소 권한 사용자 설정 과정에서 함께 결정하십시오.

Docker는 데몬을 권한이 없는 사용자로 실행하는 rootless 모드도 제공합니다. 이는 별도의 설치 경로를 가지며 스토리지 드라이버와 1024번 미만 포트의 동작 방식이 달라지므로, 나중에 추가하는 옵션이 아닌 별도의 프로젝트로 계획해야 합니다.

다음 단계

이제 엔진, compose 플러그인, 재부팅 후에도 유지되는 서비스, 그리고 위에서 설명한 3가지 EL 전용 동작을 모두 갖추었습니다. 다음 단계는 서비스별 compose.yaml를 구성하는 것이며, Compose 파일의 구조에서 파일 형식과 이를 실행하는 명령어를 다룹니다. 이번이 첫 번째 컨테이너 호스트라면, VPS에서 Docker 실행하기를 통해 이 가이드에서 다루지 않은 사이징, 스토리지, 이미지 관리 관련 문제를 확인하십시오.

FAQ

Docker의 CentOS 저장소가 Rocky Linux와 AlmaLinux에서 작동합니까?

네, 작동합니다. https://download.docker.com/linux/centos/docker-ce.repo를 dnf config-manager으로 추가하십시오. 해당 파일의 baseurl에는 $releasever이 포함되어 있으며, Rocky Linux와 AlmaLinux는 이를 메이저 버전 번호로 확장합니다. 따라서 EL 9 시스템은 CentOS 9 트리로, EL 10 시스템은 CentOS 10 트리로 해석됩니다. sudo dnf repoinfo docker-ce-stable로 확장을 확인하고 Repo-baseurl 라인을 읽어 보십시오. dnf가 메타데이터를 가져올 때 Status code: 404이 발생한다면, 변수가 포인트 릴리스로 확장된 것이므로 /etc/yum.repos.d/docker-ce.repo를 편집하여 메이저 버전 번호만 사용하도록 수정하면 해결됩니다.

Docker와 podman을 같은 서버에 설치할 수 있습니까?

Docker 문서에서는 podman과 runc를 충돌하는 패키지로 분류하며, Docker Engine을 설치하기 전에 둘 다 제거할 것을 권장합니다. 구체적인 충돌 원인은 /usr/bin/docker을 소유하고 모든 docker 명령을 podman 명령으로 변환하는 podman-docker 패키지입니다. rpm -qf "$(command -v docker)"을 실행하여 해당 경로를 소유한 패키지를 확인하십시오. 출력 결과가 podman-docker로 시작한다면 podman이 응답하고 있는 것입니다. 두 엔진을 모두 유지하는 것은 Docker가 지원하는 구성이 아니므로, 중요한 서버라면 하나만 선택하십시오.

바인드 마운트에서 컨테이너가 permission denied 오류를 내는 이유는 무엇입니까?

Rocky Linux와 AlmaLinux에서는 SELinux가 기본적으로 강제(enforcing) 모드로 동작합니다. 컨테이너는 container_t 타입으로 실행되며 container_file_t로 레이블이 지정된 파일에만 접근할 수 있습니다. 따라서 사용자가 생성한 디렉터리는 잘못된 레이블을 가지고 있어 소유자나 권한 모드와 관계없이 접근이 거부됩니다. 호스트 경로에서 ls -ldZ를 실행하고, 일치하지 않는 두 컨텍스트를 출력하는 sudo ausearch -m avc -ts recent과 avc: denied를 통해 이를 확인하십시오. 컨테이너 간 공유되는 콘텐츠에는 볼륨 인수에 :z를 추가하고, 단일 컨테이너 전용 콘텐츠에는 :Z을 추가하십시오. :Z을 /home이나 /usr로 지정하지 마십시오. 레이블 재지정 작업이 재귀적으로 수행되어 호스트 시스템을 손상시킬 수 있습니다.

컨테이너 포트를 공개하려면 firewalld에서 포트를 열어야 합니까?

아니요, 오히려 그것이 문제입니다. Docker의 NAT 규칙은 패킷이 호스트의 입력 경로에 도달하기 전에 목적지 주소를 다시 작성하므로, firewalld의 영역 규칙은 이를 검사하지 않습니다. 또한 Docker는 브리지를 ACCEPT 타겟을 가진 docker이라는 firewalld 영역에 배치합니다. -p 8080:80로 시작된 컨테이너는 sudo firewall-cmd --list-ports이 아무것도 출력하지 않더라도 인터넷에서 접근할 수 있습니다. 호스트에서만 서비스에 접근해야 한다면 -p 127.0.0.1:8080:80를 사용하여 특정 주소로 공개하거나, Docker가 자체 허용 규칙을 처리하기 전에 실행되는 DOCKER-USER 체인에 필터링 규칙을 삽입하십시오.

사용자를 docker 그룹에 추가하는 것은 안전합니까?

이는 root 권한을 부여하는 것과 같습니다. docker 그룹의 구성원은 /var/run/docker.sock에 쓸 수 있으며, docker run --rm -v /:/host alpine wc -l /host/etc/shadow은 sudo 권한이 없는 계정에서도 root 전용 파일을 읽을 수 있게 합니다. Docker의 설치 후 문서에서도 동일한 권한 수준임을 명시하고 있습니다. 이미 sudo을 맡길 수 있는 신뢰할 수 있는 계정만 추가하고, 공유 계정이나 서비스 계정은 계속해서 sudo docker를 사용하십시오. 권한이 없는 사용자로 컨테이너를 실행해야 할 때는 Rootless 모드가 대안이며, 이는 설정 변경이 아닌 별도의 설치 경로를 따릅니다.