VPS-ல் Podman vs Docker: எது சிறந்தது?

Podman மற்றும் Docker-க்கு இடையே உள்ள உண்மையான வேறுபாடுகள் என்ன

Podman மற்றும் Docker ஆகிய இரண்டும் ஒரு VPS-ல் ஒரே மாதிரியான OCI (open container initiative) images-ஐ இயக்குகின்றன, எனவே எந்த மென்பொருளை இயக்கலாம் என்பது இங்கு கேள்வியல்ல. இவற்றின் செயல்முறை மாதிரியே (process model) வேறுபடுகிறது. Docker ஒரு root daemon-ஐ இயக்குகிறது, அதுவே அனைத்து container-களையும் கட்டுப்படுத்துகிறது; மேலும் docker கட்டளை என்பது அந்த daemon-இடம் வேலைகளைச் செய்யக் கோரும் ஒரு சிறிய client ஆகும். Podman-ல் daemon கிடையாது: podman run கட்டளையானது, அதை அழைக்கும் பயனரின் unprivileged user உரிமையின் கீழ், ஒரு child process-ஆக container-ஐத் தொடங்குகிறது.

இந்த ஒரு அடிப்படை உண்மையிலிருந்தே மற்ற அனைத்தும் உருவாகின்றன. Auto-start என்பது daemon-ன் பொறுப்பிலிருந்து மாறி systemd-ன் பொறுப்பாகிறது. Volume ownership ஒரு user namespace வழியாகச் செல்கிறது, எனவே host-ல் நீங்கள் ls -l மூலம் பார்க்கும் உரிமையாளரும், container-க்குள் இருக்கும் உரிமையாளரும் வேறானவர்கள். 1024-க்குக் கீழே உள்ள ports-ஐ bind செய்ய முயற்சிக்கும்போது, நீங்கள் kernel setting-ஐ மாற்றும் வரை அவை மறுக்கப்படும். docker CLI (command line interface) ஒரு wrapper வழியாகத் தொடர்ந்து செயல்படும், ஆனால் Docker socket-ஐ நேரடியாக அணுக வேண்டிய தேவை ஏற்படும் வரை மட்டுமே இது சாத்தியம்.

Daemon இல்லை: ஒரு container-ஐத் தொடங்கும்போது உண்மையில் என்ன இயங்குகிறது

ஒரு Docker host-ல், pstree -a கட்டளையானது dockerd-ஐ root பயனராகவும், அதன் அருகில் containerd-ஐயும், இயங்கும் ஒவ்வொரு container-க்கும் ஒரு containerd-shim-runc-v2-ஐயும் காட்டும். உங்கள் application அந்த shim-ன் child process ஆகும், மேலும் அந்த shim PID 1-ன் child process ஆகும். container-ஐத் தொடங்கிய shell-க்கும் அந்த container-க்கும் எந்தத் தொடர்பும் இல்லை. daemon-ஐ நிறுத்தினால், அந்த host-ல் உள்ள அனைத்து container-களின் control plane-ஐயும் இழப்பீர்கள். மேலும், இயல்பான live-restore அமைப்பு முடக்கப்பட்டிருந்தால், systemctl restart docker உங்கள் container-களையும் சேர்த்து நிறுத்திவிடும்.

Podman-ல் இதற்கு இணையான process எதுவும் இல்லை. ஒரு container-ஐத் தொடங்கினால், நீங்கள் ஒரு conmon (container monitor) process-ஐப் பெறுவீர்கள். இது container-ன் முதன்மை process-ஐத் தன்வசம் வைத்திருக்கும், மேலும் அந்த command-ஐ இயக்கிய பயனரே இதன் உரிமையாளராக இருப்பார்.

podman run -d --name web -p 8080:80 docker.io/library/caddy:2
ps -o user,pid,ppid,args -C conmon
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080

ps கட்டளையானது conmon உங்கள் login பயனரின் கீழ் இயங்குவதைக் காட்ட வேண்டும், root பயனரின் கீழ் அல்ல. மேலும், curl கட்டளை 200 என்பதை அச்சிட வேண்டும். மையப்படுத்தப்பட்ட service எதுவும் container-ஐக் கட்டுப்படுத்தாததால், sudo apt upgrade podman ஏற்கனவே இயங்கிக்கொண்டிருக்கும் எதையும் நிறுத்தாது. ஒரு container-ன் monitor செயலிழந்தாலும், அது மற்ற container-களைப் பாதிக்காது.

இந்த daemon இல்லாததால் சில குறைபாடுகளும் உள்ளன. reboot செய்த பிறகு உங்கள் container-களைத் தானாகத் தொடங்குவதற்கு எதுவுமில்லை. Docker-ன் --restart=always என்பது daemon boot-ன் போது நிறைவேற்றும் ஒரு வாக்குறுதியாகும். Podman-ல் இதற்குப் பதிலாக systemd பயன்படுத்தப்படுகிறது, இதற்காகவே கீழே உள்ள quadlet பகுதி உள்ளது.

