Instalacja Docker na Rocky Linux i AlmaLinux

Instalacja Docker na systemach Rocky Linux i AlmaLinux

Aby zainstalować Docker na systemach Rocky Linux lub AlmaLinux, należy dodać własne repozytorium dnf firmy Docker, zainstalować silnik wraz z wtyczką compose, a następnie włączyć usługę. Proces ten składa się z czterech poleceń i jest identyczny w obu dystrybucjach, ponieważ obie są kompilacjami Red Hat Enterprise Linux (RHEL) i współdzielą układ pakietów. CentOS Stream działa w ten sam sposób. Wszystkie poniższe informacje dotyczą obu systemów, więc jeśli nadal dokonujesz wyboru, czynnikami decydującymi są obietnica kompatybilności składana przez każdy z projektów oraz to, czy Twój starszy procesor jest nadal wspierany.

Instalacja jest krótka, dlatego większość tego przewodnika opisuje różnice w działaniu Enterprise Linux (EL) względem Ubuntu. Podman może już zajmować polecenie docker w Twoim obrazie. SELinux blokuje pliki montowane przez bind-mount, dopóki nie otrzymają one odpowiedniej etykiety. Firewalld nie filtruje portów udostępnionych przez Docker, więc port kontenera może być otwarty na świat, podczas gdy firewall-cmd raportuje, że żaden port nie jest otwarty.

Nie używaj skryptu wygody (convenience script) z get.docker.com. Dokumentacja Docker wskazuje, że nie jest on zalecany w środowiskach produkcyjnych. Skrypt nadpisuje konfigurację repozytoriów bez pytania i nie można go bezpiecznie uruchomić ponownie w celu aktualizacji. Ręczne dodanie repozytorium sprawia, że dnf upgrade traktuje Docker jak każdy inny pakiet w systemie. Dzięki temu silnik zostaje objęty działaniem dnf-automatic, jeśli używasz tego narzędzia do automatycznego stosowania aktualizacji bezpieczeństwa, więc zdecyduj wcześniej, czy chcesz, aby Docker był aktualizowany automatycznie, czy wstrzymywany do okna serwisowego. W obu przypadkach aktualizacja zastępuje plik binarny pakietu, podczas gdy stary dockerd nadal działa, a needs-restarting jest poleceniem, które wskazuje, które usługi nadal korzystają z kodu, który właśnie został zastąpiony.

Czy podman obsługuje już polecenie docker?

Systemy Rocky Linux i AlmaLinux dostarczają pakiet podman w domyślnych repozytoriach, a wiele obrazów VPS instaluje go automatycznie. Niektóre obrazy idą o krok dalej i instalują podman-docker, co umieszcza skrypt powłoki w /usr/bin/docker, który wywołuje podman. Każde wpisane polecenie docker uruchamia wtedy podman, więc poradnik napisany dla Docker generuje nieoczekiwane wyniki.

Pierwszą wskazówką jest baner. Skrypt /usr/bin/docker sprawdza obecność pliku /etc/containers/nodocker, a gdy plik ten nie istnieje, wyświetla jedną linię przed wykonaniem jakiejkolwiek operacji:

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

Ktoś mógł utworzyć ten plik, aby wyciszyć baner, więc nie należy polegać wyłącznie na tym. Należy zapytać bazę danych pakietów, który pakiet jest właścicielem pliku binarnego:

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

Odpowiedź zaczynająca się od podman-docker oznacza, że to podman obsługuje polecenie. Odpowiedź zaczynająca się od docker-ce-cli oznacza, że zainstalowano właściwy Docker. Jeśli rpm -qf zgłasza, że żaden pakiet nie jest właścicielem pliku, oznacza to, że został on zainstalowany ręcznie i przed zaufaniem mu należy przeczytać skrypt.

