Rocky Linux, AlmaLinux లలో Docker ఎలా ఇన్‌స్టాల్ చేయాలి?

Rocky Linux మరియు AlmaLinux లపై Docker ఇన్‌స్టాలేషన్

Rocky Linux లేదా AlmaLinux లపై Docker ఇన్‌స్టాల్ చేయడానికి, మీరు Docker యొక్క సొంత dnf రిపోజిటరీని జోడించి, compose ప్లగిన్‌తో ఇంజిన్‌ను ఇన్‌స్టాల్ చేసి, ఆపై సర్వీస్‌ను ఎనేబుల్ చేయాలి. ఈ ప్రక్రియలో నాలుగు కమాండ్లు ఉంటాయి. ఇవి రెండూ Red Hat Enterprise Linux (RHEL) యొక్క పునర్నిర్మాణాలు (rebuilds) మరియు ఒకే విధమైన ప్యాకేజీ నిర్మాణాన్ని కలిగి ఉంటాయి కాబట్టి, రెండు డిస్ట్రిబ్యూషన్లలోనూ ఈ కమాండ్లు ఒకేలా పనిచేస్తాయి. CentOS Stream కూడా ఇదే విధంగా పనిచేస్తుంది. కింద ఉన్న సమాచారం రెండింటికీ వర్తిస్తుంది, కాబట్టి మీరు ఇంకా వీటిలో దేనిని ఎంచుకోవాలో నిర్ణయించుకోకపోతే, ప్రతి ప్రాజెక్ట్ ఇచ్చే అనుకూలత హామీ మరియు మీ పాత CPU కి మద్దతు ఉందా లేదా అనేవి నిర్ణయాత్మక అంశాలు.

ఇన్‌స్టాలేషన్ చాలా చిన్నది, కాబట్టి ఈ గైడ్‌లో ఎక్కువ భాగం Enterprise Linux (EL) మరియు Ubuntu ల మధ్య ఉన్న వ్యత్యాసాల గురించి వివరిస్తుంది. మీ ఇమేజ్‌లో ఇప్పటికే docker కమాండ్ Podman ఆధీనంలో ఉండవచ్చు. bind-mounted ఫైళ్లకు సరైన లేబుల్ లేకపోతే SELinux వాటిని బ్లాక్ చేస్తుంది. Firewalld అనేది Docker ప్రచురించిన పోర్టులను ఫిల్టర్ చేయదు, కాబట్టి firewall-cmd ద్వారా ఏ పోర్టులు తెరిచి లేవని చూపిస్తున్నప్పటికీ, ఒక కంటైనర్ పోర్ట్ ఇంటర్నెట్‌కు బహిర్గతం అయ్యే అవకాశం ఉంది.

get.docker.com నుండి Docker యొక్క కన్వీనియన్స్ స్క్రిప్ట్‌ను ఉపయోగించవద్దు. ఇది ప్రొడక్షన్ వాతావరణానికి సిఫార్సు చేయబడదని Docker డాక్యుమెంటేషన్ చెబుతోంది. ఇది మీ రిపోజిటరీ కాన్ఫిగరేషన్‌ను అడగకుండానే మార్చివేస్తుంది మరియు అప్‌గ్రేడ్ కోసం దీనిని సురక్షితంగా మళ్ళీ రన్ చేయలేము. రిపోజిటరీని మాన్యువల్‌గా జోడించడం వల్ల, dnf upgrade మీ సిస్టమ్‌లోని ఇతర ప్యాకేజీల మాదిరిగానే Docker ను కూడా పరిగణిస్తుంది. దీనివల్ల మీరు సెక్యూరిటీ అప్‌డేట్‌లను టైమర్ ద్వారా ఆటోమేటిక్‌గా అప్లై చేస్తుంటే, dnf-automatic ద్వారా Docker ఇంజిన్ కూడా అప్‌డేట్ అవుతుంది. కాబట్టి Docker ను ఆటోమేటిక్‌గా ప్యాచ్ చేయాలా లేదా మెయింటెనెన్స్ విండో వరకు వేచి ఉండాలా అనేది ముందే నిర్ణయించుకోండి. ఏది ఏమైనప్పటికీ, అప్‌గ్రేడ్ చేసినప్పుడు ప్యాకేజీలోని బైనరీ మారుతుంది, కానీ పాత dockerd రన్ అవుతూనే ఉంటుంది. కాబట్టి మీరు ఇప్పుడే రీప్లేస్ చేసిన కోడ్‌ను ఏ సర్వీసులు ఇంకా వాడుతున్నాయో తెలుసుకోవడానికి needs-restarting కమాండ్‌ను ఉపయోగించండి.