socket என்பது இந்த விஷயத்தின் மற்றொரு பக்கம். /var/run/docker.sock என்பது root உரிமையுள்ள ஒரு API (application programming interface) endpoint ஆகும். இதற்கு எழுதக்கூடிய எந்தவொரு process-ம், host filesystem-ஐ mount செய்யும் privileged container-ஐத் தொடங்க முடியும். ஒரு பயனரை docker குழுவில் சேர்ப்பது, அந்தப் பயனருக்கு மறைமுகமாக root உரிமையை வழங்குகிறது. இது குறித்து ஒவ்வொரு service account-க்கும் தேவையான அணுகலை மட்டும் வழங்குதல் பகுதியில் விரிவாகப் படிப்பது அவசியம். Podman எந்தவொரு socket-ஐயும் தானாகத் திறப்பதில்லை. நீங்கள் கேட்டால் மட்டுமே socket கிடைக்கும், அதுவும் /run/user/<uid>/podman/podman.sock-ல் ஒரு குறிப்பிட்ட பயனருக்குச் சொந்தமானதாகவே இருக்கும்.

Ubuntu 24.04-ல் Podman-ஐ நிறுவுதல் மற்றும் rootless செயல்பாட்டை உறுதி செய்தல்

sudo apt update
sudo apt install -y podman uidmap
podman --version
podman info | grep -i rootless

uidmap தொகுப்பு newuidmap மற்றும் newgidmap ஆகியவற்றை வழங்குகிறது. இவை சாதாரண பயனர் ஒரு குறிப்பிட்ட subordinate ID வரம்பைப் பெற உதவும் setuid helpers ஆகும்; இவை இல்லையெனில் rootless containers இயங்காது. podman info கட்டளையை இயக்கினால் rootless: true என்று காட்ட வேண்டும்.

ஆகஸ்ட் 2026 நிலவரப்படி, Ubuntu 24.04-ல் Podman 4.9-ம், Debian 13-ல் Podman 5.x-ம் உள்ளன. இந்த பதிப்பு வேறுபாடு முக்கியமானது, ஏனெனில் quadlet கோப்புகளுக்கு 4.4 அல்லது அதற்கு மேற்பட்ட பதிப்பு தேவை, மேலும் .pod quadlet கோப்புகளுக்கு 5.0 தேவை. upstream ஆவணங்களிலிருந்து ஒரு உதாரணத்தை நகலெடுக்கும் முன் podman --version கட்டளையை இயக்கவும்.

ஒவ்வொரு rootless பயனருக்கும் ஒரு subordinate ID வரம்பு தேவை:

grep "$USER" /etc/subuid /etc/subgid

Ubuntu-வில் adduser மூலம் உருவாக்கப்பட்ட பயனருக்கு இந்த வரம்பு தானாகவே கிடைக்கும். useradd -M அல்லது ஏதேனும் configuration கருவி மூலம் உருவாக்கப்பட்ட பயனருக்கு இது பெரும்பாலும் இருக்காது, அவ்வாறு இல்லாதபோது இந்த பிழை ஏற்படும்:

Error: cannot find UID/GID for user deploy: no subuid ranges found for user "deploy" in /etc/subuid - check rootless mode in man pages.

ஒரு வரம்பை ஒதுக்கி, அந்த பயனரின் storage-ஐ reset செய்யவும், அப்போதுதான் புதிய mapping பயன்படுத்தப்படும்:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 deploy
podman system migrate

முதல்முறை இயக்கும்போது ஏற்படும் மற்றொரு ஆச்சரியம்: Podman தானாகவே Docker Hub-ஐ எடுத்துக்கொள்ளாது. ஒரு குறுகிய image பெயர் /etc/containers/registries.conf-ல் உள்ள unqualified-search-registries மூலம் தீர்மானிக்கப்படுகிறது, மேலும் terminal இல்லாத ஒரு script-ல் pull செய்ய முயன்றால் short-name resolution enforced but cannot prompt without a TTY பிழையுடன் தோல்வியடையும். எப்போதும் முழுப் பெயரையும் குறிப்பிடவும். nginx-க்கு பதிலாக docker.io/library/nginx:1.27-ஐப் பயன்படுத்தவும்.

வாடகை server-ல் rootless containers உங்களுக்கு என்ன பயனைத் தருகின்றன

ஒரு rootless container, user namespace-க்குள் இயங்குகிறது. இது ஒரு process-க்கு அதன் சொந்த user ID-களின் வரைபடத்தை வழங்கும் kernel வசதியாகும். அந்த namespace-க்குள், container-ன் superuser என்பது UID (user ID) 0 ஆகும். ஆனால், உங்கள் VPS-ல் வெளியே பார்க்கும்போது, அதே process உங்கள் சாதாரண login user-ஆகவே இருக்கும். Container-க்குள் இருக்கும் root, host-ல் root கிடையாது.

இதுவே இதன் உண்மையான பலன். Root-ஆக இயங்க வேண்டிய கட்டாயத்தில் உள்ள ஒரு image, remote code execution bug கொண்ட ஒரு web application, அல்லது UID 0-வைச் சார்ந்திருக்கும் ஒரு escape முயற்சி என எதுவாக இருந்தாலும், அவை machine-ன் அனுமதிகளைப் பெறுவதற்குப் பதிலாக, உங்கள் unprivileged user-ன் அனுமதிகளை மட்டுமே பெறும். Rootless முறை உங்களை kernel bug-களிலிருந்து பாதுகாக்காது; மேலும் உங்கள் சொந்த கோப்புகளையும் இது பாதுகாக்காது, ஏனெனில் வெளியேறிய process உங்களைப் போலவே இயங்குவதால், உங்களால் படிக்கக்கூடிய எதையும் அதாலும் படிக்க முடியும். தனிமைப்படுத்தப்படும் அலகு (unit), UID mapping-ஐ விட முக்கியமானது. இதை ஒரு FreeBSD jail, இது நீங்கள் ஒரு சிறிய machine-ஐ நிர்வகிப்பது போல முழு userland-ஐயும் உள்ளடக்கும் என்பதில் எளிதாகப் புரிந்துகொள்ளலாம். இது registry-யிலிருந்து பெறப்படும் layered image-ஐ விட மாறுபட்டது.

