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 உரிமையின் கீழ், container-ஐ ஒரு child process-ஆகத் தொடங்குகிறது.

இந்த ஒரு அடிப்படை உண்மையைச் சார்ந்தே மற்ற அனைத்தும் அமைகின்றன. Auto-start என்பது daemon-ன் வேலைக்குப் பதிலாக systemd-ன் வேலையாகிறது. Volume ownership ஒரு user namespace வழியாகச் செல்கிறது, எனவே host-ல் நீங்கள் ls -l மூலம் பார்க்கும் உரிமையாளரும், container-க்குள் இருக்கும் உரிமையாளரும் வேறானவர்கள். நீங்கள் kernel அமைப்பை மாற்றும் வரை 1024-க்குக் கீழே உள்ள ports-ஐ bind செய்ய முடியாது. 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-க்கும் அதற்கும் எந்தத் தொடர்பும் இல்லை. daemon-ஐ நிறுத்தினால், அந்த box-ல் உள்ள அனைத்து container-களின் control plane-ஐயும் இழந்துவிடுவீர்கள். மேலும், இயல்பான live-restore அமைப்பு முடக்கப்பட்டிருந்தால், systemctl restart docker உங்கள் container-களையும் சேர்த்து நிறுத்திவிடும்.

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

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 என்பது boot நேரத்தில் daemon வழங்கும் ஒரு வாக்குறுதி. 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 உங்கள் user-ஆகவே இயங்குவதால், உங்களால் படிக்கக்கூடிய அனைத்தையும் அதாலும் படிக்க முடியும்.

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 ஏன் 80-வது port-ஐ 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, நீங்கள் தடுத்ததாக நினைத்த ufw விதியைப் புறக்கணிக்கிறது. Rootful Podman-ம் இதே போன்ற கட்டமைப்பைப் பயன்படுத்துவதால், அதே சிக்கலை எதிர்கொள்கிறது. Rootless முறையில் இந்தச் சிக்கல் இல்லை.

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

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

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

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

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-ல் உள்ள containers தங்களுக்குள் பெயரைக் கொண்டு ஒன்றையொன்று கண்டறியும்.

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

Pods: Docker-ல் இல்லாத ஒரு தனித்துவமான அம்சம்

Pod என்பது ஒரே network namespace-ஐப் பகிர்ந்து கொள்ளும் containers-ன் தொகுப்பாகும். Podman ஒரு சிறிய infra container-ஐத் தொடங்கி அந்த namespace-ஐத் திறந்து வைத்திருக்கும். அதன் பிறகு, உறுப்பினர்கள் எந்தவொரு user-defined 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 மட்டத்தில் மட்டுமே publish செய்ய வேண்டும், உறுப்பினர்கள் மட்டத்தில் செய்யக்கூடாது; மேலும், எந்த இரு உறுப்பினர்களும் ஒரே 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 type உள்ளது, இது அத்தகைய கோப்பை ஒரு systemd service-ஆக இயக்குகிறது. இது சேவைகளை ஒருங்கிணைப்பதற்கான முற்றிலும் மாறுபட்ட ஒரு வழியாகும். உங்கள் எதிர்காலத் திட்டங்களில் Kubernetes இருந்தால், Podman-ஐத் தேர்ந்தெடுப்பதற்கு இதுவே மிக முக்கியமான காரணமாகும்.

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

Quadlet என்பது ஒரு systemd generator ஆகும். இது container-ஐ விவரிக்கும் ஒரு சிறிய கோப்பை, boot செய்யும்போது உண்மையான systemd service-ஆக மாற்றுகிறது. Rootless பயனருக்கு ~/.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] section-தான் boot செய்யும்போது container-ஐத் தொடங்குகிறது, மேலும் daemon-reload என்பது நீங்கள் கோப்பைத் திருத்திய பிறகு unit-ஐ மீண்டும் உருவாக்குகிறது.

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

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] section-ல் உள்ள 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 அந்த வேலையைச் செய்கிறது. சேமிப்பகம் தனித்தனியாக இருப்பதால், Docker மூலம் நீங்கள் ஏற்கனவே பதிவிறக்கிய images-ஐ Podman-ஆல் பார்க்க முடியாது, மேலும் பிஸியாக இருக்கும் ஒரு Docker host-ல் podman images காலியாகவே தொடங்கும்.

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

1. Container-களை நிர்வகிக்கும் unprivileged user-ஐ உருவாக்கவும் அல்லது தேர்ந்தெடுக்கவும். அந்த user-க்கு /etc/subuid-ல் குறிப்பிட்ட range ஒதுக்கப்பட்டுள்ளதை உறுதிப்படுத்தவும்.
2. Registry-யிலிருந்து பெறப்பட்ட அனைத்தையும் முழுமையான பெயர்களைப் பயன்படுத்தி மீண்டும் 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 தொடர்பான முடிவை எடுக்கவும்: reverse proxy-க்கு பின்னால் 1024-க்கு மேற்பட்ட port-களைப் பயன்படுத்தவும் அல்லது 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-இலேயே தொடருங்கள். மற்றவர்கள் எழுதும் குறியீடுகளுடன் இணக்கமாக இருப்பது ஒரு முக்கியமான வசதியாகும், Docker-இல் அந்த வசதி அதிகம். குழுவில் உள்ள அனைவரின் மடிக்கணினிகளிலும் Docker இயங்கினால், production-லும் அதே engine-ஐப் பயன்படுத்துவது நடைமுறைப் பலன்களைத் தரும்.

நீங்கள் முழுமையாகக் கட்டுப்படுத்தும் சில சேவைகளை மட்டும் VPS-இல் இயக்குகிறீர்கள் என்றால், அல்லது ஒவ்வொரு application-ஐயும் எந்தவிதமான docker குழுவும் இன்றி, தனிப்பட்ட unprivileged user-ன் கீழ் இயக்க விரும்பினால் Podman-க்கு மாறுங்கள். விநியோக முறைமையும் (Distribution alignment) முக்கியமானது: RHEL மற்றும் அதன் மறுவடிவங்கள் Podman-ஐயே ஆதரிக்கப்படும் engine-ஆக வழங்குகின்றன, எனவே அந்த அமைப்புகளில் Podman-ஐப் பயன்படுத்துவது குறைவான சிக்கல்களைத் தரும். மற்ற அனைத்தையும் ஏற்கனவே systemd units மூலம் நிர்வகித்து வருகிறீர்கள் என்றால், quadlets என்பது ஒரு புதிய கருவியாகத் தெரியாமல், விடுபட்ட ஒரு பகுதியாகவே உங்களுக்குத் தோன்றும்.

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

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

FAQ

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

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

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

உங்கள் கடைசி login அமர்வு முடிவடையும் போது, systemd பயனர் அமர்வையும் (user session) அதனுடன் தொடர்புடைய அனைத்து பயனர் சேவைகளையும் நிறுத்திவிடுவதால் இது நிகழ்கிறது. 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 வரம்பிற்குள் (range) மாற்றுகிறது. 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 group, rootless Podman-ல் இல்லை. இது kernel பாதிப்புகளைத் தடுக்காது, மேலும் உங்கள் பயனர் அணுகக்கூடிய கோப்புகளைப் பாதுகாக்காது, எனவே எந்தவொரு server-லும் நீங்கள் செய்யும் பிற பாதுகாப்பு நடவடிக்கைகளைத் தொடர்ந்து மேற்கொள்ளுங்கள்.