Docker Compose சேவைகளை தானாக தொடங்குவது எப்படி?

சுருக்கமான பதில்

இரண்டு நிபந்தனைகள் ஒரே நேரத்தில் பூர்த்தியாகும்போது, Docker Compose சேவைகள் boot-ன் போது தொடங்கும். Docker daemon ஒரு system service-ஆக enabled நிலையில் இருக்க வேண்டும், மேலும் கோப்பில் உள்ள ஒவ்வொரு சேவைக்கும் unless-stopped அல்லது always என்ற restart policy இருக்க வேண்டும். ஒவ்வொரு சேவைக்கும் restart: unless-stopped-ஐச் சேர்த்து, docker compose up -d-ஐ ஒருமுறை இயக்கினால், reboot-க்கு பிறகு containers தானாகவே மீண்டும் இயங்கும். பொதுவான சூழல்களில் இதற்கு மேல் எதுவும் தேவையில்லை.

சேவைகள் தொடங்கும் வரிசை முக்கியமாக இருக்கும்போது மட்டுமே உங்களுக்கு systemd unit தேவைப்படும்: Docker daemon தொடங்கும் நேரத்தில் தயாராக இல்லாத ஒரு mounted disk, VPN interface அல்லது network share-ஐச் சார்ந்திருக்கும் stack-களுக்கு இது பொருந்தும். அத்தகைய சூழல் உண்மையானது, இந்த வழிகாட்டியின் இரண்டாம் பகுதி அதை விளக்குகிறது. நீங்கள் இன்னும் service definitions மற்றும் volumes பற்றிப் பழகி வருகிறீர்கள் என்றால், VPS-ல் Docker Compose-ன் அடிப்படைகள் என்பதிலிருந்து தொடங்கிவிட்டு மீண்டும் இங்கே வரவும்.

compose.yaml-ல் restart policy-ஐ அமைத்தல்

ஒவ்வொரு service-க்கும் ஒரு வரியில் இந்த policy-ஐ குறிப்பிட வேண்டும். இதற்கு global switch கிடையாது, எனவே நீங்கள் மறக்கும் ஒரு service reboot-க்கு பிறகு இயங்காது, அதேசமயம் stack-ல் உள்ள மற்றவை இயங்கும்.

services:
  app:
    image: nginx:1.27
    restart: unless-stopped
    ports:
      - "8080:80"
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: change-me
    volumes:
      - dbdata:/var/lib/postgresql/data

volumes:
  dbdata:

இதை அமல்படுத்தி, இயங்கும் container-லிருந்து policy-ஐ சரிபார்க்கவும்:

docker compose up -d
docker inspect -f '{{.HostConfig.RestartPolicy.Name}}' $(docker compose ps -q app)

இது unless-stopped என்பதை அச்சிடும். இது no என்று காட்டினால், கோப்பு திருத்தப்பட்டுள்ளது ஆனால் container மீண்டும் உருவாக்கப்படவில்லை என்று அர்த்தம்.

இதுவே மிகவும் பொதுவான தோல்விக்கு காரணமாகும். Restart policy என்பது YAML கோப்பில் அல்ல, container-ல் சேமிக்கப்படுகிறது. ஏற்கனவே உள்ள container-ல் compose.yaml-ஐ திருத்துவதால் எந்த மாற்றமும் ஏற்படாது. docker compose restart-ம் உதவாது, ஏனெனில் அது configuration-ஐ மாற்றாமல் அதே container object-ஐ நிறுத்தி மீண்டும் தொடங்கும். docker compose up -d மட்டுமே கோப்பையும் இயங்கும் container-களையும் ஒப்பிட்டு, policy மாறியிருப்பதை உணர்ந்து அவற்றை மீண்டும் உருவாக்கும்.

தற்போது மீண்டும் உருவாக்க விரும்பாத ஒரு container-க்கு, நேரடியாக policy-ஐ மாற்றவும்:

docker update --restart unless-stopped my-container

அதே சமயம் YAML கோப்பையும் திருத்தவும். docker update நேரடி container-ஐ மாற்றும், ஆனால் அடுத்தமுறை docker compose up -d இயங்கும்போது, அது கோப்பைப் படித்து பழைய மதிப்பையே மீண்டும் அமைத்துவிடும்.

ஒவ்வொரு restart மதிப்பும் என்ன செய்கிறது