Docker-ஐயும் rootless முறையில் இயக்க முடியும். dockerd-rootless-setuptool.sh install ஒவ்வொரு user-க்கும் ஒரு daemon-ஐ அமைக்கிறது, இது சிறப்பாகச் செயல்படுகிறது. இதில் உள்ள வித்தியாசம் என்னவென்றால், default அமைப்பு எதை நோக்கி உள்ளது என்பதுதான். Podman-ல் நீங்கள் கேட்காமலேயே rootless வசதி கிடைத்துவிடும். எனவே, இரண்டு ஆண்டுகளாகத் தெரியாமல் root-ஆக இயங்கிய ஒரு service-க்கு பதிலாக, port 80-ஐ bind செய்ய முடியாத ஒரு container-ஐ நீங்கள் முதல் தோல்வியாகச் சந்திப்பீர்கள்.

எனது volume கோப்புகள் ஏன் UID 100999-க்கு சொந்தமாக உள்ளன?

இது அதே user namespace காரணமாக நிகழ்கிறது. Container-ன் UID 0, உங்கள் host-ன் UID-க்கு map செய்யப்படுகிறது. Container-ன் UID 1, உங்கள் subuid வரம்பின் முதல் ID-க்கு map செய்யப்படுகிறது, அங்கிருந்து அது எண்ணப்படுகிறது. 100000-ல் தொடங்கும் வரம்பில், container-ன் UID 1000 என்பது host-ல் 100999 ஆக அமைகிறது.

mkdir -p "$PWD/data"
podman run --rm --user 1000 -v "$PWD/data:/data" docker.io/library/alpine:3 sh -c 'id -u; touch /data/f'
ls -ln "$PWD/data"

Container 1000-ஐ அச்சிடுகிறது. Host listing 100999-ஐ உரிமையாளராகக் காட்டுகிறது, ஏனெனில் 100000 உடன் 1000-ஐக் கூட்டி 1-ஐக் கழித்தால் 100999 கிடைக்கிறது. இதில் எந்தப் பிழையும் இல்லை, மேலும் ஒரு சாதாரண chown கட்டளையினால் இதைச் சரிசெய்ய முடியாது, ஏனெனில் உங்கள் unprivileged user-ஆல் namespace-க்கு வெளியே கோப்பின் உரிமையை மாற்ற முடியாது.

இதிலிருந்து விடுபட நான்கு வழிகள் உள்ளன:

• podman unshare chown 1000:1000 "$PWD/data" கட்டளையானது அதே user namespace-க்குள் chown-ஐ இயக்குகிறது, அங்கு எண்கள் container-க்கு என்ன அர்த்தமோ அதையே குறிக்கின்றன.
• -v "$PWD/data:/data:U" கட்டளையானது source directory-ன் உரிமையை உங்களுக்காகச் சரிசெய்ய Podman-ஐக் கேட்கிறது. இதை புதிய directory-களில் மட்டும் பயன்படுத்தவும், நீங்கள் முக்கியமாகக் கருதும் தரவுகளில் பயன்படுத்த வேண்டாம்.
• --userns=keep-id கட்டளையானது உங்கள் host UID-ஐ container-க்குள் அதே UID-க்கு map செய்கிறது, எனவே புதிய கோப்புகள் உங்களுக்குச் சொந்தமானதாகவே அமையும்.
• -v appdata:/data போன்ற named volume-ஐப் பயன்படுத்துவது இந்தச் சிக்கலைத் தவிர்க்கிறது, ஏனெனில் Podman அதை உங்கள் சொந்த storage-க்குள் சரியான உரிமையுடன் உருவாக்குகிறது.

Docker-ல் நீங்கள் இதை எதிர்கொண்டிருந்தால், இது ஒரு அடுக்கு மேலே உள்ள அதே சிக்கலாகும். பல images வழங்கும் PUID மற்றும் PGID மாறிகள் container-க்குள் இருக்கும் process பயன்படுத்தும் UID-ஐ அமைக்கின்றன, rootless Podman-ன் கீழ் அந்த UID இரண்டாவது முறையாக map செய்யப்படுகிறது. Rootless container-க்குள் இருக்கும் PUID=1000 இப்போதும் 100999 உரிமையாளரைக் கொண்ட host கோப்புகளைத்தான் எழுதும். அந்த இரண்டாவது mapping-ஐ மனதில் கொண்டு எண்களைத் தேர்ந்தெடுக்கவும், அல்லது தரவை ஒரு named volume-க்கு மாற்றிவிட்டு இதைப் பற்றி கவலைப்படுவதை நிறுத்தவும்.

Mounts குறித்து மேலும் இரண்டு குறிப்புகள். Fedora மற்றும் RHEL உதாரணங்களில் நீங்கள் காணும் :z மற்றும் :Z flags-கள் SELinux relabel விருப்பங்களாகும், Ubuntu-வில் AppArmor பயன்படுத்தப்படுவதால் அவை அங்கு எந்த மாற்றத்தையும் ஏற்படுத்தாது. Rootless Podman-ஆல் உங்கள் user-ஆல் படிக்க முடியாத host directory-ஐ mount செய்ய முடியாது, இது ஒரு குறைபாடு அல்ல, மாறாக அதன் பாதுகாப்பு அம்சமாகும்.

