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.

  • How to check if docker daemon is running?
  • Tensorflow on Docker: How to save the work on Jupyter notebook?
  • Update & Upgrade Docker distribution on Windows
  • Is there a way to add only changed files to a docker image as a new layer - without resorting to docker commit?
  • InsecurePlatformWarning when building Docker image
  • Connection reset: set up Oracle SSL in docker
  • 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).

  • Docker Volume another disk
  • Phalcon doesnt work properly on nginx
  • Docker: Give container user write access to host directory
  • Dockerfile for on and off proxy
  • docker on windows not working
  • Seeing protocol error with ln for mounted volume inside docker
  • 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>.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.