Docker நான்கு மதிப்புகளை வரையறுக்கிறது. இயந்திரம் reboot செய்யப்படும்போதோ அல்லது daemon restart செய்யப்படும்போதோ மட்டுமே அவற்றுக்கிடையேயான வேறுபாடு வெளிப்படும்.

• no என்பது default ஆகும். எந்தச் சூழலிலும் container தானாகவே restart செய்யப்படாது.
• always என்பது container நிற்கும் போதெல்லாம் அதை restart செய்யும். நீங்கள் அதை நீங்களாகவே நிறுத்தியிருந்தாலும், அடுத்த முறை Docker daemon தொடங்கும் போது அது மீண்டும் இயங்கத் தொடங்கும். இது பெரும்பாலும் ஆச்சரியத்தை அளிக்கும்: கடந்த வாரம் நீங்கள் வேண்டுமென்றே நிறுத்திய ஒரு container, reboot-க்கு பிறகு மீண்டும் இயங்கிக் கொண்டிருக்கும்.
• unless-stopped என்பது always போலவே செயல்படும். ஆனால், நீங்களாகவே நிறுத்திய ஒரு container, daemon restart செய்யப்பட்டாலும் தொடர்ந்து நின்ற நிலையிலேயே இருக்கும். பராமரிப்புப் பணிக்காக எப்போதாவது நிறுத்தி வைக்கும் service-களுக்கு இந்த மதிப்பைத்தான் நீங்கள் பயன்படுத்த வேண்டும்.
• on-failure என்பது non-zero exit code-உடன் ஒரு container வெளியேறினால் மட்டுமே அதை restart செய்யும். restart: on-failure:3-ல் உள்ளது போல, முயற்சிகளின் எண்ணிக்கையை நீங்கள் கட்டுப்படுத்தலாம்.

server இயங்கும் போதெல்லாம் ஒரு stack இயங்க வேண்டும் என்றால், unless-stopped என்பதே சரியான default ஆகும். ஒரு container நிறுத்தப்படுவதைத் தவிர்க்க விரும்பினால் மட்டுமே always-ஐத் தேர்ந்தெடுக்கவும்.

ஏன் restart: on-failure என்பது reboot-க்குப் பிறகு இயங்குவதில்லை

பலர் on-failure-ஐத் தேர்ந்தெடுக்கிறார்கள், ஏனெனில் இது பாதுகாப்பானது என்று தோன்றுகிறது, ஆனால் முதல் reboot-க்குப் பிறகு ஒவ்வொரு container-ம் நின்றுவிடுவதைக் காண்கிறார்கள். இதற்கான காரணம் அதன் வரையறையிலேயே உள்ளது. on-failure ஒரு விஷயத்திற்கு மட்டுமே எதிர்வினையாற்றும்: container process ஒரு error code-உடன் முடிவடைவது.

Reboot என்பது ஒரு பிழை அல்ல. Host shutdown ஆகும்போது, systemd docker.service-ஐ நிறுத்துகிறது, மேலும் daemon ஒவ்வொரு container-ஐயும் திட்டமிட்டு நிறுத்துகிறது. Container தோல்வியடையவில்லை, எனவே இந்த policy எதிர்வினையாற்ற எதுவும் இல்லை. மீண்டும் system தொடங்கும் போது, daemon தான் மீண்டும் தொடங்க வேண்டிய container-களைப் பார்க்கிறது, மேலும் சுத்தமாக நிறுத்தப்பட்ட ஒரு on-failure container அதில் அடங்காது. அது exited நிலையிலேயே இருக்கும்.

இதை நீங்கள் நேரடியாகப் பார்க்கலாம். ஒரு service-ல் restart: on-failure-ஐ அமைத்து, docker compose up -d-ஐ இயக்கி, reboot செய்து, பின்வருவனவற்றை இயக்கவும்:

docker compose ps -a

அந்த service Exited நிலையிலும், Exited (0) 2 minutes ago போன்ற status-உடனும் பட்டியலிடப்படும். எதுவும் பழுதடையவில்லை மற்றும் பிழையாக எதுவும் பதிவு செய்யப்படவில்லை, இதுவே இதைக் கண்டறிவதை கடினமாக்குகிறது. அந்த policy அது என்ன சொல்கிறதோ அதைச் சரியாகச் செய்தது.