Podman uruchamia te same obrazy OCI i jest rozsądnym wyborem. Jeśli użytkownik go preferuje, należy w tym miejscu zakończyć. Oba rozwiązania to silniki kontenerów Linux, więc jeśli decyzja co do platformy nie została jeszcze podjęta, warto wiedzieć, że FreeBSD jails izolują pełne środowisko użytkownika zamiast uruchamiać warstwowe obrazy pobrane z rejestru. Jeśli wymagany jest Docker Engine, należy najpierw usunąć konfliktowe pakiety. Oto lista dokumentowana przez Docker dla RHEL:

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

Przed potwierdzeniem należy sprawdzić, co dnf planuje usunąć. Na świeżym obrazie VPS lista jest krótka. Na serwerze, który był już używany, usunięcie podman może spowodować usunięcie cockpit-podman lub innego narzędzia, które jest od niego zależne.

Utrzymanie podman obok Docker jest w zasadzie możliwe: należy usunąć tylko podman-docker, aby nazwa docker była dostępna, oraz runc, który jest zastępowany przez pakiet containerd.io. Dokumentacja Docker traktuje podman jako pakiet konfliktowy, więc taki układ nie jest wspierany przez Docker. Jeśli instalacja nadal zgłasza konflikt, należy użyć pełnej listy usuwania podanej powyżej.

Dodawanie repozytorium Docker za pomocą dnf config-manager

Docker publikuje pakiety RPM dla systemów Enterprise Linux pod adresem download.docker.com. Plik repozytorium wskazuje na drzewo CentOS, z którym integrują się Rocky Linux oraz AlmaLinux. Wskazanie repozytorium CentOS w systemie Rocky Linux może wydawać się błędem, dopóki nie zrozumie się w jaki sposób obie dystrybucje wywodzą się z linii CentOS po tym, jak Red Hat przekształcił CentOS w Stream w 2020 roku. Stan na sierpień 2026 potwierdza, że Docker dokumentuje to repozytorium dla CentOS Stream 9 oraz 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

Wersja 5 narzędzia dnf usunęła argument --add-repo, dlatego drugie polecenie kończy się niepowodzeniem w nowszych wydaniach. Sprawdź posiadaną wersję, a następnie wybierz odpowiednią formę:

dnf --version

Jeśli wyświetlona zostanie wersja 5.x, użyj formy z podpoleceniem:

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

Obie metody zapisują ten sam plik w /etc/yum.repos.d/docker-ce.repo. Błędna forma kończy się błędem nieznanego argumentu zamiast cichego wykonania nieprawidłowej operacji, więc nie przeoczysz tego komunikatu.

Plik repozytorium ustawia baseurl na ścieżkę zawierającą $releasever, a dnf rozwija tę zmienną na podstawie pakietu wydania. Rocky Linux i AlmaLinux ustawiają ją na numer głównej wersji, czyli 9 w EL 9 oraz 10 w EL 10, dlatego repozytorium CentOS poprawnie rozwiązuje ścieżki w systemie Rocky. Przed instalacją zweryfikuj rozwinięcie zmiennej:

sudo dnf repoinfo docker-ce-stable

Odczytaj linię Repo-baseurl. Powinna kończyć się ciągiem /9/x86_64/stable lub /10/x86_64/stable. Jeśli wydanie ustawia $releasever na wersję punktową, taką jak 9.6, dnf zgłosi błąd Status code: 404 dla tego adresu URL podczas pobierania metadanych. Napraw to, edytując /etc/yum.repos.d/docker-ce.repo i zastępując $releasever samym numerem głównej wersji.

Instalacja silnika i wtyczki compose

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

Pięć pakietów, z których każdy pełni określoną funkcję. docker-ce to demon, dockerd. docker-ce-cli to polecenie docker, które wpisujesz. containerd.io to środowisko uruchomieniowe kontenerów, którym steruje demon. docker-buildx-plugin służy do budowania obrazów. docker-compose-plugin dostarcza docker compose jako podpolecenie.

Pakiety te nie instalują pliku binarnego docker-compose z łącznikiem. Była to wersja Compose v1, której okres wsparcia zakończył się w lipcu 2023 roku. Każde wywołanie docker-compose z łącznikiem wymaga aktualizacji do docker compose ze spacją.

