This post shows you how to install containerd as the container runtime in a Kubernetes cluster. I will also cover setting the cgroup driver for containerd to systemd, which is the preferred cgroup driver for Kubernetes.
In Kubernetes version 1.20 Docker was deprecated as a container runtime in a Kubernetes cluster and support was removed in 1.22. Kubernetes 1.26 requires that you use a runtime that conforms with the Container Runtime Interface (CRI).
Last week I purchased a shiny new MacBook Air with an M2 processor. After I got all the standard stuff up and running, I set out to learn how to run SQL Server containers on this new hardware. This post shows you how to run SQL Server on Apple Silicon using colima.
Colima is a container runtime that runs a Linux VM on your Mac. This Linux VM runs using the Virtualization framework hypervisor native in MacOS.
This post introduces you to the Pure Storage FlashArray OpenMetrics Exporter. It shows you how to get started quickly using Docker Compose so you can monitor your Pure Storage FlashArray environment.
I implemented this in Docker Compose since that handles all the implementation and configuration steps for you. It specifically configures Prometheus’ data source and a Grafana dashboard for monitoring.
Tip: If you’re building a persistent monitoring solution, I suggest using a dedicated Linux server running Docker Engine (Server) for Linux.
Yesterday in this post I described a method to correct permissions when upgrading a SQL Server 2017 container using Data Volumes to 2019’s non-root container on implementations that use the Moby or HyperKit VM. My friend Steve Jones’ on Twitter wondered if you could do this in one step by attaching a shell (bash) in the 2017 container prior to shutdown. Absolutely…let’s walk through that here in this post. I opted to use an intermediate container in the prior post out of an abundance of caution so that I was not changing permissions on the SQL Server instance directory and all of the data files while they were in use.
Recently Microsoft released a Non-Root SQL Server 2019 container and that’s the default if you’re pulling a new container image. But what if you’re using a 2017 container running as root and want to upgrade your system the SQL Server 2019 container…well something’s going to break. As you can see here, my friend Grant Fritchey came across this issue recently and asked for some help on Twitter’s #sqlhelp. This article describe a solution to getting things sorted and running again.
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.
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.