on-failure இன்னும் பயனுள்ளது. இது ஒரு பணியைச் செய்து crash ஆகக்கூடிய container-க்கு ஏற்றது, அங்கு உங்களுக்கு வரையறுக்கப்பட்ட எண்ணிக்கையிலான முயற்சிகள் தேவை மற்றும் restart loop இருக்கக்கூடாது. நீண்ட காலம் இயங்கும் ஒரு service-ஐ reboot-க்குப் பிறகும் உயிர்ப்புடன் வைத்திருக்க இது தவறான கருவியாகும்.

Docker service boot-ல் தொடங்கினால் மட்டுமே restart policies செயல்படும்

Restart policies-ஐ Docker daemon நிர்வகிக்கிறது. Daemon தொடங்கவில்லை என்றால், எதையும் அமல்படுத்த முடியாது. இதைச் சரிபார்க்கவும்:

systemctl is-enabled docker
systemctl is-enabled containerd

இரண்டுமே enabled என்று காட்ட வேண்டும். Docker-ன் அதிகாரப்பூர்வ repository-லிருந்து நிறுவப்படும் packages, நிறுவலின்போதே இவற்றை enable செய்துவிடும், எனவே புதிய server-களில் இது பொதுவாகச் சரியாக இருக்கும். ஏதேனும் ஒன்று disabled என்று காட்டினால், அதைச் சரிசெய்யவும்:

sudo systemctl enable --now docker containerd

இதில் கவனிக்க வேண்டிய ஒரு முக்கியமான விஷயம் உள்ளது. Ubuntu-வில் docker.socket உள்ளது, இது Docker API-ஐ ஏதேனும் ஒரு service அழைக்கும்போது மட்டுமே daemon-ஐத் தொடங்கும். பலர் docker.socket enabled நிலையில் இருப்பதைக் கண்டு, daemon சரியாக இயங்குகிறது என்று நினைத்துக்கொண்டு, memory-ஐச் சேமிக்க docker.service-ஐ disable செய்துவிடுவார்கள். Boot-ன் போது API-ஐ யாரும் அழைப்பதில்லை என்பதால், socket-ஐ யாரும் தொடுவதில்லை, daemon தொடங்குவதில்லை, நீங்கள் முதல் docker கட்டளையைத் தட்டச்சு செய்யும் வரை எந்த container-ம் இயங்காது. Socket activation என்பது docker.service enabled நிலையில் இருப்பதற்கு மாற்றாகாது.

systemd unit எப்போது சிறந்த தீர்வாகிறது

Restart policies-க்கு கணினியின் பிற பகுதிகளுடன் ஒப்பிடும்போது வரிசைமுறை (ordering) குறித்த புரிதல் இல்லை. Daemon தொடங்கும்போது, அது உங்களது containers-ஐ எவ்வளவு விரைவாக முடியுமோ அவ்வளவு விரைவாகத் தொடங்கும். உங்கள் stack ஒரு தனி volume, NFS (network file system) share, அல்லது encrypted disk-லிருந்து ஒரு directory-ஐ bind-mount செய்தால், அந்தப் பாதை (path) உருவாவதற்கு முன்பே containers தொடங்கக்கூடும். Docker அந்த mount point-ல் ஒரு காலி directory-ஐ உருவாக்கி, container-ஐ அதனுடன் தொடங்கும்; இதனால் உங்கள் database தரவுகள் ஏதுமின்றி இயங்கும்.

இவற்றில் ஏதேனும் ஒன்று பொருந்தும்போது systemd unit-ஐ எழுதவும். உங்கள் stack-க்கு ஒரு mount, VPN interface, அல்லது மற்றொரு unit முதலில் தயாராக இருக்க வேண்டும். மற்ற அனைத்து services-க்கும் கிடைப்பது போல systemctl stop myapp மற்றும் systemctl start myapp வேலை செய்ய வேண்டும் என்று நீங்கள் விரும்பினால், அல்லது daemon-உடன் சேர்த்து நிறுத்தப்படாமல், shutdown-ன் போது stack முறையாக நிறுத்தப்பட வேண்டும் என்று விரும்பினால், systemd unit-ஐப் பயன்படுத்தவும். systemd units உங்களுக்குப் புதியது என்றால், systemd service மற்றும் timer எழுதுதல் என்ற பகுதி அதன் file format-ஐப் பற்றி விரிவாக விளக்குகிறது.

systemd unit-ஐ எழுதுதல்

