Rocky Linux वर Docker कसे इन्स्टॉल करावे

Rocky Linux आणि AlmaLinux वर Docker इन्स्टॉल करणे

Rocky Linux किंवा AlmaLinux वर Docker इन्स्टॉल करण्यासाठी तुम्हाला Docker ची अधिकृत dnf रिपॉझिटरी जोडावी लागेल, compose प्लगइनसह इंजिन इन्स्टॉल करावे लागेल आणि त्यानंतर सर्व्हिस इनेबल करावी लागेल. ही प्रक्रिया चार कमांड्सची आहे आणि दोन्ही डिस्ट्रिब्युशन्ससाठी ती सारखीच आहे, कारण दोन्ही Red Hat Enterprise Linux (RHEL) वर आधारित आहेत आणि त्यांची पॅकेज रचना समान आहे. CentOS Stream वरही हीच पद्धत वापरली जाते.

इन्स्टॉलेशनची प्रक्रिया छोटी आहे, त्यामुळे या मार्गदर्शकाचा बहुतेक भाग Enterprise Linux (EL) आणि Ubuntu मधील फरकांवर लक्ष केंद्रित करतो. तुमच्या इमेजवर कदाचित Podman ने docker कमांड आधीच व्यापलेली असू शकते. जोपर्यंत bind-mounted फाइल्सना योग्य लेबल लावले जात नाही, तोपर्यंत SELinux त्यांना ब्लॉक करते. Firewalld हे Docker ने पब्लिश केलेल्या पोर्ट्सना फिल्टर करत नाही, त्यामुळे एखादा कंटेनर पोर्ट इंटरनेटसाठी खुला असू शकतो, तर firewall-cmd असे दर्शवेल की कोणताही पोर्ट खुला नाही.

get.docker.com वरील Docker ची convenience script वापरू नका. 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 इमेजेस चालवते आणि तो एक योग्य पर्याय आहे. जर तुम्हाला तोच हवा असेल, तर इथेच थांबा. जर तुम्हाला 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 द्वारे समर्थित नाही. जर इन्स्टॉलेशन दरम्यान अजूनही संघर्ष (conflict) दिसून येत असेल, तर वरील पूर्ण यादी वापरून ती पॅकेजेस काढून टाका.

dnf config-manager वापरून Docker ची रिपॉझिटरी जोडा

Docker एंटरप्राइझ लिनक्ससाठी RPMs download.docker.com वर प्रकाशित करते. रिपॉझिटरी फाइल CentOS ट्रीकडे निर्देश करते, ज्याचा वापर Rocky Linux आणि AlmaLinux द्वारे केला जातो. ऑगस्ट 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 च्या जागी फक्त मेजर नंबर लिहा.

इंजिन आणि 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 बायनरी इन्स्टॉल करत नाहीत. ते Compose v1 होते, ज्याचा कालावधी जुलै 2023 मध्ये संपला आहे. जे काही docker-compose ला हायफनसह कॉल करते, त्याला docker compose मध्ये स्पेस देऊन अपडेट करणे आवश्यक आहे.

पहिले इन्स्टॉलेशन Docker ची साइनिंग की इम्पोर्ट करण्यासाठी थांबते आणि तुम्हाला त्याचा फिंगरप्रिंट दाखवते. ही की तुम्ही नुकत्याच ॲड केलेल्या रेपो फाईलमधील 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 पॅकेजेस इन्स्टॉल केल्यानंतर daemon थांबवलेले आणि disabled असते. म्हणूनच ही पायरी Docker च्या 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 वर परवानगी त्रुटी (permission error) आली, तर तुम्ही sudo वगळले आहे, जे खालील docker group विभागात दुरुस्त केले आहे.

Compose प्लगइन स्वतंत्रपणे तपासा, कारण ते एक वेगळे पॅकेज आहे आणि इंजिन व्यवस्थित असतानाही ते गहाळ असू शकते:

docker compose version

एक यशस्वी उत्तर Docker Compose version v2.x.x सारखे दिसते. रीबूटनंतर तुमच्या सेवा परत मिळवणे हा daemon enable करण्यापेक्षा वेगळा प्रश्न आहे आणि restart policies हे ठरवतात की बूट झाल्यावर Compose सेवा पुन्हा सुरू होतील की नाही.

bind mount मध्ये permission denied का येते?

Rocky Linux आणि AlmaLinux वर डीफॉल्टनुसार SELinux (Security-Enhanced Linux) 'enforcing' मोडमध्ये असते. याची खात्री getenforce कमांड वापरून करा, जी Enforcing आउटपुट देते.

