Rocky Linux மற்றும் AlmaLinux-ல் Docker நிறுவுவது எப்படி?

Rocky Linux மற்றும் AlmaLinux-ல் Docker-ஐ நிறுவுதல்

Rocky Linux அல்லது AlmaLinux-ல் Docker-ஐ நிறுவ, நீங்கள் Docker-ன் சொந்த dnf repository-ஐச் சேர்த்து, compose plugin-உடன் engine-ஐ நிறுவி, பின் அந்தச் சேவையை (service) enable செய்ய வேண்டும். இந்த செயல்முறை நான்கு கட்டளைகளைக் கொண்டது. இவை இரண்டும் Red Hat Enterprise Linux (RHEL)-ன் மறுவடிவங்கள் என்பதால், package அமைப்பு ஒரே மாதிரியாக இருக்கும்; எனவே இந்த கட்டளைகள் இரண்டு விநியோகங்களுக்கும் (distributions) பொதுவானவை. CentOS Stream-லும் இதே முறைதான் செயல்படுகிறது.

நிறுவல் மிகச் சுருக்கமானது என்பதால், இந்த வழிகாட்டியின் பெரும்பகுதி Ubuntu-விலிருந்து Enterprise Linux (EL) எவ்வாறு மாறுபடுகிறது என்பதை விளக்குகிறது. உங்கள் image-ல் ஏற்கனவே docker கட்டளையை Podman பயன்படுத்திக்கொண்டிருக்கலாம். SELinux-ல் சரியான label இல்லாத வரை, bind-mounted கோப்புகளை அது தடுக்கும். Firewalld, Docker-ன் published ports-ஐ வடிகட்டாது (filter); எனவே ஒரு container port இணையத்திற்குத் திறந்திருந்தாலும், firewall-cmd கட்டளை எதையும் திறக்கவில்லை என்று காட்டக்கூடும்.

get.docker.com-லிருந்து Docker-ன் convenience script-ஐப் பயன்படுத்த வேண்டாம். இது production சூழலுக்குப் பரிந்துரைக்கப்படுவதில்லை என்று Docker-ன் ஆவணங்களே குறிப்பிடுகின்றன. இது உங்கள் அனுமதி இன்றி repository அமைப்புகளை மாற்றிவிடும், மேலும் upgrade செய்வதற்கு இதை மீண்டும் பாதுகாப்பாக இயக்க முடியாது. repository-ஐ நீங்களே கைமுறையாகச் சேர்ப்பதன் மூலம், dnf upgrade மற்ற அனைத்து package-களைப் போலவே Docker-ஐயும் கையாளும்.

docker கட்டளைக்கு ஏற்கனவே podman பதிலளிக்கிறதா?

Rocky Linux மற்றும் AlmaLinux ஆகியவற்றின் default repositories-ல் podman உள்ளது. பல VPS images-ல் இது ஏற்கனவே நிறுவப்பட்டிருக்கும். சில images-ல் podman-docker தொகுப்பு கூடுதலாக நிறுவப்பட்டிருக்கும். இது /usr/bin/docker பாதையில் ஒரு shell script-ஐ உருவாக்கும், இது podman-ஐ இயக்கும். நீங்கள் தட்டச்சு செய்யும் ஒவ்வொரு docker கட்டளையும் podman-ஐ இயக்குவதால், Docker-க்காக எழுதப்பட்ட வழிகாட்டிகள் நீங்கள் எதிர்பாராத முடிவுகளைத் தரும்.

இதனை கண்டறியும் முதல் வழி banner ஆகும். /usr/bin/docker script, /etc/containers/nodocker கோப்பு உள்ளதா என்று சரிபார்க்கும். அந்தக் கோப்பு இல்லையென்றால், எதையும் இயக்குவதற்கு முன்பு அது ஒரு வரியை அச்சிடும்:

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

யாராவது அந்த banner-ஐத் தவிர்க்க அந்தக் கோப்பை உருவாக்கியிருக்கலாம், எனவே அதை மட்டும் நம்ப வேண்டாம். எந்தத் தொகுப்பு அந்த binary-ஐக் கொண்டுள்ளது என்பதை package database-இடம் கேட்கவும்:

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

