Paano Mag-install ng Docker sa Rocky Linux at AlmaLinux

Mag-install ng Docker sa Rocky Linux at AlmaLinux

Para mag-install ng Docker sa Rocky Linux o AlmaLinux, idagdag ang sariling dnf repository ng Docker, i-install ang engine kasama ang compose plugin, at i-enable ang service. Apat na command lang ang bahaging ito, at pareho ito sa dalawang distribution dahil parehong rebuild ng Red Hat Enterprise Linux (RHEL) ang mga ito at pareho ang package layout. Pareho rin ang proseso sa CentOS Stream. Nalalapat ang lahat ng nasa ibaba sa dalawang distribution, kaya kung pumipili ka pa sa pagitan ng mga ito, ang dapat pagbatayan ay ang compatibility promise ng bawat project at kung supported pa ang mas lumang CPU mo.

Maikli ang proseso ng installation, kaya karamihan sa guide na ito ay tungkol sa mga pagkakaiba ng Enterprise Linux (EL) kumpara sa Ubuntu. Maaaring ginagamit na ng Podman ang docker command sa image mo. Bina-block ng SELinux ang mga file na bind-mounted hanggang mailapat sa mga ito ang tamang label. Hindi sini-filter ng Firewalld ang published ports ng Docker, kaya maaaring bukas sa internet ang container port kahit iniulat ng firewall-cmd na walang bukas na port.

Huwag gamitin ang convenience script ng Docker mula sa get.docker.com. Ayon sa sariling documentation ng Docker, hindi ito inirerekomenda para sa production. Binabago nito ang repository configuration mo nang walang confirmation, at hindi ito ligtas na patakbuhin muli para sa upgrade. Kapag mano-mano mong idinagdag ang repository, itinuturing ng dnf upgrade ang Docker na parang iba pang package sa server. Dahil dito, saklaw din ng dnf-automatic, kung ginagamit mo itong awtomatikong nag-a-apply ng security updates ayon sa schedule, ang engine. Kaya maaga pa lang, magpasya kung gusto mong awtomatikong ma-patch ang Docker o ipagpaliban ito hanggang sa maintenance window. Alinman ang piliin mo, pinapalitan ng upgrade ang packaged binary habang patuloy na tumatakbo ang lumang dockerd, at ang needs-restarting ang command na nagsasabi kung aling mga service ang gumagamit pa rin ng code na pinalitan mo.

Nang sumasagot na ba ang podman sa docker command?

Kasama ang podman sa default repositories ng Rocky Linux at AlmaLinux, at ini-install ito ng maraming VPS image para sa iyo. May ilang image na mas kumpleto pa at nag-i-install ng podman-docker, na naglalagay ng shell script sa /usr/bin/docker na tumatawag sa podman. Kaya ang bawat docker command na tina-type mo ay podman ang nagpapatakbo, at nagsisimulang maglabas ng output na hindi mo inaasahan ang isang gabay na isinulat para sa Docker.

Ang unang palatandaan ay isang banner. Sinusuri ng /usr/bin/docker script ang file na /etc/containers/nodocker, at kapag wala ang file na iyon, nagpi-print ito ng isang linya bago magpatakbo ng anuman:

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

Maaaring may gumawa ng file na iyon upang patahimikin ang banner, kaya huwag itong gawing tanging batayan. Itanong sa package database kung aling package ang may-ari ng binary:

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

Nangangahulugang podman ang sumasagot kapag nagsisimula sa podman-docker ang sagot. Nangangahulugang totoong Docker naman kapag nagsisimula sa docker-ce-cli ang sagot. Kapag nag-ulat ang rpm -qf na walang package na nagmamay-ari sa file, maaaring mano-manong na-install ito, kaya basahin muna ang script bago ito pagkatiwalaan.

