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, and
CAP_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.
I want to show the two modules running against a number of SQL Versions so I have installed
- 2 Domain Controllers
- 2 SQL 2017 instances on Windows 2016 with an Availability Group and WideWorldImporters database
- 1 Windows 2016 jump box with all the programmes I need
- 1 Windows 2016 with containers
using a VSTS build and this set of ARM templates and scripts
I wanted to create containers running SQL2017, SQL2016, SQL2014 and SQL2012 and restore versions of the AdventureWorks database onto each one.
Rob shows how to do this all via Powershell so you can automate the process.
I’m going to push my custom dbafromthecold/sqlserverlinuxagent image. It’s a public image so if you want to use it, just run: –docker pull dbafromthecold/sqlserverlinuxagent:latest
So similar to pushing to the Docker hub, we need to tag the image with the login server name that we retrieved a couple of commands ago and the name of the image: –docker tag dbafromthecold/sqlserverlinuxagent apcontainerregistry01.azurecr.io/sqlserverlinuxagent:latest
Read on for a full example.
The April 2018 update for Windows brought a few cool things but the best one (imho) is that now we can now connect to Windows containers locally using ‘localhost’ and the port specified upon container runtime.
Let’s have a look at how this works.
Click through for a walkthrough.
A few weeks ago I was presenting at SQL Saturday Raleigh and was asked a question that I didn’t know the answer to.
The question was, “can you change the location of named volumes in docker?”
This is one of the things that I love about presenting, being asked questions that I don’t know the answer to. They give me something to go away and investigate (many thanks to Dave Walden (b|t) for his help!)
Read on for Andrew’s answer.
So, how do you do it when running SQL Server in Azure Container Services?
Well there’s a couple of options available.
The first one is to change the port that SQL is listening on in the container, open that port on the container, and direct to that port from the service.
The second one is to leave SQL Server listening on the default port and direct a non-default port to port 1433 from the service.
Read on to see Andrew try out both of these methods.
Data scientists are not always equipped with the requisite engineering skills to deploy robust code to a production job execution and scheduling system. Yet, forcing reliance on data platform engineers will impede the scientists’ autonomy. If only there was another way.
Today we’re excited to introduce Flotilla, our latest open source project. Flotilla is a human friendly service for task execution. It allows you to focus on the work you’re doing rather than how to do it. In other words, Flotilla takes the struggle out of defining and running containerized jobs.
It looks like an interesting service.
Windows Server version 1709 brings the following important improvements that developers can take advantage of with the updated container images.
First of all, the microsoft/windowsservercore image underneath SQL shrunk by more than 2GB, so the SQL Server images are also 2GB smaller.
If you want to store your databases on remote storage, you can now by using global SMB mounts (New-SMBGlobalMapping) along with a docker volume (docker run -v c:\shared:c:\data microsoft/mssql-express-…).
Seems like a useful improvement.
Now, if this is the first time working with Kubernetes you won’t have to perform the next couple of steps but just to confirm, run the following: –kubectl config current-context
If your shell cannot find the kubectl command, add
to your PATH environment variable and restart your shell.
If the command outputs anything other than docker-for-desktop you will need to switch to the desktop cluster.
Click through to see how to set this up.