docker కమాండ్‌కు ఇప్పటికే podman సమాధానమిస్తోందా?

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 ఇమేజ్‌లను రన్ చేస్తుంది మరియు ఇది ఒక మంచి ఎంపిక. మీకు ఇది కావాలంటే, ఇక్కడే ఆగిపోండి. రెండూ Linux కంటైనర్ ఇంజిన్‌లే, కాబట్టి ప్లాట్‌ఫారమ్ నిర్ణయం ఇంకా తీసుకోకపోతే, FreeBSD jails రిజిస్ట్రీ నుండి లాగిన లేయర్డ్ ఇమేజ్‌లను రన్ చేయడానికి బదులుగా పూర్తి యూజర్‌ల్యాండ్‌ను వేరు చేస్తాయి అని తెలుసుకోవడం మంచిది. మీకు 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 పేరు ఖాళీ అవుతుంది, మరియు runcను తొలగించండి, దీనిని containerd.io ప్యాకేజీ భర్తీ చేస్తుంది. Docker డాక్యుమెంటేషన్ podmanను వైరుధ్యంగా ఉన్న ప్యాకేజీగా పరిగణిస్తుంది, కాబట్టి ఈ అమరికకు Docker మద్దతు ఇవ్వదు. ఇన్‌స్టాలేషన్ ఇప్పటికీ వైరుధ్యాన్ని చూపిస్తుంటే, పైన పేర్కొన్న పూర్తి తొలగింపు జాబితాను ఉపయోగించండి.

dnf config-manager తో Docker రిపోజిటరీని జోడించడం

Docker తన RPMలను Enterprise Linux కోసం download.docker.com వద్ద విడుదల చేస్తుంది. ఈ రిపోజిటరీ ఫైల్ CentOS ట్రీని సూచిస్తుంది, దీనినే Rocky Linux మరియు AlmaLinux కూడా ఉపయోగిస్తాయి. 2020లో Red Hat సంస్థ CentOSను Streamగా మార్చిన తర్వాత, ఈ రెండు డిస్ట్రిబ్యూషన్లు CentOS వంశం నుండి ఎలా ఉద్భవించాయో తెలియనంత వరకు, Rocky బాక్స్‌ను CentOS రిపోజిటరీకి మళ్లించడం పొరపాటుగా అనిపించవచ్చు. ఆగస్టు 2026 నాటికి, 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 లో రాస్తాయి. తప్పు ఫార్మాట్‌ను ఉపయోగిస్తే, అది నిశ్శబ్దంగా తప్పుగా పనిచేయకుండా, తెలియని ఆర్గ్యుమెంట్ (unknown-argument) ఎర్రర్‌ను చూపిస్తుంది, కాబట్టి మీరు దానిని సులభంగా గుర్తించవచ్చు.

ఆ రిపోజిటరీ ఫైల్ baseurl ను $releasever ఉన్న పాత్‌కు సెట్ చేస్తుంది, మరియు dnf మీ రిలీజ్ ప్యాకేజీ నుండి ఆ వేరియబుల్‌ను విస్తరిస్తుంది (expand). 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 స్థానంలో కేవలం మేజర్ నంబర్‌ను మాత్రమే ఉంచండి.

ఇంజిన్ మరియు కంపోజ్ ప్లగిన్‌ను ఇన్‌స్టాల్ చేయండి

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 బైనరీని ఇన్‌స్టాల్ చేయవు. అది Compose v1, ఇది జూలై 2023లో ముగిసింది (end of life). హైఫన్‌తో docker-compose అని పిలిచే ఏదైనా కమాండ్‌ను, స్పేస్‌తో కూడిన docker compose కి అప్‌డేట్ చేయాలి.

మొదటి ఇన్‌స్టాలేషన్ సమయంలో Docker యొక్క సైనింగ్ కీని ఇంపోర్ట్ చేయడానికి ఆగుతుంది మరియు దాని ఫింగర్‌ప్రింట్‌ను మీకు చూపుతుంది. ఈ కీ మీరు ఇప్పుడే జోడించిన రిపో ఫైల్‌లోని gpgkey=https://download.docker.com/linux/centos/gpg నుండి వస్తుంది, కాబట్టి మీరు అంగీకరించే ముందు dnf చూపే ఫింగర్‌ప్రింట్‌ను ఆ URLతో సరిపోల్చుకోండి.

