Kellyn Pot’vin-Gorman has a set of tips for working with SQL Server on Linux using Docker:
Easy Download
Docker is available for Mac and Windows with a simple installation by the defaults.
- Download the correct installation for your OS type.
- Run the installer and keep all the defaults, choosing Linux containers, not Windows containers
- Reboot Windows workstations- Done.
Incredibly Simple MSSQL Container Install
Microsoft has done a great job of creating a very small, (maybe a bit too small, but we’ll get into that later…) image that can be used to create a running Linux container with SQL Server. This grants to student a great opportunity to simulate much of what it would be like to work on a real Linux server.
Click through to read the whole thing. And Kellyn’s not kidding about the image missing basic packages.
Rohit Bakhshi walks us through how to install Kafka on a Kubernetes cluster:
Now available on GitHub in developer preview are open-source Helm Chart deployment templates for Confluent Platform components. These templates enable developers to quickly provision Apache Kafka, Apache ZooKeeper, Confluent Schema Registry, Confluent REST Proxy, and Kafka Connect on Kubernetes, using official Confluent Platform Docker images.
Helm is an open-source packaging tool that helps you install applications and services on Kubernetes. Helm uses a packaging format called charts. A chart is a collection of YAML templates that describe a related set of Kubernetes resources.
For stateful components like Kafka and ZooKeeper, the Helm Charts use both StatefulSets to provide an identity to each pod in the form of an ordinal index, and Persistent Volumes that are always mounted for the pod. For stateless components, like REST Proxy, the Helm Charts utilize Deployments instead to provide an identity to each pod. Each component’s charts utilize Services to provide access to each pod.
Read on for more.
Andrew Pruski walks us through fixing a connection error:
I recently bought a Dell XPS 13 running Ubuntu 16.04 and ran into an issue when connecting SQL Operations Studio (version 0.31.4) to SQL 2017 CU9 running in a docker container. Other people seem to encountering this issue as well so am posting it so that it may be of some help to someone in the future.
The error generated was: –
System.Data.SqlClient.SqlException (0x80131904): A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 31)
The full error can be viewed here
Read on for the solution.
How do SQL Containers work with High Availability and Disaster Recovery?
Backups and data persistency are primary concerns here. You still need to care and feed for your SQL Server databases just as if they were platformed on a full operating system. For HA, Microsoft has some guidance on how to use Kubernetes to provide HA services to your SQL Server containers here. What I want you to think about when using containers for SQL Server is deploying a new container is VERY fast. We want to be able to persist the data and be able to stand up a new container and mount our data inside that container. Using this technique we can restore SQL Services very quickly with low RTO. That itself is an interesting way to provide HA services without any additional technologies.
Read on for more Q&A and check out Anthony’s presentation.
Fantastic, one build task created! How easy was that??
Let’s test by running: –
az acr build-task run --registry TestContainerRegistry01 --name buildsqlimageAnd the progress of the build task can be monitored: –
az acr build-task logs --registry TestContainerRegistry01
Andrew gives us the step-by-step details, so check it out.
Awesome! Our custom image is in our ACR!
But has it worked? Has it really? Oh ye of little faith…
I guess the only way to find out is to run a container! So let’s run a Azure Container Instance from our new image.
Spoilers: it worked.
Marek Masko has some commands which will help DBAs get familiar with Docker:
Stop container
To stop container:
- docker stop <container ID>
To stop all running containers:
docker stop $(docker ps -a -q)
Most of the commands are straightforward but it’s nice to have a reference guide.
The mainstay of my presentation material this year has been my deck on continuous integration, Docker and Jenkins. For people who have not had the chance to see this presentation or have seen it and wanted to get some more context around it, I have written this first in a series of posts. Much, in fact just about all of the material in this post features in other posts on my blog. The aim of this set of posts is to present the material in a more digestible manner for people who might not be fully fully familiar with Docker and Jenkins.
This first post will cover an introduction to Jenkins and use of the “Sidecar pattern” for deploying DACPACs to. Subsequent posts will expand on this to include:
- Multi branch build pipelines
- Parallelism
- Unit testing with tSQLt
- The management of database state via Docker volumes
Many people in the SQL Server community have displayed a great interest in containers, only to be left scratching their heads thinking “Well, that is nice, but what can I practically use them for ?”. In my humble opinion, spinning up SQL Server inside a container as a deployment target for a continuous integration pipeline, is one of the, if not the best ways to leverage SQL Server and Docker.
I’m looking forward to the rest of the series.
Andrew Pruski shows us how to deploy an Azure Container Instance:
The code should be fairly self explanatory. I’m using the username and password created earlier to access the ACR and am then spin up a container from the sqlserverlinuxagent:latest image. The container has 2 CPUs and 4GB of memory available to it and it will be listening on a public IP address on port 1433 (be very careful with this).
At the time of writing, the only option available for ip-address is public, hopefully further options will be available soon. I will update this blog if/when that happens.
Read on for a demo.
Container runtimes have security layers defined by Seccomp, Apparmor, kernel namespaces, cgroups, capabilities, and an unprivileged Linux user. All the layers don’t perfectly overlap, but a few do.
Let’s go over some of the ones that do overlap. I could do them all, but I would be here all day. The
mountsyscall is prevented by the default Apparmor profile, default Seccomp profile, andCAP_SYS_ADMIN. This is a neat example as it is literally three layers. Wow.Everyone’s favorite thing to complain about in containers or to prove that they know something is creating a fork bomb. Well this is actually easily preventable. With the PID cgroup you can set a max number of processes per container.
Interesting reading from an insider.
Kevin Feasel
2018-08-14
Containers, Linux
No Comment