Docker VDS-ზე: image-ები, volume-ები, პორტები და გადატვირთვა

Docker ერთ სერვერზე არც ორკესტრაციაა და არც ღრუბელი. ეს პროგრამის დაყენების საშუალებაა დაყენების გარეშე: ერთი ბრძანება ჩამოტვირთავს გამოცდილ image-ს, გაუშვებს მას როგორც იზოლირებულ პროცესების ხეს საკუთარი ფაილური სისტემით და შენს ოპერაციულ სისტემაზე Docker-ის გარდა არაფერს ტოვებს. შენ მაგივრად არაფერი ხდება, არაფერი მასშტაბირდება და არაფერი თვითონ არ მკურნალობს. რასაც იღებ, ეს განმეორებადობაა - ერთი და იგივე container ერთნაირად იქცევა შენს ლეპტოპზეც და გერმანიაში მდგარ მანქანაზეც - და შესაძლებლობა, ერთსა და იმავე მონაცემთა ბაზის ორი ვერსია ჩხუბის გარეშე გაუშვა.

ერთ მანქანაზე მთელი საქმე თითოეული container-ისთვის ხუთ გადაწყვეტილებამდე დადის: რომელი image და რომელი tag, რომელი პორტები ქვეყნდება და რა მისამართზე, სად ცხოვრობს მონაცემები, რა ხდება, როცა პროცესი ჩერდება, და რა უშლის მას ხელს დისკის შეჭმაში. ეს პოსტი ამ ხუთს თანმიმდევრობით გადის ბრძანებებით, შემდეგ კი იმ გზებს, რომლებითაც ხალხი მონაცემებს კარგავს.

რას ცვლის Docker ერთ სერვერზე#

რას იგებ, პირდაპირ:

• დაყენება ხდება pull. არც PPA-ები, არც კომპილაცია, არც "ამას Python 3.9 უნდა და მანქანაზე 3.11 დგას". image თავის userland-ს თვითონ ატარებს.
• ვერსიები აღარ ეჯიბრებიან ერთმანეთს. PostgreSQL 15 და 17 ერთ მანქანაზე გვერდიგვერდ შეიძლება მუშაობდეს, თითოეულს თავისი მონაცემების დირექტორიით და თავისი პორტით, და ერთმანეთის შესახებ არაფერი იციან.
• წაშლა სრულია. docker rm პროცესსაც წაიღებს და ფაილურ სისტემასაც. /usr-ში, /etc-ში ან პაკეტების ბაზაში არაფერი რჩება.
• კონფიგურაცია ბრძანებად იქცევა, რომლის ჩაწერაც შეგიძლია. docker run ხაზი დაყენების ინსტრუქციაა და შეგიძლია ფაილში შეინახო - სწორედ ეს არის Docker Compose პატარა stack-ებისთვის.

და რასაც არ იძლევა, რაც უფრო მნიშვნელოვანია, რადგან ხალხი სხვას ვარაუდობს. Container-ები ვირტუალური მანქანები არ არის: ისინი host-ის kernel-ს იზიარებენ, ამიტომ kernel panic ან out-of-memory მოვლენა host-ზე ყველაფერს თან იყოლიებს. ისინი root-ის წინააღმდეგ უსაფრთხოების საზღვარი არ არის - ვინც docker-ის გაშვება შეუძლია, container-ში host-ის ფაილური სისტემის მიმაგრება და ნებისმიერი რამის წაკითხვა შეუძლია. ისინი პროგრამას უფრო სწრაფს არ ხდიან; დანახარჯი ნულთან ახლოსაა, მაგრამ ნულთან ახლოსაა სარგებელიც. და ისინი არაფრის backup-ს არ აკეთებენ.