ఒక వైఫల్యం తరచుగా కనిపిస్తుంది. containerd.io కి container-selinux అవసరమని మరియు దేని ద్వారా అది లభించడం లేదని dnf నివేదిస్తే, మీ 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 ప్యాకేజీలు ఇన్‌స్టాలేషన్ తర్వాత daemonను ఆపివేసి, disable చేసి ఉంచుతాయి. అందుకే ఈ దశ Docker యొక్క CentOS పేజీలో కనిపిస్తుంది, కానీ Ubuntu పేజీలో కనిపించదు; అక్కడ deb ప్యాకేజీ మీ కోసం సేవను స్వయంచాలకంగా ప్రారంభిస్తుంది. మీరు enableని దాటవేస్తే, తదుపరి reboot వరకు మాత్రమే Docker నడుస్తుంది, ఆ తర్వాత అది ఆగిపోయి, దానితో పాటు అన్ని కంటైనర్లు కూడా ఆగిపోతాయి.

systemctl status కమాండ్ Active: active (running)ని చూపాలి. hello-world కంటైనర్ This message shows that your installation appears to be working correctly.ని ప్రింట్ చేసి నిష్క్రమించాలి. ఒకవేళ అది /var/run/docker.sock వద్ద permission errorని చూపిస్తే, మీరు sudoని మర్చిపోయారని అర్థం; దీనిని కింద ఉన్న docker group విభాగం ద్వారా సరిచేయవచ్చు.

Compose ప్లగిన్‌ను విడిగా తనిఖీ చేయండి, ఎందుకంటే ఇది వేరే ప్యాకేజీ మరియు Docker engine సరిగ్గా ఉన్నప్పటికీ ఇది మిస్ అయ్యే అవకాశం ఉంది:

docker compose version

సరిగ్గా పనిచేస్తున్నప్పుడు వచ్చే సమాధానం Docker Compose version v2.x.x లాగా ఉంటుంది. Reboot తర్వాత మీ సేవలు తిరిగి ప్రారంభం కావడం అనేది daemonను enable చేయడంతో సంబంధం లేని వేరే విషయం, మరియు restart policies ద్వారా Compose సేవలు బూట్ సమయంలో తిరిగి రావాలో లేదో నిర్ణయించవచ్చు.

bind mount ఎందుకు 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 } ఉంటుంది, ఇది scontext= ఫీల్డ్‌లో container_t ని మరియు tcontext= ఫీల్డ్‌లో మీరు డైరెక్టరీపై చూసిన లేబుల్‌ను కలిగి ఉంటుంది. ఆ రెండు ఫీల్డ్‌ల మధ్య ఉన్న వ్యత్యాసమే అసలు సమస్య.

దీనికి పరిష్కారం వాల్యూమ్ ఆర్గ్యుమెంట్‌కు ఒక సఫిక్స్ (suffix) చేర్చడం. Docker మీ కోసం పాత్‌ను రీలేబుల్ చేస్తుంది:

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

చిన్న అక్షరాలతో ఉండే :z కంటెంట్‌ను షేర్డ్ (shared) గా రీలేబుల్ చేస్తుంది, తద్వారా అనేక కంటైనర్లు ఒకే డైరెక్టరీని ఉపయోగించవచ్చు. పెద్ద అక్షరాలతో ఉండే :Z దానిని ప్రైవేట్ మరియు అన్‌షేర్డ్ (unshared) గా రీలేబుల్ చేస్తుంది, ఇది ఒక కంటైనర్‌కు మాత్రమే పరిమితం అవుతుంది; అప్పుడు అదే పాత్‌ను చదవడానికి ప్రయత్నించే రెండో కంటైనర్‌కు అనుమతి నిరాకరించబడుతుంది. సైడ్‌కార్ లేదా బ్యాకప్ కంటైనర్ కూడా యాక్సెస్ చేసే దేనికైనా :z ఉపయోగించండి. ఒకే కంటైనర్ యాజమాన్యంలో ఉండే డేటాబేస్ డైరెక్టరీ కోసం :Z ఉపయోగించండి.

