SSD Nodes Learn Hosting plans →
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-08-27

Ubuntu 24.04-ல் Docker Compose அமைப்பது எப்படி?

Ubuntu 24.04-ல் Docker Engine மற்றும் Compose v2 நிறுவுவது எப்படி என்பதை அறியுங்கள். UFW firewall சிக்கல்களைத் தவிர்த்து, தரவுகளைப் பாதுகாப்பாக பேக்கப் எடுக்கும் முறைகளை விளக்குகிறோம்.

நீங்கள் உருவாக்குவது என்ன

இந்தத் தளத்தில் உள்ள பெரும்பாலானவற்றிற்கு Docker Compose தான் அடிப்படையாக உள்ளது. Nextcloud, Vaultwarden, n8n, Immich, Rocket.Chat என ஒவ்வொரு வழிகாட்டியும் "இந்த compose கோப்பை எழுதுங்கள்" என்றுதான் தொடங்குகிறது. அந்த கோப்பு உண்மையில் எதைக் குறிக்கிறது என்பதை இந்தப் பக்கம் விளக்குகிறது. நீங்கள் Ubuntu 24.04-ல் Docker-ன் சொந்த apt repository-லிருந்து Docker Engine மற்றும் Compose v2 plugin-ஐ நிறுவுவீர்கள். பின்னர், Miniflux எனும் சிறிய RSS reader மற்றும் PostgreSQL ஆகிய இரண்டு service-களைக் கொண்ட ஒரு stack-ஐ உருவாக்குவீர்கள். பெரிய applications-களில் பயன்படுத்தப்படும் அனைத்து முறைகளையும் இந்த ஜோடி உள்ளடக்கியுள்ளது: pinned images, healthcheck கொண்ட database, named volume, .env கோப்பில் உள்ள secrets மற்றும் localhost-க்கு மட்டும் திறக்கப்பட்ட port.

நிறுவுவதற்கு ஐந்து நிமிடங்கள் ஆகும். இந்த வழிகாட்டியின் மீதமுள்ள பகுதி, பிற்காலத்தில் சிக்கலை ஏற்படுத்தக்கூடிய அம்சங்களை விளக்குகிறது: docker group என்பது root-க்கு இணையானது, published ports உங்கள் ufw விதிகளைத் தாண்டிச் செயல்படுவது, மற்றும் docker compose down-ல் உள்ள ஒரு flag, உறுதிப்படுத்தல் (confirmation) கேட்காமலேயே உங்கள் database-ஐ நீக்கிவிடுவது போன்றவை இதில் அடங்கும்.

முன்தேவைகள்: புதிய Ubuntu 24.04 KVM VPS, sudo வசதி கொண்ட ஒரு பயனர், மற்றும் ஒரு gigabyte அல்லது அதற்கு மேற்பட்ட RAM. ஏற்கனவே Docker நிறுவப்பட்டிருந்தாலும் பரவாயில்லை, முதல் பகுதியில் எதை நீக்க வேண்டும் என்பது விளக்கப்பட்டுள்ளது.

Ubuntu-வின் repository-க்கு பதிலாக Docker-ன் repository-லிருந்து நிறுவுதல்

முதல் கட்டளையை இயக்கும் முன் தவிர்க்க வேண்டிய இரண்டு தவறுகள் உள்ளன. Ubuntu-வின் சொந்த docker.io package வேலை செய்யும், ஆனால் இது Docker-ன் புதிய releases-ஐ விடப் பின்தங்கியிருக்கும் மற்றும் பிற மென்பொருட்கள் எதிர்பார்க்கும் plugin அமைப்பைக் கொண்டிருக்காது. மேலும், ஹைபன் குறியீடு கொண்ட தனித்த docker-compose binary என்பது Compose v1 ஆகும்: இது Python-ல் எழுதப்பட்டது, 2023 முதல் பயன்பாட்டில் இல்லை, மேலும் பழைய tutorial-கள் வேலை செய்யாமல் போவதற்கு இதுவே காரணம். தற்போதைய Compose என்பது இடைவெளி கொண்ட docker compose ஆகும்; இது ஒரு CLI plugin, இது engine-ன் அதே repository-லிருந்து நிறுவப்படுகிறது.

இவற்றில் ஏதேனும் ஏற்கனவே உங்கள் கணினியில் இருந்தால், அவற்றை முதலில் நீக்கிவிடவும். இதில் Ubuntu-வின் சொந்த plugin தொகுப்பான docker-compose-v2-வும் அடங்கும், அப்போதுதான் அனைத்தும் ஒரே repository-லிருந்து வரும்:

sudo apt remove -y docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc

புதிய VPS-ல் Package 'docker.io' is not installed, so not removed என்பது இயல்பான வெளியீடாக இருக்கும். பின் Docker-ன் repository-ஐச் சேர்த்து நிறுவுங்கள்:

sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

மூன்று அடுக்குகளையும் சரிபார்க்கவும்:

docker --version
docker compose version
sudo docker run --rm hello-world

முதல் இரண்டு கட்டளைகளும் version strings-ஐக் காட்டும், Docker Compose version v2.x.x என்பது நீங்கள் v1 binary-க்கு பதிலாக plugin-ஐ வைத்துள்ளீர்கள் என்பதை உறுதிப்படுத்தும். hello-world கட்டளையின் இயக்கம் Hello from Docker! என்று முடிய வேண்டும். இந்த package boot-ன் போது service-ஐ இயக்கும்; systemctl is-enabled docker கட்டளை enabled என்று காட்டும்.

docker group என்பது root-க்கு சமமானது, விழிப்புணர்வுடன் முடிவெடுங்கள்

தற்போது ஒவ்வொரு docker கட்டளைக்கும் sudo தேவைப்படுகிறது, ஏனெனில் /var/run/docker.sock-ல் உள்ள daemon-ன் socket, root மற்றும் docker குழுவிற்குச் சொந்தமானது. இந்த குழுவில் உறுப்பினர் இல்லை என்றால், Docker தொடர்பான மிக முக்கியமான பிழைச் செய்தியைப் பெறுவீர்கள்:

permission denied while trying to connect to the Docker daemon socket at
unix:///var/run/docker.sock

இதற்கான பொதுவான தீர்வு:

sudo usermod -aG docker $USER

குழு உறுப்பினர் தகுதி நீங்கள் உள்நுழையும்போது (login) அமலுக்கு வரும், எனவே உங்கள் தற்போதைய shell-ல் பிழை தொடரும். இந்த session-க்கு மட்டும் newgrp docker-ஐ இயக்கவும், அல்லது வெளியேறி மீண்டும் உள்நுழையவும்; அதன் பிறகு id கட்டளை உங்கள் குழுக்களில் docker-ஐக் காட்ட வேண்டும்.

இப்போது உண்மையான நிலையைத் தெளிவாகக் கூறுகிறோம்: docker குழுவில் உறுப்பினராக இருப்பது என்பது host-ல் root-ஆக இருப்பதற்குச் சமம். இது "root போன்றது" அல்லது "உயர்த்தப்பட்ட அதிகாரம்" அல்ல, இது முழுமையான root. அந்த குழுவில் உள்ள எவரும் docker run --rm -it -v /:/host alpine chroot /host-ஐ இயக்கி, கடவுச்சொல் கேட்கப்படாமலேயே முழு filesystem-ஐயும் தங்கள் கட்டுப்பாட்டில் கொண்டு வர முடியும். இந்தக் குழு வசதிக்காக உருவாக்கப்பட்டது, பாதுகாப்பிற்காக அல்ல.

Docker-ன் rootless mode என்பதே உண்மையான மாற்று வழி; இதில் daemon உங்கள் சாதாரண பயனர் உரிமையிலேயே இயங்கும். இதற்கு நீங்கள் சிலவற்றை விட்டுக்கொடுக்க வேண்டியிருக்கும்: 1024-க்குக் கீழே உள்ள ports-க்கு கூடுதல் அமைப்பு தேவைப்படும், networking ஒரு userspace shim வழியாக இயங்குவதால் செயல்திறனில் சிறிய பாதிப்பு இருக்கும், மேலும் சில images உண்மையான root இல்லாமல் சரியாக இயங்காது. ஒரே ஒரு நிர்வாகி மட்டுமே உள்ள VPS-ல், ஏற்கனவே sudo அதிகாரம் இருப்பதால், இந்த குழு மாற்றத்தால் நடைமுறையில் எந்தப் பாதிப்பும் இல்லை. இந்தத் தொடரில் உள்ள அனைத்து வழிகாட்டிகளும் இதையே அடிப்படையாகக் கொண்டுள்ளன, ஆனால் இதை sudo-வை விடக் குறைவான அதிகாரம் என்று ஒருபோதும் கருத வேண்டாம்.

Compose கோப்பின் கட்டமைப்பு

ஒவ்வொரு stack-க்கும் தனித்தனி directory-ஐ ஒதுக்குங்கள். அந்த directory-ன் பெயரே project-ன் பெயராக மாறும்; இது containers, networks மற்றும் volumes-க்கு முன்னொட்டாக (prefix) அமையும்:

sudo mkdir -p /opt/miniflux && sudo chown $USER /opt/miniflux && cd /opt/miniflux

compose.yml-ஐ உருவாக்குங்கள் (இதுவே தற்போதைய நவீன முறை; docker-compose.yml இப்போதும் வேலை செய்யும்). பழைய version: key-ஐத் தவிர்க்கவும்; அது வழக்கற்றுப் போய்விட்டது, அதைப் பயன்படுத்தினால் Compose எச்சரிக்கை செய்யும்.