Stack-ஐ home directory-க்கு வெளியே ஒரு நிலையான பாதையில் வைக்கவும். /srv/myapp ஒரு சிறந்த தேர்வாகும், ஏனெனில் எவரும் login செய்வதற்கு முன்பே இயங்கும் ஒரு unit, /home-ஐ வாசிப்பது முறையல்ல.

/etc/systemd/system/myapp.service-ஐ உருவாக்கவும்:

[Unit]
Description=myapp docker compose stack
Requires=docker.service
After=docker.service network-online.target
Wants=network-online.target
RequiresMountsFor=/srv/myapp/data

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/srv/myapp
ExecStart=/usr/bin/docker compose up -d --remove-orphans
ExecStop=/usr/bin/docker compose down
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target

அதை enable செய்து தொடங்கவும்:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service
systemctl status myapp.service

ஆரோக்கியமான ஒரு unit Active: active (exited)-ஐக் காட்டும். இதை முதல்முறை பார்க்கும்போது தவறாகத் தோன்றலாம். ஆனால் இது சரியானது: Type=oneshot உடன் RemainAfterExit=yes என்பது, அந்த unit தனது command-ஐ இயக்கி முடித்துவிட்டது என்பதையும், shutdown-ன் போது ExecStop இயங்குவதற்காக systemd அந்த unit-ஐ active நிலையில் வைத்திருக்கிறது என்பதையும் குறிக்கிறது.

ஒவ்வொரு வரியும் முக்கியமானது. Requires=docker.service என்பது, செயலிழந்த socket-க்கு எதிராக docker compose-ஐ இயக்குவதற்குப் பதிலாக, unit உடனடியாகத் தோல்வியடைவதை உறுதி செய்கிறது. After= வரிசையை அமைக்கிறது, ஏனெனில் Requires= மட்டும் அதைச் செய்யாது. RequiresMountsFor= அந்தப் பாதையிற்கான mount unit-ஐ systemd இழுத்து, அதற்காகக் காத்திருக்கச் செய்கிறது; restart policy-க்கு பதிலாக unit-ஐப் பயன்படுத்துவதற்கான முழு நோக்கமும் இதுவே. TimeoutStartSec=0, ஒரு பெரிய image pull செய்யப்படும்போது, start job-ஐ systemd நிறுத்துவதைத் தடுக்கிறது.

இந்த இரண்டு வழிமுறைகளை இணைப்பது குறித்த குறிப்பு: Docker-ன் ஆவணங்கள், restart policy-களையும் host process manager-ஐயும் கலக்க வேண்டாம் என்று அறிவுறுத்துகின்றன. அந்த எச்சரிக்கை, container process-ஐயே கண்காணித்து, daemon அதே வேலையைச் செய்ய முயலும்போது அதை restart செய்யும் ஒரு process manager-ஐப் பற்றியது. ஒரு Type=oneshot unit எதையும் கண்காணிப்பதில்லை, எனவே இந்த unit-உடன் சேர்த்து compose file-ல் restart: unless-stopped-ஐ வைத்திருப்பது சரியானது, அதுவே உங்களுக்குத் தேவையானதும் கூட. boot-ன் போது வரிசையை systemd கையாள்கிறது, அதிகாலை மூன்று மணிக்கு ஒரு container செயலிழந்தால் அதை daemon கவனித்துக்கொள்ளும்.

நீங்கள் உயிர்ப்புடன் வைத்திருக்க வேண்டியது ஒரு stack-ஆக இல்லாமல், நீண்ட நேரம் இயங்கும் ஒரு சாதாரண process-ஆக இருந்தால், அந்த unit மாறுபடும். ஏனெனில் அப்போது அதன் கீழ் daemon இருக்காது, மேலும் systemd-ன் சொந்த Restart= கண்காணிப்புப் பணியைச் செய்ய வேண்டியிருக்கும்; systemd-ன் பின்னால் dsh-ஐ headless-ஆக இயக்குதல் என்பது, அதற்கான பிரத்யேக user மற்றும் journal உள்ளிட்ட ஒரு முழுமையான உதாரணம் ஆகும்.

உண்மையான reboot மூலம் சரிபார்த்தல்

உண்மையான சோதனைக்கு மாற்றாக எதுவும் இல்லை. systemctl restart docker என்பது mount வரிசையைச் சோதிக்காது, மேலும் docker compose down மற்றும் அதைத் தொடர்ந்து வரும் docker compose up -d ஆகியவை boot செயல்முறையை எவ்விதத்திலும் சோதிக்காது.