podman-docker என்று தொடங்கும் பதில், podman பதிலளிப்பதைக் குறிக்கும். docker-ce-cli என்று தொடங்கும் பதில், உண்மையான Docker-ஐக் குறிக்கும். rpm -qf எந்தத் தொகுப்பும் அந்தக் கோப்பைக் கொண்டிருக்கவில்லை என்று கூறினால், யாரோ அதைத் தாங்களாகவே நிறுவியுள்ளனர் என்று அர்த்தம். அதை நம்புவதற்கு முன் script-ஐப் படித்துப் பார்க்கவும்.

Podman அதே OCI images-ஐ இயக்குவதால், அது ஒரு நல்ல மாற்றாகும். உங்களுக்கு அதுவே போதும் என்றால், இத்துடன் நிறுத்திக் கொள்ளவும். உங்களுக்கு 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 image-ல் இந்தப் பட்டியல் சிறியதாக இருக்கும். ஏற்கனவே பயன்படுத்தப்பட்ட server-ல், podman-ஐ நீக்குவது cockpit-podman அல்லது அதைச் சார்ந்திருக்கும் பிற கருவிகளை நீக்கக்கூடும்.

கோட்பாட்டு ரீதியாக podman மற்றும் Docker-ஐ ஒன்றாக வைத்திருக்க முடியும்: podman-docker-ஐ மட்டும் நீக்கினால் docker பெயர் விடுதலையாகும், மேலும் containerd.io தொகுப்பு மாற்றும் runc-ஐயும் நீக்க வேண்டும். Docker-ன் ஆவணங்கள் podman-ஐ ஒரு முரண்படும் தொகுப்பாகவே கருதுகின்றன, எனவே இந்த அமைப்பை Docker ஆதரிக்காது. நிறுவலின் போது இன்னும் முரண்பாடு ஏற்பட்டால், மேலே உள்ள முழுமையான நீக்கப் பட்டியலைப் பயன்படுத்தவும்.

dnf config-manager மூலம் Docker repository-ஐச் சேர்த்தல்

Docker தனது RPM-களை Enterprise Linux-க்காக download.docker.com-ல் வெளியிடுகிறது. இந்த repository கோப்பு CentOS tree-ஐச் சுட்டிக்காட்டுகிறது; Rocky Linux மற்றும் AlmaLinux ஆகியன இதையே பயன்படுத்துகின்றன. ஆகஸ்ட் 2026-ல் சரிபார்க்கப்பட்டதன்படி, CentOS Stream 9 மற்றும் CentOS Stream 10-க்கான இந்த repository-ஐ Docker ஆவணப்படுத்தியுள்ளது.

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 argument நீக்கப்பட்டுவிட்டது, எனவே புதிய releases-ல் இரண்டாவது கட்டளை தோல்வியடையும். உங்களிடம் உள்ள பதிப்பைச் சரிபார்த்து, அதற்குப் பொருத்தமான கட்டளையைத் தேர்ந்தெடுக்கவும்:

dnf --version

அது 5.x பதிப்பைக் காட்டினால், அதற்குப் பதிலாக subcommand முறையைப் பயன்படுத்தவும்:

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 பிழையைத் தரும்; எனவே நீங்கள் அதைத் தவறவிட மாட்டீர்கள்.

அந்த repo கோப்பு baseurl-ஐ $releasever உள்ள ஒரு பாதைக்கு அமைக்கிறது, மேலும் உங்கள் release package-லிருந்து dnf அந்த மாறியை (variable) விரிவுபடுத்துகிறது. Rocky Linux மற்றும் AlmaLinux இதை major version எண்ணாக அமைப்பதால், EL 9-ல் 9 என்றும் EL 10-ல் 10 என்றும் அமையும்; இதனால்தான் CentOS repository ஒரு Rocky கணினியில் சரியாகச் செயல்படுகிறது. நிறுவும் முன் இந்த விரிவாக்கத்தைச் சரிபார்க்கவும்:

sudo dnf repoinfo docker-ce-stable