services:
  miniflux:
    image: miniflux/miniflux:2.2.9
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      - DATABASE_URL=postgres://miniflux:${POSTGRES_PASSWORD}@db/miniflux?sslmode=disable
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=${ADMIN_PASSWORD}
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=miniflux
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux", "-d", "miniflux"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  db-data:

மேலே உள்ள ஒவ்வொரு வரியும் ஒரு முக்கியமான முடிவு. ஒவ்வொன்றாகப் பார்ப்போம்.

Image version-களைக் குறிப்பிடுங்கள், :latest மற்றும் pull செய்வது தானியங்கி மேம்படுத்தல் அல்ல

postgres:16-alpine-ஐப் பயன்படுத்துங்கள், postgres:latest-ஐ அல்ல. ஒரு tag என்பது நிலையானது அல்ல: நீங்கள் ஒவ்வொரு முறை pull செய்யும்போதும், maintainer கடைசியாக எதை push செய்தாரோ அதையே :latest மீண்டும் பெற்றுக்கொள்ளும். இதனுடன் நீங்கள் கற்றுக்கொள்ளப்போகும் வழக்கமான மேம்படுத்தல் முறையான docker compose pull && docker compose up -d-ஐச் சேர்த்தால், upstream-ல் புதிய பதிப்பு வரும்போதெல்லாம் :latest தானாகவே major-version மாற்றங்களைச் செய்துவிடும். PostgreSQL-ல் இது வெறும் ஊகம் அல்ல: 16-லிருந்து 17-க்கு எதிர்பாராத விதமாக மாறினால், container crash-loop-ல் சிக்கிக்கொள்ளும். ஏனெனில், Postgres major upgrades-க்கு restart மட்டும் போதாது, dump மற்றும் restore செய்ய வேண்டும்.

குறைந்தது major version-ஐயாவது குறிப்பிடுங்கள் (postgres:16-alpine என்பது 16.x patch பதிப்புகளைக் குறிக்கும்). application-களை miniflux/miniflux:2.2.9 போன்ற சரியான பதிப்பு எண்ணுடன் குறிப்பிடுங்கள். project-ன் releases பக்கத்தைப் பார்த்து, கோப்பை எழுதும் நேரத்தில் எது தற்போதைய பதிப்போ அதைப் பயன்படுத்துங்கள். அப்போதுதான், நீங்கள் திட்டமிட்டுச் செய்யும் ஒரு வரி மாற்றமாக மேம்படுத்தல் அமையும், இது git diff-ல் தெளிவாகத் தெரியும்.

127.0.0.1-ல் publish செய்யுங்கள், ஏனெனில் Docker ufw-ஐத் தவிர்க்கிறது

"127.0.0.1:8080:8080" என்பது host address, host port, container port ஆகியவற்றைக் குறிக்கும். பெரும்பாலான tutorials "8080:8080" என்று குறிப்பிடுகின்றன, இது 0.0.0.0:8080:8080-ன் சுருக்கமாகும்: அதாவது, public interface உட்பட அனைத்து interface-களிலும் இது கேட்கும் (listen).

இங்கேயேதான் சிக்கல் தொடங்குகிறது, இது அனைவரையும் ஒருமுறையாவது பாதிக்கும். Docker ஒரு port-ஐ publish செய்யும்போது, packet-ன் destination-ஐ container-ன் internal IP-க்கு மாற்றும் DNAT விதியை எழுதும். இது filtering-க்கு முன்பே நடப்பதால், packet FORWARD பாதையில் சென்று, உங்கள் ufw விதிகள் இருக்கும் INPUT-ஐத் தொடவே செய்யாது. sudo ufw deny 8080 வெற்றி என்று காட்டும், ufw status port மறுக்கப்பட்டதாகக் காட்டும், ஆனால் அந்த service முழு இணையத்திற்கும் பதிலளித்துக்கொண்டிருக்கும். உங்கள் firewall பழுதடையவில்லை; அது வடிவமைப்பிலேயே தவிர்க்கப்படுகிறது. Docker ஏன் ufw-ஐத் தவிர்க்கிறது மற்றும் container traffic-ஐ எவ்வாறு முறையாக filter செய்வது என்ற கட்டுரை, இதற்கான காரணத்தையும், public-ஆக இருக்க வேண்டிய port-களுக்கான DOCKER-USER தீர்வையும் விளக்குகிறது.