Pierwsza instalacja zatrzymuje się w celu zaimportowania klucza podpisu Docker i wyświetla jego odcisk palca. Klucz pochodzi z gpgkey=https://download.docker.com/linux/centos/gpg w pliku repozytorium, który właśnie dodano, dlatego przed zaakceptowaniem porównaj odcisk palca wyświetlony przez dnf z tym adresem URL.

Jeden błąd występuje na tyle często, że warto go wymienić. Jeśli dnf zgłasza, że containerd.io wymaga container-selinux i żaden pakiet go nie dostarcza, oznacza to, że repozytorium AppStream jest wyłączone. Uruchom dnf repolist i potwierdź, że appstream znajduje się na liście, ponieważ to właśnie tam container-selinux jest dostarczane w systemach EL 9 oraz EL 10.

Uruchomienie Docker i weryfikacja działania

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

Pakiety RPM oprogramowania Docker pozostawiają demona w stanie zatrzymanym i wyłączonym po instalacji. Z tego powodu ten krok pojawia się w dokumentacji Docker dla systemu CentOS, a nie dla Ubuntu, gdzie pakiet deb uruchamia usługę automatycznie. Pominięcie enable sprawi, że Docker będzie działał tylko do następnego restartu, po czym zostanie wyłączony, zabierając ze sobą wszystkie kontenery.

Polecenie systemctl status powinno zwrócić Active: active (running). Kontener hello-world powinien wyświetlić This message shows that your installation appears to be working correctly. i zakończyć działanie. Jeśli zamiast tego pojawi się błąd uprawnień do /var/run/docker.sock, oznacza to pominięcie sudo, co zostanie naprawione w sekcji dotyczącej grupy docker poniżej.

Sprawdź wtyczkę compose oddzielnie, ponieważ jest to osobny pakiet, który może być nieobecny, mimo poprawnego działania silnika:

docker compose version

Poprawna odpowiedź wygląda jak Docker Compose version v2.x.x. Przywracanie usług po restarcie to kwestia odrębna od włączania demona, a polityki restartu decydują, czy usługi Compose uruchomią się ponownie przy starcie systemu.

Dlaczego bind mount zwraca błąd permission denied?

Systemy Rocky Linux oraz AlmaLinux domyślnie uruchamiają SELinux (Security-Enhanced Linux) w trybie wymuszania (enforcing). Potwierdź to za pomocą getenforce, które wyświetla Enforcing.

Kontenery Docker działają z typem SELinux container_t, który może odczytywać i zapisywać wyłącznie pliki oznaczone etykietą container_file_t. Katalog utworzony na hoście dziedziczy etykietę od ścieżki nadrzędnej, która nie jest container_file_t. Kontener otrzymuje odmowę dostępu, mimo że właściciel, grupa oraz uprawnienia wyglądają poprawnie z perspektywy hosta. Problem można odtworzyć trzema poleceniami:

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

Kontener wyświetli komunikat:

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

Dwa polecenia wskazują przyczynę. ls -ldZ /srv/site wyświetla etykietę, która dla ścieżki w /srv wynosi system_u:object_r:var_t:s0, a nie container_file_t. Następnie sudo ausearch -m avc -ts recent wyświetla wpis w dzienniku audytu jądra, zawierający avc: denied { read }, pole scontext= wskazujące na container_t oraz pole tcontext= wskazujące na etykietę widoczną na katalogu. Niezgodność między tymi dwoma polami jest bezpośrednią przyczyną błędu.

Rozwiązaniem jest dodanie przyrostka do argumentu wolumenu. Docker automatycznie zmieni etykiety ścieżki:

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

:z zapisane małymi literami zmienia etykietę na współdzieloną, dzięki czemu kilka kontenerów może korzystać z tego samego katalogu. :Z zapisane wielkimi literami zmienia etykietę na prywatną i niewspółdzieloną, przypisaną do jednego kontenera; próba odczytu tej samej ścieżki przez drugi kontener zostanie odrzucona. Używaj :z dla zasobów, do których dostęp mają również kontenery typu sidecar lub backup. Używaj :Z dla katalogów baz danych, których właścicielem jest jeden kontener.

