Ano ang nagbabago sa Docker sa isang VPS?

Ano ang nagbabago kapag nagpapatakbo ka ng Docker sa isang VPS

Ginagamit ng Docker sa isang VPS ang parehong engine at parehong images tulad ng Docker sa laptop mo, kaya gumagana pa rin ang lahat ng command na alam mo na. Ang nagbabago ay ang espasyong nakapaligid dito. May ekstrang memory ang laptop, firewall na walang nag-i-scan, at disk na sapat ang laki kaya hindi mo na ito sinusuri. Ang rented server ay may nakapirming memory ceiling, public IP address na ini-scan ilang minuto pa lamang matapos mag-boot, at root filesystem na pupunuin ng Docker nang hindi nagtatanong.

Apat na pagkakaiba ang sanhi ng karamihan ng problema sa maliit na server:

• Limitado ang memory, at tinatapos ng kernel ang isang process kapag kapos ang memory.
• Direktang dumadaan sa UFW (uncomplicated firewall) ang published port dahil ang Docker ang nagsusulat ng sarili nitong firewall rules.
• Hindi awtomatikong bumabalik ang mga container pagkatapos ng reboot maliban kung itinakda mo ito nang maaga.
• Patuloy na lumalaki ang images, containers, volumes, at build cache hanggang mapuno ang disk.

Tinutukoy sa bawat seksyon sa ibaba ang failure, ang string na aktuwal mong makikita, at ang gabay na nag-aayos nito nang detalyado. Kung hindi ka pa nakasusulat ng compose file, basahin muna ang Mga pangunahing kaalaman sa Docker Compose sa isang VPS at bumalik dito. Ipinapalagay ng page na ito na kaya mo nang magpatakbo ng isang stack.

Gaano karaming RAM ang ginagamit ng Docker container?

Mas kaunti kaysa sa inaakala ng karamihan. Ang container ay isang process sa loob ng cgroup (control group), hindi virtual machine. Kaya walang guest kernel at walang fixed allocation. Ang konsumo nito ay nakadepende sa memory na ginagamit ng process sa loob. Dahil dito, kasya sa 2 GB ang isang buong stack kahit hindi kasya ang parehong stack kung virtual machines ang gagamitin.

Ang mga figure sa ibaba ay karaniwang idle value para sa stock images sa Ubuntu 24.04 na may default configuration. Kinuha ang mga ito mula sa docker stats ilang minuto matapos magsimula. Panimulang batayan lamang ang mga ito para sa pagpaplano, hindi benchmark ng workload mo. Patakbuhin ang docker stats --no-stream sa sarili mong server bago ka umasa sa anumang figure, kabilang ang mga ito.

[
  {
    "label": "nginx",
    "idle_mb": 8,
    "budget_mb": 64
  },
  {
    "label": "Redis 7",
    "idle_mb": 12,
    "budget_mb": 128
  },
  {
    "label": "Traefik v3",
    "idle_mb": 40,
    "budget_mb": 128
  },
  {
    "label": "PostgreSQL 16",
    "idle_mb": 45,
    "budget_mb": 512
  },
  {
    "label": "Uptime Kuma",
    "idle_mb": 95,
    "budget_mb": 256
  },
  {
    "label": "MariaDB 11",
    "idle_mb": 190,
    "budget_mb": 512
  },
  {
    "label": "Nextcloud (Apache)",
    "idle_mb": 210,
    "budget_mb": 768
  }
]

Magkaiba ang gamit ng dalawang column. Ipinapakita ng idle_mb kung gaano karaming memory ang ginagamit ng container habang walang ginagawa. Ipinapakita naman ng budget_mb kung gaano karaming memory ang dapat i-reserve kapag nagpaplano, dahil hindi idle ang aktuwal na paggamit. Karaniwang nasa 45 MB ang idle memory ng PostgreSQL at nangangailangan ito ng 512 MB kapag aktibo na ang mga connection, sort, at cache. Gamitin ang budget column sa pagpaplano. Gamitin ang idle column sa pag-debug.

Pansinin ang pattern ng 7 row na iyon. Nasa 8 MB ang idle memory ng nginx, at nasa 210 MB naman ang Nextcloud. Halos walang dagdag na memory ang proxy sa harap ng mga application mo. Ang database at PHP application ang dapat pagbatayan sa pag-size ng server.

