VPS-ல் Docker Compose அடிப்படை: Ubuntu 24.04 வழிகாட்டி

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

Docker Compose ஆனது இந்தத் தளத்தில் உள்ள மற்ற எல்லாவற்றிற்கும் அடிப்படையாக இருக்கிறது. Nextcloud, Vaultwarden, n8n, Immich, Rocket.Chat — இந்த வழிகாட்டிகள் ஒவ்வொன்றுமே "இந்த compose கோப்பை எழுதுங்கள்" என்று தொடங்குகின்றன. அந்தக் கோப்பு உண்மையில் என்ன பொருள் படுகிறது என்பதை விளக்கும் பக்கம் இதுவாகும். நீங்கள் Ubuntu 24.04 இல் Docker இன் சொந்த apt களஞ்சியத்திலிருந்து Docker Engine மற்றும் Compose v2 சொருகையை நிறுவுவீர்கள். பின்னர் இரண்டு சேவைகளைக் கொண்ட ஒரு உண்மையான அடுக்கை எழுப்புவீர்கள் — சிறிய RSS வாசிப்பி Miniflux மற்றும் PostgreSQL. இந்த இணை பெரிய செயலிகள் பயன்படுத்தும் ஒவ்வொரு வடிவத்தையும் சோதிக்கிறது: பொருத்தப்பட்ட இமேஜ்கள், healthcheck கொண்ட தரவுத்தளம், பெயரிடப்பட்ட தொகுதி, .env கோப்பில் ரகசியங்கள், மற்றும் localhost க்கு மட்டும் வெளியிடப்பட்ட போர்ட்.

நிறுவல் ஐந்து நிமிடங்கள் ஆகும். இந்த வழிகாட்டியின் மீதமுள்ள பகுதி பிறகு தொல்லை தரும் அம்சங்களை உள்ளடக்கியது: docker குழு என்பது வேறொரு பெயரில் root ஆகும், வெளியிடப்பட்ட போர்ட்கள் உங்கள் ufw விதிகளை நேரடியாகத் தாண்டிச் செல்கின்றன, மற்றும் எந்த உறுதிப்படுத்தலும் இல்லாமல் உங்கள் தரவுத்தளத்தை நீக்கும் docker compose down இல் உள்ள ஒரு flag.

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

Docker-இன் களஞ்சியத்திலிருந்து நிறுவவும், Ubuntu-இன் களஞ்சியத்திலிருந்து அல்ல

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

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

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-இன் களஞ்சியத்தைச் சேர்த்து நிறுவவும்:

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

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

docker குழு என்பது 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

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

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

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

compose கோப்பின் அமைப்பு

ஒவ்வொரு stack-க்கும் அதனது சொந்த கோப்புறையை வழங்கவும் — கோப்புறையின் பெயரே project பெயராகும், அது containers, networks, மற்றும் volumes-ன் முன்னொட்டாக அமையும்:

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 பதிப்புகளை பிடித்துவைக்கவும் — :latest உடன் ஒரு pull என்பது கவனிக்கப்படாத மேம்பாடு

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

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

127.0.0.1 க்கு வெளியிடவும், ஏனெனில் Docker என்பது ufw-ஐ புறக்கணித்து செல்கிறது

"127.0.0.1:8080:8080" — host முகவரி, host port, container port. பெரும்பாலான பயிற்சிகள் "8080:8080" என எழுதுகின்றன, அது 0.0.0.0:8080:8080-க்கான சுருக்கம்: ஒவ்வொரு interface-லும், public interface உட்பட, கவனிப்பது.

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

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

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

Named volumes மற்றும் bind mounts

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

நடைமுறையில் நிலைத்திருக்கும் பிரிப்பு: containers தொடும் தரவிற்கு மட்டும் named volumes — மேலெல்லாம் தரவுத்தளங்கள், ஏனெனில் Docker தொகுதியை image எதிர்பார்க்கும் உரிமையுடன் தொடங்குகிறது மற்றும் கோப்பு அனுமதிகள் சரியாக வேலை செய்கின்றன. நீங்கள் host-லிருந்து தொடும் கோப்புகளுக்கு bind mounts — நீங்கள் உரை ஆசிரியர் கொண்டு திருத்தும் config கோப்புகள், நீங்கள் rsync செய்யும் ஒரு media நூலகம், அதன் பாதை வெளிப்படையாக இருக்க வேண்டும் என நீங்கள் விரும்பும் எதுவும். பாரம்பரிய bind-mount தோல்வி உரிமை: container ஆனது UID 999 ஆக இயங்குகிறது, உங்கள் host கோப்புறையின் உரிமையாளர் UID 1000, மேலும் பயன்பாடு தொடக்கத்தில் அதன் பதிவுகளில் permission denied உடன் இறக்கிறது. Named volumes அந்த வகுப்பு பிழையை பெரும்பாலும் மறைக்கின்றன, தரவு ஒரு Docker-நிர்வகிக்கும் பாதையில் இருப்பதற்கான செலவில் — கீழே விளக்கப்பட்டுள்ளது.