Repo-baseurl வரியைப் படிக்கவும். அது /9/x86_64/stable அல்லது /10/x86_64/stable என்று முடிய வேண்டும். உங்கள் release $releasever-ஐ 9.6 போன்ற point version-ஆக அமைத்திருந்தால், metadata-வை எடுக்கும்போது அந்த URL-க்கு Status code: 404 என்று dnf பிழையைக் காட்டும். /etc/yum.repos.d/docker-ce.repo-ஐத் திருத்தி, $releasever-க்கு பதிலாக வெறும் major எண்ணை இடுவதன் மூலம் இதைச் சரிசெய்யலாம்.

Engine மற்றும் compose plugin-ஐ நிறுவுதல்

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

ஐந்து தொகுப்புகள் (packages), ஒவ்வொன்றும் ஒரு பணியைச் செய்கிறது. docker-ce என்பது daemon ஆகும், dockerd. docker-ce-cli என்பது நீங்கள் தட்டச்சு செய்யும் docker கட்டளை ஆகும். containerd.io என்பது daemon இயக்கும் container runtime ஆகும். docker-buildx-plugin என்பது images-ஐ உருவாக்குகிறது. docker-compose-plugin என்பது docker compose-ஐ ஒரு subcommand-ஆக வழங்குகிறது.

இந்தத் தொகுப்புகள் hyphen குறியீடு கொண்ட docker-compose binary-ஐ நிறுவுவதில்லை. அது Compose v1 ஆகும், இது ஜூலை 2023-ல் அதன் ஆயுட்காலத்தை முடித்துக்கொண்டது. hyphen குறியீட்டுடன் docker-compose-ஐ அழைக்கும் எதையும், இடைவெளியுடன் கூடிய docker compose-க்கு மாற்ற வேண்டும்.

முதல் நிறுவலின் போது Docker-ன் signing key-ஐ இறக்குமதி செய்ய நிறுத்தம் ஏற்படும், அப்போது அதன் fingerprint காட்டப்படும். நீங்கள் சேர்த்த repo கோப்பில் உள்ள gpgkey=https://download.docker.com/linux/centos/gpg-லிருந்து இந்த key வருகிறது, எனவே அதை ஏற்றுக்கொள்வதற்கு முன் dnf காட்டும் fingerprint-ஐ அந்த URL-உடன் ஒப்பிட்டுப் பார்க்கவும்.

ஒரு பிழை அடிக்கடி நிகழ்கிறது. containerd.io-க்கு container-selinux தேவைப்படுகிறது என்றும், அதை வழங்க எதுவும் இல்லை என்றும் dnf தெரிவித்தால், உங்கள் AppStream repository முடக்கப்பட்டுள்ளது என்று அர்த்தம். 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 packages நிறுவப்பட்ட பிறகு, அதன் daemon நிறுத்தப்பட்டும், முடக்கப்பட்டும் (disabled) இருக்கும். இதனால்தான் Docker-ன் CentOS பக்கத்தில் இந்த படிநிலை உள்ளது; Ubuntu பக்கத்தில் deb கோப்பு தானாகவே service-ஐத் தொடங்குவதால் அங்கு இது தேவையில்லை. enable-ஐத் தவிர்த்தால், அடுத்த reboot வரை மட்டுமே Docker இயங்கும்; அதன் பிறகு அது நின்றுவிடும், அதனுடன் அனைத்து container-களும் நின்றுவிடும்.

systemctl status கட்டளை Active: active (running)-ஐக் காட்ட வேண்டும். hello-world container, This message shows that your installation appears to be working correctly. என்பதை அச்சிட்டு வெளியேற வேண்டும். மாறாக, /var/run/docker.sock-ல் permission error காட்டினால், நீங்கள் sudo-ஐ விடுபட்டுள்ளீர்கள் என்று அர்த்தம்; கீழே உள்ள docker group பகுதியில் இதைச் சரிசெய்யலாம்.

Compose plugin-ஐத் தனித்தனியாகச் சரிபார்க்கவும், ஏனெனில் இது ஒரு தனி package ஆகும்; Docker engine சரியாக இருந்தாலும் இது விடுபட்டிருக்கலாம்:

docker compose version

சரியான வெளியீடு Docker Compose version v2.x.x என்பது போல இருக்கும். Reboot செய்த பிறகு உங்கள் services மீண்டும் கிடைப்பது என்பது daemon-ஐ enable செய்வதிலிருந்து வேறுபட்டது; restart policies, Compose services boot-ன் போது மீண்டும் தொடங்க வேண்டுமா என்பதைத் தீர்மானிக்கின்றன.