Docker డాక్యుమెంటేషన్‌లో ఒక హెచ్చరిక ఉంది, దానిని మళ్ళీ గుర్తుచేసుకోవడం ముఖ్యం, ఎందుకంటే ఈ రీలేబుల్ రికర్సివ్‌గా జరుగుతుంది. /home లేదా /usr వంటి సిస్టమ్ డైరెక్టరీలను :Z తో bind-mount చేయడం వల్ల "మీ హోస్ట్ మెషీన్ పని చేయకుండా పోవచ్చు మరియు మీరు హోస్ట్ మెషీన్ ఫైళ్లను మాన్యువల్‌గా రీలేబుల్ చేయాల్సి రావచ్చు". ఈ సఫిక్స్‌లను మీరు కంటైనర్ కోసం సృష్టించిన డైరెక్టరీలకు మాత్రమే ఉపయోగించండి, సిస్టమ్ పాత్‌లకు ఎప్పుడూ వాడకండి.

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 ను కేవలం ఒక నిమిషం పాటు పరీక్షించడానికి మాత్రమే ఉపయోగించండి: ఒకవేళ కంటైనర్ అప్పుడు పనిచేస్తే, సమస్య లేబుల్‌కు సంబంధించినదని అర్థం మరియు :z దానికి పరిష్కారం. వెంటనే sudo setenforce 1 తో దానిని తిరిగి ఆన్ చేయండి. Enterprise Linux లో, bind mount పై permission denied రావడానికి ఒకేలా కనిపించే రెండు వేర్వేరు కారణాలు ఉండవచ్చు. ఒకటి SELinux లేబుల్. రెండోది సాధారణ సంఖ్యాపరమైన యూజర్ మరియు గ్రూప్ యాజమాన్యం, దీనిని PUID మరియు PGID వేరియబుల్స్ పరిష్కరిస్తాయి. ls -lnZ మీకు మోడ్, సంఖ్యాపరమైన ఓనర్ మరియు లేబుల్‌ను ఒకే లైన్‌లో చూపుతుంది, తద్వారా మీరు దేనితో పోరాడుతున్నారో తెలుసుకోవచ్చు.

firewalld క్లోజ్డ్‌గా ఉన్నట్లు కనిపిస్తున్నప్పుడు, పబ్లిష్ చేసిన పోర్ట్ ఎలా అందుబాటులో ఉంటుంది?

Rocky Linux మరియు AlmaLinux లలో firewalld డిఫాల్ట్ ఫైర్‌వాల్‌గా ఉంటుంది. ఇది రన్ అవుతుందో లేదో sudo systemctl is-active firewalld ద్వారా తనిఖీ చేయండి. మీరు ఈ బాక్స్‌లో ఇంకా దీన్ని కాన్ఫిగర్ చేయకపోతే, ముందుగా firewalld తో SSH మరియు వెబ్ పోర్ట్‌ను తెరవడం పూర్తి చేయాలి, ఎందుకంటే పోల్చడానికి మీకు పని చేసే జోన్ రూల్‌సెట్ ఉన్నప్పుడే కింద పేర్కొన్న ఆశ్చర్యకరమైన విషయం అర్థమవుతుంది. ఇప్పుడు ఒక పోర్ట్‌ను పబ్లిష్ చేసి, 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 ఒక డెస్టినేషన్ NAT (network address translation) రూల్‌ను ఇన్‌స్టాల్ చేస్తుంది. ఇది ప్యాకెట్ హోస్ట్ యొక్క ఇన్‌పుట్ పాత్‌కు చేరకముందే, డెస్టినేషన్‌ను కంటైనర్ అడ్రస్‌కు మారుస్తుంది, కాబట్టి కెర్నల్ ప్యాకెట్‌ను స్థానికంగా డెలివర్ చేయకుండా ఫార్వర్డ్ చేస్తుంది. ఆ తర్వాత Docker తన బ్రిడ్జ్ ఇంటర్‌ఫేస్‌లను docker అనే firewalld జోన్‌లో ఉంచుతుంది, దీని టార్గెట్ ACCEPT గా ఉంటుంది. అలాగే, ఏదైనా జోన్ నుండి docker జోన్‌కు ఫార్వర్డింగ్‌ను అనుమతించే docker-forwarding అనే ఫార్వర్డింగ్ పాలసీని జోడిస్తుంది. మీ జోన్ రూల్స్ ఈ ప్యాకెట్‌ను ఎప్పటికీ చూడలేవు.

దీనికి అత్యంత సరైన పరిష్కారానికి ఎటువంటి ఫైర్‌వాల్ రూల్ అవసరం లేదు. పబ్లిష్ చేసేటప్పుడు హోస్ట్ సైడ్‌ను loopback కు బైండ్ చేసి, దాని ముందు ఒక రివర్స్ ప్రాక్సీని ఉంచండి:

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 యొక్క సొంత accept రూల్స్ కంటే ముందే ప్రాసెస్ చేయబడుతుంది, కాబట్టి మీరు అక్కడ ఉంచిన రూల్ Docker రీస్టార్ట్ అయినా మరియు దాని చైన్స్‌ను రీరైట్ చేసినా చెరిగిపోదు:

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