ერთი წინაპირობა: ამას შენი საკუთარი, ნამდვილი kernel სჭირდება. KVM-ზე, VMware-ზე, Hyper-V-სა და Xen-ზე Docker მუშაობს. OpenVZ-ისა და LXC-ის მსგავს container ვირტუალიზაციაზე ის ან უხერხულია, ან შეუძლებელი. გეგმის გაკეთებამდე გაუშვი systemd-detect-virt - VPS, VDS თუ dedicated სერვერი განმარტავს, რას გეუბნება ეს ერთი სიტყვა შენ მიერ ნაყიდ გეგმაზე.

Docker-ის დაყენება და ჯგუფი, რომელიც სინამდვილეში root-ია#

ორი მხარდაჭერილი გზა. მოხერხებულობის სკრიპტი კარგია მანქანაზე, რომელიც შენია:

$ curl -fsSL https://get.docker.com -o get-docker.sh$ sudo sh get-docker.sh$ sudo systemctl enable --now docker$ docker version

repository-ის მეთოდი იგივე პაკეტებია მეტი ნაბიჯით და ის გინდა ყველაფერში, რასაც გაიმეორებ. ორივე შემთხვევაში საბოლოოდ გექნება docker-ce (daemon), docker-ce-cli (ბრძანება), containerd.io (ქვემოთ მდგარი runtime), და docker-buildx-plugin და docker-compose-plugin ქვებრძანებები. აარიდე შენი დისტრიბუტივის საკუთარ docker.io პაკეტს: ის ჩამორჩება და Compose plugin-ს სანდოდ არ მოიტანს, რომელიც კვირაში დაგჭირდება.

შემდეგ ნაწილი, რომელსაც ყველა ტოვებს:

$ sudo usermod -aG docker deploy$ newgrp docker$ docker run --rm hello-world

თუ docker run hello-world მისალმების ტექსტს დაბეჭდავს, daemon მუშაობს, ქსელი მუშაობს და image-ების ჩამოტვირთვაც მუშაობს. ეს სამი ტესტია ერთ ბრძანებაში და ღირს მისი გაკეთება უფრო რთულ რამეზე დებაგამდე.

Image-ები და container-ები: პირველი გაშვება#

image არის მხოლოდ წასაკითხი ფაილური სისტემის ფენების დასტა და მეტამონაცემები, რომლებიც ამბობს, რა უნდა შესრულდეს. container არის image-ის ერთი გაშვებული ეგზემპლარი თხელი ჩასაწერი ფენით ზემოდან. container-ის წაშლა ამ ჩასაწერ ფენასაც შლის - ამიტომ ყველაფერი, რაც გენანება, volume-ში უნდა ცხოვრობდეს, სამი განყოფილება ქვემოთ.

$ docker run -d \    --name web \    --restart unless-stopped \    -p 127.0.0.1:8080:80 \    -v /srv/web/html:/usr/share/nginx/html:ro \    nginx:1.27-alpine

ამ ხაზს მარცხნიდან მარჯვნივ ასე კითხულობ: გაუშვი detached რეჟიმში, დაარქვი web, რებუტის შემდეგ დააბრუნე, გამოაქვეყნე container-ის პორტი 80 როგორც პორტი 8080 მხოლოდ loopback-ზე, მიამაგრე host-ის დირექტორია მხოლოდ წასაკითხად, nginx image-იდან tag-ით 1.27-alpine.

tag გადაწყვეტილებაა და არა დეკორაცია:

latest არხი არ არის და არანაირ დაპირებას არ შეიცავს. ეს უბრალოდ tag-ია, რომელიც მაშინ ედება, როცა არავის დაუზუსტებია, და ის მაშინ მოძრაობს, როცა maintainer-ს მოესურვება. ექვსი თვის შემდეგ docker pull შეიძლება ახალი major ვერსია მოგცეს, და პირველი, რაც ამის შესახებ გაიგე, container-ია, რომელიც არ ეშვება. ყველაფერზე, რაც მონაცემებს ინახავს, ჩაამაგრე სულ მცირე minor ვერსია.