Dokumentacja Docker zawiera ostrzeżenie, które warto powtórzyć, ponieważ zmiana etykiet jest rekurencyjna. Bind mount katalogu systemowego, takiego jak /home lub /usr, z użyciem :Z „czyni maszynę hosta niezdatną do pracy i może wymagać ręcznego przywrócenia etykiet plików hosta”. Stosuj te przyrostki wyłącznie dla katalogów utworzonych na potrzeby kontenera, nigdy dla ścieżek systemowych.

W pliku Compose przyrostek dodaje się do tego samego ciągu znaków:

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

Łatwo natknąć się na dwa ograniczenia. Flaga --mount nie pozwala na ustawienie etykiety SELinux, dlatego w razie potrzeby należy użyć -v. Wolumeny nazwane nie wymagają przyrostka, ponieważ Docker samodzielnie etykietuje katalogi tworzone w /var/lib/docker/volumes.

Nie wyłączaj SELinux. Używaj sudo setenforce 0 wyłącznie jako minutowego testu: jeśli kontener po tym zadziała, problemem jest etykieta, a rozwiązaniem :z. Natychmiast przywróć tryb wymuszania za pomocą sudo setenforce 1. W systemach Enterprise Linux błąd permission denied przy bind mount ma dwie odrębne przyczyny, które z wnętrza kontenera wyglądają identycznie. Pierwszą jest etykieta SELinux. Drugą są standardowe numeryczne uprawnienia użytkownika i grupy, czyli problem, który rozwiązują zmienne PUID i PGID. ls -lnZ wyświetla uprawnienia, numerycznego właściciela oraz etykietę w jednej linii, co pozwala ustalić, z którym problemem masz do czynienia.

Dlaczego opublikowany port jest dostępny, mimo że firewalld wskazuje na zamknięcie?

Firewalld jest domyślnym firewallem w systemach Rocky Linux oraz AlmaLinux. Sprawdź jego działanie za pomocą sudo systemctl is-active firewalld. Jeśli konfiguracja nie została jeszcze przeprowadzona, otwarcie portu SSH i portu WWW w firewalld powinno być pierwszym krokiem, ponieważ poniższe zjawisko jest zrozumiałe dopiero po posiadaniu działającego zestawu reguł strefy. Opublikuj port i sprawdź, co firewalld uznaje za otwarte:

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

firewall-cmd wyświetla pustą linię. Z innej maszyny polecenie curl -I http://YOUR_SERVER_IP:8080/ zwraca HTTP/1.1 200 OK. Port jest otwarty na świat, a firewall nie zgłasza żadnych reguł.

Przyczyną jest ścieżka, którą pokonuje pakiet. Reguły stref firewalld filtrują ruch skierowany do samego hosta. Opublikowany port nie jest adresowany do hosta: Docker instaluje regułę NAT (network address translation) typu destination, która przepisuje adres docelowy na adres kontenera, zanim pakiet dotrze do ścieżki wejściowej hosta. W rezultacie jądro przekazuje pakiet dalej, zamiast dostarczać go lokalnie. Docker umieszcza swoje interfejsy mostkowe w strefie firewalld o nazwie docker, której celem jest ACCEPT, oraz dodaje politykę przekazywania docker-forwarding, która zezwala na forwardowanie z dowolnej strefy do strefy docker. Reguły Twojej strefy nigdy nie widzą tego pakietu.

Najczystsze rozwiązanie nie wymaga reguł firewalla. Powiąż hostową stronę publikacji z interfejsem loopback i umieść przed nią reverse proxy:

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/

Lokalne curl zwraca HTTP/1.1 200 OK, a to samo żądanie z innej maszyny nie nawiązuje już połączenia. Każdy port bez określonego adresu hosta w argumencie -p jest publikowany na wszystkich interfejsach, dlatego traktuj surowe -p 8080:80 jako decyzję o publicznym udostępnieniu usługi.