sudo reboot

காத்திருந்து, மீண்டும் இணைத்து, இந்த வரிசையில் சரிபார்க்கவும்:

uptime
systemctl is-active docker
docker compose ps

uptime என்பது நீங்கள் உண்மையில் reboot செய்யப்பட்ட கணினியைத்தான் பார்க்கிறீர்கள் என்பதை உறுதிப்படுத்துகிறது. stack கோப்பகத்திலிருந்து (directory) இயக்கப்படும் docker compose ps, ஒவ்வொரு service-ஐயும் running நிலையில் காட்ட வேண்டும், மேலும் அதன் uptime கணினியின் uptime-க்கு நெருக்கமாக இருக்க வேண்டும். Exited என்று காட்டும் service-ஐத்தான் நீங்கள் கவனிக்க வேண்டும்.

ஏதாவது ஒரு service தொடங்கவில்லை என்றால், daemon log அந்த boot கால இடைவெளியை உள்ளடக்கும்:

journalctl -u docker.service -b --no-pager | tail -50

Unit மூலம் நிர்வகிக்கப்படும் stack-க்கு, journalctl -u myapp.service -b --no-pager என்பது boot-ன் போது கிடைத்த துல்லியமான docker compose வெளியீட்டைக் காட்டும்; இதில் தோல்வியடைந்த image pull அல்லது விடுபட்ட .env கோப்பு போன்ற தகவல்கள் அடங்கும். நீங்கள் திட்டமிடும் reboot-ஐ நீங்களே கண்காணிக்க வேண்டும், எனவே கண்காணிக்கப்படாத தோல்விகளை unit மூலம் அறியலாம்: self-hosted ntfy server-ஐக் குறிக்கும் OnFailure= வரி, மீண்டும் தொடங்கத் தவறிய stack குறித்த தகவலை push notification-ஆக உங்களுக்கு அனுப்பும்; இதன் மூலம் பல நாட்களுக்குப் பிறகு நீங்கள் அதைக் கண்டறியும் நிலை தவிர்க்கப்படும்.

தானியங்கி தொடக்கத்தை அமைதியாக முடக்கும் காரணிகள்

docker compose run மூலம் உருவாக்கப்பட்ட containers, கோப்பிலிருந்து restart policy-ஐ ஒருபோதும் பெறுவதில்லை. Compose அவற்றை ஒருமுறை மட்டும் இயங்கும் containers-ஆகவே கருதுகிறது. ஒரு service தனது policy-ஐ புறக்கணிப்பது போல் தோன்றினால், அது up-க்கு பதிலாக run மூலம் தொடங்கப்பட்டதா என்று சரிபார்க்கவும்.

ஒரு volume அல்லது env_file உள்ளீட்டில் உள்ள relative path, compose கோப்பு இருக்கும் கோப்பகத்தை (directory) அடிப்படையாகக் கொண்டு தீர்மானிக்கப்படுகிறது. இது உங்கள் shell-லிலும், WorkingDirectory-ஐ அமைக்கும் unit-லிலும் சரியாக வேலை செய்யும். WorkingDirectory இல்லாத unit-களில் இது தோல்வியடையும், ஏனெனில் அப்போது working directory என்பது / ஆக இருக்கும்.

Rootless Docker ஒரு தனிப்பட்ட சூழல். இதன் daemon ஒரு user service-ஆக இயங்குகிறது, மேலும் அந்த பயனரின் கடைசி session முடிவடையும் போது அந்த service-ம் நின்றுவிடும். பயனருக்காக இதை enable செய்து, யாரும் login செய்யாத நிலையிலும் அது தொடர்ந்து இயங்க அனுமதிக்கவும்:

systemctl --user enable docker
sudo loginctl enable-linger $USER

enable-linger இல்லையென்றால், நீங்கள் logout செய்யும்போது rootless daemon-ம் நின்றுவிடும், அதனுடன் containers-ம் நின்றுவிடும். இது பார்ப்பதற்கு restart policy வேலை செய்யாதது போலவே தோன்றும்.