Docker कंटेनर container_t या SELinux प्रकारांतर्गत चालतात आणि हा प्रकार फक्त container_file_t लेबल असलेल्या फाइल्स वाचू किंवा लिहू शकतो. तुम्ही होस्टवर तयार केलेल्या डिरेक्टरीला तिच्या मूळ पाथचे लेबल मिळते, जे container_file_t नसते. होस्टच्या बाजूने मालक (owner), गट (group) आणि मोड (mode) बरोबर दिसत असले तरी, कंटेनरला प्रवेश नाकारला जातो. हे तीन कमांड्स वापरून पुन्हा तयार करता येते:

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= फील्डमध्ये तुम्ही डिरेक्टरीवर पाहिलेले लेबल असते. या दोन फील्डमधील विसंगती हेच मुख्य कारण आहे.

यावर उपाय म्हणून volume आर्गुमेंटला एक सफिक्स जोडणे आवश्यक आहे. Docker तुमच्यासाठी पाथचे लेबल पुन्हा सेट (relabel) करते:

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 (मोठ्या लिपीत) त्याला 'private' आणि 'unshared' म्हणून लेबल करते, जे एका कंटेनरपुरते मर्यादित असते; अशा वेळी दुसरा कंटेनर त्याच पाथला वाचण्याचा प्रयत्न केल्यास त्याला प्रवेश नाकारला जातो. जर sidecar किंवा backup कंटेनर त्या डिरेक्टरीला स्पर्श करत असतील, तर :z वापरा. जर ती डिरेक्टरी फक्त एकाच कंटेनरच्या मालकीची डेटाबेस डिरेक्टरी असेल, तर :Z वापरा.

Docker च्या डॉक्युमेंटेशनमध्ये एक महत्त्वाची चेतावणी दिली आहे, कारण relabeling ही प्रक्रिया रिकर्सिव्ह (recursive) असते. /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 नुसार कोणते पोर्ट उघडे आहेत ते तपासा:

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 एक destination NAT (network address translation) नियम तयार करते, जो पॅकेट होस्टच्या इनपुट पाथपर्यंत पोहोचण्यापूर्वी त्याचे डेस्टिनेशन कंटेनरच्या ॲड्रेसमध्ये बदलतो. त्यामुळे कर्नल पॅकेटला स्थानिक पातळीवर पोहोचवण्याऐवजी फॉरवर्ड करते. त्यानंतर Docker आपल्या ब्रिज इंटरफेसेसना docker नावाच्या firewalld झोनमध्ये ठेवते, ज्याचे टार्गेट ACCEPT असते आणि ते docker-forwarding नावाची फॉरवर्डिंग पॉलिसी जोडते, जी कोणत्याही झोनमधून docker झोनमध्ये फॉरवर्डिंगला परवानगी देते. तुमचे झोन नियम हे पॅकेट कधीच पाहू शकत नाहीत.

सर्वात सोपा उपाय म्हणजे कोणत्याही फायरवॉल नियमाची गरज नाही. पब्लिश केलेल्या पोर्टला loopback वर बाइंड करा आणि त्याच्या पुढे एक 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/

स्थानिक 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 वर एक सुसंगतता स्तर (compatibility layer) आहे आणि Docker च्या चेन त्याद्वारे दिसतात. अशा प्रकारे जोडलेले नियम रीबूटनंतर निघून जातात, जोपर्यंत तुम्ही ते सेव्ह करत नाही. एकदा खात्री पटली की ते systemd युनिटमध्ये लिहा.

Docker Engine 28.0, जे 2025 मध्ये रिलीज झाले, त्याने एक त्रुटी दूर केली: पब्लिश न केलेले कंटेनर पोर्ट्स आता DOCKER चेनमध्ये ब्लॉक केले जातात. हा बदल पब्लिश केलेल्या पोर्ट्सवर परिणाम करत नाही, त्यामुळे वरील सर्व माहिती सध्याच्या व्हर्जन्ससाठी लागू आहे. एक कार्यपद्धती म्हणून ही सवय लावा: कोणत्याही sudo firewall-cmd --reload नंतर, पब्लिश केलेले पोर्ट पुन्हा तपासा. जर त्याने प्रतिसाद देणे बंद केले असेल, तर sudo systemctl restart docker कमांड Docker चे नियम पुन्हा इन्स्टॉल करते.

Ubuntu ॲडमिनिस्ट्रेटरना वेगळ्या टूलद्वारे याच समस्येचा सामना करावा लागतो, ज्याचे तपशील Docker पब्लिश केलेले पोर्ट ufw नियमांकडे दुर्लक्ष का करतात येथे दिले आहेत. दोन्ही प्रकरणांत NAT पाथ हेच मूळ कारण आहे. फक्त त्यापुढील फायरवॉल बदलते.