Pinapatakbo ng Podman ang parehong OCI image at makatuwiran itong piliin. Kung ito ang gusto mo, maaari kang huminto rito. Pareho silang Linux container engine, kaya kung bukas pa ang desisyon sa platform, mahalagang malaman na ini-isolate ng FreeBSD jail ang isang buong userland sa halip na magpatakbo ng layered image na kinukuha mula sa registry. Kung Docker Engine ang gusto mo, alisin muna ang mga package na nagkakaroon ng conflict. Ito ang listahang itinatala ng Docker para sa RHEL:

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

Basahin muna kung ano ang planong alisin ng dnf bago mo kumpirmahin. Sa bagong VPS image, maikli ang listahan. Sa server na nagamit na ng iba, maaaring maalis ng pag-remove sa podman ang cockpit-podman o iba pang tool na nakadepende rito.

Posibleng pagsabayin sa prinsipyo ang podman at Docker: podman-docker lamang ang alisin upang maging available ang pangalang docker, pati ang runc na pinapalitan ng package na containerd.io. Itinuturing ng dokumentasyon ng Docker ang podman bilang conflicting package, kaya hindi sinusuportahan ng Docker ang ganitong setup. Kung mag-ulat pa rin ng conflict ang installation, gamitin ang buong listahan ng removal sa itaas.

Magdagdag ng Docker repository gamit ang dnf config-manager

Naglalabas ang Docker ng mga RPM para sa Enterprise Linux sa download.docker.com. Tumuturo ang repository file sa CentOS tree, na siyang ginagamit ng Rocky Linux at AlmaLinux. Mukhang mali ang pagturo ng Rocky box sa CentOS repository hanggang malaman mo kung paano nagmula ang dalawang distribution sa CentOS lineage matapos gawing Stream ng Red Hat ang CentOS noong 2020. Noong sinuri noong August 2026, idinodokumento ng Docker ang repository na ito para sa CentOS Stream 9 at 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

Inalis ng Version 5 ng dnf ang --add-repo argument, kaya mabibigo ang ikalawang command sa mga mas bagong release. Tingnan kung aling version ang mayroon ka, at gamitin ang katugmang anyo:

dnf --version

Kung mag-print ito ng 5.x version, gamitin ang subcommand form:

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

Parehong isinusulat ng dalawang form ang file sa /etc/yum.repos.d/docker-ce.repo. Mabibigo ang maling form na may unknown-argument error sa halip na gumawa ng tahimik na maling pagbabago, kaya mapapansin mo ito.

Itinatakda ng repo file na iyon ang baseurl sa isang path na naglalaman ng $releasever, at ine-expand ng dnf ang variable na iyon mula sa release package mo. Itinatakda ito ng Rocky Linux at AlmaLinux sa major version number, kaya 9 sa EL 9 at 10 sa EL 10. Ito ang dahilan kung bakit wastong nareresolba ang CentOS repository sa Rocky box. Kumpirmahin ang expansion bago mag-install:

sudo dnf repoinfo docker-ce-stable

Basahin ang Repo-baseurl line. Dapat itong magtapos sa /9/x86_64/stable o /10/x86_64/stable. Kung itinatakda ng release mo ang $releasever sa point version gaya ng 9.6, magrereport ang dnf ng Status code: 404 para sa URL na iyon kapag kumukuha ito ng metadata. Ayusin ito sa pamamagitan ng pag-edit sa /etc/yum.repos.d/docker-ce.repo at pagpapalit ng $releasever sa bare major number.

I-install ang engine at ang compose plugin

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

Limang package ang kailangan, at may isang partikular na gawain ang bawat isa. Ang docker-ce ay ang daemon, dockerd. Ang docker-ce-cli ay ang docker command na tina-type mo. Ang containerd.io ang container runtime na pinapatakbo ng daemon. Ang docker-buildx-plugin ang nagbu-build ng images. Ang docker-compose-plugin ang nagbibigay ng docker compose bilang subcommand.

Hindi nag-i-install ang mga package na ito ng hyphenated na docker-compose binary. Iyon ang Compose v1, na nag-end of life noong July 2023. Kailangang i-update ang anumang tumatawag sa docker-compose na may hyphen upang gamitin ang docker compose na may space.