environment மற்றும் .env — ரகசியங்களை git-லிருந்து வெளியே வைக்கவும்

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

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 அல்ல, வேண்டுமென்றே: இந்த கடவுச்சொல் DATABASE_URL connection string-க்குள் வருகிறது, மேலும் base64 உருவாக்கும் /, +, மற்றும் = எழுத்துக்கள் URL parsing-ஐ உடைக்கின்றன — இந்த தோல்வி ஒரு syntax பிழையாக அல்லாமல் authentication பிழையாக வெளிப்படுகிறது, மேலும் ஒரு மாலை நேரத்தை ஆக்கிரமிக்கிறது. .gitignore வரி முதல் commit-க்கு முன் சேர்க்கப்படுகிறது: compose கோப்பு வெளியிடவும் version செய்யவும் பாதுகாப்பானது, .env கோப்பு ஒருபோதும் பாதுகாப்பானதல்ல, மேலும் git வரலாற்றைத் தொட்ற ஒரு ரகசியம் என்பது நீங்கள் rotate செய்யும் ரகசியம். ஒரு variable இல்லாமல் stack-ஐ தொடங்கினால், Compose சத்தமாக எச்சரித்து வெற்று சரத்துடன் தொடரும் — அது Postgres கடவுச்சொல்லுக்கு ஒரு உடைந்த deployment என்று பொருள்:

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

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

depends_on எதற்கும் காத்திருப்பதில்லை — நீங்கள் ஒரு healthcheck சேர்க்கும் வரை

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

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

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

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

restart: unless-stopped

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

தினசரி வினைகள்

தினசரி அனைத்தும் ஐந்து கட்டளைகள், project அடைவிலிருந்து இயக்கப்படுகின்றன.

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 மீண்டும் மீண்டும் இயக்குவது பாதுகாப்பானது — இது கோப்பினை நிஜநிலையுடன் ஒப்பிடுகிறது, config அல்லது image மாறியுள்ள சேவைகளை மட்டுமே தொடுகிறது. மேம்படுத்தல் இணை உங்கள் பொருத்தப்பட்ட tags தற்போது சுட்டும் இடத்தை எடுக்கிறது: postgres:16-alpine கீழ் patch வெளியீடுகள், நீங்கள் திருத்தும் வரை சரியான பொருத்தத்திற்கு எதுவும் இல்லை — இதுவே நோக்கம். பழைய images மேம்படுத்தலுக்குப் பிறகு திரளுகின்றன; docker image prune -f மூலம் வட்டை மீட்கவும்.

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

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

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

பெயரிடப்பட்ட தொகுதிகள் திட்டத்தின் முன்னொட்டைப் பெறுகின்றன. எனவே db-data என்ற கோப்பகத்தில் miniflux என்ற பெயரில் இருந்தால், அது miniflux_db-data ஆகிறது:

docker volume ls
docker volume inspect miniflux_db-data

inspect வெளியீடு முக்கியமான வரியைக் கொண்டுள்ளது:

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

அந்த கோப்பகம்தான் தரவுத்தளம். இது பெருநிருவாகி உரிமையுடையது. இது பெருநிருவாகி கோப்பு முறைமையில் உள்ளது. இது down, மேம்படுத்தல்கள் மற்றும் கொள்கலன் மறுகட்டமைப்புகளைக் கடந்து நிலைத்திருக்கும். உங்கள் காப்புப்பிரதிகள் இதைத்தான் சேமிக்க வேண்டும்.

பெயரிடப்பட்ட வால்யூமை காப்புப் பிரதி எடுக்கவும்

நிலையான முறை ஒரு தற்காலிக கன்டெய்னரைப் பயன்படுத்துவதாகும். இந்த கன்டெய்னர் வால்யூமை படிக்க மட்டும் அணுகலுடன் ஹோஸ்ட் டைரக்டரியுடன் இணைத்து மவுண்ட் செய்கிறது. பிறகு 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 .

எதையும் நிறுவ தேவையில்லை. பின்னணியில் எதுவும் இயங்காது. மீட்டெடுப்பு இதற்கு நேர்மாறான செயல்முறை — tar xzf கட்டளையை புதிய காலி வால்யூமில் இதே மவுண்டுகளை தலைகீழாகக் கொடுத்து இயக்கவும்.

டேட்டாபேஸ்களுக்கு ஒரு எச்சரிக்கை: இயங்கிக்கொண்டிருக்கும் Postgres டேட்டா டைரக்டரியை tar செய்வது எழுத்து நடக்கும் நிலையைப் பிடிக்கக்கூடும். அது சரியாக தொடங்காது. tar கட்டளை இயங்கும் சில நொடிகளுக்கு docker compose stop செய்யவும். அல்லது — சிறந்த வழி — ஒரு லாஜிக்கல் டம்ப் எடுக்கவும். அது அமைப்பின் அடிப்படையிலேயே ஒருங்கிணைந்ததாக இருக்கும்:

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