docker ग्रुपमध्ये non-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 ला राईट (write) ॲक्सेस देते, आणि जे काही या सॉकेटशी संवाद साधू शकते, ते डेमनला (daemon) असा कंटेनर सुरू करण्यास सांगू शकते जो होस्ट फाईलसिस्टमला माउंट करतो. खालील एक कमांड याचा अर्थ स्पष्ट करते:

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

ही कमांड अशी फाईल वाचते जी फक्त root वाचू शकतो, आणि ती अशा अकाउंटवरून वाचली जाते ज्याला कोणतेही sudo अधिकार नाहीत. Docker च्या स्वतःच्या पोस्ट-इन्स्टॉल डॉक्युमेंटेशनमध्येही हेच नमूद केले आहे: docker ग्रुप root च्या बरोबरीचे अधिकार देतो. एखाद्या अकाउंटला या ग्रुपमध्ये तेव्हाच समाविष्ट करा जेव्हा तुम्ही त्या अकाउंटला sudo चे अधिकार देण्यास तयार असाल. जर तुम्ही नवीन सर्व्हरवर अकाउंट्स सेट करत असाल, तर हा निर्णय नंतर घेण्याऐवजी तुमच्या VPS वरील least-privilege user setup च्या वेळीच घ्या.

Docker मध्ये rootless मोड देखील उपलब्ध आहे, जो डेमनला एका अनप्रिव्हिलेज्ड (unprivileged) युजरच्या रूपात चालवतो. हा एक वेगळा इन्स्टॉल मार्ग आहे आणि यामुळे स्टोरेज ड्रायव्हर्स आणि 1024 च्या खालील पोर्ट्सच्या कार्यपद्धतीत बदल होतो, त्यामुळे याला नंतर जोडायचा एक फ्लॅग न समजता एक स्वतंत्र प्रकल्प म्हणून नियोजित करा.

पुढील पावले

आता तुमच्याकडे इंजिन, compose प्लगइन, रीबूटनंतरही सुरू राहणारी सेवा आणि वर नमूद केलेले तीन EL-विशिष्ट वर्तन उपलब्ध आहेत. पुढील पायरी म्हणजे प्रत्येक सेवेसाठी एक compose.yaml तयार करणे, आणि Compose फाईलची रचना या विषयामध्ये फाईल फॉरमॅट आणि ती चालवणारे कमांड्स यांची माहिती दिली आहे. जर हा तुमचा पहिला कंटेनर होस्ट असेल, तर VPS वर Docker चालवणे या मार्गदर्शकामध्ये या गाईडमध्ये न समाविष्ट केलेले आकारमान (sizing), स्टोरेज आणि इमेज-हायजीन संबंधित प्रश्न हाताळले आहेत.

FAQ

Docker चे CentOS रिपॉझिटरी Rocky Linux आणि AlmaLinux वर चालते का?

हो. https://download.docker.com/linux/centos/docker-ce.repo वापरून dnf config-manager जोडा. त्या फाईलमधील baseurl मध्ये $releasever असते. Rocky Linux आणि AlmaLinux हे आपोआप मेजर व्हर्जन नंबरमध्ये विस्तारित (expand) करतात. त्यामुळे 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 इन्स्टॉल करण्यापूर्वी दोन्ही काढून टाकण्यास सांगितले जाते. मुख्य तांत्रिक संघर्ष 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 चालवा, जे दोन विसंगत संदर्भ दर्शवणारे 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-USER चेनमध्ये फिल्टरिंग नियम टाका, जे Docker स्वतःच्या accept नियमांपूर्वी प्रोसेस करते.

माझ्या युजरला docker ग्रुपमध्ये जोडणे सुरक्षित आहे का?

हे root ॲक्सेस देण्यासारखेच आहे. docker ग्रुपचा सदस्य /var/run/docker.sock मध्ये लिहू शकतो आणि docker run --rm -v /:/host alpine wc -l /host/etc/shadow नंतर sudo अधिकार नसलेल्या खात्याकडून root-only फाईल वाचू शकतो. Docker चे पोस्ट-इन्स्टॉल डॉक्युमेंटेशन ही समानता स्पष्ट करते. फक्त अशाच खात्यांना जोडा ज्यांच्यावर तुम्ही आधीच sudo साठी विश्वास ठेवता, आणि शेअर केलेल्या किंवा सर्व्हिस खात्यांसाठी sudo docker वापरणे सुरू ठेवा. जेव्हा तुम्हाला अनप्रिव्हिलेज्ड युजर अंतर्गत कंटेनर चालवायचे असतात, तेव्हा Rootless मोड हा पर्याय आहे, जो सेटिंग नसून एक स्वतंत्र इन्स्टॉलेशन पाथ आहे.