Humihinto ang unang install upang i-import ang Docker signing key at ipinapakita ang fingerprint nito. Nagmumula ang key sa gpgkey=https://download.docker.com/linux/centos/gpg sa repo file na idinagdag mo. Kaya ihambing ang fingerprint na ipinapakita ng dnf sa URL na iyon bago mo ito tanggapin.

May isang failure na sapat na madalas mangyari para bigyang-pansin. Kung iniulat ng dnf na kailangan ng containerd.io ang container-selinux at walang nagbibigay nito, disabled ang iyong AppStream repository. Patakbuhin ang dnf repolist at tiyaking nakalista ang appstream, dahil doon nagmumula ang container-selinux sa EL 9 at EL 10.

Simulan ang Docker at tiyaking tumatakbo ito

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

Pagkatapos i-install, naka-stop at naka-disable ang daemon sa RPM packages ng Docker. Kaya nasa Docker CentOS page ang hakbang na ito at wala sa Ubuntu page, kung saan awtomatikong sinisimulan ng deb package ang service. Kapag nilaktawan ang enable, tatakbo ang Docker hanggang sa susunod na reboot. Pagkatapos nito, mananatili itong down at isasama nito ang lahat ng container.

Dapat ipakita ng systemctl status ang Active: active (running). Dapat i-print ng hello-world container ang This message shows that your installation appears to be working correctly. at pagkatapos ay mag-exit. Kung permission error naman ang i-print nito sa /var/run/docker.sock, hindi mo isinama ang sudo. Inaayos ito ng seksyon sa ibaba tungkol sa docker group.

Hiwalay na suriin ang Compose plugin dahil ibang package ito. Maaaring wala ito kahit maayos ang engine:

docker compose version

Ganito ang inaasahang healthy na resulta: Docker Compose version v2.x.x. Ang pagbabalik ng iyong mga service pagkatapos ng reboot ay ibang usapin kaysa sa pag-enable ng daemon. Ang restart policy ang nagtatakda kung babalik sa boot ang mga Compose service.

Bakit nagkakaroon ng permission denied ang bind mount?

Naka-enable bilang default ang SELinux (Security-Enhanced Linux) sa enforcing mode sa Rocky Linux at AlmaLinux. Kumpirmahin ito gamit ang getenforce, na nagpi-print ng Enforcing.

Tumatakbo ang Docker containers sa ilalim ng SELinux type na container_t. Maaari lamang magbasa at magsulat ang type na ito sa mga file na may label na container_file_t. Ang directory na ginawa mo sa host ay nagmamana ng label ng parent path nito, at hindi ito container_file_t. Tinatanggihan ang container kahit mukhang tama ang owner, group, at mode mula sa host. I-reproduce ito gamit ang tatlong command:

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

Ito ang output ng container:

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

Dalawang command ang magpapakita ng sanhi. Ipi-print ng ls -ldZ /srv/site ang label. Para sa path sa ilalim ng /srv, ang label ay system_u:object_r:var_t:s0, hindi container_file_t. Pagkatapos, ipi-print ng sudo ausearch -m avc -ts recent ang audit record ng kernel. Naglalaman ito ng avc: denied { read }, isang scontext= field na tumutukoy sa container_t, at isang tcontext= field na tumutukoy sa label na nakita mo sa directory. Ang hindi pagtutugma ng dalawang field na ito ang buong sanhi.

Ang fix ay isang suffix sa volume argument. Awtomatikong nire-relabel ng Docker ang path:

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

Kapag lowercase ang :z, nire-relabel nito ang content bilang shared para magamit ng maraming container ang parehong directory. Kapag uppercase ang :Z, nire-relabel nito ang content bilang private at unshared. Itinatali ito sa isang container, kaya tatanggihan ang ikalawang container kapag binasa nito ang parehong path. Gamitin ang :z para sa anumang directory na ginagamit din ng sidecar o backup container. Gamitin ang :Z para sa database directory na pagmamay-ari ng isang container.

