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 அமைப்பு ஒரே மாதிரியாக இருக்கும்; எனவே இந்த செயல்முறை இரண்டுக்கும் பொதுவானது. CentOS Stream-க்கும் இதுவே பொருந்தும். கீழே உள்ளவை இரண்டுக்கும் பொதுவானவை என்பதால், நீங்கள் எதைத் தேர்ந்தெடுப்பது என்று குழப்பத்தில் இருந்தால், ஒவ்வொரு திட்டமும் வழங்கும் compatibility உறுதிமொழி மற்றும் உங்கள் பழைய CPU-க்கு ஆதரவு உள்ளதா என்பதே முடிவெடுக்கும் காரணிகள்.

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

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

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-ஐ மறைக்க அந்தக் கோப்பை உருவாக்கியிருக்கலாம், எனவே அதை மட்டும் நம்ப வேண்டாம். எந்த package அந்த binary-ஐக் கொண்டுள்ளது என்பதை package database-இடம் கேட்கவும்:

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

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

Podman அதே OCI images-ஐ இயக்குவதால், அது ஒரு சிறந்த தேர்வாகும். உங்களுக்கு அதுவே போதும் என்றால், இங்கேயே நிறுத்திவிடவும். இரண்டும் Linux container engines என்பதால், platform தேர்வு இன்னும் முடிவாகவில்லை என்றால், FreeBSD jails, registry-யிலிருந்து பெறப்பட்ட layered images-ஐ இயக்குவதற்குப் பதிலாக, முழு userland-ஐயும் தனிமைப்படுத்துகின்றன என்பதைத் தெரிந்துகொள்வது அவசியம். உங்களுக்கு Docker Engine தேவைப்பட்டால், முதலில் முரண்படும் packages-ஐ நீக்கவும். 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-ல் இந்தப் பட்டியல் சிறியதாக இருக்கும். ஏற்கனவே பயன்படுத்தப்பட்ட ஒரு கணினியில், podman-ஐ நீக்குவது, அதைச் சார்ந்திருக்கும் cockpit-podman அல்லது பிற கருவிகளையும் நீக்கக்கூடும்.

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

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

Docker தனது RPM-களை Enterprise Linux-க்காக download.docker.com-ல் வெளியிடுகிறது. இந்த repository கோப்பு CentOS tree-ஐச் சுட்டிக்காட்டுகிறது; Rocky Linux மற்றும் AlmaLinux ஆகியவையும் இதையே பயன்படுத்துகின்றன. Red Hat நிறுவனம் 2020-ல் CentOS-ஐ Stream-ஆக மாற்றிய பிறகு, இரு விநியோகங்களும் எவ்வாறு CentOS மரபிலிருந்து உருவாயின என்பதை அறியாதவர்களுக்கு, Rocky server-ஐ CentOS repository-க்கு மாற்றுவது தவறாகத் தோன்றலாம். ஆகஸ்ட் 2026-ல் சரிபார்க்கப்பட்டபடி, Docker இந்த repository-ஐ 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 argument நீக்கப்பட்டுவிட்டது, எனவே புதிய பதிப்புகளில் இரண்டாவது கட்டளை தோல்வியடையும். உங்களிடம் உள்ள பதிப்பைச் சரிபார்த்து, அதற்குப் பொருத்தமான கட்டளையைத் தேர்ந்தெடுக்கவும்:

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 தொகுப்பிலிருந்து dnf அந்த variable-ஐ விரிவுபடுத்துகிறது. Rocky Linux மற்றும் AlmaLinux இதை major version எண்ணுக்கு அமைப்பதால், EL 9-ல் 9 என்றும் EL 10-ல் 10 என்றும் அமையும்; இதனால்தான் CentOS repository ஒரு Rocky box-ல் சரியாகச் செயல்படுகிறது. நிறுவும் முன் இந்த விரிவாக்கத்தைச் சரிபார்க்கவும்:

sudo dnf repoinfo docker-ce-stable

Repo-baseurl வரியைப் படிக்கவும். அது /9/x86_64/stable அல்லது /10/x86_64/stable என்று முடிய வேண்டும். உங்கள் release, $releasever-ஐ 9.6 போன்ற point version-க்கு அமைத்திருந்தால், metadata-வை எடுக்கும்போது dnf அந்த URL-க்கு Status code: 404 என்று பிழை காட்டும். /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

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

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

முதல் நிறுவலின் போது Docker-ன் signing key-ஐ இறக்குமதி செய்ய நிறுத்தம் ஏற்படும் மற்றும் அதன் fingerprint-ஐக் காட்டும். இந்த key நீங்கள் சேர்த்த repo கோப்பில் உள்ள gpgkey=https://download.docker.com/linux/centos/gpg-லிருந்து வருகிறது, எனவே நீங்கள் அதை ஏற்றுக்கொள்வதற்கு முன், 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-ல் இருந்து பார்க்கும்போது owner, group மற்றும் 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 கர்னலின் audit பதிவை அச்சிடும். இதில் avc: denied { read } இருக்கும், ஒரு scontext= field container_t-ஐக் குறிப்பிடும், மற்றும் ஒரு tcontext= field நீங்கள் directory-ல் பார்த்த லேபிளைக் குறிப்பிடும். இந்த இரண்டு fields-க்கும் இடையே உள்ள முரண்பாடே இதற்குக் காரணம்.