இறுதியாக ஒன்று. தானியங்கி பாதுகாப்பு மேம்படுத்தல்கள் (automatic security updates) ஒரு குறிப்பிட்ட நேரத்தில் server-ஐ reboot செய்யலாம். உங்கள் stack தானாகவே மீண்டும் தொடங்கும் பட்சத்தில் மட்டுமே இது பயனுள்ளது. புதிய machine-ல் இதை அமைப்பது, புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற பகுதியில் உள்ள ஆரம்பக்கட்ட பணிகளில் ஒன்றாக இருக்க வேண்டும்.

FAQ

restart: always மற்றும் restart: unless-stopped ஆகியவற்றுக்கு இடையே உள்ள வேறுபாடு என்ன?

இரண்டுமே container தானாக நின்றுவிடும்போது அதை மீண்டும் தொடங்கும். நீங்கள் கைமுறையாக (manually) ஒரு container-ஐ நிறுத்திய பிறகுதான் இவற்றின் வேறுபாடு வெளிப்படும். always பயன்படுத்தினால், அடுத்த முறை Docker daemon தொடங்கும்போதும் container தானாகவே தொடங்கிவிடும்; எனவே, reboot செய்தாலும் உங்கள் manual stop செயல் நீக்கப்படும். unless-stopped பயன்படுத்தினால், container வேண்டுமென்றே நிறுத்தப்பட்டது என்பதை daemon நினைவில் வைத்துக்கொண்டு, அதைத் தானாகத் தொடங்காது. ஒரு container எப்போதும் இயங்கிக்கொண்டே இருக்க வேண்டும் என்று நீங்கள் விரும்பினால் ஒழிய, unless-stopped-ஐப் பயன்படுத்தவும்.

நான் restart: unless-stopped சேர்த்தும், reboot-க்குப் பிறகு container தொடங்கவில்லை. ஏன்?

இந்தக் கொள்கை (policy) YAML கோப்பில் அல்ல, container-ன் மீதுதான் அமல்படுத்தப்படுகிறது. ஏற்கனவே இருக்கும் ஒரு container-ஐ YAML-ல் மாற்றம் செய்வதன் மூலம் புதுப்பிக்க முடியாது. docker compose up -d கட்டளையை இயக்கினால் Compose அதை மீண்டும் உருவாக்கும், பிறகு docker inspect -f '{{.HostConfig.RestartPolicy.Name}}' $(docker compose ps -q app) மூலம் உறுதிப்படுத்தவும். அது no என்று காட்டினால், அந்த container உங்கள் மாற்றத்திற்கு முன்பே உருவாக்கப்பட்டது என்று அர்த்தம். மற்றொரு பொதுவான காரணம் docker.service enabled நிலையில் இல்லாதது; இதை systemctl is-enabled docker மூலம் சரிபார்க்கலாம்.

என்னிடம் ஏற்கனவே restart policies இருந்தால், systemd unit தேவையா?

பொதுவாகத் தேவையில்லை. Network மட்டும் தேவைப்படும் பெரும்பாலான stack-களுக்கு restart policy போதுமானது. Docker daemon தொடங்கும் போது தயாராக இல்லாத external disk, encrypted volume, NFS share, அல்லது VPN interface போன்றவற்றை container சார்ந்திருக்கும்போது மட்டும் unit-ஐச் சேர்க்கவும். ஒரு restart policy-ஆல் செய்ய முடியாத ordering வசதியை After= மற்றும் RequiresMountsFor= மூலம் இந்த unit உங்களுக்கு வழங்குகிறது.

அடுத்த reboot-ல் மீண்டும் வராதபடி ஒரு stack-ஐ நிரந்தரமாக நிறுத்துவது எப்படி?

unless-stopped பயன்படுத்தினால், docker compose stop போதுமானது; ஏனெனில் கைமுறையாக நிறுத்தப்பட்ட container-ஐ daemon மீண்டும் தொடங்காது. always பயன்படுத்தினால், stop செய்வது மட்டும் போதாது, reboot-க்குப் பிறகு container மீண்டும் வந்துவிடும். எனவே, docker compose down கட்டளையை இயக்கி container-களை நீக்கவும் அல்லது முதலில் docker update --restart no my-container மூலம் கொள்கையை மாற்றவும். ஒரு systemd unit அந்த stack-ஐ நிர்வகித்தால், sudo systemctl disable myapp.service கட்டளையையும் இயக்கவும், இல்லையெனில் அந்த unit அதை மீண்டும் தொடங்கிவிடும்.