May mahalagang babala ang dokumentasyon ng Docker dahil recursive ang relabel. Kapag nag-bind-mount ng system directory gaya ng /home o /usr gamit ang :Z, "renders your host machine inoperable and you may need to relabel the host machine files by hand". Ituro ang mga suffix na ito sa mga directory na ginawa mo para sa container. Huwag kailanman gamitin ang mga ito sa system path.

Sa Compose, ilagay ang suffix sa parehong string:

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

Madaling mapagkamalan ang dalawang limitasyon. Hindi makakapagtakda ng SELinux label ang --mount flag, kaya gamitin ang -v kapag kailangan mo ng label. Hindi kailangan ng suffix ng named volumes dahil awtomatikong nilalagyan ng Docker ng label ang mga directory na ginagawa nito sa ilalim ng /var/lib/docker/volumes.

Huwag i-disable ang SELinux. Gamitin lamang ang sudo setenforce 0 bilang isang minutong test. Kung gumana ang container pagkatapos nito, label ang problema at :z ang sagot. Ibalik agad ito gamit ang sudo setenforce 1. Sa Enterprise Linux, may dalawang magkahiwalay na sanhi ang permission denied sa bind mount na magkapareho ang hitsura mula sa loob ng container. Ang isa ay ang SELinux label. Ang isa pa ay ordinaryong numeric user at group ownership. Ito ang dahilan kung bakit umiiral ang PUID at PGID variables. Ipinapakita ng ls -lnZ ang mode, numeric owner, at label sa isang linya, kaya matutukoy mo kung alin ang kailangang ayusin.

Bakit naaabot ang isang published port kapag mukhang sarado ang firewalld?

Ang firewalld ang default firewall sa Rocky Linux at AlmaLinux. Tiyaking tumatakbo ito gamit ang sudo systemctl is-active firewalld. Kung hindi mo pa ito na-configure sa server na ito, unahin ang pagbubukas ng SSH at web port gamit ang firewalld, dahil mauunawaan lamang ang sumusunod na problema kapag mayroon ka nang gumaganang zone ruleset na paghahambingan. Mag-publish ngayon ng port at tingnan kung ano ang itinuturing na bukas ng firewalld:

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

Nagpi-print ang firewall-cmd ng isang walang-lamang linya. Mula sa ibang machine, nagbabalik ang curl -I http://YOUR_SERVER_IP:8080/ ng HTTP/1.1 200 OK. Bukas sa internet ang port, ngunit walang iniuulat ang firewall mo.

Ang sanhi ay ang dinaanang path ng packet. Sinasala ng mga zone rule ng firewalld ang traffic na nakatalaga mismo sa host. Hindi sa host nakatalaga ang isang published port. Nag-i-install ang Docker ng destination NAT (network address translation) rule na nagbabago sa destination address para tumukoy sa address ng container bago makarating ang packet sa input path ng host. Dahil dito, ipinapasa ng kernel ang packet sa halip na ihatid ito nang lokal. Inilalagay naman ng Docker ang mga bridge interface nito sa firewalld zone na tinatawag na docker, na may target na ACCEPT. Nagdaragdag din ito ng forwarding policy na tinatawag na docker-forwarding, na nagpapahintulot ng forwarding mula sa anumang zone papunta sa docker zone. Hindi nakikita ng mga zone rule mo ang packet.

Hindi kailangan ng firewall rule ang pinakamalinis na ayos. I-bind ang host side ng publish sa loopback at maglagay ng reverse proxy sa harap nito:

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/

Nagbabalik ang lokal na curl ng HTTP/1.1 200 OK, at hindi na kumokonekta ang parehong request mula sa ibang machine. Ang anumang walang host address sa argumentong -p ay pino-publish sa bawat interface. Kaya ituring ang isang bare -p 8080:80 bilang desisyong gawing public ang service na iyon.

Kapag kailangan mong maabot ang isang service mula sa ilang address ngunit hindi mula sa iba, naglalaan ang Docker ng chain para sa iyo. Pinoproseso ang DOCKER-USER bago ang sariling accept rule ng Docker. Kaya mananatili ang rule na inilagay mo roon kahit mag-restart ang Docker at muling isulat ang mga chain nito:

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