இந்தச் சிக்கலைத் தவிர்க்கும் சிறந்த வழி: குறிப்பிட்ட காரணம் இல்லையென்றால், publish செய்த port-களை 127.0.0.1-ல் bind செய்யுங்கள். உலகிற்குத் தெரிய வேண்டிய எதற்கும் முன்னால் ஒரு reverse proxy-ஐ வையுங்கள். இதுதான் இந்தத் தொடரின் அடுத்த கட்டமாக Traefik reverse proxy guide-ல் விளக்கப்பட்டுள்ளது. இது 80 மற்றும் 443 port-களைக் கையாளும் ஒரே container-ஐ உருவாக்கி, TLS மூலம் hostname அடிப்படையில் அனைத்தையும் வழிநடத்தும். (பழைய Traefik v2-லிருந்து வருகிறீர்களா? Traefik v2 to v3 migration guide பெயர் மாற்றங்கள் மற்றும் விதி மாற்றங்களை விளக்குகிறது.)

Stack-ஐத் தொடங்கிய பிறகு bind சரியாக உள்ளதா எனச் சரிபார்க்கவும்: sudo ss -tlnp | grep 8080 கட்டளை 127.0.0.1:8080-ஐக் காட்ட வேண்டும், 0.0.0.0:8080 அல்லது *:8080-ஐ அல்ல.

Named volumes vs bind mounts

db-data:/var/lib/postgresql/data என்பது ஒரு named volume: Docker, /var/lib/docker/volumes/-க்குக் கீழ் ஒரு directory-ஐ உருவாக்கி நிர்வகிக்கும், அதை container-க்குள் mount செய்யும். இதற்கு மாற்றாக இருப்பது bind mount, ./data:/var/lib/postgresql/data; இது host-ல் நீங்கள் தேர்ந்தெடுக்கும் ஒரு path-ஐ map செய்யும்.

நடைமுறையில் இதைப் பிரிக்கும் முறை: container மட்டுமே கையாளும் தரவுகளுக்கு named volumes-ஐப் பயன்படுத்துங்கள், குறிப்பாக databases. ஏனெனில், image எதிர்பார்ப்பது போலவே Docker அந்த volume-ன் உரிமையையும் (ownership) அனுமதிகளையும் (permissions) அமைத்துவிடும். நீங்கள் host-லிருந்து கையாளும் கோப்புகளுக்கு bind mounts-ஐப் பயன்படுத்துங்கள், உதாரணமாக நீங்கள் திருத்தும் config கோப்புகள் அல்லது rsync செய்யும் media library. Bind-mount-ல் பொதுவாக ஏற்படும் சிக்கல் உரிமை சார்ந்தது: container UID 999-ல் இயங்கும், உங்கள் host directory UID 1000-ல் இருக்கும், இதனால் app தொடங்கும்போதே permission denied பிழையுடன் நின்றுவிடும். Named volumes இந்த வகைச் சிக்கல்களைத் தவிர்க்கும், ஆனால் தரவுகள் Docker நிர்வகிக்கும் path-ல் இருக்கும்.

environment மற்றும் .env, ரகசியங்களை git-ல் வைக்காதீர்கள்

${POSTGRES_PASSWORD} உங்கள் shell-லிருந்து படிக்கப்படாது; compose.yml-க்கு அருகில் உள்ள .env என்ற கோப்பிலிருந்து Compose அதை எடுத்துக்கொள்ளும். அதை உருவாக்கவும்:

cat > .env <<'EOF'
POSTGRES_PASSWORD=change-me-to-something-long
ADMIN_PASSWORD=change-me-too
EOF
chmod 600 .env
echo ".env" >> .gitignore

openssl rand -hex 24 மூலம் உண்மையான மதிப்புகளை உருவாக்குங்கள். Hex-ஐப் பயன்படுத்துங்கள், base64-ஐ அல்ல. ஏனெனில், இந்த password DATABASE_URL connection string-க்குள் செல்லும். base64 உருவாக்கும் /, +, மற்றும் = குறியீடுகள் URL parsing-ஐப் பாதிக்கும். இது syntax பிழையாகத் தெரியாமல் authentication பிழையாகத் தெரியும், இதைச் சரிசெய்ய ஒரு மாலைப்பொழுதே தேவைப்படலாம். .gitignore வரியை முதல் commit-க்கு முன்பே சேர்த்துவிடுங்கள்: compose கோப்பை git-ல் பதிவேற்றலாம், ஆனால் .env கோப்பை ஒருபோதும் பதிவேற்றக்கூடாது. git history-ல் ஒரு ரகசியம் கசிந்துவிட்டால், அதை மாற்றிவிடுங்கள் (rotate). ஒரு variable இல்லாமல் stack-ஐத் தொடங்கினால், Compose எச்சரிக்கை செய்யும், ஆனால் empty string-ஐ வைத்துத் தொடரும். Postgres password-க்கு இது deployment தோல்வியையே தரும்:

WARN[0000] The "POSTGRES_PASSWORD" variable is not set. Defaulting to a blank string.

docker compose config கட்டளை முழுமையாக நிரப்பப்பட்ட கோப்பைக் காட்டும், containers எதைப் பெறும் என்பதைச் சரிபார்க்க இதுவே வேகமான வழி; இதன் வெளியீட்டில் உங்கள் ரகசியங்களும் இருக்கும் என்பதை நினைவில் கொள்ளுங்கள்.