bind mount ஏன் permission denied பிழையைத் தருகிறது?

Rocky Linux மற்றும் AlmaLinux இயல்பாகவே SELinux (Security-Enhanced Linux)-ஐ enforcing mode-ல் இயக்குகின்றன. இதை getenforce மூலம் உறுதிப்படுத்தலாம், இது Enforcing என்பதை வெளியிடும்.

Docker containers container_t எனும் SELinux type-ன் கீழ் இயங்குகின்றன, இந்த type container_file_t என லேபிளிடப்பட்ட கோப்புகளை மட்டுமே படிக்கவும் எழுதவும் முடியும். நீங்கள் host-ல் உருவாக்கும் ஒரு directory, அதன் parent path-ன் லேபிளையே பெறும், அது container_file_t ஆக இருக்காது. host-ன் பார்வையில் உரிமையாளர், குழு மற்றும் mode சரியாகத் தெரிந்தாலும், container-க்கு அனுமதி மறுக்கப்படும். இதை மூன்று கட்டளைகள் மூலம் உறுதிப்படுத்தலாம்:

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

container பின்வருவனவற்றை அச்சிடும்:

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

இரண்டு கட்டளைகள் இதற்கான காரணத்தைக் காட்டும். ls -ldZ /srv/site லேபிளை அச்சிடும், இது /srv-க்கு கீழ் உள்ள ஒரு path-க்கு system_u:object_r:var_t:s0 என்று இருக்கும், container_file_t என்று இருக்காது. பின்னர் sudo ausearch -m avc -ts recent kernel-ன் audit பதிவை அச்சிடும், அதில் avc: denied { read }, container_t-ஐக் குறிப்பிடும் scontext= புலம் மற்றும் நீங்கள் directory-ல் பார்த்த லேபிளைக் குறிப்பிடும் tcontext= புலம் ஆகியவை இருக்கும். இந்த இரண்டு புலங்களுக்கு இடையே உள்ள முரண்பாடே முழுப் பிரச்சினைக்கும் காரணம்.

இதற்கான தீர்வு, volume argument-ன் இறுதியில் ஒரு suffix சேர்ப்பதாகும். Docker உங்களுக்காக path-ஐ மீண்டும் லேபிளிடும்:

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

சிறிய எழுத்துக்களில் உள்ள :z, உள்ளடக்கத்தை shared என மீண்டும் லேபிளிடும், எனவே பல containers ஒரே directory-ஐப் பயன்படுத்தலாம். பெரிய எழுத்துக்களில் உள்ள :Z, அதை private மற்றும் unshared என மீண்டும் லேபிளிடும், இது ஒரு container-டன் மட்டுமே பிணைக்கப்படும், இரண்டாவது container அதே path-ஐப் படிக்க முயன்றால் அனுமதி மறுக்கப்படும். sidecar அல்லது backup container பயன்படுத்தும் எதற்கும் :z-ஐப் பயன்படுத்தவும். ஒரு container-க்குச் சொந்தமான database directory-க்கு :Z-ஐப் பயன்படுத்தவும்.

Docker-ன் ஆவணத்தில் உள்ள ஒரு எச்சரிக்கையை மீண்டும் குறிப்பிடுவது அவசியம், ஏனெனில் இந்த relabel செயல்முறை recursive ஆகும். /home அல்லது /usr போன்ற system directory-களை :Z கொண்டு bind-mount செய்வது "உங்கள் host machine-ஐச் செயலிழக்கச் செய்யும், நீங்கள் host machine கோப்புகளைக் கையால் மீண்டும் லேபிளிட வேண்டியிருக்கும்". இந்த suffix-களை நீங்கள் container-க்காக உருவாக்கிய directory-களுக்கு மட்டுமே பயன்படுத்தவும், system path-களுக்கு ஒருபோதும் பயன்படுத்த வேண்டாம்.

Compose-ல், இந்த suffix அதே string-ல் சேர்க்கப்படும்:

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

