როგორ მუშაობს მონაცემთა დაშენება Docker-ის ტომების მাধ্যმით?

Question

Accepted Answer

ნაგულისხმევად, კონტეინერის მონაცემები **ეფემერული** არის — დაკარგული იმ შემთხვევაში, თუ კონტეინერი ამოღებულია. **Volumes** (და bind mounts) უზრუნველყოფენ **მუდმივ შენახვას**, რომელიც გადამეტრდება კონტეინერებს, აუცილებელი მონაცემთა ბაზებისთვის და ნებისმიერი მონაცემისთვის, რომელიც უნდა გადაურჩეს კონტეინერის ხელახლა დაწყებას/ამოღებას.

## პრობლემა: კონტეინერები ეფემერული არის

```text
A container's writable layer is DELETED when the container is removed:
  → data written inside the container (e.g. a database's files) is LOST
  → containers are meant to be disposable/replaceable → don't store important data in them
→ For persistent data, you need storage OUTSIDE the container's lifecycle.
```

## Volumes — მართული მუდმივი შენახვა

```bash
# create and use a named volume (managed by Docker)
docker volume create mydata
docker run -v mydata:/var/lib/mysql mysql      # mount the volume into the container
# → data in /var/lib/mysql persists in the volume, surviving container removal

docker volume ls                 # list volumes
docker volume inspect mydata     # details
```

**Volumes** არის Docker-მართული მუდმივი შენახვა (შენახული ჰოსტში, მართული Docker-ის მიერ) — დაშენების ჩვეულებრივი გზა. მონაცემები მონტირებული ბილიკში უსაფრთხოა, თუნდაც კონტეინერი ამოღებული იყოს.

## Bind mounts — ჰოსტის დირექტორიის რუკა

```bash
# bind mount: map a specific HOST directory into the container
docker run -v /host/path:/app -p 3000:3000 myapp
docker run -v $(pwd):/app myapp   # mount the current directory (great for development)
# → changes on the host are reflected in the container (and vice versa)
```

**Bind mounts** რუკაზე ჰოსტის დირექტორია კონტეინერში — სასარგებლო განვითარებისთვის (კოდის რედაქტირება ჰოსტში, ცვლილებების ხილვა ცოცხალი კონტეინერში).

## Volumes წინააღმდეგ bind mounts

```text
VOLUMES      → Docker-managed, portable, the preferred choice for PERSISTENT DATA
               (databases, uploads) — decoupled from the host's filesystem layout
BIND MOUNTS  → map a specific host path; great for DEVELOPMENT (live code reload)
               and sharing host files; tied to the host's filesystem
tmpfs        → in-memory (non-persistent), for sensitive/temporary data
```

## რატომ აქვს მნიშვნელობა

მონაცემთა დაშენების გაცნობიერება ტომების მাধ্যმით აუცილებელია Docker-ის სწორად გამოყენებისთვის ნებისმიერი აპლიკაციით, რომელსაც აქვს მონაცემები, ამიტომ ეს მნიშვნელოვანი პრაქტიკული ცოდნაა.

ფუნდამენტური სამეზობლო — **კონტეინერები ეფემერული** არის, მათი წერთადი ფენა წაშლილი ამოღების დროს, რას ნიშნავს **კონტეინერის შიგნით დაწერილი მონაცემები დაკარგულია** — მნიშვნელოვანი კონცეფცია: კონტეინერები განკუთვნილია იყვნენ განკარგული, ამიტომ მნიშვნელოვანი მონაცემების შენახვა მათში (მონაცემთა ბაზის ფайლები) იწვევს მონაცემთა დაკარგვას კონტეინერის ჩანაცვლებისას. **Volumes** წყვეტენ ამას **Docker-მართული მუდმივი შენახვის** მიერ, რომელიც მდებარეობს კონტეინერის ცხოვრების ციკლის გარეთ, ამიტომ მონაცემები (მონაცემთა ბაზები, ატვირთვები, ნებისმიერი მდგომარეობა) გადამეტრდება კონტეინერის ამოღებას და ჩანაცვლებას — აუცილებელი stateful აპლიკაციებისთვის.

**Bind mounts** (ჰოსტის დირექტორიის რუკა კონტეინერში) გაცნობიერება მნიშვნელოვანია **განვითარებისთვის** (კოდის რედაქტირება ჰოსტში და ცვლილებების ხილვა კონტეინერში ცოცხალი, ძალიან გავრცელებული dev სამუშაო) და ჰოსტის ფайლების გაზიარებისთვის.

**განსხვავების** შემცირება — volumes (Docker-მართული, პორტატული, დაშენების სასურველი არჩევანი მუდმივი აპლიკაციის მონაცემებისთვის მონაცემთა ბაზების მსგავსად) წინააღმდეგ bind mounts (ჰოსტ-ბილიკი-სპეციფიკური, მშვენიერი განვითარებისთვის) — ხელმძღვანელობს სწორი ხელმისაწვდომობის არჩევანს.

ამ შემთხვევაში კონტეინერები ეფემერული არის ডიზაინით და ყველაზე რეალური აპლიკაციებს აქვთ მონაცემები, რომელიც უნდა დაჯდეს (მონაცემთა ბაზები განსაკუთრებით), და რამდენადაც volumes არის მუდმივი შენახვის აუცილებელი მექანიზმი (bind mounts მნიშვნელოვანი განვითარებისთვის), Docker მონაცემთა დაშენების გაცნობიერება — ეფემერული-კონტეინერი პრობლემა, volumes მუდმივი მონაცემებისთვის, bind mounts განვითარებისთვის, და რომელი გამოვიყენოთ — აუცილებელია, პრაქტიკულად აქტუალური Docker ცოდნა, აუცილებელი stateful აპლიკაციების სწორად ფუნქციონირებისთვის და მნიშვნელოვანი შეცდომის თავიდან აცილებისთვის გამორიცხული კონტეინერების შიგნით შენახული მონაცემების დაკარგვის.