depends_on எதற்கும் காத்திருக்காது, healthcheck சேர்த்தால் ஒழிய

வெறும் depends_on: [db] என்பது தொடங்கும் வரிசையை (order) மட்டுமே கட்டுப்படுத்தும்: Postgres-ஐ முதலில் தொடங்கும், சிறிது நேரத்தில் app-ஐத் தொடங்கும். ஆனால், Postgres இணைப்புகளை ஏற்கத் தயாராவதற்கு முன்பே app தரவுத்தளத்தை அணுகி, தோல்வியடைந்து crash ஆகும்.

மேலே உள்ள கோப்பில் உள்ளதுதான் நம்பகமான முறை: db service ஒரு healthcheck-ஐ வரையறுக்கிறது (Postgres இதற்காகவே pg_isready-ஐ வழங்குகிறது), app depends_on-ஐ condition: service_healthy மூலம் குறிப்பிடுகிறது. Compose தரவுத்தளத்தைத் தொடங்கி, ஒவ்வொரு 10 வினாடிக்கும் healthcheck-ஐச் சரிபார்க்கும். check வெற்றி பெற்றால் மட்டுமே Miniflux-ஐத் தொடங்கும். தரவுத்தளம் சரியாக இயங்கவில்லை என்றால் (தவறான password, பழுதடைந்த volume), app தொடங்காது, எந்த dependency தோல்வியடைந்தது என்பதை Compose உங்களுக்குத் தெரிவிக்கும்:

dependency failed to start: container miniflux-db-1 is unhealthy

அந்தச் செய்தி உங்களை docker compose logs db-க்கு அழைத்துச் செல்லும், அங்குதான் உண்மையான பிழை இருக்கும்.

restart: unless-stopped

இரு service-களிலும் restart: unless-stopped இருந்தால், crash ஆனாலோ அல்லது VPS reboot ஆனாலோ containers மீண்டும் தொடங்கும். ஆனால், நீங்கள் வேண்டுமென்றே docker compose stop கட்டளையைப் பயன்படுத்தினால் அவை இயங்காது. இதற்கு மாற்றான always, நீங்கள் கைமுறையாக நிறுத்தினாலும் containers-ஐ மீண்டும் உயிர்ப்பிக்கும், இது பெரும்பாலும் நீங்கள் விரும்புவதாக இருக்காது. Restart policy இல்லையென்றால், அதிகாலை 4 மணிக்கு நடக்கும் kernel-update reboot உங்கள் services-ஐ நிறுத்திவிடும், நீங்கள் கவனிக்கும் வரை அவை இயங்காது.

அன்றாட செயல்பாடுகள்

தினசரி பயன்பாட்டிற்கு ஐந்து கட்டளைகள் மட்டுமே தேவை, இவற்றை project directory-ல் இருந்து இயக்க வேண்டும்.

docker compose up -d        # create and start; idempotent, recreates only what changed
docker compose ps           # status, ports, and health of this project's containers
docker compose logs -f miniflux   # follow one service's logs; --tail 100 for recent history
docker compose pull && docker compose up -d   # upgrade to the pinned tags
docker compose down         # stop and remove containers and the network

up -d கட்டளையை மீண்டும் மீண்டும் இயக்குவது பாதுகாப்பானது; இது கோப்புகளை தற்போதைய நிலையுடன் ஒப்பிட்டு, configuration அல்லது image மாறியுள்ள services-ஐ மட்டும் மாற்றியமைக்கும். Upgrade ஜோடி கட்டளைகள், நீங்கள் குறிப்பிட்ட tags எதைக் குறிக்கின்றனவோ அந்தப் புதிய பதிப்புகளைப் பதிவிறக்கும்: postgres:16-alpine மூலம் patch பதிப்புகள் கிடைக்கும், ஆனால் குறிப்பிட்ட பதிப்பை (exact pin) மாற்றும் வரை அது மாறாது, இதுவே இதன் நோக்கம். Upgrade-க்கு பிறகு பழைய images தேங்கிவிடும்; docker image prune -f மூலம் வட்டு இடத்தை (disk space) மீட்டெடுக்கலாம்.

இப்போது அழிவை ஏற்படுத்தும் கட்டளை, கவனமாக இருக்கவும்: docker compose down பாதுகாப்பானது, containers மற்றும் network-ஐ எப்போது வேண்டுமானாலும் நீக்கலாம், உங்கள் தரவு volume-ல் இருக்கும். docker compose down -v கட்டளை named volumes-ஐயும் நீக்கிவிடும். அதாவது உங்கள் database, எந்தவித உறுதிப்படுத்தலும் (confirmation) இன்றி, உடனடியாகவும் மீட்க முடியாத வகையிலும் அழிந்துவிடும். -v flag சோதனைகளை நீக்குவதற்காக உருவாக்கப்பட்டது; உண்மையான தரவு உள்ள stack-ல், இதை rm -rf கட்டளையைப் போலவே கவனமாகக் கையாளவும். /var/lib/docker/volumes/-ல் குப்பைத் தொட்டி (trash can) வசதி கிடையாது.