இரண்டு வரம்புகளைக் கவனிக்க வேண்டும். --mount flag-ஆல் SELinux லேபிளை அமைக்க முடியாது, எனவே உங்களுக்கு லேபிள் தேவைப்படும்போது -v-ஐப் பயன்படுத்தவும். Named volumes-க்கு suffix தேவையில்லை, ஏனெனில் Docker /var/lib/docker/volumes-க்கு கீழ் அது உருவாக்கும் directory-களைத் தானே லேபிளிடுகிறது.

SELinux-ஐ அணைக்க வேண்டாம். sudo setenforce 0-ஐ ஒரு நிமிட சோதனைக்கு மட்டுமே பயன்படுத்தவும்: container வேலை செய்தால், பிரச்சினை லேபிளில் உள்ளது என்று அர்த்தம், அதற்கு :z தான் தீர்வு. உடனடியாக sudo setenforce 1 மூலம் அதை மீண்டும் பழைய நிலைக்கு மாற்றவும். Enterprise Linux-ல், bind mount-ல் ஏற்படும் permission denied பிழைக்கு ஒரே மாதிரியாகத் தோன்றும் இரண்டு தனித்தனி காரணங்கள் உள்ளன. ஒன்று SELinux லேபிள். மற்றொன்று சாதாரண numeric user மற்றும் group உரிமை, இதைத்தான் PUID மற்றும் PGID variables தீர்க்கின்றன. ls -lnZ mode, numeric owner மற்றும் லேபிளை ஒரே வரியில் காட்டும், எனவே நீங்கள் எதனுடன் போராடுகிறீர்கள் என்பதை அறியலாம்.

firewalld மூடப்பட்டதாகத் தெரிந்தாலும், publish செய்யப்பட்ட port ஏன் அணுகக்கூடியதாக உள்ளது?

Rocky Linux மற்றும் AlmaLinux-ல் firewalld இயல்பான firewall ஆகும். அது இயங்குகிறதா என்பதை sudo systemctl is-active firewalld மூலம் சரிபார்க்கவும். இப்போது ஒரு port-ஐ publish செய்து, 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 என்று விடையளிக்கும். அந்த port இணையத்திற்குத் திறந்திருக்கும், ஆனால் உங்கள் firewall எதையும் காட்டாது.

இதற்குக் காரணம் பாக்கெட் செல்லும் பாதையாகும். Firewalld-ன் zone விதிகள் host-க்கு வரும் traffic-ஐ மட்டுமே வடிகட்டும். Publish செய்யப்பட்ட port host-ஐ நோக்கியது அல்ல: Docker ஒரு destination NAT (network address translation) விதியை நிறுவுகிறது. இது பாக்கெட் host-ன் input path-க்கு வருவதற்கு முன்பே, அதன் destination-ஐ container-ன் முகவரிக்கு மாற்றுகிறது. இதனால் kernel பாக்கெட்டை உள்ளூர் பயன்பாட்டிற்கு வழங்காமல், forward செய்கிறது. Docker தனது bridge interfaces-ஐ docker என்ற firewalld zone-ல் வைக்கிறது, அதன் target ACCEPT ஆகும். மேலும், எந்த zone-லிருந்தும் docker zone-க்கு forward செய்ய அனுமதிக்கும் docker-forwarding என்ற forwarding policy-ஐயும் சேர்க்கிறது. எனவே, உங்கள் zone விதிகள் பாக்கெட்டைப் பார்ப்பதே இல்லை.

மிகவும் தெளிவான தீர்வுக்கு firewall விதி தேவையில்லை. Publish செய்யும் host-ன் பக்கத்தை loopback-ல் bind செய்து, அதற்கு முன்னால் ஒரு 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 argument-ல் host முகவரி இல்லையெனில், அது அனைத்து interface-களிலும் publish செய்யப்படும். எனவே, வெறும் -p 8080:80 என்பதை அந்தச் சேவையை பொதுவெளியில் வெளிப்படுத்துவதற்கான முடிவாகக் கருதவும்.

சில குறிப்பிட்ட முகவரிகளிலிருந்து மட்டும் சேவை அணுகப்பட வேண்டும் எனில், Docker உங்களுக்காக ஒரு chain-ஐ ஒதுக்குகிறது. DOCKER-USER என்பது Docker-ன் சொந்த accept விதிகளுக்கு முன்பே செயல்படுத்தப்படும். எனவே, அங்கு நீங்கள் சேர்க்கும் விதி Docker restart ஆனாலும் அல்லது அதன் chains மாற்றப்பட்டாலும் அழியாது:

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