Rootless Podman ஏன் port 80-ஐ publish செய்ய மறுக்கிறது?

1024-க்குக் கீழே உள்ள port-ஐ bind செய்வதற்கு, உங்கள் பயனருக்கு இல்லாத ஒரு சிறப்பு அனுமதி தேவைப்படுவதே இதற்குக் காரணம். அந்தப் பிழைச் செய்தி அதற்கான தீர்வை இவ்வாறு குறிப்பிடுகிறது:

Error: rootlessport cannot expose privileged port 80, you can add 'net.ipv4.ip_unprivileged_port_start=80' to /etc/sysctl.conf (currently 1024), or choose a larger port number (>= 1024): listen tcp 0.0.0.0:80: bind: permission denied

இதற்கு இரண்டு தீர்வுகள் உள்ளன. முழு host-க்கும் அந்த வரம்பைக் குறைப்பது முதல் வழி:

echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee /etc/sysctl.d/99-podman.conf
sudo sysctl --system
sysctl net.ipv4.ip_unprivileged_port_start

கடைசியாக உள்ள கட்டளை 80 என்பதைத் திரும்பக் காட்ட வேண்டும். இந்த அமைப்பு என்ன செய்கிறது என்பதைத் தெளிவாகப் புரிந்துகொள்ளுங்கள்: இப்போது அந்த machine-ல் உள்ள எந்தவொரு பயனரும் 80 மற்றும் 443 port-களை bind செய்ய முடியும்; containers-ஐ இயக்கும் பயனர் மட்டுமல்ல. ஒரே ஒரு நிர்வாகி மட்டும் உள்ள VPS-ல் இது ஏற்றுக்கொள்ளக்கூடிய ஒரு சமரசம். மற்றவர்களின் கணக்குகளும் உள்ள ஒரு server-ல் இது பாதுகாப்பானது அல்ல. மற்றொரு தீர்வு, 8080-ல் publish செய்துவிட்டு, அதற்கு முன்னால் ஒரு reverse proxy-ஐ வைப்பது. அங்கேதான் நீங்கள் certbot மூலம் nginx-ல் certificates-ஐப் பெற்று புதுப்பிக்க விரும்புவீர்கள்.

Rootless publishing உங்கள் application-ன் பார்வையையும் மாற்றுகிறது. Podman 4.x இயல்பாகவே rootlesskit port handler-உடன் slirp4netns-ஐப் பயன்படுத்துகிறது. இதனால், forwarded இணைப்புகள் மாற்றப்பட்ட source address-உடன் வருவதால், access log-ல் ஒவ்வொரு பார்வையாளரும் 10.0.2.100 என்றே பதிவாகும். Podman 5.0-ல் இயல்புநிலை pasta என மாற்றப்பட்டுள்ளது, இது உண்மையான client address-ஐ அப்படியே வைத்திருக்கும். 4.x பதிப்பில், --network slirp4netns:port_handler=slirp4netns-ஐப் பயன்படுத்துவது throughput-ல் சிறிய பாதிப்பை ஏற்படுத்தினாலும், உண்மையான source address-ஐ மீட்டெடுக்கும்.

இதில் ஒரு நல்ல விஷயம் உள்ளது. Rootless முறையில் publish செய்யப்பட்ட port என்பது, ஒரு சாதாரண process-க்குச் சொந்தமான listening socket ஆகும். எனவே, உங்கள் firewall-ன் input விதிகள் இதற்குப் பொருந்தும். Docker, NAT (network address translation) விதிகள் மற்றும் அதன் சொந்த forwarding accepts-ஐ எழுதுவதன் மூலம் port-களை publish செய்கிறது. இதனால்தான் publish செய்யப்பட்ட Docker port, நீங்கள் block செய்ததாக நினைத்த ufw விதியைப் புறக்கணிக்கிறது. Rootful Podman-ம் இதே போன்ற அமைப்பைப் பயன்படுத்துவதால், அதே சிக்கலை எதிர்கொள்கிறது. ஆனால், Rootless முறையில் இந்தச் சிக்கல் இல்லை.

எனது Docker Compose கோப்புகள் Podman-ல் தொடர்ந்து செயல்படுமா?

பெரும்பாலும் செயல்படும், இதற்கு இரண்டு வழிகள் உள்ளன. முதலாவது podman-compose, இது அதே கோப்பை வாசித்து Podman CLI-ஐ இயக்கும் ஒரு தனிப்பட்ட மென்பொருள் ஆகும்:

sudo apt install -y podman-compose
podman-compose up -d
podman ps

இரண்டாவது, Podman-ன் Docker-இணக்கமான API-உடன் பயனர் சார்ந்த socket வழியாகத் தொடர்பு கொள்ளும் உண்மையான Docker Compose ஆகும்:

systemctl --user enable --now podman.socket
export DOCKER_HOST="unix:///run/user/$(id -u)/podman/podman.sock"
docker compose up -d
podman ps

docker compose ps மற்றும் podman ps ஆகிய இரண்டும் ஒரே கொள்கலன்களைத்தான் (containers) பட்டியலிட வேண்டும், ஏனெனில் அவை ஒரே தொகுப்பைக் குறிக்கின்றன. பெயர் தீர்மானிப்பும் (name resolution) சரியாகச் செயல்படும்: Podman-ன் இயல்புநிலை network backend ஆன netavark, aardvark-dns-ஐ இயக்குகிறது, எனவே பயனர் வரையறுத்த network-ல் உள்ள கொள்கலன்கள் ஒன்றையொன்று பெயரைக் கொண்டு கண்டறியும்.