இயங்கிக்கொண்டிருக்கும் container-க்குள் ஒருமுறை shell-ஐப் பெற: docker compose exec db psql -U miniflux உங்களை database-க்குள் கொண்டு செல்லும், docker compose exec miniflux sh உங்களை app-க்குள் shell-க்கு அழைத்துச் செல்லும்.

உங்கள் தரவு உண்மையில் எங்கு சேமிக்கப்படுகிறது

Named volumes-க்கு project prefix சேர்க்கப்படும். எனவே, miniflux என்ற கோப்பகத்தில் உள்ள db-data என்பது miniflux_db-data என்று மாறும்:

docker volume ls
docker volume inspect miniflux_db-data

inspect வெளியீட்டில் முக்கியமான வரி இதோ:

"Mountpoint": "/var/lib/docker/volumes/miniflux_db-data/_data"

அந்தக் கோப்பகம் தான் database ஆகும். இது host filesystem-ல் root உரிமையுடன் இருக்கும். இது down, upgrades மற்றும் container rebuilds ஆகியவற்றிற்குப் பிறகும் அழியாமல் இருக்கும். உங்கள் backups-ல் இந்த இடத்தைச் சேர்ப்பது கட்டாயமாகும்.

Named volume-ஐ பேக்கப் எடுத்தல்

இதற்கான பொதுவான முறை, ஒரு தற்காலிக container-ஐ உருவாக்கி, அதில் volume-ஐ read-only முறையில் mount செய்து, host directory-க்கு tar கோப்பாக மாற்றுவதாகும்:

docker run --rm \
  -v miniflux_db-data:/data:ro \
  -v "$PWD":/backup \
  alpine:3.22 tar czf /backup/miniflux-db-$(date +%F).tar.gz -C /data .

இதில் எதையும் install செய்ய வேண்டியதில்லை, பின்னணியில் எந்த process-ம் இயங்காது. Restore செய்வதற்கு, இதே முறையைத் தலைகீழாகச் செய்து, tar xzf கட்டளை மூலம் புதிய காலி volume-ல் கோப்புகளைப் பதிவேற்ற வேண்டும்.

Database-களுக்கு ஒரு முக்கிய எச்சரிக்கை: இயங்கிக்கொண்டிருக்கும் Postgres data directory-ஐ tar செய்யும்போது, தரவு எழுதும் நிலையில் (mid-write) இருந்தால், அது சரியாக இயங்காமல் போகலாம். எனவே, tar எடுக்கும் சில நொடிகள் docker compose stop செய்ய வேண்டும். அல்லது, logical dump எடுப்பது சிறந்தது, இது தரவு ஒருமைப்பாட்டை (consistency) உறுதி செய்யும்:

docker compose exec -T db pg_dump -U miniflux miniflux | gzip > miniflux-$(date +%F).sql.gz

-T என்பது Compose இயல்பாக ஒதுக்கும் pseudo-terminal-ஐத் தவிர்க்கிறது; dump output-ஐ TTY வழியாக அனுப்பினால் அது சிதைந்துவிட வாய்ப்புள்ளது. இதில் ஏதேனும் ஒன்றை cron-ல் சேர்த்து, அதன் முடிவுகளை VPS-க்கு வெளியே நகர்த்தவும்; தரவு இருக்கும் அதே disk-ல் பேக்கப் எடுப்பது உண்மையான பேக்கப் ஆகாது, அது வெறும் நகல் மட்டுமே. Nextcloud வழிகாட்டி இந்த இரண்டு முறைகளையும் பயன்படுத்தி முழுமையான காலமுறை பேக்கப் திட்டத்தை உருவாக்குகிறது.

தோல்வி நிலைகள் மற்றும் நீங்கள் காணும் செய்திகள்

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock, நீங்கள் இன்னும் docker குழுவில் இல்லை, அல்லது நீங்கள் குழுவில் இருந்தாலும் தற்போதைய session அதற்கு முன்பே தொடங்கப்பட்டது. id உங்கள் தற்போதைய குழுக்களைக் காட்டும்; newgrp docker தற்போதைய shell-ஐச் சரிசெய்யும், வெளியேறி மீண்டும் உள்நுழைவது அனைத்து மாற்றங்களையும் நடைமுறைப்படுத்தும்.

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?, இது வேறு சிக்கல்: daemon செயலிழந்துள்ளது. sudo systemctl status docker மற்றும் sudo journalctl -u docker -n 50 இதற்கான காரணத்தைக் கூறும். VPS-ல் இதற்குப் பொதுவான காரணம் வட்டு (disk) நிறைந்து இருப்பது, முதலில் df -h /var/lib/docker மூலம் சரிபார்க்கவும்.