Jeśli usługa musi być dostępna tylko z wybranych adresów, Docker rezerwuje dla Ciebie odpowiedni łańcuch. DOCKER-USER jest przetwarzany przed własnymi regułami akceptacji Dockera, więc reguła tam umieszczona przetrwa restart Dockera i nadpisanie przez niego łańcuchów:

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

Pobierz nazwę interfejsu z ip route show default zamiast zakładać eth0, ponieważ obecne obrazy EL używają nazw takich jak enp1s0 lub ens3. W systemach Rocky i AlmaLinux polecenie iptables jest warstwą kompatybilności nad nftables, a łańcuchy Dockera są przez nie widoczne. Reguły dodane w ten sposób znikają po restarcie, chyba że zostaną zapisane, więc po przetestowaniu należy umieścić je w jednostce systemd.

Docker Engine 28.0, wydany w 2025 roku, zamknął lukę: bezpośredni dostęp routowany do portów kontenerów, które nie zostały opublikowane, jest teraz blokowany w łańcuchu DOCKER. Ta zmiana nie dotyczy portów opublikowanych, więc powyższe zasady pozostają aktualne w obecnych wersjach. Warto wyrobić sobie nawyk: po każdym sudo firewall-cmd --reload przetestuj ponownie opublikowany port. Jeśli przestał odpowiadać, sudo systemctl restart docker przywróci reguły Dockera.

Administratorzy Ubuntu napotykają ten sam problem przy użyciu innego narzędzia, co wyjaśniono w dlaczego opublikowane porty Dockera ignorują reguły ufw. W obu przypadkach przyczyną jest ścieżka NAT. Zmienia się jedynie używany firewall.

Dodawanie użytkownika bez uprawnień root do grupy docker

Wpisywanie sudo przed każdym poleceniem docker staje się uciążliwe, a przynależność do grupy docker eliminuje tę konieczność:

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

usermod -aG modyfikuje /etc/group, jednak bieżąca powłoka posiada już załadowaną listę grup, więc zmiana nie zostanie zastosowana do momentu uruchomienia nowej sesji. newgrp docker uruchamia powłokę z przypisaną grupą, co pozwala na natychmiastowe przetestowanie zmian. Nowe sesje SSH pobierają te uprawnienia automatycznie.

Należy mieć świadomość, jakie uprawnienia nadaje ta grupa. Członkostwo zapewnia dostęp do zapisu w /var/run/docker.sock, a każdy proces komunikujący się z tym gniazdem może zlecić demonowi uruchomienie kontenera, który zamontuje system plików hosta. Jedno polecenie obrazuje konsekwencje tego rozwiązania:

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

Polecenie to odczytuje plik dostępny tylko dla użytkownika root z poziomu konta, które nie posiada uprawnień sudo. Dokumentacja Docker potwierdza ten fakt: grupa docker nadaje uprawnienia równoważne z root. Dodawaj konto do tej grupy tylko wtedy, gdy przyznałbyś mu również sudo. Jeśli konfigurujesz konta na nowym serwerze, podejmij tę decyzję w ramach zasady minimalnych uprawnień na VPS, a nie po fakcie.

Docker oferuje również tryb rootless, w którym demon działa jako użytkownik bez uprawnień administracyjnych. Jest to odrębna ścieżka instalacji, która zmienia sposób działania sterowników pamięci masowej oraz portów poniżej 1024, dlatego należy zaplanować to jako osobne zadanie, a nie jako opcję dodawaną w późniejszym czasie.

Dalsze kroki

System posiada już silnik, wtyczkę compose, usługę działającą po restarcie oraz trzy zachowania specyficzne dla EL opisane powyżej. Kolejnym etapem jest compose.yaml dla każdej usługi, a struktura pliku Compose omawia format pliku oraz polecenia, które nim sterują. Jeśli jest to pierwszy host kontenerowy, uruchamianie Docker na VPS wyjaśnia kwestie doboru rozmiaru, pamięci masowej oraz higieny obrazów, które zostały pominięte w tym przewodniku.

FAQ

Czy repozytorium Docker dla CentOS działa na systemach Rocky Linux i AlmaLinux?