சில நுணுக்கமான வேறுபாடுகள் உள்ளன. /var/run/docker.sock-ஐ mount செய்யும் எதையும் Podman socket-ஐ நோக்கி மாற்ற வேண்டும் அல்லது நீக்க வேண்டும். network_mode: host பயனர் namespace-ன் கீழ் மாறுபட்ட முறையில் செயல்படும். depends_on மற்றும் condition: service_healthy ஆகியவற்றின் பயன்பாடு podman-compose பதிப்புகளைப் பொறுத்து மாறுபடும். restart: always தானாகவே reboot-க்கு பிறகு நிலைத்திருக்காது, இதை அடுத்த பகுதியில் சரிசெய்யலாம். ஒரே கோப்பில் பல கொள்கலன்களைக் கொண்ட stack-ஐ விவரிக்க Compose இப்போதும் ஒரு சிறந்த வழியாகும், Podman-ல் இது ஒரு மொழிபெயர்ப்பு அடுக்காக (translation layer) செயல்படுகிறது. பல ஆண்டுகள் பராமரிக்க வேண்டிய stack-க்கு, அதை quadlets-ஆக மாற்றி, இரண்டு abstraction-களுக்குப் பதிலாக ஒன்றை மட்டும் பராமரிப்பது சிறந்தது.

Pods: Docker-ல் இல்லாத ஒரு கருத்து

Pod என்பது ஒரே network namespace-ஐப் பகிர்ந்து கொள்ளும் containers-ன் தொகுப்பாகும். Podman ஒரு சிறிய infra container-ஐத் தொடங்கி அந்த namespace-ஐத் திறந்து வைத்திருக்கும். அதன் உறுப்பினர்கள் எந்தவொரு பயனர் வரையறுத்த network அல்லது service discovery-யும் இன்றி 127.0.0.1 மூலம் ஒருவரை ஒருவர் தொடர்பு கொள்ளலாம்.

podman pod create --name app -p 8080:80
podman run -d --pod app --name app-cache docker.io/library/redis:7
podman run -d --pod app --name app-web docker.io/library/nginx:1.27
podman pod ps
podman ps --pod

podman pod ps கட்டளை, infra container-ஐயும் சேர்த்து மூன்று containers கொண்ட pod Running-ஐக் காட்ட வேண்டும். இப்போது web container, Redis-ஐ app-cache:6379-க்கு பதிலாக 127.0.0.1:6379-ல் தொடர்பு கொள்கிறது. பகிரப்பட்ட namespace-லிருந்து இரண்டு விதிகள் உருவாகின்றன: ports-ஐ pod-ல் மட்டுமே வெளியிட வேண்டும், உறுப்பினர்களில் வெளியிடக்கூடாது; மேலும், எந்த இரு உறுப்பினர்களும் ஒரே port-ல் listening செய்யக்கூடாது.

இதுவே Kubernetes மாதிரி, Podman இதைப் பின்பற்றுகிறது. podman kube generate app > app.yaml தற்போது இயங்கிக்கொண்டிருப்பவற்றிலிருந்து ஒரு Kubernetes manifest-ஐ உருவாக்குகிறது (பழைய packages-ல் இது podman generate kube என்று குறிப்பிடப்படும்), மேலும் podman kube play app.yaml அதை மற்றொரு host-ல் மீண்டும் உருவாக்குகிறது. Quadlet-ல் .kube unit வகை உள்ளது, இது அத்தகைய கோப்பை ஒரு systemd service-ஆக இயக்குகிறது. இது சேவைகளை ஒருங்கிணைப்பதற்கான முற்றிலும் மாறுபட்ட வழியாகும். உங்கள் எதிர்காலத் திட்டங்களில் Kubernetes இருந்தால், Podman-ஐத் தேர்ந்தெடுப்பதற்கு இதுவே மிக முக்கியமான காரணமாகும்.

Daemon இல்லாமல் தானாகத் தொடங்குதல்: Quadlet units

Quadlet என்பது ஒரு systemd generator ஆகும். இது container-ஐ விவரிக்கும் ஒரு சிறிய கோப்பை, boot-ன் போது உண்மையான systemd service-ஆக மாற்றுகிறது. Rootless user-க்கு ~/.config/containers/systemd/ பாதையிலும், root-க்கு /etc/containers/systemd/ பாதையிலும் இக்கோப்புகளை வைக்க வேண்டும்.

~/.config/containers/systemd/caddy.container:

[Unit]
Description=Caddy web server
After=network-online.target

[Container]
Image=docker.io/library/caddy:2
ContainerName=caddy
PublishPort=8080:80
Volume=caddy-data.volume:/data
Environment=TZ=UTC
AutoUpdate=registry

[Service]
Restart=always
MemoryMax=512M

[Install]
WantedBy=default.target

~/.config/containers/systemd/caddy-data.volume பகுதி காலியாக இருந்தாலும் பரவாயில்லை, ஏனெனில் section header-தான் volume-ஐ உருவாக்குகிறது:

[Volume]

systemctl --user daemon-reload
systemctl --user start caddy
systemctl --user status caddy
journalctl --user -u caddy -n 50