May isang paalala tungkol sa docker stats: kasama sa memory figure ang page cache na na-load dahil sa sariling file reads ng container. Dahil dito, tumataas muna ito ilang sandali matapos magsimula at saka nagse-settle. I-monitor ito nang isang oras bago magpasya kung may memory leak.

Pag-size ng VPS: ano ang kasya sa 2 GB, 4 GB, at 8 GB

Unahin mong ibawas ang bahagi ng host. Ang kernel, systemd, journald, sshd, at Docker daemon ay gumagamit ng parehong RAM na ginagamit ng iyong mga container, at ang dockerd kasama ang containerd ay kumokonsumo ng humigit-kumulang 100 MB nito. Kailangan mo rin ng libreng memory para sa page cache at para sa biglaang pagtaas ng gamit kapag tumatakbo ang image build o database dump.

[
  {
    "plan": "2 GB VPS",
    "total_mb": 2048,
    "host_reserve_mb": 768,
    "container_mb": 1280
  },
  {
    "plan": "4 GB VPS",
    "total_mb": 4096,
    "host_reserve_mb": 1024,
    "container_mb": 3072
  },
  {
    "plan": "8 GB VPS",
    "total_mb": 8192,
    "host_reserve_mb": 1536,
    "container_mb": 6656
  }
]

Saklaw ng host_reserve_mb ang operating system, Docker daemon, at headroom na nagpapanatiling responsive ng server kapag may load. Ang natitira ay container_mb, at iyon lamang ang memory na maaari mong ilaan. Lumalaki ang reserve ayon sa plan, mula 768 MB sa pinakamaliit na server hanggang 1536 MB sa pinakamalaki, dahil mas maraming container ang pinapatakbo ng mas malaking server, mas maraming log ang sinusulat, at mas malaking page cache ang kailangan.

Ang 2 GB plan ay nag-iiwan ng 1280 MB para sa mga container. Gamitin ang 512 MB para sa PostgreSQL at 128 MB para sa Traefik, at kalahati nito ay nagamit na agad. Ang natitira ay sapat para sa dalawang maliit na application na humigit-kumulang 256 MB bawat isa. Totoo at kapaki-pakinabang na server na iyon. Hindi ito sapat para sa Nextcloud at search cluster nang sabay.

Ang 4 GB plan ay nag-iiwan ng 3072 MB, kung saan kasya nang sabay ang database, reverse proxy, tatlong application, at monitoring container. Ito ang pinakamaliit na sukat na sulit gamitin para sa anumang mahalagang workload, dahil ang ekstrang memory ang sumasalo sa epekto ng isang maling deployment.

Ang 8 GB plan ay nag-iiwan ng 6656 MB mula sa 8192 MB nito, at karaniwang lumilipat ang limitasyon mula memory papunta sa CPU o disk throughput. Kung ipinapakita ng kalkulasyon na hindi kasya ang iyong stack, bumili ng mas malaking plan sa halip na piliting i-tune ito: ipinapaliwanag ng tunay na gastos ng VPS kung magkano ang halaga ng dagdag na gigabytes bawat buwan.

May dalawang panuntunan para manatiling tama ang kalkulasyon. Magtakda ng memory limit sa bawat service upang hindi mapasama ang buong server kapag nag-runaway ang isang process. Mag-iwan din ng hindi nagagamit na bahagi sa itaas ng budget, dahil parehong nangangailangan ng memory ang docker compose build at pg_dump sa pinakamasamang oras. Nasa Memory limits sa Docker Compose ang syntax at mga karaniwang problema.

Bakit nag-e-exit ang container ko na may code 137?

Dahil pinatay ito ng kernel. Ang 137 ay 128 plus 9, at ang signal 9 ay SIGKILL. Humingi ang container ng mas maraming memory kaysa sa pinapayagan dito, kaya tinapos ito ng out of memory (OOM) killer.

CONTAINER ID   IMAGE         STATUS
9f2c1a4d7b3e   postgres:16   Exited (137) 4 minutes ago

Kumpirmahin ang sanhi sa halip na manghula:

docker inspect my-db | grep -i oomkilled
sudo journalctl -k | grep -i "out of memory"

Ibig sabihin ng "OOMKilled": true, naabot ng container ang sarili nitong cgroup limit, at tinutukoy sa kernel log ang process na pinili nito:

Memory cgroup out of memory: Killed process 2417 (postgres) total-vm:1284416kB