ყოველდღიური ბრძანებები, რომლებსაც საათობრივად გამოიყენებ:

$ docker ps                      # running containers$ docker ps -a                   # including the dead ones$ docker logs -f --tail 100 web  # follow the output$ docker exec -it web sh         # a shell inside it$ docker stop web && docker rm web$ docker inspect web             # every setting, as JSON

docker stop აგზავნის SIGTERM-ს, ელოდება ათ წამს და შემდეგ აგზავნის SIGKILL-ს. თუ შენს აპლიკაციას სუფთა გამორთვისთვის მეტი დრო სჭირდება - ჩაწერის დასრულება, მოთხოვნის დამთავრება, სამყაროს შენახვა - გაზარდე docker stop -t 60-ით და დარწმუნდი, რომ პროცესი SIGTERM-ს რეალურად ამუშავებს. Graceful shutdown და health check-ები გვიჩვენებს, როგორ გამოიყურება მისი სწორი დამუშავება აპლიკაციის კოდში.

პორტები, გამოქვეყნება და firewall#

-p აყენებს destination NAT-ს host-ის პორტიდან container-ის პორტზე. როცა ეწერება -p 8080:80, ის მანქანის ყველა მისამართზე მიება, საჯაროზეც. როცა ეწერება -p 127.0.0.1:8080:80, ის მხოლოდ loopback-ზე მიება.

მეორე ფორმა ამჯობინე. თითქმის ყველაფერი, რასაც გაუშვებ, სხვა რამის უკან უნდა იდგეს - reverse proxy ყველაფრისთვის, რაც HTTP-ს ლაპარაკობს, და საერთოდ არაფერი მონაცემთა ბაზისთვის, რომელსაც მხოლოდ შენი აპლიკაცია იყენებს. წესი ასეთია: პორტი გამოაქვეყნე მხოლოდ მაშინ, თუ ინტერნეტმა მასთან პირდაპირ უნდა მიაღწიოს.

ეს გემოვნების საკითხი არ არის. გამოქვეყნებული პორტები UFW-ს უვლიან გვერდს. container, რომელიც -p 8080:80-ით არის გამოქვეყნებული, ინტერნეტიდან მისაწვდომია მაშინაც, როცა ufw status default-deny პოლიტიკას აჩვენებს და 8080-ისთვის წესი არ არის, რადგან პაკეტი container-ს გადაეცემა და არა host-ს, ხოლო Docker-ის გადამისამართების წესები პირველი ფასდება. სრული ახსნა და ოთხი გზა მის შესავლელად UFW firewall-ის გზამკვლევშია; ერთხაზიანი ვერსია ასეთია: გამოაქვეყნე 127.0.0.1-ზე და საჯარო მხარე host-ზე მდგარ proxy-ს მიანდე.

container-ებმა, რომლებსაც ერთმანეთთან საუბარი სჭირდებათ, გამოქვეყნების ნაცვლად საერთო user-defined ქსელი უნდა გამოიყენონ:

$ docker network create appnet$ docker run -d --name db  --network appnet -e POSTGRES_PASSWORD=... postgres:17$ docker run -d --name app --network appnet -p 127.0.0.1:3000:3000 my/app:1.4

user-defined ქსელზე Docker ჩაშენებულ DNS სერვერს უშვებს, ამიტომ აპლიკაცია უერთდება host-სახელს db პორტზე 5432 და არსად არაფერი ჩანს გარეთ. ნაგულისხმევ bridge ქსელს ეს სახელების გადაწყვეტა არ აქვს, და სწორედ ამიტომაა "Compose-ში მუშაობს, docker run-ით არა" თითქმის ყოველთვის გამოტოვებული docker network create.

Volume-ები და სად ცხოვრობს შენი მონაცემები სინამდვილეში#