eth0 అని ఊహించుకోకుండా, ip route show default నుండి ఇంటర్‌ఫేస్ పేరును తీసుకోండి, ఎందుకంటే ప్రస్తుత EL ఇమేజ్‌లు enp1s0 లేదా ens3 వంటి పేర్లను ఉపయోగిస్తున్నాయి. 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

ఇది కేవలం root మాత్రమే చదవగల ఫైల్‌ను, sudo హక్కులు లేని ఖాతా ద్వారా చదువుతుంది. Docker యొక్క పోస్ట్-ఇన్‌స్టాల్ డాక్యుమెంటేషన్ కూడా ఇదే చెబుతోంది: docker గ్రూపు root తో సమానమైన అధికారాలను ఇస్తుంది. మీరు ఒక ఖాతాకు sudo హక్కులను ఇవ్వాలనుకుంటేనే ఆ ఖాతాను ఈ గ్రూపులో చేర్చండి. మీరు కొత్త సర్వర్‌లో ఖాతాలను సెటప్ చేస్తుంటే, దీనిని తర్వాత కాకుండా, మిగిలిన VPS పై కనీస అధికారాలు కలిగిన వినియోగదారు సెటప్ తో పాటే నిర్ణయించుకోండి.

Docker లో rootless మోడ్ కూడా ఉంది, ఇది డెమన్‌ను తక్కువ అధికారాలు కలిగిన వినియోగదారుగా నడుపుతుంది. ఇది ఒక ప్రత్యేక ఇన్‌స్టాలేషన్ మార్గం మరియు ఇది స్టోరేజ్ డ్రైవర్లు మరియు 1024 కంటే తక్కువ ఉన్న పోర్టుల పనితీరును మారుస్తుంది, కాబట్టి దీనిని తర్వాత జోడించే ఫ్లాగ్‌గా కాకుండా, ఒక ప్రత్యేక ప్రాజెక్ట్‌గా ప్లాన్ చేసుకోండి.

తదుపరి అడుగులు

ఇప్పుడు మీ వద్ద ఇంజిన్, compose ప్లగిన్, రీబూట్ తర్వాత కూడా పనిచేసే సర్వీస్ మరియు పైన పేర్కొన్న మూడు EL-నిర్దిష్ట ప్రవర్తనలు సిద్ధంగా ఉన్నాయి. తదుపరి అడుగు ప్రతి సర్వీస్‌కు ఒక compose.yamlని సెటప్ చేయడం. Compose ఫైల్ నిర్మాణం అనే విభాగం ఫైల్ ఫార్మాట్ మరియు దానిని నియంత్రించే కమాండ్ల గురించి వివరిస్తుంది. మీరు మొదటిసారి కంటైనర్ హోస్ట్‌ను ఉపయోగిస్తుంటే, VPSలో Docker రన్ చేయడం అనే గైడ్ ఈ మార్గదర్శిలో లేని సైజింగ్, స్టోరేజ్ మరియు ఇమేజ్-హైజీన్ వంటి అంశాలను కవర్ చేస్తుంది.

FAQ

Docker యొక్క CentOS repository, Rocky Linux మరియు AlmaLinux లపై పనిచేస్తుందా?

అవును. https://download.docker.com/linux/centos/docker-ce.repo ను dnf config-manager తో జోడించండి. ఆ ఫైల్‌లోని baseurl లో $releasever ఉంటుంది. Rocky Linux మరియు AlmaLinux దీనిని major version నంబర్‌గా విస్తరిస్తాయి. కాబట్టి, EL 9 బాక్స్ CentOS 9 tree కి, EL 10 బాక్స్ CentOS 10 tree కి మారుతాయి. sudo dnf repoinfo docker-ce-stable తో ఈ విస్తరణను నిర్ధారించుకుని, Repo-baseurl లైన్‌ను చదవండి. dnf మెటాడేటాను పొందుతున్నప్పుడు Status code: 404 కనిపిస్తే, ఆ వేరియబుల్ పాయింట్ రిలీజ్‌కు విస్తరించినట్లు అర్థం. అప్పుడు /etc/yum.repos.d/docker-ce.repo ని ఎడిట్ చేసి, కేవలం major number ను మాత్రమే ఉంచడం ద్వారా ఈ సమస్య పరిష్కారమవుతుంది.

