There was an interesting conversation on Twitter recently, between Grant Fritchey (blog | twitter), Kenneth Fisher (blog | twitter), Anthony E. Nocentino (blog | twitter), Vicky Harp (twitter), and me about containers and SQL Server. Here’s the summary tweet:
Already mentioned, you can use a persisted storage volume to keep your databases around (thanks @_randolph_west ). However, it does bring up an issue presented by containers. Data.
— Grant Fritchey (@GFritchey) May 29, 2019
The gist of containers is how easy they are to get going when testing new features of SQL Server, without going through the time-consuming process of installing it. On Windows Server, SQL Server can take anywhere from 20 to 60 minutes to install, and there are a lot of things that can go wrong. On Linux it takes less time, but this is a lot of effort if you’re just testing things out and want to keep your test environment clean.
With containers, SQL Server can be injected, inspected, detected, infected, neglected and selected (with apologies to Arlo Guthrie), without causing any untoward side-effects on the underlying host computer.
Where it gets interesting is that the SQL Server container is also where the database files are stored by default. I raised a point (which Grant and others have already noted in the past) that persisted storage volumes allow us to throw away a SQL Server container without throwing away the database files, provided that the container is set up to use that persisted storage.
For example, I can map the SQL Server container to a local directory on my Ubuntu or Windows Server, or — as is the case with Kubernetes — a second container can serve as the storage volume. SQL Server is then just a compute engine, or a “service” as Anthony points out in the Twitter thread.
As an added bonus, upgrading SQL Server has never been easier: pull the latest container image from the Microsoft Container Registry, stop the SQL Server container, then start up a new one pointing at the same persisted storage volume.
This is a new world we’re living in, and containers are changing how we think about database management. SQL Server becomes an endpoint to access the data. Our customers and end-users don’t have to know where the data is located, as long as SQL Server does.
Which is where you, the DBA, come in. Provided that you know where the container is pointing, that’s all that matters.
Share your thoughts in the comments below.
One maybe gotcha. You have to like the options chosen for the image build. Eg no ssis iirc. Course you could modfy the build and save as a new image. Not hard with a compose file.