Docker image extending the mysql image isn't running the initdb scripts
When a container is started for the first time […] it will execute files with extensions .sh and .sql that are found in /docker-entrypoint-initdb.d. You can easily populate your mysql services by mounting a SQL dump into that directory and provide custom images with contributed data.
How to communicate with Kafka server running inside a docker How to install a python package with all the dependencies into a Docker image? docker-compose up Permission denied on Windows restcomm docker image installation on windows 8.1 Github repo with more than one python packages Restarting containers after docker-machine host is rebooted
So at first I did this in my
version: '2' services: db: image: mysql:5.7 volumes: - .:/docker-entrypoint-initdb.d:ro
When I ran
docker-compose build and
docker-compose up the container was created and the sql files in the current directory were executed. So far all good.
But if I want to deploy these containers to another machine (using
/docker-entrypoint-initdb.d as a volume won’t work, since that machine won’t have access to my machine’s
So then I tried to extend the
FROM mysql:5.7 COPY ./*.sql /docker-entrypoint-initdb.d/
And do this in my
version: '2' services: db: build: context: . dockerfile: Dockerfile
However, when I then run
docker-compose build and
docker-compose up on the second machine and try to run my application, the
*.sql files in the current directory aren’t executed. None of my tables are created.
Why doesn’t my second approach work?
Ah, wait. I have asked the wrong question. The problem is not that the second approach doesn’t work, it is that the second approach doesn’t work when running it on the local docker-machine running in Virtualbox. The second approach actually works when I use it on my host machine (i.e. not using docker-machine).
One Solution collect form web for “Docker image extending the mysql image isn't running the initdb scripts”
I found the issue. The problem was that I thought
docker-compose rm -f destroyed any volumes attached to the containers, but I was wrong. So what I thought was the first up:ed containers were in fact using the database created by an earlier up. So the sql-files weren’t run because it wasn’t actually the first time the containers started. Duh. Thanks Ken for pointing me in the right direction.
Turns out that not even using
docker-compose rm -v removes the volumes. I had to list them with
docker volume ls and then remove them manually with
docker volume rm <volume>.