Управление на данните – Volumes и Persistent Storage в Docker.

След като вече знаем как да пускаме готови приложения и да пакетираме свои, идва моментът да се погрижим за най-ценното – данните. Тази статия ще обясни как да не губим информация, когато контейнерите се рестартират или изтриват.
🐳 Част 3: Сърцето на данните – Volumes и Persistent Storage в Docker
Досега научихме как да стартираме контейнери и дори да си правим собствени. Но има един голям проблем: по подразбиране, когато изтриете един Docker контейнер, всички данни вътре в него изчезват завинаги!
Представете си, че пускате база данни, създавате потребители и след рестарт на сървъра – всичко е изчезнало. Не е идеално, нали?
За да решим това, използваме концепцията за Docker Volumes.
1. Какво са Docker Volumes? (Външният диск на контейнера) 💾
Представете си вашия контейнер като малък, временен компютър, който при изключване забравя всичко.
Volume е като да включите USB флашка или външен хард диск към този контейнер. Данните на флашката не се намират вътре в контейнера, а са на вашия истински сървър. Когато контейнерът изчезне, флашката (Volume) остава и можете да я включите към нов контейнер.
Две основни цели на Volumes:
- Persistent Storage (Постоянно съхранение): За да не губим важни данни като тези на база данни.
- Live Development (Разработка в реално време): За да редактираме код на нашия сървър и веднага да виждаме промените в контейнера, без да го преизграждаме постоянно.
2. Типове Volumes (и кой да изберете) 🤓
Има два основни типа Volumes, които ще използваме:
- Named Volumes (Именовани обеми): Управляват се изцяло от Docker. Вие просто му казвате "Искам volume на име
moqta-baza-danni". Docker го създава, управлява и пази данните за вас. Не знаете къде точно на сървъра се намират файловете, но няма и нужда. - Bind Mounts (Привързани монтирания): Вие контролирате точно коя папка от вашия сървър да се "монтира" в контейнера. Това е супер полезно за разработка на код.
3. Практика 1: Постоянна база данни с Named Volumes (Използвайки Docker Compose) 🗄️
Ще използваме примера с MySQL база данни от Част 1. Ако не ползвахме Volume, всеки път, когато стартирахме docker compose down, базата данни щеше да е празна.
Влезте в папката на предишния проект (cd my-app) и редактирайте docker-compose.yml: nano docker-compose.yml
version: '3.8'
services:
web:
image: nginx
ports:
- "8080:80"
database:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: my-secret-pw
volumes: # <--- Нова секция
- db_data:/var/lib/mysql # <--- Тук казваме: "Пази данните от контейнера в 'db_data' volume"
volumes: # <--- Дефинираме нашия volume
db_data: # <--- Името на volume-а
Сега стартирайте: docker compose up -d
Какво стана?
- Docker създаде един
named volumeна имеdb_data. - Монтира го в
databaseконтейнера в папката/var/lib/mysql(това е стандартното място, където MySQL пази своите данни).
Дори да спрете docker compose down, а след това пак да пуснете docker compose up -d, вашите данни в базата данни ще са там, където сте ги оставили. Можете да видите всички ваши named volumes с docker volume ls.
4. Практика 2: Разработка в реално време с Bind Mounts (Използвайки Docker Compose) 👨💻
Bind Mounts са идеални за разработка. Вместо всеки път да изграждате нов Docker образ, когато промените един ред код, просто "показвате" на контейнера къде да чете файла от вашия сървър.
Нека модифицираме нашия Python проект от Част 2. Влезте в папката moqt-proekt и редактирайте docker-compose.yml (създайте го, ако го няма): nano docker-compose.yml
version: '3.8'
services:
app:
build: . # <--- Казваме на Compose да изгради образа от текущата папка
volumes:
- .:/app # <--- Това е Bind Mount: "Монтирай текущата папка на сървъра в /app в контейнера"
Сега стартирайте: docker compose up -d
Направете промяна в app.py: nano app.py
import time
while True:
print("Здравейте от новата версия на приложението!")
time.sleep(2)
След като запазите app.py, погледнете логовете на контейнера: docker compose logs -f app. Ще видите, че контейнерът веднага отразява промените, без да сте го рестартирали или преизграждали! Това е силата на Bind Mounts.
5. Почистване: Когато един Volume вече не е нужен 🗑️
Именованите Volumes не се изтриват автоматично с docker compose down. За да изтриете всички данни, свързани с даден проект, използвайте:
docker compose down --volumes
Ако сте създали Volume ръчно или той не е свързан с docker compose проект, може да го изтриете с: docker volume rm ime-na-volume
6. Често срещани грешки с Volumes ⚠️
- Грешни пътища: Уверете се, че пътят до папката на сървъра ви (при Bind Mounts) е абсолютно правилен.
- Забравени данни: Ако сте забравили да дефинирате Volume и сте изтрили контейнера, данните са изчезнали завинаги. Винаги планирайте Volumes отрано!
- Недостатъчно място: Volumes ползват място на вашия сървър. Наблюдавайте свободното пространство.
Заключение
След тази статия вече имате пълния контрол върху вашите приложения. Знаете как да пускате готови, как да правите свои и най-важното – как да пазите своите данни.
Намерихте материала за полезен?
Съдържанието на itpraktika.com е безплатно и ще остане такова.
Ако статията ти е помогнала — можеш да подкрепиш сайта с малка доброволна сума.
Всяко дарение помага за поддръжката и развитието на портала.
