By default docker compose uses the directory name the compose yaml resides in as a project name to prefix to any named volumes.
So given:
home
|_fig-rolls
|_projects
|_awesome
|_docker-compose.yml
With the docker-compose.yml
defining a database server I can use where (I hoped) the initial import of a large database dump is persisted between containers:
services:
mysql:
image: percona/percona-server:8.4
container_name: percona-server
ports:
- "3306:3306"
environment:
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
MYSQL_DATABASE: not_so_awesome
MYSQL_USER: ${MYSQL_USER}
MYSQL_PASSWORD: ${MYSQL_PASSWORD}
volumes:
- percona-data:/var/lib/mysql # Database data
- percona-logs:/var/log/mysql # MySQL logs
- percona-backups:/backups # XtraBackup output
- ${PWD}/data/not_so_awesome.sql.gz:/docker-entrypoint-initdb.d/not_so_awesome.sql.gz
restart: unless-stopped
volumes:
percona-data:
percona-logs:
percona-backups:
You end up with:
$ docker volume ls | grep awesome
local awesome_percona-backups
local awesome_percona-data
local awesome_percona-logs
Should be good to docker compose down
, all my data is safe in awesome_percona-data
.
Of course I only learned this after I renamed my project.
mv /home/fig-rolls/projects/awesome /home/fig-rolls/projects/not_so_awesome
Bring a new container up and of course it's created and mounted an empty not_so_awesome_percona-data
volume.
It's obvious really, what-else would Docker use to name the volumes to avoid conflicts with other projects?
Never mind, not that long to reimport from an existing DB dump (used the time to write this.)
It's worth noting you can specify your own volume name which will then not get this project prefix and remain consistent.
And of course the old volumes were actually still there so I could have just jumped through hoops to copy the contents to the newly named volumes (there's weirdly no option to rename.)
Hope this was useful.
Thanks for reading and don't make the same mistake :)
Top comments (0)