Kunin ang pangalan ng interface mula sa ip route show default sa halip na ipagpalagay ang eth0, dahil gumagamit ang mga kasalukuyang EL image ng mga pangalan gaya ng enp1s0 o ens3. Sa Rocky at AlmaLinux, ang command na iptables ay compatibility layer para sa nftables, at makikita rito ang mga chain ng Docker. Mawawala ang mga rule na idinagdag sa ganitong paraan pagkatapos ng reboot maliban kung ise-save mo ang mga ito. Kaya ilagay ang mga ito sa isang systemd unit kapag nakumpirma mong tama na ang mga ito.

Isinara ng Docker Engine 28.0, na inilabas noong 2025, ang kaugnay na butas: bina-block na ngayon sa DOCKER chain ang direct routed access sa mga container port na hindi kailanman na-publish. Hindi naaapektuhan ng pagbabagong iyon ang mga published port, kaya naaangkop pa rin ang lahat ng nasa itaas sa mga kasalukuyang version. May isang operational habit na dapat mong buuin: pagkatapos ng anumang sudo firewall-cmd --reload, subukang muli ang isang published port. Kung hindi na ito sumagot, muling ini-install ng sudo systemctl restart docker ang mga rule ng Docker.

Nararanasan din ng mga Ubuntu administrator ang parehong problema gamit ang ibang tool, na ipinaliliwanag sa kung bakit binabalewala ng published Docker port ang mga rule ng ufw. Ang NAT path ang sanhi sa parehong kaso. Ang firewall lamang na nasa unahan nito ang nagkakaiba.

Magdagdag ng non-root user sa docker group

Nakakasawa ang pag-type ng sudo bago ang bawat command na docker. Inaalis ng docker group ang pangangailangang ito:

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

Ini-edit ng usermod -aG ang /etc/group, pero mayroon nang group list ang kasalukuyang shell mo. Kaya hindi agad naaangkop ang pagbabago hanggang sa magsimula ka ng bagong shell. Nagbubukas ang newgrp docker ng shell na kasama ang group, kaya masusubukan mo agad ang pagbabago. Awtomatikong makukuha ito ng mga bagong SSH session.

Linawin kung anong access ang ibinibigay ng group na ito. Nagbibigay ang membership ng write access sa /var/run/docker.sock. Anumang makakakonekta sa socket na iyon ay maaaring humiling sa daemon na magsimula ng container na nagmo-mount sa filesystem ng host. Ipinapakita ng isang command kung ano ang ibig sabihin nito:

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

Binabasa nito ang file na root lamang ang maaaring magbasa, gamit ang account na walang sudo rights. Ganito rin ang sinasabi sa sariling post-install documentation ng Docker: ang docker group ay nagbibigay ng mga privilege na katumbas ng root. Magdagdag lamang ng account dito kung bibigyan mo rin ang account na iyon ng sudo. Kung nagse-set up ka ng mga account sa bagong server, pagdesisyunan ito kasabay ng iba pang bahagi ng iyong least-privilege user setup sa isang VPS, hindi pagkatapos ma-configure ang lahat.

May rootless mode din ang Docker na nagpapatakbo sa daemon bilang unprivileged user. Hiwalay itong install path at binabago nito kung paano gumagana ang storage drivers at ang mga port na mas mababa sa 1024. Kaya planuhin ito bilang hiwalay na proyekto, hindi bilang flag na idaragdag mo sa hinaharap.

Saan susunod

Mayroon ka na ngayong engine, Compose plugin, isang serbisyong nananatiling gumagana pagkatapos ng reboot, at ang tatlong behavior na partikular sa EL na nakadokumento sa itaas. Ang susunod na hakbang ay isang compose.yaml bawat serbisyo. Sinasaklaw ng anatomya ng Compose file ang format ng file at ang mga command na nagpapatakbo nito. Kung ito ang una mong container host, sinasaklaw ng pagpapatakbo ng Docker sa isang VPS ang mga tanong tungkol sa sizing, storage, at image hygiene na hindi kasama sa gabay na ito.