Ito ang mabuting sitwasyon dahil natigil ang pinsala sa isang container. Masama ang sitwasyon kapag walang limit ang isang container. Kung walang limit, ang buong machine ang nagiging ceiling nito. Dahil dito, maaaring maubusan ng resources ang host dahil sa memory leak sa isang service, at pipili ang kernel ng process na tatapusin batay sa laki nito sa buong system. Nawawala sa log line ang prefix na Memory cgroup at nagiging Out of memory: Killed process 2417 (postgres) ito. Kadalasan, database mo ang napipili nitong process, habang patuloy na tumatakbo ang container na nag-leak. Kaya mas mahalagang may limit ang bawat service kaysa maging eksakto ang value ng alinmang indibidwal na limit.

Binabago ng swap ang timing, hindi ang arithmetic. Karamihan sa VPS image ay walang swap. Suriin ito gamit ang swapon --show, na walang ilalabas kapag walang swap. Nagbibigay ang swap file ng lugar kung saan maaaring ilagay ng kernel ang cold pages, kaya may ilang minuto kang para mapansin ang problema.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

Dapat magpakita na ngayon ang free -h ng non-zero na total sa Swap row. Hindi nagdaragdag ng RAM ang swap. Kapag palaging nasa ilalim ng memory pressure ang isang box, bumabagal ito nang sapat para hindi ka makapag-SSH at makaayos nito. Kaya ituring ang swap bilang alarm buffer at ayusin ang sizing.

Bakit hindi bina-block ng UFW ang published Docker port?

Dahil hindi dumadaan ang traffic sa chain na binabantayan ng UFW. Kapag nag-publish ka ng port gamit ang -p 5432:5432 o isang compose ports: entry, nagsusulat ang daemon ng DNAT (destination network address translation) rule sa nat table at accept rule sa sarili nitong DOCKER chain. Ipinapasa ang packet na nakalaan sa container sa container sa halip na ihatid sa host, kaya dumadaan ito sa FORWARD path at hindi sa INPUT rules na isinusulat ng UFW.

Makikita mo ito sa server:

sudo ufw status | grep 5432
sudo iptables -t nat -L DOCKER -n | grep 5432

Maaaring i-print ng UFW ang 5432 DENY IN Anywhere habang may DNAT tcp ... to:172.18.0.2:5432 rule para sa parehong port sa nat table. Mula sa ibang machine, nakakakonekta pa rin ang nc -vz your.server.ip 5432. Nasa public internet ang database kahit sinasabi ng firewall na hindi ito nakalantad.

Ang solusyon ay bawasan ang mga port na pine-publish. Ang mga container sa iisang compose project ay nagbabahagi ng network at naaabot ang isa’t isa gamit ang service name, kaya hindi kailangan ng ports: entry ang database na application lang sa tabi nito ang gumagamit. Kung kailangan mo ng local access, i-bind ang publish sa loopback:

services:
  db:
    image: postgres:16
    ports:
      - "127.0.0.1:5432:5432"

Pagkatapos ng docker compose up -d, mabibigo ang nc -vz your.server.ip 5432 mula sa labas, habang gagana pa rin ang psql -h 127.0.0.1 -p 5432 sa mismong box. Sa maayos na maliit na stack, reverse proxy lamang ang nagpa-publish ng kahit ano, sa ports 80 at 443. Sinasaklaw ng Bakit nilalampasan ng Docker published ports ang UFW ang DOCKER-USER chain para sa mga sitwasyong kailangan mong mag-publish ng port at mag-filter pa rin nito, habang tinatalakay sa Mga pangunahing kaalaman sa UFW firewall ang mga host rule sa ilalim nito.

Bakit nawawala ang mga container ko pagkatapos ng reboot?

Dahil walang nagsabi sa kanila na bumalik. Ginagawa ang isang container gamit ang restart policy na no maliban kung magtakda ka ng iba. Kaya pagkatapos ng reboot, nananatili itong stopped at hindi ito awtomatikong ibinabalik ng daemon. Hindi bihira ang reboot sa isang VPS: maaaring magmula ito sa kernel updates ng unattended upgrades, maintenance ng provider, o sa OOM sequence sa itaas.

Dalawang kondisyon ang dapat matupad. Dapat magsimula ang daemon sa boot:

systemctl is-enabled docker

Ipinapakita nito ang enabled sa isang stock Ubuntu install. Pagkatapos, kailangang may policy ang bawat service:

