Andrew Pruski shows how to set up and use the Kubernetes dashboard inside Azure Container Services:
But not only can existing objects be viewed, new ones can be created.
In my last post I created a single pod running SQL Server, I want to move on from that as you’d generally never just deploy one pod. Instead you would create what’s called a deployment.
The dashboard makes it really simple to create deployments. Just click Deployments on the right-hand side menu and fill out the details:
Check it out; this looks like a good way of managing Kubernetes on the small, or getting an idea of what it can do.
Looks pretty good to me! SQL is up and has accepted the config value within our yaml file to change the SA password. But how are we going to connect to it?
What we need to do now is define a Kubernetes service. A service is a level of abstraction over pods to allow connections to the containers within the pods regardless of where the pod is located in the cluster. So let’s setup a service.
Andrew does a good job of taking us through the process step by step.
James Anderson shows an easy way of creating a custom Docker image which relies on some other image:
The FROM statement declares that we want to lay some instructions on top of the microsoft/mssql-server-windows image. The beauty of this approach is that when I pull down a new version of the microsoft/mssql-server-windows image, my image will be updated too. The microsoft/mssql-server-windows Dockerfile does the same thing with the microsoft/windowsservercore image.
The rest of the Dockerfile sets some meta data, downloads the installer and adds the Advanced Analytics feature.
SSIS, SSAS, SSRS or any other SQL Server feature could be added to a containerised SQL Server deployment in the same way.
With this approach, you do run the risk that upstream changes will break your image, but for something like this, it’s a very useful approach.
Andrew Pruski shows one scenario where Docker on Windows is better than Docker on Linux:
One of the (if not the) main benefits of working with SQL in a container is that you can create a custom image to build container from that has all of your development databases available as soon as the container comes online.
This is really simple to do with Windows containers. Say I want to attach DatabaseA that has one data file (DatabaseA.mdf) and a log file (DatabaseA_log.ldf): –
ENV attach_dbs="[{'dbName':'DatabaseA','dbFiles':['C:\\SQLServer\\DatabaseA.mdf','C:\\SQLServer\\DatabaseA_log.ldf']}]"Nice and simple! One line of code and any containers spun up from the image this dockerfile creates will have DatabaseA ready to go.
However this functionality is not available when working with Linux containers. Currently you cannot use an environment variable to attach a database to a SQL instance running in a Linux container.
Read on to see what you can do if you’re using a Linux container.
Andrew Pruski has a script on GitHub:
So I’ve created a repository on GitHub that pulls together the code from Docker to install the Community Edition and the code from Microsoft to install the SQL command line tools.
The steps it performs are: –
Installs the Docker Community Edition
Installs the SQL Server command line tools
Pulls the latest SQL Server on Linux image from the Docker Hub
Read on for more details and some limitations.
Andrew Pruski helps out those of us who can’t seem to let our containers go:
One of the problems that I’ve encountered since moving my Dev/QA departments to using SQL Server within containers is that the host machine is now a single point of failure.
Now there’s a whole bunch of posts I could write about this but the one point I want to bring up now is…having to start up all the containers after patching the host.
I know, I know…technically I shouldn’t bother. After patching and bouncing the host, the containers should all be blown away and new ones deployed. But this is the real world and sometimes people want to retain the container(s) that they’re working with.
It’s pretty easy to set up a restart policy, as Andrew shows.
Andrew Pruski explains how to use Watchtower to keep your SQL Server Docker containers up to date:
The databases that I store in my container image are updated on a weekly basis and currently, the process to update our containers is manual. Once the updated image has been created, the existing running containers are dropped and new ones created from the updated image.
But what if we could automatically refresh our containers with the updated image? If we could do that then the only process that’s manual is updating the image. We would no longer have to worry about any containers running SQL instances with databases that are out of date.
Luckily, there’s a way to do this and it’s accessible via an image on the Docker Hub called Watchtower. What Watchtower does is monitor the Docker Hub and if there’s an update to an image it will automatically refresh all running containers that are on the same host.
Read on for a step-by-step solution.
Andrew Pruski shows how to run Linux-based Docker containers on Windows:
This post is a step-by-step guide to getting Linux containers running on your Windows 10 machine. The first thing to do is install the Docker Engine.
Installing Docker on Windows 10 is different than installing on Windows Server 2016, you’ll need to grab the Community Edition installer from the Docker Store.
Once installed, you’ll then need to switch the engine from Windows Container to Linux Containers by right-clicking the Docker icon in the taskbar and selecting “Switch to Linux Containers…”
Andrew walks us through step by step, so check it out.
Andrew Pruski shows how to use Docker compose to build multiple containers simultaneously:
As SQL Server people we’re only going to be interested in one application but that doesn’t mean we can’t use compose to our advantage.
What I’m going to do is go through the steps to spin up 5 containers running SQL Server, all listening on different ports with different sa passwords.
Bit of prep before we run any commands. I’m going to create a couple of folders on my C:\ drive that’ll hold the compose and dockerfiles: –
Andrew also explains a couple of common errors as he walks us through the process.
Andrew Pruski gives us a third option for persisting SQL Server database files in Docker containers:
Last week in Part Two I went through how to create named volumes and map them to containers in order to persist data.
However, there is also another option available in the form of data volume containers.
The idea here is that create we a volume in a container and then mount that volume into another container. Confused? Yeah, me too but best to learn by doing so let’s run through how to use these things now.
Read through for the step-by-step description.
Kevin Feasel
2017-09-08
Cloud, Containers
No Comment