Service-ன் பெயர் கோப்பின் பெயரிலிருந்து பெறப்படுகிறது: caddy.container என்பது caddy.service ஆக மாறும். systemctl --user enable caddy கட்டளையை இயக்க வேண்டாம். உருவாக்கப்பட்ட unit-களை enable செய்ய முடியாது, மேலும் systemd Failed to enable unit: Unit /run/user/1000/systemd/generator/caddy.service is transient or generated. என்று பதிலளிக்கும். [Install] பகுதிதான் boot-ன் போது container-ஐத் தொடங்குகிறது, மேலும் நீங்கள் கோப்பைத் திருத்திய பிறகு unit-ஐ மீண்டும் உருவாக்க daemon-reload பயன்படுகிறது.

இப்போது அனைவரையும் குழப்பும் அந்த அமைப்பு:

sudo loginctl enable-linger deploy
loginctl show-user deploy --property=Linger

Linger=yes கட்டளையை எதிர்பார்க்கவும். Linger வசதி இல்லையென்றால், உங்கள் கடைசி SSH இணைப்பு துண்டிக்கப்படும்போது systemd முழு பயனர் அமர்வையும் (user session) முடித்துவிடும். இதனால் அனைத்து rootless container-களும் நின்றுவிடும், boot-ன் போது அவை மீண்டும் தொடங்காது. நீங்கள் log out செய்யும்போது container-கள் மறைந்துவிட்டால், அதற்கு இதுவே காரணம்.

Container என்பது ஒரு சாதாரண service unit-ன் முதன்மை process என்பதால், systemd-ன் சொந்தக் கட்டுப்பாடுகள் நேரடியாகப் பொருந்தும். [Service] பகுதியில் உள்ள MemoryMax= மற்றும் CPUQuota= ஆகியவை systemd மூலம் நீங்கள் கட்டுப்படுத்தும் பிற service-களுக்கு செயல்படுவது போலவே செயல்படும். இதற்கு cgroup v2 (control group version 2) தேவை, இது Ubuntu 22.04 முதல் இயல்பாகவே உள்ளது. இதை podman info | grep -i cgroup மூலம் உறுதிப்படுத்தவும்.

Updates-க்கு ஒரு பொருத்தமான வழிமுறை உள்ளது. AutoUpdate=registry உடன் systemctl --user enable --now podman-auto-update.timer சேர்ப்பது, அதே tag-ல் புதிய image உள்ளதா என registry-ல் சரிபார்த்து, unit-ஐ restart செய்யும். புதிய container தொடங்கத் தவறினால், அது பழைய image-க்குத் திரும்பிவிடும் (roll back). என்ன மாற்றங்கள் ஏற்படும் என்பதைப் பார்க்க முதலில் podman auto-update --dry-run கட்டளையை இயக்கவும். பழைய podman generate systemd கட்டளை இன்னும் உள்ளது, ஆனால் அது பயன்பாட்டிலிருந்து நீக்கப்பட்டு வருகிறது (deprecated), எனவே புதிய எதற்கும் quadlet-களைப் பயன்படுத்தவும்.

Docker alias எங்கு செயல்படும், எங்கு செயல்படாது

sudo apt install -y podman-docker
sudo touch /etc/containers/nodocker
docker ps

podman-docker, Podman-ஐ அழைக்கும் ஒரு /usr/bin/docker wrapper-ஐ நிறுவுகிறது. nodocker கோப்பு இல்லையென்றால், ஒவ்வொரு அழைப்பின்போதும் முதலில் Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg. என்று அச்சிடப்படும். இந்த wrapper நீங்கள் நாள் முழுவதும் பயன்படுத்தும் கட்டளைகளை உள்ளடக்கியது: run, ps, logs, exec, build, pull, push, inspect, cp, volume, network.

எவை செயல்படாது என்பதற்கான பட்டியல் சிறியது, ஆனால் முக்கியமானது. Swarm mode-க்கு இணையான வசதி இதில் இல்லை, எனவே Swarm stack-ஐ இதில் இயக்க முடியாது. Docker socket-உடன் தொடர்பு கொள்ளும் கருவிகளுக்கு Podman socket-ஐ export செய்ய வேண்டும், சில கருவிகள் இன்னும் இந்த மாற்றத்தை உணர்கின்றன; Traefik-ன் Docker provider, /run/user/<uid>/podman/podman.sock-ஐ சுட்டிக்காட்டும்போது வேலை செய்யும், ஆனால் Watchtower-க்கு இதில் இடமில்லை, ஏனெனில் podman auto-update அந்த வேலையைச் செய்கிறது. சேமிப்பகம் (storage) தனித்தனியானவை, எனவே Docker மூலம் நீங்கள் ஏற்கனவே பதிவிறக்கிய images-ஐ Podman-ஆல் பார்க்க முடியாது, மேலும் பிஸியாக இருக்கும் ஒரு Docker host-ல் podman images காலியாகவே தொடங்கும்.

இயங்கிக்கொண்டிருக்கும் stack-ஐ படிப்படியாக இடமாற்றம் செய்தல்