services:
  app:
    image: ghcr.io/example/app:1.4
    restart: unless-stopped

Ibinabalik ng unless-stopped ang container pagkatapos ng reboot at iginagalang nito ang container na sinadya mong ihinto. Nire-restart din ng always ang mga container na sinadya mong ihinto sa tuwing magre-restart ang daemon. Maaari itong maging hindi inaasahan habang nagde-debug. Hindi sapat na i-edit lamang ang file, dahil itinatakda ang restart policy kapag ginagawa ang container. Patakbuhin ang docker compose up -d upang muli itong malikha, pagkatapos ay tingnan ang aktuwal na value:

docker inspect my-app | grep -A3 RestartPolicy

Pagkatapos, sinadyang i-reboot ang server at patakbuhin ang docker compose ps sa project directory. Kung nakaligtas ang stack sa planadong reboot, makaliligtas din ito sa hindi planadong reboot. Kung kailangan ng stack mo ng garantisadong pagkakasunod-sunod o one-shot job sa boot, mas angkop ang systemd unit: nasa pagsisimula ng Docker Compose sa boot ang unit file. Para malaman kung talagang nagsisilbi na ang container na bumalik, idagdag ang Compose healthchecks.

Bakit puno ang disk ng aking VPS?

Dahil pinapanatili ng Docker ang lahat hanggang sa sabihan mo itong maglinis. Nananatili sa disk ang bawat image tag na na-pull mo, bawat stopped container, bawat anonymous volume na naiwan matapos ang recreate, at bawat layer ng build cache. Sa root filesystem na 40 GB o 80 GB, na karaniwan sa ganitong plan size, nauuwi ito sa outage pagkalipas ng ilang buwan sa halip na ilang taon.

Hindi parang crash ang full disk. Makakakuha ka ng no space left on device mula sa isang container, mula sa apt, mula sa journald, at mula sa docker pull sa loob ng parehong oras. Hihinto ang PostgreSQL sa pagtanggap ng writes. Naka-up pa rin ang server, kaya mas mahirap itong mapansin kaysa sa reboot loop.

Suriin muna bago mag-delete:

docker system df
df -h /

Hinahati ng docker system df ang kabuuang paggamit sa images, containers, local volumes, at build cache, at may katabing RECLAIMABLE column para sa bawat isa. Sa server na gumagawa ng sarili nitong images, karaniwang pinakamalaki ang build cache.

docker image prune -a
docker builder prune
docker system df

Tinatanggal ng docker image prune -a ang bawat image na hindi ginagamit ng anumang container. Nililinis ng docker builder prune ang build cache. Ligtas ang dalawang ito habang tumatakbo ang mga service, dahil nilalaktawan ang anumang ginagamit. Hindi ligtas ang docker system prune --volumes, na nagde-delete ng bawat volume na walang tinutukoy na container sa kasalukuyan. Ganito mismo ang isang stack na itinigil mo para sa weekend, at kasama nitong made-delete ang database volume nito. Basahin ang bind mounts kumpara sa named volumes bago mong gamitin ang flag na iyon, at mag-backup muna.

Mas tahimik ang paglaki ng container logs. Walang size limit ang default na json-file driver, kaya maaaring magsulat ang isang maingay na container ng gigabytes sa /var/lib/docker/containers. Magtakda ng limit para sa bawat container sa /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Ilapat ito gamit ang sudo systemctl restart docker, na magre-restart sa iyong mga container, kaya piliin ang tamang oras. Nalalapat ang limit sa mga container na gagawin pagkatapos ng pagbabago, kaya i-recreate ang mga tumatakbo gamit ang docker compose up -d --force-recreate at kumpirmahin:

docker inspect my-app | grep -A5 LogConfig
sudo du -sh /var/lib/docker/containers

Dapat ipakita ng inspect output na naka-set ang max-size. Kung walang laman ito, nauna ang container na iyon sa pagbabago at patuloy pa rin itong nagsusulat nang walang limit.

Mga nakagawiang paraan para manatiling maayos ang isang maliit na Docker box

Hindi kailangan dito ang dashboard o tool na kailangan mo pang pag-aralan.