eth0 என்று கருதுவதற்குப் பதிலாக, ip route show default கட்டளையிலிருந்து interface பெயரைப் பெறவும். ஏனெனில் தற்போதைய EL images enp1s0 அல்லது ens3 போன்ற பெயர்களைப் பயன்படுத்துகின்றன. Rocky மற்றும் AlmaLinux-ல் iptables கட்டளை என்பது nftables-ன் மேல் உள்ள ஒரு compatibility layer ஆகும், அதன் மூலம் Docker-ன் chains-ஐக் காண முடியும். இந்த முறையில் சேர்க்கப்படும் விதிகள் reboot-க்குப் பிறகு அழிந்துவிடும். எனவே, அவை சரியாகச் செயல்படுகின்றன என்பதை உறுதி செய்த பிறகு, அவற்றை ஒரு systemd unit-ல் எழுதவும்.

2025-ல் வெளியான Docker Engine 28.0, ஒரு பாதுகாப்பு ஓட்டையை அடைத்தது: publish செய்யப்படாத container ports-க்கு நேரடியாக routed access கிடைப்பது இப்போது DOCKER chain-ல் தடுக்கப்பட்டுள்ளது. அந்த மாற்றம் publish செய்யப்பட்ட ports-ஐப் பாதிக்காது, எனவே தற்போதைய பதிப்புகளிலும் மேலே உள்ளவை பொருந்தும். ஒரு செயல்பாட்டுப் பழக்கத்தை ஏற்படுத்திக்கொள்வது நல்லது: ஏதேனும் sudo firewall-cmd --reload செய்த பிறகு, publish செய்யப்பட்ட port-ஐ மீண்டும் சோதிக்கவும். அது பதிலளிக்கவில்லை என்றால், sudo systemctl restart docker கட்டளை Docker-ன் விதிகளை மீண்டும் நிறுவும்.

Ubuntu நிர்வாகிகளும் இதே சிக்கலை வெவ்வேறு கருவி மூலம் சந்திக்கின்றனர், அதைப் பற்றி Docker ports ஏன் ufw விதிகளைப் புறக்கணிக்கின்றன என்பதில் காணலாம். இரண்டு நிகழ்வுகளிலும் NAT பாதையே இதற்குக் காரணம். அதற்கு முன்னால் இருக்கும் firewall மட்டுமே மாறுகிறது.

docker group-ல் non-root user-ஐச் சேர்த்தல்

ஒவ்வொரு docker command-க்கு முன்பும் sudo-ஐத் தட்டச்சு செய்வது சலிப்பைத் தரும், docker group-ஐப் பயன்படுத்துவது இந்தத் தேவையை நீக்குகிறது:

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

usermod -aG, /etc/group-ஐத் திருத்துகிறது, ஆனால் உங்கள் தற்போதைய shell ஏற்கனவே அதன் group பட்டியலைக் கொண்டிருப்பதால், புதிய shell-ஐப் பெறும் வரை இந்த மாற்றம் நடைமுறைக்கு வராது. newgrp docker, group-உடன் இணைக்கப்பட்ட ஒரு shell-ஐத் தொடங்கும், எனவே நீங்கள் உடனடியாகச் சோதிக்கலாம். புதிய SSH sessions தானாகவே இந்த மாற்றத்தை எடுத்துக்கொள்ளும்.

இந்த group என்னென்ன உரிமைகளை வழங்குகிறது என்பதில் தெளிவாக இருங்கள். இதில் உறுப்பினராக இருப்பது /var/run/docker.sock-க்கு write access-ஐ வழங்குகிறது. அந்த socket-உடன் தொடர்பு கொள்ளக்கூடிய எதனாலும், host filesystem-ஐ mount செய்யும் container-ஐத் தொடங்க daemon-க்குக் கட்டளையிட முடியும். ஒரே ஒரு command இதன் அர்த்தத்தை விளக்கும்:

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

