SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Containers and Databases


Containers and Databases

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)

Group: Administrators
Points: 109549 Visits: 19358
Comments posted to this topic are about the item Containers and Databases

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Gary Varga
Gary Varga
SSC-Insane
SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)

Group: General Forum Members
Points: 23175 Visits: 6534
I am in the "containers are stateless" camp so am also looking for enlightenment here.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Dave Poole
Dave Poole
SSChampion
SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)

Group: General Forum Members
Points: 13207 Visits: 3386
I'm using Apache Spark more and more and we are using it to join and query data from many different sources. It makes sense to have a compute engine in a container but the data storage has to be state-full. I think we'd need a radical redesign of a database engine to be able to use containers in a meaningful way in production.

LinkedIn Profile
www.simple-talk.com
call.copse
call.copse
SSCarpal Tunnel
SSCarpal Tunnel (5K reputation)SSCarpal Tunnel (5K reputation)SSCarpal Tunnel (5K reputation)SSCarpal Tunnel (5K reputation)SSCarpal Tunnel (5K reputation)SSCarpal Tunnel (5K reputation)SSCarpal Tunnel (5K reputation)SSCarpal Tunnel (5K reputation)

Group: General Forum Members
Points: 4978 Visits: 1983
I'm afraid I don't get it, but I have yet to give containers a go at all so it's not surprising. Awaiting enlightenment!
Ryan Lambert
Ryan Lambert
SSC Journeyman
SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)

Group: General Forum Members
Points: 98 Visits: 59
I have no experience with using MS SQL Server in containers, but I have used PostgreSQL in containers using Docker for nearly two years now. I wrote a post about my initial impressions of that experience here, if you're interested. For us, at the time, it was absolutely the correct choice. While we are still using Postgres in Docker, I'm starting to consider un-doing that change and putting it back on the base servers.

We realized three major benefits by using containers for databases:

1) It helps ensure development databases have the same level of security and configuration applied as production (accidental "Oops" protection)
2) It made it very easy to migrate one database while leaving the rest alone, since each database has a dedicated container
3) It enabled a very easy method to create automated tests of database restorations

In the past 6 months we have fully embraced Ansible for automating the deployment/configuration of servers. With this in place, a lot of the benefits I found using Docker can be realized using Ansible. Containers were a perfect solution for a tiny startup trying to keep resources at a bare minimum, but we've outgrown that stage now.

We will continue to use containers for deploying web applications, VPN services, etc., but will likely stop using them for databases in the next 6 months. I don't think that using containers is inherently a problem for a database server, but at this point I don't see it as a value-add either.

I hope others have some feedback on this topic too, I am very interested in other experiences in this realm!
jasona.work
jasona.work
SSCertifiable
SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)

Group: General Forum Members
Points: 7491 Visits: 12316
I've not played with containers yet, but the concept sounds interesting.

The use cases for development / QA types systems is fairly easy to see, but for a production environment I'm having a hard time coming up with a case where it would be worth the time / effort to get things set up. About the only situation I've been able to think of would be some sort of reporting type application.
Set it up so that every morning, or whenever, it creates a SQL container with a blank DB, pulls in the required data from the production SQL instance on another server, then holds the data for the reporting application until the user is done (could be all day, could be a couple hours, whatever.) The user would be able to generate reports, even if not connected to the network, without impacting the production data. The user could even modify the data, again without impacting the production data (although if they generate reports and play with the data on a production instance, you might need to re-think your process anyways...)

But even there, why not just stand up an Express instance on their device? Less headache, and probably about as much work initially...
Steve Jones
Steve Jones
SSC Guru
SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)

Group: Administrators
Points: 109549 Visits: 19358
rustprooflabs - Tuesday, February 28, 2017 6:12 AM
I have no experience with using MS SQL Server in containers, but I have used PostgreSQL in containers using Docker for nearly two years now. I wrote a post about my initial impressions of that experience here, if you're interested. For us, at the time, it was absolutely the correct choice. While we are still using Postgres in Docker, I'm starting to consider un-doing that change and putting it back on the base servers.

We realized three major benefits by using containers for databases:

1) It helps ensure development databases have the same level of security and configuration applied as production (accidental "Oops" protection)
2) It made it very easy to migrate one database while leaving the rest alone, since each database has a dedicated container
3) It enabled a very easy method to create automated tests of database restorations

In the past 6 months we have fully embraced Ansible for automating the deployment/configuration of servers. With this in place, a lot of the benefits I found using Docker can be realized using Ansible. Containers were a perfect solution for a tiny startup trying to keep resources at a bare minimum, but we've outgrown that stage now.

We will continue to use containers for deploying web applications, VPN services, etc., but will likely stop using them for databases in the next 6 months. I don't think that using containers is inherently a problem for a database server, but at this point I don't see it as a value-add either.

I hope others have some feedback on this topic too, I am very interested in other experiences in this realm!

I'd love to see you write more on each of these topics, pros, cons, etc. I'm not sure how much overlap there is with the PostgreSQL/SQL Server paradigms for development and administration, but I'd like to learn more.


Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
pauls 72822
pauls 72822
SSC-Enthusiastic
SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)

Group: General Forum Members
Points: 129 Visits: 61
You raise good questions Steve, a couple of points of clarification should help. First, let's clarify what are "SQL Server containers?" SQL Server containers are simply SQL Server instances created and managed with Docker commands and APIs. They have a few added features specific to being a "container," such as a higher level of process and user isolation, and resource governance via the Docker API, and a private file system. On the other hand they are normal full featured SQL Server instance that operates on the Windows host, and interoperate with all normal SQL Server tools. Databases can be attached on the local host, or on network or SAN attached storage, and data persistence is no different than other SQL Server instances. Containers add a private file system, which is a new option and provides a simple non-persistent option for working with data that is suited for dev/QA use. But, there is nothing otherwise to distinguish Windocks SQL Server containers from other SQL Server instances installed on the host. You have the same registry settings, the same features and functions, the same performance. Containres work with all normal SQL Server tools, and are comprised of the same sqlserver.exe and DLL's.

With Windocks SQL Server containers you get the best of both worlds . . . fast instance creation and great support for dev/QA use, as well as a complete, full featured SQL Server environment. SQL Server containers support VSS and existing backup systems too.

Do "containers" add value in production environments? While a container instance can be managed and patched just as any instance, the container "adds value" in production only to the extent that containers are a common infrastructure in a Continuous Integration and Delivery strategy.. In time I believe there will be interest in use of containers for production for "continuous delivery" and rollback strategies, as DevOps and CI processes are adopted. But, today, the particular value of containers is realized in improved support of Dev and QA teams.

I hope this helps . . . I think this is a great discussion.
pauls 72822
pauls 72822
SSC-Enthusiastic
SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)SSC-Enthusiastic (129 reputation)

Group: General Forum Members
Points: 129 Visits: 61
One additional comment that I think adds to this discussion. To the extent you believe that Docker containers represent an industry-wide strategy, and certainly Microsoft seems to emphasize Docker containers for their vNext release . . . I would argue that is another reason for exploring these SQL Server containers. As SQL Server professionals we need to be aware of larger trends, and consider that there is an entire industry innovating on containers, and it may be important in the future to have SQL Server strategies that align with a container oriented world.
Steve Jones
Steve Jones
SSC Guru
SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)SSC Guru (109K reputation)

Group: Administrators
Points: 109549 Visits: 19358
Thanks, Paul. Appreciate the comments.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search