none
Dockerfile to build SQL Server image, question on volume mapping RRS feed

  • Question

  • Just got a SQL Server docker image going... with a lot of help from various posts on the forum. Planning to try this in an automated test environment within the next 1-2 months.

     It configures SQL Server Express to listen on static port 1433 and supports a runtime choice of data / backups stored internal-to-container or on a host volume

    Here's a write-up: Blog post: Dockerfile to create SQL Server Express windows container image

    Github dockerfile source

    Curious if anyone has any thoughts on volume mapping and when it would be most appropriate, in particular for databases - I am using volume mapping with my scheme, but there are some limitations as of TP4 including:

    • dockerfile VOLUME command not yet supported
    • mapping a volume to an existing folder in the container does not work

    I'm currently planning to use volume mapping (or not) as follows:

    • Mapping: For persistent data environments (like ad-hoc data entry test environments) - more reliable, data and backups are exposed to host volume and thus don't die with container
    • Not mapping (internal to container): For bootstrap-data test environments - simpler, everything is cleaned up


    Monday, January 4, 2016 4:05 AM

All replies

  • Firstly awesome write up! - if your so inclined you can also contribute this directly to our documentation (as a pier of https://msdn.microsoft.com/en-us/virtualization/windowscontainers/examples/dotnet35 or to our sample section in GitHub https://github.com/Microsoft/Virtualization-Documentation/tree/live/windows-server-container-samples) - totally up to you but would love to see those grow with community contributions...

    I'll look into the VOLUME keyword in the dockerfile to see what's up there.  I look at features like Volumes in the same light as tools - there's a lots of ways you can use them, some of those uses are good, some are less recommended by the manufacture but work quite well and even lead towards new tools being built.  One of the major value propositions for volumes is managing persistent data - so for example mounting in the database/transactions files to containers.  Using SQL as a specific example a scenario we heard from the Azure DB team was that they wanted to use containers for upgrading the SQL build - they would role a new container image out to the hosts, stop the running containers and start new ones using the updated build, the database files would be mapped in via volumes.


    -Taylor

    Friday, January 15, 2016 6:46 PM