இதற்கான தீர்வு, volume argument-ன் இறுதியில் ஒரு suffix சேர்ப்பதாகும். Docker உங்களுக்காக path-ஐ மறு லேபிளிடும் (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 என மறு லேபிளிடும், இதனால் பல 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 கோப்புகளைக் கையால் மறு லேபிளிட வேண்டியிருக்கும்". இந்த suffixes-ஐ நீங்கள் 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 ownership, இதைச் சரிசெய்யவே PUID மற்றும் PGID variables பயன்படுகின்றன. ls -lnZ கட்டளை mode, numeric owner மற்றும் லேபிளை ஒரே வரியில் காட்டும், எனவே நீங்கள் எதனுடன் போராடுகிறீர்கள் என்பதை அறியலாம்.

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

Rocky Linux மற்றும் AlmaLinux-ல் firewalld இயல்பான firewall ஆகும். அது இயங்குகிறதா என்பதை sudo systemctl is-active firewalld மூலம் சரிபார்க்கவும். இந்த server-ல் நீங்கள் இன்னும் அதை configure செய்யவில்லை என்றால், முதலில் firewalld மூலம் SSH மற்றும் web port-ஐத் திறத்தல் என்பதைச் செய்ய வேண்டும். ஏனெனில், கீழே உள்ள முரண்பாட்டைப் புரிந்துகொள்ள, ஏற்கனவே உள்ள zone ruleset-உடன் ஒப்பிட்டுப் பார்ப்பது அவசியம். இப்போது ஒரு port-ஐ publish செய்து, firewalld எதைக் குறிப்பிடுகிறது என்று பார்ப்போம்:

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

firewall-cmd ஒரு காலி வரியை அச்சிடும். மற்றொரு machine-லிருந்து, curl -I http://YOUR_SERVER_IP:8080/ கட்டளையை இயக்கினால் HTTP/1.1 200 OK என்று விடையளிக்கும். அந்த port இணையத்திற்குத் திறந்திருக்கிறது, ஆனால் உங்கள் firewall எதையும் காட்டவில்லை.

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

இதற்கான மிகச் சரியான தீர்விற்கு 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 என்று விடையளிக்கும், ஆனால் மற்றொரு machine-லிருந்து அதே கோரிக்கையை அனுப்பினால் connection கிடைக்காது. -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 port-களுக்கான நேரடி routed அணுகல் இப்போது DOCKER chain-ல் தடுக்கப்பட்டுள்ளது. இந்த மாற்றம் publish செய்யப்பட்ட port-களைப் பாதிக்காது, எனவே தற்போதைய பதிப்புகளிலும் மேலே உள்ளவை பொருந்தும். ஒரு செயல்பாட்டுப் பழக்கத்தை ஏற்படுத்திக்கொள்வது நல்லது: எந்தவொரு sudo firewall-cmd --reload கட்டளைக்குப் பிறகும், publish செய்யப்பட்ட port-ஐ மீண்டும் சோதிக்கவும். அது பதிலளிக்கவில்லை என்றால், sudo systemctl restart docker கட்டளை Docker-ன் விதிகளை மீண்டும் நிறுவும்.

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

docker group-ல் root அல்லாத பயனரைச் சேர்த்தல்

ஒவ்வொரு docker கட்டளைக்கு முன்பும் 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 அமர்வுகள் தானாகவே இந்த மாற்றத்தைப் பெற்றுக்கொள்ளும்.

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

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

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

Docker-ல் rootless mode என்ற வசதியும் உள்ளது; இது daemon-ஐ அதிகாரம் இல்லாத ஒரு பயனராக இயக்குகிறது. இது ஒரு தனிப்பட்ட நிறுவல் முறையாகும் (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 எண்ணை மட்டும் பயன்படுத்தினால் இந்தச் சிக்கல் சரியாகும்.

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

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 இயல்பாகவே அமலில் இருக்கும். Containers container_t என்ற வகையில் இயங்குகின்றன; அவை container_file_t என்று பெயரிடப்பட்ட கோப்புகளை மட்டுமே அணுக முடியும். நீங்கள் உருவாக்கிய directory தவறான label-ஐக் கொண்டிருப்பதால், அதன் உரிமையாளர் அல்லது mode எதுவாக இருந்தாலும் அணுகல் மறுக்கப்படுகிறது. இதை உறுதிப்படுத்த host பாதையில் ls -ldZ கட்டளையைப் பயன்படுத்தவும். sudo ausearch -m avc -ts recent கட்டளை, பொருந்தாத இரண்டு contexts-ஐக் காட்டும் avc: denied-ஐ அச்சிடும். Containers-க்கு இடையே பகிரப்படும் உள்ளடக்கத்திற்கு volume argument-ல் :z-ஐச் சேர்க்கவும், அல்லது ஒரு container-க்கு மட்டும் உரிய உள்ளடக்கத்திற்கு :Z-ஐச் சேர்க்கவும். :Z-ஐ ஒருபோதும் /home அல்லது /usr-க்குக் காட்ட வேண்டாம்; ஏனெனில் இது recursive முறையில் label-ஐ மாற்றும், இதனால் host சிதைந்துவிடும்.

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

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

எனது user-ஐ docker group-ல் சேர்ப்பது பாதுகாப்பானதா?

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