• Patakbuhin ang docker system df at df -h / sa unang araw ng buwan. Dalawang command at 30 segundo lang ito, at makikita mo ang trend bago pa ito maging outage.
• Magtakda ng memory limit para sa bawat service, kabilang ang mga service na sigurado kang maliit ang paggamit. Ginagawang isang container na kailangang i-restart ng limit ang outage na maaaring makaapekto sa buong host.
• I-monitor ang box mula sa ibang lugar para malaman mo ang memory o disk pressure bago pa kumilos ang kernel. Tumatakbo ang Uptime Kuma sa isang container at gumagamit ng humigit-kumulang 95 MB kapag idle.
• I-back up ang volumes, hindi ang containers. Disposable ang container, pero hindi ang volume. Saklaw ng restic backups sa isang VPS ang schedule at restore test.
• I-pin ang image tags sa compose file at mag-update sa araw na pinili mo. Sa latest, ang version na makukuha mo mula sa susunod na docker compose pull ay ang version na ni-release noong umagang iyon.

Mananatiling maayos sa loob ng maraming taon ang isang maliit na VPS na nagpapatakbo ng Docker kapag nasa tamang range ang apat na value: memory budget, listahan ng published ports, restart policy ng bawat service, at libreng disk space. Ang lahat ng iba pa ay kapareho ng Docker na ginagamit mo na sa bahay.

FAQ

Gaano karaming RAM ang kailangan ko para patakbuhin ang Docker sa isang VPS?

Mababa ang resource requirement ng Docker mismo. Karaniwang nasa 100 MB ang pinagsamang gamit ng daemon at containerd, at ang natitirang requirement ay nakadepende sa mga container mo. Ilaan muna ang bahagi para sa host: 768 MB sa 2048 MB na machine para sa operating system, daemon, at headroom. Dahil dito, 1280 MB ang matitira para sa mga container. Kasya rito ang database na gumagamit ng 512 MB, reverse proxy na gumagamit ng 128 MB, at dalawang maliit na application. Sukatin ang sarili mong stack gamit ang docker stats --no-stream sa halip na umasa sa anumang inilabas na figure.

Maaari ko bang patakbuhin ang Docker sa isang 1 GB VPS?

Oo, para sa isa o dalawang magagaan na container. Magdagdag muna ng swap file bago magsimula. Humigit-kumulang kalahati ng 1 GB na machine ang nagagamit kapag tumatakbo na ang operating system at Docker daemon. Dahil dito, may sapat na espasyo para sa isang maliit na application at reverse proxy, ngunit hindi para sa database na may aktuwal na load. Mabibigo o makakaapekto sa ibang proseso ang pagbuo ng images sa ganitong kaliit na machine. Bumuo ng images sa ibang machine at i-pull ang natapos na image.

Pinoprotektahan ba ng UFW ang isang Docker container?

Hindi para sa mga port na ipinublish mo. Gumagawa ang Docker ng sarili nitong DNAT at forward rules. Kaya ang packet na nakalaan para sa published container port ay ipinapasa sa container sa halip na ihatid sa host. Hindi ito nakikita ng INPUT rules na pinamamahalaan ng UFW. Maaaring aktibo ang ufw deny 5432 habang sumasagot ang port na iyon mula sa internet. I-publish ito sa loopback gamit ang 127.0.0.1:5432:5432, huwag i-publish ang mga internal service, o mag-filter sa DOCKER-USER chain.

Magre-restart ba ang mga container ko pagkatapos mag-reboot ang VPS?

Mangyayari lamang ito kung ginawa ang mga ito na may restart policy. Itakda ang restart: unless-stopped sa bawat service, patakbuhin ang docker compose up -d upang muling malikha ang mga container na may policy na iyon, at tiyaking ipinapakita ng systemctl is-enabled docker ang enabled. Pagkatapos, magsagawa ng reboot at suriin ang docker compose ps. Ang restart policy na hindi mo pa nasusubukan ay hindi pa mapagkakatiwalaang restart policy.

Gaano kadalas dapat mag-prune ng Docker images?

Sapat na ang buwanang pag-prune para sa karamihan ng maliliit na server. Maaari mo rin itong gawin kapag nag-ulat ang docker system df ng reclaimable space na kakailanganin mo. Ligtas gamitin ang docker image prune -a at docker builder prune habang tumatakbo ang mga service, dahil nilalaktawan nito ang mga image at cache na ginagamit. Iwasan ang docker system prune --volumes maliban kung alam mo nang eksakto kung aling mga volume ang walang reference. Buburahin nito ang data ng anumang stack na nagkataong nakahinto.