FAQ

Gumagana ba ang Docker's CentOS repository sa Rocky Linux at AlmaLinux?

Oo. Idagdag ang https://download.docker.com/linux/centos/docker-ce.repo gamit ang dnf config-manager. Naglalaman ang baseurl sa file na iyon ng $releasever, at ine-expand ito ng Rocky Linux at AlmaLinux sa major version number, kaya nireresolba ng isang EL 9 box ang CentOS 9 tree at ng isang EL 10 box ang CentOS 10 tree. Kumpirmahin ang expansion gamit ang sudo dnf repoinfo docker-ce-stable at basahin ang linyang Repo-baseurl. Kapag may Status code: 404 habang kumukuha ng metadata ang dnf, nangangahulugan itong na-expand ang variable sa isang point release. Ayusin ito sa pamamagitan ng pag-edit sa /etc/yum.repos.d/docker-ce.repo para gamitin ang bare major number.

Maaaring i-install ang Docker at podman sa iisang server?

Nakalista sa documentation ng Docker ang podman at runc bilang conflicting packages, at sinasabi nitong alisin muna ang dalawa bago i-install ang Docker Engine. Ang aktuwal na conflict ay ang podman-docker package, na nagmamay-ari sa /usr/bin/docker at ginagawang podman command ang bawat docker command. Patakbuhin ang rpm -qf "$(command -v docker)" para makita kung aling package ang nagmamay-ari sa path na iyon. Kung nagsisimula sa podman-docker ang output, podman ang sumasagot. Hindi suportado ng Docker ang pagpapatakbo ng dalawang engine nang sabay, kaya pumili ng isa sa server na iyon.

Bakit may permission denied ang container ko sa bind mount?

Enforcing bilang default ang SELinux sa Rocky Linux at AlmaLinux. Tumatakbo ang mga container bilang type na container_t at maaari lamang humawak ng mga file na may label na container_file_t. Kaya maling label ang dala ng directory na ginawa mo, at dini-deny ang access anuman ang owner at mode nito. Kumpirmahin ito gamit ang ls -ldZ sa host path at sudo ausearch -m avc -ts recent, na nagpi-print ng avc: denied kasama ang dalawang hindi tugmang context. Idagdag ang :z sa volume argument para sa content na ibinabahagi sa pagitan ng mga container, o :Z para sa content na pribado sa isang container. Huwag kailanman ituro ang :Z sa /home o /usr, dahil recursive ang relabel at masisira nito ang host.

Kailangan ko bang magbukas ng port sa firewalld para ma-publish ang container port?

Hindi, at iyon ang problema. Binabago ng NAT rule ng Docker ang destination address bago makarating ang packet sa input path ng host, kaya hindi ito sinusuri ng zone rules ng firewalld. Inilalagay rin ng Docker ang mga bridge nito sa firewalld zone na tinatawag na docker, na may target na ACCEPT. Ang container na sinimulan gamit ang -p 8080:80 ay maaabot mula sa internet, habang walang inilalabas ang sudo firewall-cmd --list-ports. I-publish sa isang partikular na address gamit ang -p 127.0.0.1:8080:80 kung host lamang ang dapat makaabot sa service, o magpasok ng filtering rules sa DOCKER-USER chain, na pinoproseso ng Docker bago ang sarili nitong accept rules.

Ligtas ba ang pagdaragdag ng user ko sa docker group?

Nagbibigay ito ng root access. Maaaring sumulat ang miyembro ng docker group sa /var/run/docker.sock, at mababasa naman ng docker run --rm -v /:/host alpine wc -l /host/etc/shadow ang file na para lamang sa root mula sa account na walang sudo rights. Pareho ang equivalence na ito sa post-install documentation ng Docker. Idagdag lamang ang mga account na pagkakatiwalaan mo na rin sa sudo, at patuloy na gamitin ang sudo docker para sa shared o service accounts. Ang rootless mode ang alternatibo kapag kailangan mong magpatakbo ng mga container sa ilalim ng unprivileged user. Hiwalay itong install path at hindi setting lamang.