1. Container-களை நிர்வகிக்கும் unprivileged user-ஐ உருவாக்கவும் அல்லது தேர்ந்தெடுக்கவும். அந்த user-க்கு /etc/subuid-ல் குறிப்பிட்ட வரம்பு (range) இருப்பதை உறுதி செய்யவும்.
2. Registry-யிலிருந்து பெறப்பட்ட அனைத்தையும் முழுமையான பெயர்களைப் (fully qualified names) பயன்படுத்தி மீண்டும் பதிவிறக்கவும் (re-pull). Podman-க்கு எனத் தனி image store உள்ளது; அது Docker-ன் image-களைப் படிக்காது.
3. உள்ளூரில் உருவாக்கப்பட்ட (locally built) image-களை docker save app:1.4 | podman load மூலம் இடமாற்றவும்.
4. Docker container-ஐ நிறுத்தவும். /var/lib/docker/volumes/<name>/_data-லிருந்து ஒவ்வொரு volume-ன் உள்ளடக்கத்தையும் நகலெடுக்கவும். பின் podman unshare chown -R 1000:1000 <path> மூலம் ownership-ஐச் சரிசெய்யவும்.
5. Port தொடர்பான சிக்கலைத் தீர்க்கவும்: 1024-க்கு மேல் உள்ள port-களை reverse proxy-க்கு பின்னால் வெளியிடவும் அல்லது net.ipv4.ip_unprivileged_port_start-ஐ அமைக்கவும்.
6. ஒவ்வொரு container-க்கும் ஒரு quadlet file-ஐ எழுதவும். systemctl --user daemon-reload-ஐ இயக்கி, ஒவ்வொரு service-ஐயும் தொடங்கவும்.
7. sudo loginctl enable-linger <user>-ஐ இயக்கவும். VPS-ஐ reboot செய்யவும். மீண்டும் login செய்து, podman ps மூலம் அனைத்து service-களும் பட்டியலிடப்பட்டுள்ளதா எனச் சரிபார்க்கவும்.

இந்த இரண்டு engine-களும் எதையும் பகிர்ந்துகொள்வதில்லை: இவை தனித்தனி image storage மற்றும் தனித்தனி network-களைக் கொண்டுள்ளன. எனவே, நீங்கள் இடமாற்றம் செய்யும்போதே இரண்டையும் ஒரே நேரத்தில் இயக்க முடியும். host port எண் மட்டுமே மோதலுக்கு உள்ளாகக்கூடிய ஒரே காரணியாகும். ஒரு service-ஐ மட்டும் முதலில் நகர்த்தவும், ஒரு நாள் முழுவதும் அதைக் கண்காணித்த பிறகு, அடுத்த service-ஐ நகர்த்தவும்.

Podman மற்றும் Docker: உங்கள் VPS-க்கு எது சிறந்தது?

உங்கள் stack மற்றவர்களால் பராமரிக்கப்படும் compose கோப்புகளைச் சார்ந்திருந்தால் அல்லது Docker socket-உடன் தொடர்பு கொள்ளும் கருவிகளைப் பயன்படுத்துகிறீர்கள் என்றால், Docker-இலேயே தொடருங்கள். மற்றவர்கள் எழுதும் குறியீடுகளுடன் இணக்கத்தன்மை (compatibility) என்பது ஒரு முக்கியமான வசதியாகும், இதில் Docker சிறந்து விளங்குகிறது. குழுவில் உள்ள அனைவரின் மடிக்கணினிகளிலும் Docker இயங்கினால், production-லும் அதே engine-ஐப் பயன்படுத்துவது நடைமுறைப் பலன்களைத் தரும்.

நீங்கள் முழுமையாகக் கட்டுப்படுத்தும் சில சேவைகளை மட்டும் VPS-ல் இயக்குகிறீர்கள் என்றால், அல்லது ஒவ்வொரு application-மும் எந்தவிதமான docker குழுவும் இன்றி, தனித்தனி unprivileged user-களின் கீழ் இயங்க வேண்டும் என்று விரும்பினால் Podman-க்கு மாறுங்கள். Distribution-ன் தன்மையும் முக்கியமானது: RHEL மற்றும் அதன் வழித்தோன்றல்கள் Podman-ஐ அதிகாரப்பூர்வ engine-ஆக வழங்குகின்றன, எனவே அந்த system-களில் Podman-ஐப் பயன்படுத்துவது சிக்கல்களைக் குறைக்கும். ஒருவேளை அந்த host-களில் Docker-ஐப் பயன்படுத்த விரும்பினால், Rocky Linux மற்றும் AlmaLinux-ல் dnf வழிமுறை மூலம் தொடங்குவதற்கு முன், ஏற்கனவே docker கட்டளையைக் கொண்டுள்ள podman-docker wrapper-ஐ நீக்க வேண்டும். மற்ற அனைத்தையும் systemd units மூலம் ஏற்கனவே நிர்வகித்து வருகிறீர்கள் என்றால், quadlets உங்களுக்குப் புதிய கருவியாகத் தெரியாமல், விடுபட்ட ஒரு பகுதியாகவே அமையும்.

இடைப்பட்ட ஒரு விருப்பத்தையும் கவனத்தில் கொள்ள வேண்டும். Rootful Podman, Docker போலவே செயல்படும், wrapper மூலம் docker கட்டளையைத் தக்கவைக்கும், அதே சமயம் எப்போதும் இயங்கிக்கொண்டிருக்கும் daemon-ஐ நீக்கும். ஆனால், இது உங்கள் பாதுகாப்பு நிலையை மாற்றும் rootless வசதியைத் தியாகம் செய்கிறது, எனவே இதை ஒரு தற்காலிக மாற்றமாக மட்டும் கருதுங்கள்.