container-ის ჩასაწერი ფენა container-თან ერთად კვდება. მონაცემების შესანახად ორი გზაა და ისინი სხვადასხვა საქმისთვისაა.

Named volume-ებს Docker მართავს და ინახავს /var/lib/docker/volumes/-ში. გამოიყენე ისინი ყველაფრისთვის, რასაც პროგრამა ფლობს და შენ მხოლოდ იმავე პროგრამის გავლით ეხები: მონაცემთა ბაზის ფაილები, თამაშის სამყარო, აპლიკაციის state დირექტორია.

$ docker volume create pgdata$ docker run -d --name db -v pgdata:/var/lib/postgresql/data postgres:17$ docker volume ls$ docker volume inspect pgdata

Bind mount-ები host-ის გზას container-ში ასახავს. გამოიყენე ისინი იმისთვის, რასაც საკუთარი რედაქტორით ცვლი: კონფიგურაციის ფაილები, სტატიკური საიტის HTML, ატვირთული მედიის დირექტორია, რომელსაც nginx-იდანაც აწვდი.

$ docker run -d --name web -v /srv/web/html:/usr/share/nginx/html:ro nginx:1.27-alpine

სამი პრაქტიკული წერტილი. :ro სუფიქსი mount-ს მხოლოდ წასაკითხად აქცევს და არაფერი უჯდება - გამოიყენე ყველგან, სადაც container-ს ჩაწერის საქმე არ აქვს. Bind mount-ები host-ის მფლობელობას container-ში გადააქვთ, ამიტომ container-ში UID 1000-ით გაშვებული პროცესი ვერ ჩაწერს დირექტორიაში, რომელიც გარეთ root-ს ეკუთვნის; ან chown გაუკეთე დირექტორიას სწორ რიცხვით ID-ზე, ან გაუშვი container --user "$(id -u):$(id -g)"-ით. და named volume, რომელიც საწყის შიგთავსს image-იდან იღებს, ამას მხოლოდ მაშინ აკეთებს, როცა ცარიელია, სწორედ ამიტომ ჩანს, რომ image-ის ნაგულისხმევი კონფიგურაციის შეცვლა პირველი გაშვების შემდეგ არაფერს აკეთებს.

volume-ის backup არის container, რომელიც მას მიამაგრებს და tarball-ს სხვაგან ჩაწერს:

$ docker run --rm -v pgdata:/data:ro -v /srv/backups:/out alpine \    tar czf /out/pgdata-$(date +%F).tar.gz -C /data .

მონაცემთა ბაზისთვის ამჯობინე თავად ბაზის dump ინსტრუმენტი ცოცხალი მონაცემების დირექტორიის ფაილური ასლის ნაცვლად - pg_dump docker exec-ით გაძლევს ფაილს, რომელიც სანდოდ აღდგება, რასაც იმ ფაილების tarball არ აკეთებს, რომლებშიც ამჟამად წერენ. pg_dump და pg_restore flag-ებს შეიცავს.

Restart პოლიტიკა, რებუტები და health#

container თავისით არ ბრუნდება. ნაგულისხმევად, როცა პროცესი ჩერდება ან მანქანა გადაიტვირთება, ის გამორთული რჩება.

unless-stopped სწორი პასუხია თითქმის ყველაფრისთვის პატარა სერვერზე. ის რებუტსაც უძლებს და ავარიასაც და პატივს სცემს იმას, რომ container შენ განზრახ გააჩერე - რასაც always არ აკეთებს და daemon-ის შემდეგ გაშვებისას მხიარულად აბრუნებს container-ს, რომელიც ერთი საათის წინ გააჩერე.

პოლიტიკის შეცვლა გაშვებულ container-ზე თავიდან შექმნის გარეშეც შეგიძლია:

$ docker update --restart unless-stopped web