-T கட்டளை Compose இயல்பாக ஒதுக்கும் போலி-டெர்மினலை முடக்குகிறது — டம்ப் வெளியீட்டை TTY வழியாகக் கடத்துவது அதைச் சேதப்படுத்தக்கூடும். இவற்றில் ஒன்றை cron-ல் சேர்த்து, முடிவை VPS-இலிருந்து வெளியே நகலெடுக்கவும்; ஒரு தரவைப் பாதுகாக்கும் அதே வட்டில் இருக்கும் காப்புப் பிரதி ஒரு நகல் மட்டுமே, காப்புப் பிரதி அல்ல. Nextcloud வழிகாட்டி இந்த இரண்டு முறைகளையும் அடிப்படையாகக் கொண்டு ஒரு முழு திட்டமிடப்பட்ட வழிமுறையை உருவாக்குகிறது.

பிழை வகைகள், நீங்கள் காணும் சரங்களுடன்

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock — நீங்கள் இன்னும் docker குழுவில் இல்லை, அல்லது இருந்தாலும் அந்த அமர்வு அதற்கு முந்தையது. 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-ல் பொதுவான காரணம் வட்டு நிரம்பியிருப்பது — df -h /var/lib/docker-ஐ முதலில் சரிபார்க்கவும்.

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

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

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

இங்கிருந்து, Traefik வழிகாட்டி இந்த ஒற்றை stack-ஐ ஒரே HTTPS நுழைவுப் புள்ளிக்குப் பின்னால் பல செயலிகளாக மாற்றுகிறது, மேலும் 2026-ல் சுய-ஹோஸ்ட் செய்வதற்குரியவை எவை அதன் வழியே இயக்கப்பட வேண்டியவற்றின் பட்டியலாகும்.

VPS-ல் ஒரு Minecraft சேவையகம் போன்ற ஒரு விளையாட்டு சேவையகம் பயிற்சி செய்வதற்கு நட்பான முதல் Compose திட்டமாகும்.

FAQ

"Docker daemon socket உடன் இணைக்க முயற்சிக்கும்போது permission denied ஏன் கிடைக்கிறது?"

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

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

வழக்கமான docker compose down நீக்காது. இது கொள்கலன்கள் மற்றும் திட்ட நெட்வொர்க்கை நீக்குகிறது. பெயரிடப்பட்ட தொகுதிகள் தப்பிக்கின்றன. அடுத்த up -d அவற்றை மீண்டும் இணைக்கிறது. docker compose down -v அழிவுறும் வடிவம். இது பெயரிடப்பட்ட தொகுதிகளை நீக்குகிறது. அதாவது உங்கள் தரவுத்தளம் எந்த உறுதிப்படுத்தலும் இல்லாமல், மீளமைக்க முடியாமல் நீக்கப்படுகிறது. உறுதிப்படுத்தப்பட்ட காப்பு இருக்கும் வரை உண்மையான தரவு கொண்ட ஸ்டாக்கில் -v ஐ இயக்க வேண்டாம்.

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

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

ufw போர்ட்டைத் தடுத்தாலும் எனது Docker கொள்கலனை இணையத்திலிருந்து அணுக முடிவது ஏன்?

Docker போர்ட்டுகளை iptables இன் PREROUTING சங்கிலியில் DNAT விதிகளுடன் வெளியிடுகிறது. மறுஎழுதப்பட்ட பாக்கெட்டுகள் Docker இன் சொந்த சங்கிலிகள் வழியாக FORWARD பாதையில் செல்கின்றன. அவை ufw விதிகள் பொருந்தும் INPUT சங்கிலியை ஒருபோதும் அடைவதில்லை. எனவே ufw deny 8080 வெளியிடப்பட்ட கொள்கலன் போர்ட்டிற்கு எதையும் செய்யாது. இதை மூலத்திலேயே சரிசெய்யவும். 127.0.0.1: க்கு வெளியிடவும். மறுதலை ப்ராக்ஸி வழியாக சேவைகளை வெளிப்படுத்தவும்.

பெயரிடப்பட்ட தொகுதியையா அல்லது bind mount ஐயா பயன்படுத்த வேண்டும்?

கொள்கலன் மட்டுமே அணுகும் தரவுக்கு பெயரிடப்பட்ட தொகுதிகள் சிறந்தவை. குறிப்பாக தரவுத்தளங்களுக்கு. ஏனெனில் Docker படிமம் எதிர்பார்க்கும் உரிமையாளரை அமைக்கிறது. அனுமதிகள் சரியாக வேலை செய்கின்றன. புரவலனிலிருந்தும் நீங்கள் கையாளும் கோப்புகளுக்கு bind mount பயன்படுத்தவும். நீங்கள் திருத்தும் கட்டமைப்புகள், பதிவேற்றும் ஊடகங்கள், பாதை வெளிப்படையாக தெரிய வேண்டிய எதற்கும் இது பயன்படுகிறது. ஒரு கொள்கலன் தொடக்கத்தில் bind mount இல் permission denied உடன் தோல்வியடைந்தால், புரவலன்-கொள்கலன் UID பொருத்தமின்மைதான் முதலில் சரிபார்க்க வேண்டியது.