இது root-ஆல் மட்டுமே படிக்கக்கூடிய ஒரு கோப்பை, sudo உரிமைகள் இல்லாத ஒரு account மூலம் படிக்கிறது. Docker-ன் சொந்த post-install ஆவணங்களும் இதையே கூறுகின்றன: docker group, root-க்கு இணையான சலுகைகளை வழங்குகிறது. ஒரு account-க்கு நீங்கள் sudo உரிமைகளை வழங்குவதாக இருந்தால் மட்டுமே, அந்த account-ஐ இதில் சேர்க்கவும். நீங்கள் ஒரு புதிய server-ல் account-களை அமைப்பதாக இருந்தால், இதைச் செய்த பிறகு முடிவெடுப்பதற்குப் பதிலாக, VPS-ல் குறைந்தபட்ச சலுகைகள் கொண்ட பயனர் அமைப்பு (least-privilege user setup) முறையின் ஒரு பகுதியாகவே இதைத் திட்டமிடுங்கள்.

Docker, daemon-ஐ privileged அல்லாத பயனராக இயக்கும் rootless mode-ஐயும் வழங்குகிறது. இது ஒரு தனிப்பட்ட install path ஆகும்; இது storage drivers மற்றும் 1024-க்குக் கீழே உள்ள ports-ன் செயல்பாட்டை மாற்றும். எனவே, இதை நீங்கள் பின்னர் சேர்க்கும் ஒரு flag-ஆகக் கருதாமல், ஒரு தனித் திட்டமாகத் திட்டமிடுங்கள்.

அடுத்த கட்ட நடவடிக்கைகள்

இப்போது உங்களிடம் engine, compose plugin, reboot-க்குப் பிறகும் இயங்கும் service மற்றும் மேலே விவரிக்கப்பட்ட மூன்று EL-குறிப்பிட்ட செயல்பாடுகள் உள்ளன. அடுத்த கட்டமாக, ஒவ்வொரு service-க்கும் ஒரு compose.yaml-ஐ உருவாக்க வேண்டும். Compose கோப்பின் கட்டமைப்பு (the anatomy of a Compose file) பகுதியில், அதன் கோப்பு வடிவம் மற்றும் அதை இயக்கும் கட்டளைகள் விளக்கப்பட்டுள்ளன. இதுவே உங்களின் முதல் container host என்றால், VPS-ல் Docker-ஐ இயக்குதல் (running Docker on a VPS) பகுதியில், இந்த வழிகாட்டியில் விடுபட்ட sizing, storage மற்றும் image-hygiene தொடர்பான கேள்விகளுக்கான விளக்கங்களைக் காணலாம்.

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 metadata-வை எடுக்கும்போது Status code: 404 ஏற்பட்டால், அந்த variable ஒரு point release-ஆக விரிவடைந்துள்ளது என்று அர்த்தம். /etc/yum.repos.d/docker-ce.repo-ஐத் திருத்தி, வெறும் major எண்ணை மட்டும் பயன்படுத்தினால் இந்தச் சிக்கல் சரியாகிவிடும்.

ஒரே server-ல் Docker மற்றும் podman ஆகிய இரண்டையும் நிறுவ முடியுமா?

Docker-ன் ஆவணங்கள் podman மற்றும் runc ஆகியவற்றை முரண்படும் packages என்று குறிப்பிடுகின்றன. Docker Engine-ஐ நிறுவும் முன் இரண்டையும் நீக்க அறிவுறுத்துகின்றன. podman-docker package-தான் இதில் முக்கிய முரண்பாடு; இது /usr/bin/docker-ஐக் கட்டுப்படுத்துவதுடன், ஒவ்வொரு docker கட்டளையையும் podman கட்டளையாக மாற்றுகிறது. அந்தப் பாதையை எந்த package கட்டுப்படுத்துகிறது என்பதை அறிய rpm -qf "$(command -v docker)"-ஐ இயக்கவும். வெளியீடு podman-docker என்று தொடங்கினால், podman பதிலளிக்கிறது என்று பொருள். இரண்டு engine-களையும் வைத்திருப்பது Docker ஆதரிக்கும் அமைப்பு அல்ல, எனவே முக்கியமான server-களில் ஏதேனும் ஒன்றை மட்டும் தேர்ந்தெடுக்கவும்.