Restart პოლიტიკა დამოკიდებულია იმაზე, რომ Docker სერვისი ჩატვირთვისას ეშვება, ამიტომ დარწმუნდი, რომ systemctl is-enabled docker ამბობს enabled. და გაითვალისწინე, რა არ არის restart პოლიტიკა: ის health check არ არის. container, რომლის პროცესი ცოცხალია, მაგრამ გაჭედილი - Node აპლიკაცია, რომელმაც კავშირების მიღება შეწყვიტა, თამაშის სერვერი, რომელიც შენახვაზე გაიჭედა - restart პოლიტიკას სრულად აკმაყოფილებს. Docker-ის საკუთარი HEALTHCHECK ასეთ container-ს unhealthy-დ მონიშნავს, მაგრამ არ გადატვირთავს. თუ გინდა "გადაიტვირთოს, როცა პასუხის გაცემას შეწყვეტს", ეს watchdog-ის საქმეა, ან systemd unit-ისა, რომელიც container-ს შენთვის სასურველ health ლოგიკაში ახვევს; systemd სერვისები შენი აპლიკაციებისთვის შეიცავს unit ფაილს ამ ფორმისთვის.

ლიმიტები და ლოგები: ორი რამ, რაც ჩუმად ავსებს მანქანას#

ნაგულისხმევად container-ს შეუძლია მანქანის მთელი მეხსიერება და მთელი CPU გამოიყენოს. სერვერზე, რომელზეც ერთი რამ მუშაობს, ეს კარგია. სერვერზე, რომელზეც ექვსი მუშაობს, ერთი გაქცეული პროცესი დანარჩენებსაც თან იყოლიებს.

$ docker run -d --name app \    --memory=1g --memory-swap=1g --cpus=1.5 \    my/app:1.4$ docker stats --no-stream

--memory-swap-ის --memory-ის ტოლად დაყენება ამ container-ისთვის swap-ს თიშავს, რაც ჩვეულებრივ სწორედ გინდა: პროცესი, რომელიც swap-ში გადაიტანეს, ისე ნელა მუშაობს, რომ დიაგნოზი უფრო რთულია, ვიდრე პირდაპირი ჩავარდნისა. როცა container მეხსიერების ლიმიტს გადააჭარბებს, kernel მასში პროცესს კლავს, container გამოდის კოდით 137 და docker inspect ამას ჩაწერს:

$ docker inspect -f '{{.State.OOMKilled}}' apptrue

გასვლის კოდი 137 არის 128 + 9, ანუ SIGKILL. კოდი 143 არის 128 + 15, სუფთა SIGTERM - ჩვეულებრივ, შენ აჩერებ. ეს ორი რიცხვი "რატომ მოკვდა" კითხვების უმეტესობას თავისით პასუხობს. Linux swap და OOM killer განმარტავს, რას წყვეტს kernel, როცა მსხვერპლს ირჩევს.

უფრო ჩუმი პრობლემა ლოგებია. Docker-ის ნაგულისხმევი logging driver ყველაფერს, რასაც container ბეჭდავს, JSON ფაილში წერს /var/lib/docker/containers/-ის ქვეშ, ზომის რაიმე ლიმიტის გარეშე. ხმაურიანი აპლიკაცია დისკს კვირებში ან თვეებში აავსებს, სიმპტომი კი სერვერია, რომელიც ერთდროულად რამდენიმე ერთმანეთთან დაუკავშირებელი გზით ფუჭდება. გაასწორე გლობალურად:

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