Bind for 127.0.0.1:8080 failed: port is already allocated, மற்றொரு container ஏற்கனவே அந்த host port-ஐப் பயன்படுத்துகிறது. docker ps எந்த container பயன்படுத்துகிறது என்பதைக் காட்டும்; சில docker run வாரங்களுக்கு முன்பு சோதனைக்காக இயக்கப்பட்ட பழைய container-ஆக இது இருக்கலாம். docker ps காலியாக இருந்தால், Docker அல்லாத ஒரு process அந்த port-ஐப் பிடித்திருக்கலாம்: sudo ss -tlnp | grep 8080 அந்த process-ன் பெயரைத் தெரிவிக்கும்.

yaml: line 14: did not find expected key, குறிப்பிடப்பட்ட வரியிலோ அல்லது அதற்கு மேலோ indentation பிழை உள்ளது. Compose கோப்புகள் YAML வடிவில் இருப்பவை: இரண்டு இடைவெளி (two-space) indentation மட்டுமே பயன்படுத்த வேண்டும், tab எழுத்து எங்கு இருந்தாலும் அது பிழையை உண்டாக்கும். docker compose config எதையும் தொடங்காமல் கோப்பைச் சரிபார்க்கும், ஒவ்வொரு முறை திருத்தம் செய்த பிறகும் இதை இயக்குவது நல்ல பழக்கம்.

ufw ஆச்சரியம் எந்தப் பிழையையும் காட்டாது, இதுவே இதை ஆபத்தானதாக மாற்றுகிறது: deploy வெற்றிகரமாக நடக்கும், ufw status சரியாகத் தோன்றும், ஆனால் வெளியிலிருந்து port scan செய்தால் உங்கள் database-ஐ யாராலும் அணுக முடியும். மேலே உள்ள ports பகுதியை மீண்டும் படிக்கவும், ஒவ்வொரு ports: பதிவிலும் 127.0.0.1: முன்னொட்டு விடுபட்டுள்ளதா என்று சரிபார்க்கவும், வேறொரு கணினியிலிருந்து curl http://your-vps-ip:8080 மூலம் உறுதிப்படுத்தவும், connection refused என்பதே நீங்கள் எதிர்பார்க்கும் பதில்.

இங்கிருந்து, Traefik வழிகாட்டி இந்த ஒற்றை stack-ஐ ஒரே HTTPS நுழைவாயிலுக்குப் பின்னால் பல பயன்பாடுகளாக மாற்றுகிறது, மேலும் 2026-ல் எவற்றை self-host செய்யலாம் என்பது இதனுள் இயக்க வேண்டிய பயன்பாடுகளின் பட்டியல். பல stack-கள் இயங்கி, ஒவ்வொன்றும் தனித்தனி login படிவங்களைக் கொண்டிருக்கும்போது, Authentik போன்ற self-hosted SSO server அவற்றை ஒரே proxy-க்கு பின்னால் ஒரே கணக்காக மாற்றும்.

VPS-ல் இயங்கும் Minecraft server போன்ற ஒரு game server மூலம் தொடங்குவது, முதல் Compose project-ஐப் பயிற்சி செய்ய ஏற்ற எளிய வழியாகும். தினமும் திறந்து பயன்படுத்தும் ஒன்றில் கற்றுக்கொள்ள விரும்பினால், self-hosted workout tracker-ஆன openGym ஒரு சிறிய stack ஆகும். இது image tag-க்கு பதிலாக git tag-ல் நிலைப்படுத்தப்பட்டுள்ளது. முதல் passkey-ஐ பதிவு செய்வதற்கு முன், இதன் முன்புறத்தில் TLS அமைக்க வேண்டும். பிறரின் cloud-லிருந்து மீட்டெடுக்க மக்கள் பொதுவாக முதலில் விரும்புவது photos ஆகும். PhotoPrism மற்றும் Immich-ஐ ஒப்பிடுவது, இரண்டில் ஏதேனும் ஒன்றுக்காக volume-ஐ ஒதுக்குவதற்கு முன் தேவையான குறைந்தபட்ச RAM அளவையும் நீங்கள் பின்பற்ற வேண்டிய backup நடைமுறையையும் தெளிவுபடுத்தும். இரண்டு services போதாது என்று தோன்றத் தொடங்கும்போது, Notion-style workspace ஆக AFFiNE-ஐ அமைப்பது நான்கு containers-ல் இதே patterns-ஐப் பயன்படுத்துகிறது. மேலே குறிப்பிடப்பட்ட pinned tags, healthchecks, மற்றும் named volumes ஆகியவை உங்கள் வழக்கமான நடைமுறையாகிவிட்டனவா என்பதைச் சோதிக்க இது பொருத்தமான project ஆகும்.

