As many of you will know, the world of ops and infrastructure is a matter of read the manual, try, get it wrong, repeat cycle.  That's great if the thing you are working with is a physical piece of hardware with clear instructions that do work.  Software Emulated hardware can have some interesting side effects as I soon found out when using Docker containers to host MySQL and Glassfish.

MySql

The official download from hub.docker does have very clear instructions, but me being me, I didn't read the writing on the tin, especially the section "Using a custom MySQL configuration".  Oh, and more importantly this section -

Initializing a fresh instance

When a container is started for the first time, a new database with the specified name will be created and initialized with the provided configuration variables. Furthermore, it will execute files with extensions .sh, .sql and .sql.gz that are found in /docker-entrypoint-initdb.d. Files will be executed in alphabetical order. You can easily populate your mysql services by mounting a SQL dump into that directory and provide custom images with contributed data. SQL files will be imported by default to the database specified by the MYSQL_DATABASE variable.

Docker option Clean up (–rm)

By default a container’s file system persists even after the container exits. This makes debugging a lot easier (since you can inspect the final state) and you retain all your data by default. But if you are running short-term foreground processes, these container file systems can really pile up. If instead you’d like Docker to automatically clean up the container and remove the file system when the container exits, you can add the --rm flag:

--rm=false: Automatically remove the container when it exits (incompatible with -d)

Note: When you set the --rm flag, Docker also removes the volumes associated with the container when the container is removed. This is similar to running docker rm -v my-container. Only volumes that are specified without a name are removed. For example, withdocker run --rm -v /foo -v awesome:/bar busybox top, the volume for /foo will be removed, but the volume for /bar will not. Volumes inherited via --volumes-from will be removed with the same logic – if the original volume was specified with a name it will not be removed.

Mounting a Windows directory 

None of the examples in the docker help seem to work but I found a strange setup that does wok, I used the following command

docker run --name ubuntu-run -it -v //c/Users/Selvyn/demo/vm_share:/var/lib/host.demo ubuntu

The key seems to be in the //c/Users/Selvyn which is C:\Users\Selvyn.  This can be mounted, but anything outside of C:\Users\Selvyn won't work???  I suspect it is something to do with privileges.