შემდეგ sudo systemctl restart docker. გაითვალისწინე, რომ ეს მოქმედებს container-ებზე, რომლებიც შემდეგ შეიქმნება; არსებულები იმ პარამეტრებს ინარჩუნებენ, რომლებითაც შეიქმნენ, ამიტომ ან თავიდან შექმენი, ან თითოეულს დაუყენე --log-opt max-size=10m. რამდენს ატარებ დღეს, შეამოწმე sudo du -sh /var/lib/docker/containers/*-ით.

განახლება, prune და დისკის ადგილი#

container-ის განახლება ადგილზე გაუმჯობესება არ არის. ჩამოტვირთავ ახალ image-ს, შლი container-ს და ქმნი ახალს იმავე volume-ებით და იმავე run ბრძანებით:

$ docker pull nginx:1.27$ docker stop web && docker rm web$ docker run -d --name web --restart unless-stopped \    -p 127.0.0.1:8080:80 -v /srv/web/html:/usr/share/nginx/html:ro nginx:1.27

სწორედ ამიტომ არის run ხაზის ჩაწერა მნიშვნელოვანი და სწორედ ამიტომ არსებობს Compose - docker compose pull && docker compose up -d იმავე სამ ნაბიჯს აკეთებს ფაილიდან, რომელიც უკვე გაქვს. წინა image tag შეინახე, სანამ ახალი container ერთი დღე იმუშავებს; უკან დაბრუნება მაშინ ძველი tag-ის ხელახლა გაშვებაა.

დისკის მოხმარება ერთდროულად ოთხ ადგილას იზრდება. ეს გეუბნება, სად:

$ docker system dfTYPE            TOTAL   ACTIVE   SIZE      RECLAIMABLEImages          14      4        6.2GB     4.9GB (79%)Containers      7       4        112MB     43MB (38%)Local Volumes   6       3        2.1GB     820MB (38%)Build Cache     41      0        3.3GB     3.3GB

docker image prune -a შლის image-ებს, რომლებსაც არც ერთი container არ იყენებს. docker builder prune ასუფთავებს build cache-ს, რომელიც მანქანაზე, რომელიც საკუთარ image-ებს აშენებს, ხშირად ყველაზე დიდი ერთეულია. docker container prune შლის შეჩერებულ container-ებს. გაუშვი ეს სამი გრაფიკით და იშვიათად თუ იფიქრებ ამაზე. გაუშვი docker system prune --volumes უდარდელად და საბოლოოდ მონაცემთა ბაზას წაშლი. ეს განსხვავება ღირს, თითებში გქონდეს.

როცა container არ ეშვება#

გამოდის დაუყოვნებლივ და `docker ps` არაფერს აჩვენებს. გასვლის კოდისთვის იხილე docker ps -a, მიზეზისთვის კი docker logs <name>. container, რომელსაც წინა პლანზე გრძელი პროცესი არ აქვს, გამოდის, როგორც კი მისი ბრძანება დასრულდება - ეს ხარვეზი არ არის, ეს დიზაინია.

Port is already allocated. host-ის პორტი სხვას უჭირავს. sudo ss -lntp | grep 8080 მას დაასახელებს. ან შეაჩერე ის, ან გამოაქვეყნე სხვა host პორტზე; container-ის პორტს არასოდეს სჭირდება შეცვლა.

Permission denied მიმაგრებულ დირექტორიაზე. UID-ის შეუსაბამობა bind mount-ზე. შეამოწმე ls -ln host-ის დირექტორიაზე და USER, რომლითაც image მუშაობს, შემდეგ დააბალანსე.

image არ იტვირთება. შეამოწმე, tag მართლა არსებობს თუ არა, შემდეგ შეამოწმე, ხომ არ გიზღუდავენ მოთხოვნებს - registry-ები ანონიმურ ჩამოტვირთვებს მისამართით ზღუდავენ, ხოლო docker login ამას იხსნის. ახალ მანქანაზე ასევე შეამოწმე DNS: container-ები ნაგულისხმევად host-ის resolver-ს იყენებენ და გატეხილი /etc/resolv.conf აქ ჩანს პირველად.

გუშინ მუშაობდა და დღეს სხვა ვერსიაა. გამოიყენე latest. იხილე tag-ების ცხრილი.

ყველაფერი ნელია და დისკი სავსეა. ლოგები ან build cache. იხილე წინა განყოფილება.

RE:NODE-ის მართული გეგმებიც container-ებია - პანელი მორგებული Pterodactyl-ია, თითო container-ით თითო სერვერზე, CPU-ს მკაცრი შეზღუდვით იმ წილზე, რომელიც იყიდე, და ზემოთ აღწერილი იგივე OOM ქცევით, იმ განსხვავებით, რომ ლიმიტზე მთელი container ჩერდება და სუფთად იწყება თავიდან, swap-ში დარჩენის ნაცვლად. რაც იქ არ შეგიძლია, საკუთარი image-ის მოტანაა, ამიტომ თუ პროგრამა, რომლის გაშვებაც გინდა, კატალოგის ხაზებში არ არის, VDS root წვდომით და Docker-ით მასზე სწორი პასუხია. არჩევანი VDS-სა და თამაშის პანელს შორის ორივეს გვერდიგვერდ აყენებს, ხოლო რა არის ჰოსტინგ პანელი სინამდვილეში მართულ მხარეს განმარტავს.

FAQ#

მჭირდება Docker პატარა VDS-ზე?

არა, და ერთი აპლიკაციისთვის ის შეიძლება იყოს დამატებითი ფენა, რომლის სწავლაც მცირე სარგებელს იძლევა. ის თავის ადგილს იმ წამს იმსახურებს, როცა მეორე რამეს უშვებ, გჭირდება ვერსია, რომელსაც შენი დისტრიბუტივი არ პაკეტავს, ან გინდა იგივე კონფიგურაცია უცვლელად სხვა მანქანაზე გადაიტანო.

რამდენ დანახარჯს ამატებს container?

CPU-სა და მეხსიერებაზე თითქმის არაფერს - ეს იგივე kernel-ია, რომელიც იგივე პროცესს სხვა namespace-ებით უშვებს. container-ის ქსელი NAT-ის გამო მცირე დაყოვნებას ამატებს, ხოლო ჩასაწერი overlay ფაილური სისტემა უფრო ნელია, ვიდრე bind mount მძიმე შემთხვევითი ჩაწერისას, რაც კიდევ ერთი მიზეზია, რატომ უნდა იყოს მონაცემთა ბაზები volume-ებზე.

სად არის ჩემი მონაცემები, თუ container-ს წავშლი?

მის volume-ებში, რომლებიც რჩება. ყველაფერი, რაც container-ში ჩაიწერა volume-ს გარეთ, ჩასაწერ ფენასთან ერთად ქრება. წაშლამდე docker inspect-ით შეამოწმე, რას ამაგრებს container.

შემიძლია Docker-ის გაშვება მართულ ჰოსტინგ გეგმაში?

არა. მართული თამაშის ან აპლიკაციის გეგმა უკვე container-ია და მის შიგნით საკუთარი kernel-ი ან daemon-ი არ გაქვს. Docker-ის გაშვება ერთ-ერთი კონკრეტული მიზეზია, რატომ უნდა აიღო VDS.

რატომ არის ჩემი container ინტერნეტიდან მისაწვდომი, როცა firewall ჩართულია?

იმიტომ, რომ პორტი გამოაქვეყნე, ხოლო გამოქვეყნებული პორტები host firewall-ის input წესებს უვლიან გვერდს. გამოქვეყნება მიაბი 127.0.0.1-ს, თუ პორტი სინამდვილეში საჯარო არ უნდა იყოს, და ყველაფრის წინ, რაც საჯაროა, reverse proxy დააყენე.

უნდა განახლდეს თუ არა container-ები ავტომატურად?

არა სერვერზე, რომელიც გენანება. image-ების ავტომატური განახლება ნიშნავს უყურადღებო major ვერსიის ცვლილებას საათზე, როცა არავინ უყურებს. ჩაამაგრე minor tag, ჩამოტვირთე შეგნებულად და წინა tag საკმარისად დიდხანს შეინახე უკან დასაბრუნებლად.