Comments
3 comments
-
Hi Tony
I'll share some of our findings and ways of working
- We currently use Docker with Kubernetes for our orchestrations for most of our new apps.
- We now only use our containers for apps and services, we previously had Postgres running on a container, we then moved on to having SQL running on a container in CentOS, but later abandoned it to use the Azure management SQL instances. We just couldn't get the performance and scale we needed using our database inside containers, granted we didn't have much experience with it at the time (2 - 3 years back)
- Our databases are generally a couple of Terabytes. But most of it is read data.
Hope this helps a bit, let me know if you need to know more -
@TheMatelix: many thanks for your response (and sorry for taking a while to get back to you). So I suppose part of what I wanted to understand was, if you need 5 (say) development/test copies of what (in production) is a multi-terabyte database, what's your process for setting up the SQL Server instances and databases for dev and test work? Does it involve use of containers? I'm assuming not, from what you say above.
-
I've been lurking here for a while since I have some strong opinions and didn't want to sway the traffic. https://robrich.org/slides/database-devops-with-containers/#/ (video at
https://www.youtube.com/watch?v=GlmssURxgFE) is the presentation I put together some time ago. SQL Clone is great at quickly provisioning things and controlling distribution (and reclamation) of those things, but a container with an embedded copy of the database (anonymized, sanitized, and shrunk to meet the need) is more native to the developer mindset. My approach: a job kicks off each night building and publishing containers for developers, dev/test environment, and pre-prod (because each needs different levels of anonymized, sanitized, and shrunk). Developers have a "real" database by running `docker-compose up`, they can install and destroy it and unstuck themselves without holding a DBA's hand, and they can update it when they're ready, running the SQL Change Automation migrations as soon as they pop it open. "The build" can start with a fresh copy, practice the next prod deploy using SCA scripts, and fail the build if the prod deploy wouldn't work on the real data. And best of all, as @grumpydba says, "Your production backup is only as good as the last time you restored it." I restore mine every night.
I'd love to do a webinar on this at an opportune time.
Add comment
Please sign in to leave a comment.
Hello Friends!
How many of you are actively using Containers for your development and test work for your applications and/or databases? I'd love to hear about the sorts of apps and services you're running in containers, and what they do. If you're happy to chat to me about this, reply below.
If you need five copies of a big database to run parallel tests, reproducibly, then using containers is probably more painful than using a tool like SQL Clone. How would you like to see a tool like SQL Clone working with containers?
Many thanks!
Tony.