Bind mount-ல் ஏன் என் container-க்கு permission denied என்று வருகிறது?

Rocky Linux மற்றும் AlmaLinux-ல் SELinux இயல்பாகவே அமலில் (enforcing) இருக்கும். Containers container_t என்ற வகையில் இயங்குகின்றன, அவை container_file_t என்று பெயரிடப்பட்ட கோப்புகளை மட்டுமே அணுக முடியும். நீங்கள் உருவாக்கிய directory தவறான label-ஐக் கொண்டிருப்பதால், அதன் உரிமையாளர் மற்றும் mode எதுவாக இருந்தாலும் அணுகல் மறுக்கப்படுகிறது. ஹோஸ்ட் பாதையில் ls -ldZ-ஐப் பயன்படுத்தி இதை உறுதிப்படுத்தவும். sudo ausearch -m avc -ts recent-ஐ இயக்கினால், அது avc: denied மூலம் பொருந்தாத இரண்டு contexts-ஐக் காட்டும். Containers-க்கு இடையே பகிரப்படும் உள்ளடக்கத்திற்கு volume argument-ல் :z-ஐச் சேர்க்கவும், அல்லது ஒரு container-க்கு மட்டும் சொந்தமான உள்ளடக்கத்திற்கு :Z-ஐச் சேர்க்கவும். :Z-ஐ ஒருபோதும் /home அல்லது /usr-க்குக் காட்ட வேண்டாம், ஏனெனில் relabel செயல்முறை recursive-ஆக இருப்பதால் அது ஹோஸ்ட் கணினியைப் பாதிக்கும்.

Container port-ஐ வெளியிட firewalld-ல் port-ஐத் திறக்க வேண்டுமா?

தேவையில்லை, அதுவே சிக்கலாகவும் மாறலாம். பாக்கெட் ஹோஸ்டின் input path-க்கு வருவதற்கு முன்பே Docker-ன் NAT விதி இலக்கு முகவரியை மாற்றிவிடுகிறது, எனவே firewalld-ன் zone விதிகள் அதைச் சோதிப்பதில்லை. Docker அதன் bridges-ஐ docker என்ற firewalld zone-ல், ACCEPT இலக்குடன் வைத்திருக்கிறது. -p 8080:80 மூலம் தொடங்கப்பட்ட container இணையத்திலிருந்து அணுகக்கூடியதாக இருக்கும், அதே சமயம் sudo firewall-cmd --list-ports எதையும் காட்டாது. ஹோஸ்ட் மட்டுமே அந்தச் சேவையை அணுக வேண்டும் என்றால், -p 127.0.0.1:8080:80 மூலம் குறிப்பிட்ட முகவரிக்கு வெளியிடவும். அல்லது, Docker-ன் சொந்த accept விதிகளுக்கு முன்பாகச் செயல்படும் DOCKER-USER chain-ல் filtering விதிகளைச் சேர்க்கவும்.

எனது பயனர் கணக்கை docker group-ல் சேர்ப்பது பாதுகாப்பானதா?

இது root அதிகாரத்தை வழங்குகிறது. docker group-ல் உள்ள ஒருவர் /var/run/docker.sock-ல் எழுத முடியும், மேலும் docker run --rm -v /:/host alpine wc -l /host/etc/shadow மூலம் sudo அதிகாரம் இல்லாத ஒரு கணக்கிலிருந்து root-மட்டும் அணுகக்கூடிய கோப்பை வாசிக்க முடியும். Docker-ன் நிறுவல் பிந்தைய ஆவணங்களும் இதே சமநிலையை உறுதிப்படுத்துகின்றன. sudo அதிகாரம் வழங்க நீங்கள் ஏற்கனவே நம்பும் கணக்குகளை மட்டும் சேர்க்கவும். பகிரப்பட்ட அல்லது சேவை கணக்குகளுக்கு sudo docker-ஐத் தொடர்ந்து பயன்படுத்தவும். ஒரு சாதாரண பயனர் மூலம் containers-ஐ இயக்க விரும்பினால், Rootless mode-ஐப் பயன்படுத்தலாம். இது ஒரு அமைப்பல்ல, மாறாக ஒரு தனிப்பட்ட நிறுவல் முறையாகும்.