ఒకే సర్వర్‌పై Docker మరియు podman లను ఇన్‌స్టాల్ చేయవచ్చా?

Docker డాక్యుమెంటేషన్ podman మరియు runc లను ఒకదానికొకటి విరుద్ధమైన ప్యాకేజీలుగా పేర్కొంటుంది. Docker Engine ను ఇన్‌స్టాల్ చేసే ముందు రెండింటినీ తొలగించాలని సూచిస్తుంది. ప్రధాన ఘర్షణ podman-docker ప్యాకేజీ వల్ల వస్తుంది, ఇది /usr/bin/docker ని కలిగి ఉండి, ప్రతి docker కమాండ్‌ను podman కమాండ్‌గా మారుస్తుంది. ఆ పాత్ ఏ ప్యాకేజీకి చెందినదో చూడటానికి rpm -qf "$(command -v docker)" రన్ చేయండి. అవుట్‌పుట్ podman-docker తో మొదలైతే, podman స్పందిస్తున్నట్లు అర్థం. రెండు ఇంజిన్‌లను ఉంచడం Docker మద్దతు ఇచ్చే పద్ధతి కాదు, కాబట్టి ముఖ్యమైన సర్వర్‌లలో ఏదో ఒకదానినే ఎంచుకోండి.

bind mount పై నా కంటైనర్‌కు permission denied అని ఎందుకు వస్తుంది?

Rocky Linux మరియు AlmaLinux లలో SELinux డిఫాల్ట్‌గా ఎన్‌ఫోర్స్ చేయబడుతుంది. కంటైనర్లు container_t రకంతో నడుస్తాయి మరియు కేవలం container_file_t అని లేబుల్ చేయబడిన ఫైళ్లను మాత్రమే తాకగలవు. మీరు సృష్టించిన డైరెక్టరీకి తప్పుడు లేబుల్ ఉండటం వల్ల, దాని యజమాని లేదా మోడ్ ఏవైనా సరే, యాక్సెస్ నిరాకరించబడుతుంది. హోస్ట్ పాత్ పై ls -ldZ తో మరియు sudo ausearch -m avc -ts recent తో దీనిని నిర్ధారించుకోండి; ఇది రెండు సరిపోలని సందర్భాలను (contexts) avc: denied తో ప్రింట్ చేస్తుంది. కంటైనర్ల మధ్య షేర్ చేయబడిన కంటెంట్ కోసం వాల్యూమ్ ఆర్గ్యుమెంట్‌కు :z ని, లేదా ఒకే కంటైనర్‌కు పరిమితమైన కంటెంట్ కోసం :Z ని జోడించండి. ఎప్పుడూ :Z ని /home లేదా /usr వైపు పాయింట్ చేయకండి, ఎందుకంటే ఈ రీలేబులింగ్ రికర్సివ్‌గా జరిగి హోస్ట్ సిస్టమ్‌ను దెబ్బతీస్తుంది.

కంటైనర్ పోర్ట్‌ను పబ్లిష్ చేయడానికి firewalld లో పోర్ట్ తెరవాలా?

అవసరం లేదు, అదే అసలు సమస్య. ప్యాకెట్ హోస్ట్ యొక్క ఇన్‌పుట్ పాత్‌కు చేరకముందే Docker యొక్క NAT రూల్ డెస్టినేషన్ అడ్రస్‌ను మారుస్తుంది, కాబట్టి firewalld జోన్ రూల్స్ దానిని తనిఖీ చేయవు. Docker తన బ్రిడ్జ్‌లను docker అనే firewalld జోన్‌లో, ACCEPT టార్గెట్‌తో ఉంచుతుంది. -p 8080:80 తో ప్రారంభించిన కంటైనర్ ఇంటర్నెట్ నుండి అందుబాటులో ఉంటుంది, కానీ sudo firewall-cmd --list-ports ఏమీ ప్రింట్ చేయదు. హోస్ట్ మాత్రమే సేవను యాక్సెస్ చేయాలనుకున్నప్పుడు -p 127.0.0.1:8080:80 తో నిర్దిష్ట అడ్రస్‌కు పబ్లిష్ చేయండి, లేదా Docker తన సొంత accept రూల్స్‌కు ముందు ప్రాసెస్ చేసే 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 mode ఒక ప్రత్యామ్నాయం, ఇది సెట్టింగ్ మాత్రమే కాదు, ఒక ప్రత్యేక ఇన్‌స్టాలేషన్ పద్ధతి.