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.

  • Is there a way to add only changed files to a docker image as a new layer - without resorting to docker commit?
  • Understanding a simple dockerfile of postgresql
  • Install SCP in Docker container
  • Installing new gentoo kernel in docker container
  • cannot reach web app from docker host (not docker-machine)
  • Running multiple instances of an image with docker-compose fails
  • 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).

  • Attempting to access USB device from Docker in Windows
  • Is Docker ARG allowed within CMD instrcution
  • Functional tests with vagrant in docker
  • PostgreSQL Docker installation how to setup initial database
  • How can I connect celery container to rabbitmq container when using --net=host?
  • PyMongo - UserNotFound: Could not find user authenticated@admin
  • 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.