நீங்கள் இன்னும் உங்கள் முதல் container host-ஐ உருவாக்குகிறீர்கள் என்றால், புதிய VPS-ல் Docker அமைப்பு மற்றும் பாதுகாப்பு வழிமுறை எளிதான பாதையாகும், இதில் நீங்கள் கற்கும் அறிவு வீணாகாது. Images மற்றும் volumes ஆகிய இரண்டும் இரண்டு engine-களிலும் ஒரே மாதிரியானவை, எனவே பிற்காலத்தில் நீங்கள் மாறினாலும், உங்கள் சேவைகளை நிர்வகிக்கும் முறையில் மட்டுமே மாற்றம் இருக்கும், மற்றவை மாறாது.

FAQ

Podman என்பது Docker-க்கு மாற்றாக நேரடியாகப் பயன்படுத்தக்கூடியதா?

நீங்கள் பயன்படுத்தும் கட்டளைகளுக்கு (commands), இது பெரும்பாலும் பொருந்தும். podman-docker-ஐ நிறுவுவது உங்களுக்கு /usr/bin/docker wrapper-ஐ வழங்குகிறது, மேலும் run, ps, build, logs மற்றும் exec ஆகியவை ஒரே மாதிரியாகச் செயல்படுகின்றன. இது daemon-க்கு மாற்றானது அல்ல. Swarm-க்கு இணையான வசதி இதில் இல்லை; /var/run/docker.sock-உடன் இணையும் கருவிகளை, ஒவ்வொரு பயனருக்குமான Podman socket-க்கு மாற்ற வேண்டும். Docker மூலம் தரவிறக்கம் செய்யப்பட்ட images, Podman-க்குத் தெரியாது, ஏனெனில் இவை இரண்டும் தனித்தனி சேமிப்பகத்தைப் (storage) பயன்படுத்துகின்றன.

SSH-லிருந்து வெளியேறியதும் எனது rootless Podman containers ஏன் நின்றுவிடுகின்றன?

உங்கள் கடைசி login அமர்வு முடிவடையும் போது, systemd அந்த பயனர் அமர்வையும், அதனுடன் இயங்கும் அனைத்து பயனர் சேவைகளையும் நிறுத்திவிடுவதால் இது நிகழ்கிறது. sudo loginctl enable-linger <user>-ஐ இயக்கவும், பின்னர் loginctl show-user <user> --property=Linger கட்டளை Linger=yes-ஐ வெளியிடுகிறதா என்று சரிபார்க்கவும். Linger வசதியானது, செயலில் உள்ள அமர்வு இல்லாவிட்டாலும் அந்த பயனரின் systemd instance-ஐ இயங்க வைக்கும்; இதுவே reboot-க்குப் பிறகு containers மீண்டும் தொடங்குவதையும் உறுதி செய்கிறது.

எனது volume-ல் உள்ள கோப்புகள் ஏன் UID 100999-க்குச் சொந்தமாக உள்ளன?

Rootless Podman, container-ன் UID 0-ஐ உங்கள் host பயனருடன் இணைக்கிறது, பின்னர் container-ன் UID 1 மற்றும் அதற்கு மேற்பட்டவற்றை உங்கள் subuid வரம்பிற்குள் இணைக்கிறது. 100000-ல் தொடங்கும் வரம்பில், container-ன் UID 1000 என்பது host-ல் 100999 ஆகிறது. இதை namespace-க்குள் podman unshare chown 1000:1000 /path/to/data மூலம் சரிசெய்யலாம், முதல்முறை இயக்கும்போது :U flag-ஐப் பயன்படுத்தி mount செய்யலாம், அல்லது container-ன் UID-கள் உங்களுடையதுடன் ஒத்துப்போக --userns=keep-id-ஐப் பயன்படுத்தலாம்.

நான் தொடர்ந்து docker-compose.yml-ஐ Podman-உடன் பயன்படுத்த முடியுமா?

ஆம், இரண்டு வழிகளில் பயன்படுத்தலாம். podman-compose அந்த கோப்பை வாசித்து, Podman CLI-ஐ நேரடியாக இயக்குகிறது. அல்லது systemctl --user enable --now podman.socket மூலம் compatibility socket-ஐ இயக்கி, DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock-ஐ அமைத்து, அதன் மூலம் உண்மையான docker compose-ஐ இயக்கலாம். network_mode: host, Docker socket-ஐ mount செய்யும் சேவைகள், மற்றும் reboot-க்குப் பிறகு இயங்க quadlet unit மற்றும் linger தேவைப்படும் restart: always ஆகியவற்றில் சில சிக்கல்கள் ஏற்படலாம்.

Rootless முறை உண்மையில் containers-ஐ அதிக பாதுகாப்புடன் வைத்திருக்கிறதா?

இது ஒரு குறிப்பிட்ட அபாயத்தை நீக்குகிறது: rootless container-லிருந்து வெளியேறும் ஒரு process, root-ன் அனுமதிகளைப் பெறுவதற்குப் பதிலாக, உங்கள் சாதாரண பயனர் அனுமதிகளை மட்டுமே கொண்டிருக்கும். இது முக்கியமான பாதுகாப்பு அம்சமாகும், இதனால்தான் root-க்கு இணையான docker குழுவிற்கு rootless Podman-ல் மாற்று இல்லை. இது kernel vulnerabilities-ஐத் தடுக்காது, மேலும் உங்கள் பயனர் அணுகக்கூடிய கோப்புகளைப் பாதுகாக்காது; எனவே எந்தவொரு server-லும் நீங்கள் செய்யும் பிற பாதுகாப்பு நடவடிக்கைகளைத் தொடர்ந்து மேற்கொள்ளுங்கள்.