Tak. Należy dodać https://download.docker.com/linux/centos/docker-ce.repo za pomocą dnf config-manager. Plik baseurl zawiera zmienną $releasever, którą systemy Rocky Linux i AlmaLinux rozwijają do numeru wersji głównej. Dzięki temu system EL 9 wskazuje na drzewo CentOS 9, a EL 10 na drzewo CentOS 10. Rozwinięcie zmiennej można potwierdzić poleceniem sudo dnf repoinfo docker-ce-stable, sprawdzając linię Repo-baseurl. Błąd Status code: 404 podczas pobierania metadanych przez dnf oznacza, że zmienna rozwinęła się do wersji punktowej; rozwiązaniem jest edycja /etc/yum.repos.d/docker-ce.repo i wpisanie samego numeru wersji głównej.

Czy Docker i podman mogą być zainstalowane na tym samym serwerze?

Dokumentacja Docker wskazuje podman oraz runc jako pakiety konfliktowe i zaleca usunięcie obu przed instalacją Docker Engine. Bezpośrednim źródłem konfliktu jest pakiet podman-docker, który zarządza plikiem /usr/bin/docker i sprawia, że każde polecenie docker jest interpretowane jako polecenie podman. Wykonaj rpm -qf "$(command -v docker)", aby sprawdzić, który pakiet zarządza tą ścieżką. Jeśli wynik zaczyna się od podman-docker, odpowiedzi udziela podman. Utrzymywanie obu silników nie jest wspierane przez Docker, dlatego na serwerach produkcyjnych należy wybrać jeden z nich.

Dlaczego kontener zgłasza permission denied przy montowaniu typu bind mount?

SELinux działa domyślnie w trybie enforcing na systemach Rocky Linux i AlmaLinux. Kontenery działają z typem container_t i mogą uzyskiwać dostęp tylko do plików oznaczonych jako container_file_t. Katalog utworzony w systemie posiada niewłaściwą etykietę, co skutkuje odmową dostępu niezależnie od właściciela i uprawnień. Można to potwierdzić poleceniem ls -ldZ dla ścieżki hosta oraz sudo ausearch -m avc -ts recent, które wyświetli avc: denied z informacją o niedopasowaniu kontekstów. Należy dodać :z do argumentu wolumenu dla danych współdzielonych między kontenerami lub :Z dla danych prywatnych. Nigdy nie należy wskazywać :Z na /home lub /usr, ponieważ zmiana etykiet jest rekurencyjna i spowoduje uszkodzenie systemu hosta.

Czy muszę otwierać port w firewalld, aby udostępnić port kontenera?

Nie, i to właśnie stanowi problem. Reguła NAT w Docker nadpisuje adres docelowy, zanim pakiet dotrze do ścieżki wejściowej hosta, więc reguły stref firewalld nie są sprawdzane. Docker umieszcza również swoje mosty w strefie firewalld o nazwie docker z celem ACCEPT. Kontener uruchomiony z -p 8080:80 jest dostępny z Internetu, podczas gdy sudo firewall-cmd --list-ports nie zwraca żadnych informacji. Aby ograniczyć dostęp tylko do hosta, należy publikować porty na konkretnym adresie za pomocą -p 127.0.0.1:8080:80 lub wstawić reguły filtrujące do łańcucha DOCKER-USER, który Docker przetwarza przed własnymi regułami akceptacji.

Czy dodanie użytkownika do grupy docker jest bezpieczne?

Daje to uprawnienia root. Członek grupy docker może zapisywać do /var/run/docker.sock, a docker run --rm -v /:/host alpine wc -l /host/etc/shadow odczytuje plik dostępny tylko dla root z konta bez uprawnień sudo. Dokumentacja instalacyjna Docker potwierdza tę równoważność. Do grupy należy dodawać tylko konta, którym już powierzono sudo, a dla kont współdzielonych lub serwisowych należy używać sudo docker. Alternatywą dla kontenerów uruchamianych przez użytkownika bez uprawnień jest tryb rootless, który wymaga osobnej ścieżki instalacji, a nie tylko zmiany ustawień.