Search code examples
mysqldockerdocker-composedocker-machine

Docker image extending the mysql image isn't running the initdb scripts

Documentation for the mysql docker image says:

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.

So at first I did this in my docker-compose.yml:

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-machine), mounting /docker-entrypoint-initdb.d as a volume won't work, since that machine won't have access to my machine's . directory.

So then I tried to extend the mysql:5.7 image:

FROM mysql:5.7
COPY ./*.sql /docker-entrypoint-initdb.d/

And do this in my docker-compose.yml

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?

EDIT: 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).

Solution

  • 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>.