Каким образом правильно выкачать из контейнера содержимое тома?
Насколько я читал, там написано, что когда том инициализируется впервые - его содержимое помещается в примонтированную к нему хостовую папку, чтобы сохранить ее состояние между перезапусками контейнера.
Однако после того как я задаю volumes: в docker-compose.yml, я лишь получаю пустые папки, более того - сервисы начинают ругаться, что в контейнерах они теперь тоже пустые, то есть пустота папки "записалась" в контейнер как состояние и удалились родные конфиги.
Отдельно пробовал выполнить удаление всех созданных томов и контейнеров через docker volume ls, на всякий случай, понимая что том при сносе контейнера остается.
Каким образом это правильно настраивается и как мне удобным образом выкачать по 2-3 папки из докера наружу - логи например чтобы можно было просматривать, или знать все конфиги, которые есть внутри, чтобы иметь возможность отредактировать их перед следующим запуском контейнера?
zohan1993, пример отличный.
Делаю все именно так. С сожалением константирую, что в случае с логами наружу выпадают файлы из контейнера - логи. Обновленные после создания контейнера я полагаю.
Однако моя цель получить возможность удобно настраивать внутренние файлы контейнера находясь на хосте, не заходя в каждый контейнер отдельно.
То есть логи он наружу выбрасывает. А вот когда я такой же волум цепляю например на папку var/lib/mysql, чтобы сохранить ее содержимое на хосте, если контейнер будет пересоздан или удален - он ничего в эту папку не копирует. и более того - записывает пустоту этой папки вовнутрь.
могу я созвониться с вами в telegram? обговорим условия помощи с вашей стороны
version: '3.7'
networks:
default:
name: test
driver: bridge
ipam:
driver: default
config:
- subnet: 172.22.11.0/24
driver_opts:
com.docker.network.bridge.name: br-test
volumes:
data:
conf:
services:
db:
image: mariadb:10.5.6
hostname: db
container_name: db
expose:
- 3306
volumes:
# - ./data:/var/lib/mysql # bind mount for MySQL data
- data:/var/lib/mysql # volume for MySQL data
- conf:/etc/mysql # volume for MySQL configuration files
# - ./my.cnf:/etc/mysql/my.cnf # Using a custom MySQL configuration file
environment:
- MYSQL_ROOT_PASSWORD=1
- MYSQL_DATABASE=test
- MYSQL_USER=test
- MYSQL_PASSWORD=test
restart: always
для "/var/lib/mysql" можно использовать как bind mount так и volume
потому что нам нужно сохранять состояние контейнера между перезапусками
то есть данные которых нет в базовом образе (данные mysql)
и на этапе монтирования в "/var/lib/mysql" пусто
данные появляются там только после запуска контейнера
для "/etc/mysql" нужно использовать volume
если хотим сохранить и использовать файлы, которые присутствуют в базовом образе
так как данные в "/etc/mysql" есть в базовом образе
тогда во время первого запуска контейнера, данные с "/etc/mysql" копируются в volume
затем контейнер монтирует volume и использует его
при следующих перезапусках контейнера данные копироваться не будут, так как volume не пустой, а будет просто монтироваться
правда можно сделать по другому и использовать bind mount
нужно создать свой конфиг (или папку с конфигами) и монтировать в "/etc/mysql"
тогда после запуска контейнера, mysql будет использовать эти конфиги
Почти все понял, еще бы нормальный удобный способ автоматизированного копирования содержимого папок
Сейчас у меня в makefile есть команды extract/build/checkout. Первая удаляет все волумы и собирает заново, выбрасывая конфиги на хост по указанным путям в папку ./extract/
вторая копирует из папки ./extract/ и папки ./replace/ (которую для проекта уже самостоятельно пишешь) конфиги в папки на хосте, которые станут волумами и собирает уже с волумами, и делает обновление уже внутренних там всяких композеров, pip-ов и npm-ов
и третья просто перезапускает контейнеры, делая то же самое обновление, когда ветки переключаешь гитом
Так-то все ясно, кроме одного - необходимость для extract запускать докер композ без волумов, т.к. иначе они замонтируются пустыми внутрь и копировать будет нечего.
Автоматизация плачет от того, что нужно ставить коммент на волумы при экстракте, потом раскоментировать их и запускать уже build.
Тут есть какое-то решение?
====
ps.
# - ./my.cnf:/etc/mysql/my.cnf # Using a custom MySQL configuration file
вчера Percona ругался, что при этом /etc/my.cnf становится "world-writable" и не запускал его совсем, поскольку у меня Docker Desktop на виндоус, не понимаю как форсировать нужные права, кроме как в Dockerfile делать COPY файла вовнутрь с переписыванием прав.
Средний
