I’m very pleased to announce that I will be speaking at PASS Summit 2019! This is my second time speaking at PASS Summit and I’m very excited to be doing so! What’s more, is I get to help blaze new ground with an emerging technology,** Kubernetes and how to run SQL Server in Kubernetes**! My session is “Inside Kubernetes – An Architectural Deep Dive” if you’re a just getting started in the container space and want to learn how Kubernetes works and dive into how to deploy SQL Server in Kubernetes this is the session for you.

Let’s get you started on your Kubernetes journey with installing Kubernetes and creating a cluster in virtual machines. Kubernetes is a distributed system, you will be creating a cluster which will have a master node that is in charge of all operations in your cluster. In this walkthrough we’ll create three workers which will run our applications. This cluster topology is, by no means, production ready. If you’re looking for production cluster builds check out Kubernetes documentation.

People often ask me what’s the number one thing to look out for when running SQL Server on Kubernetes…the answer is memory settings. In this post, we’re going to dig into why you need to configure resource limits in your SQL Server’s Pod Spec when running SQL Server workloads in Kubernetes. I’m running these demos in Azure Kubernetes Service (AKS), but these concepts apply to any SQL Server environment running in Kubernetes.

Recently I needed to write a PowerShell script that could build a backup set from a collection of backups stored in Azure Blob Storage without any backup history available from MSDB. And as with all things SQL Server and PowerShell related I went straight to dbatools.io to see if Restore-DbaDatabase was up to the task…and of course, it is…let’s talk about how I solved this challenge. When restoring from Azure Blob, the main challenge you have is accessing the blobs and building a backup set.

When working with SQL Server running containers the Error Log is written to standard out. Kubernetes will expose that information to you via kubectl. Let’s check out how it works. If we start up a Pod running SQL Server and grab the Pod name kubectl get pods NAME READY STATUS RESTARTS AGE mssql-deployment-56d8dbb7b7-hrqwj 1/1 Running 0 22m We can use follow flag and that will continuously write the error log to your console, similar to using tail with the -f option.

My new course “Managing Kubernetes Controllers and Deployments” in now available on Pluralsight here! Check out the trailer here or if you want to dive right in go here! This course offers practical tips from my experiences managing Kubernetes Clusters and workloads for Centino Systems clients. <div> </div> <p> This course targets IT professionals that design and maintain Kubernetes and container based solutions.The course can be used by both the IT pro learning new skills and the system administrator or developer preparing for using Kubernetes both on premises and in the Cloud.

Pre-conference Workshop at SQLSaturday Denver I’m proud to announce that I will be be presenting an all day pre-conference workshop at SQL Saturday Denver on October 11th 2019! This one won’t let you down! The workshop is **“Kubernetes Zero to Hero – Installation, Configuration, and Application Deployment” ** <p> <strong>Here’s the abstract for the workshop</strong> </p> </div> <div> <blockquote> <p> Modern application deployment needs to be fast and consistent to keep up with business objectives and Kubernetes is quickly becoming the standard for deploying container-based applications, fast.

So, if you’ve been following my blog you know my love for internals. Well, I needed to find out exactly how something worked at the startup of a SQL Server process running inside a docker container and my primary tool for this is strace, well how do you run strace against processes running in a container? I hadn’t done this before and needed to figure this out…so let’s go through how I pulled this off.

A quick post about pulling docker containers (this applies to docker run too)…when specifying the container image, the container image name and tag are case sensitive. We’re not going to discuss how much time troubleshooting it too me to figure this out…but let’s just say it’s more than I care to admit publicly. In this code you can see I’m specifying the following image and tag server:2019-rc1-ubuntu (notice the lowercase rc in the tag)

In the first two posts in this series we discussed the need for data persistency in containers then we discussed where the data actually lives on our systems. Now let’s look at specifying the location of the data on the underlying file system of the base OS. This is the third post in a three part series on Persisting SQL Server Data in Docker Containers. The first post introducing Docker Volumes is here.