FAQ

"permission denied while trying to connect to the Docker daemon socket" என்ற பிழை ஏன் வருகிறது?

உங்கள் பயனர் docker குழுவில் இல்லை அல்லது தற்போதைய session தொடங்கிய பிறகுதான் சேர்க்கப்பட்டார்; குழு உறுப்பினர் தகுதி login செய்யும் போது மட்டுமே அமலுக்கு வரும். sudo usermod -aG docker $USER கட்டளையை இயக்கவும், பிறகு newgrp docker கட்டளையைப் பயன்படுத்தவும் அல்லது logout செய்து மீண்டும் login செய்யவும், பின் id மூலம் உறுதிப்படுத்தவும். இந்தக் குழு host-ல் root-க்கு இணையான அணுகலை வழங்குகிறது, எனவே sudo அனுமதி வழங்கக்கூடிய பயனர்களை மட்டுமே இதில் சேர்க்கவும்.

docker compose down கட்டளை எனது தரவை நீக்கிவிடுமா?

சாதாரண docker compose down கட்டளை தரவை நீக்காது; இது containers மற்றும் project network-ஐ மட்டுமே நீக்கும். Named volumes அப்படியே இருக்கும், அடுத்தமுறை up -d இயக்கும்போது அவை மீண்டும் இணைக்கப்படும். docker compose down -v என்பது தரவை அழிக்கும் வடிவம்: இது named volumes-ஐ நீக்கிவிடும், அதாவது உங்கள் database-ம் நீக்கப்படும்; இதற்கு உறுதிப்படுத்தல் கேட்கப்படாது, மீட்கவும் முடியாது. உங்களிடம் சரிபார்க்கப்பட்ட backup இல்லாத வரை, உண்மையான தரவு உள்ள stack-ல் ஒருபோதும் -v கட்டளையை இயக்க வேண்டாம்.

docker-compose மற்றும் docker compose ஆகியவற்றுக்கு இடையே உள்ள வேறுபாடு என்ன?

docker-compose (hyphen) என்பது Compose v1 ஆகும். இது ஒரு தனித்த Python binary, இதன் ஆயுட்காலம் 2023-ல் முடிந்துவிட்டது, புதிய server-களில் இதை நிறுவக்கூடாது. docker compose (space) என்பது Compose v2 ஆகும். இது Docker CLI-க்கான Go plugin, இது Docker-ன் apt repository-லிருந்து docker-compose-plugin ஆக நிறுவப்படுகிறது. கட்டளைகளும் YAML கோப்புகளும் பெரும்பாலும் இணக்கமானவை, எனவே பழைய tutorial-களில் docker-compose up என்று இருந்தால், நீங்கள் docker compose up என்று தட்டச்சு செய்யவும்.

ufw மூலம் port தடுக்கப்பட்டிருந்தாலும், இணையத்திலிருந்து எனது Docker container-ஐ ஏன் அணுக முடிகிறது?

Docker தனது ports-ஐ iptables-ன் PREROUTING chain-ல் DNAT விதிகள் மூலம் வெளியிடுவதால், மாற்றியமைக்கப்பட்ட packets Docker-ன் சொந்த chain-கள் வழியாக FORWARD பாதையில் செல்கின்றன. இவை ufw விதிகள் செயல்படும் INPUT chain-ஐ அடைவதில்லை. எனவே, வெளியிடப்பட்ட container port-க்கு ufw deny 8080 எந்தப் பாதிப்பையும் ஏற்படுத்தாது. இதைச் சரிசெய்ய, port-ஐ 127.0.0.1:-க்கு மட்டும் வெளியிடவும், சேவைகளை reverse proxy வழியாக அணுகவும்.

நான் named volume-ஐப் பயன்படுத்த வேண்டுமா அல்லது bind mount-ஐப் பயன்படுத்த வேண்டுமா?

Container மட்டுமே பயன்படுத்தும் தரவுகளுக்கு, குறிப்பாக database-களுக்கு named volumes-ஐப் பயன்படுத்தவும். ஏனெனில், image-க்குத் தேவையான ownership-ஐ Docker அமைத்துவிடும், அனுமதிகளும் சரியாகச் செயல்படும். நீங்கள் host-லிருந்து கையாளும் கோப்புகளுக்கு bind mounts-ஐப் பயன்படுத்தவும்: நீங்கள் திருத்தும் configs, நீங்கள் பதிவேற்றும் media, அல்லது அதன் பாதை உங்களுக்குத் தெளிவாகத் தெரிய வேண்டிய கோப்புகள். ஒரு bind mount-ல் container தொடங்கும் போது permission denied பிழை ஏற்பட்டால், host மற்றும் container-க்கு இடையிலான UID முரண்பாட்டை முதலில் சரிபார்க்கவும்.

#docker#docker-compose#ubuntu#self-hosting