1

Monday Coffee 2017-02-06

A lot’s been said about last week’s Gitlab outage so I’m not going to go over the details here but I do want to talk about one point that was when I was watching the guys fix the issue live on youtube.

A lot of the people making comments kept asking if the person who made the original mistake was going to be fired (and I mean a lot of people were asking). Finally one of the guys on the channel responded by saying that this wasn’t a personal mistake, it was a process failure and if the person who had made the original error hadn’t taken a backup before he started this work, they would not have been able to recover anything at all.

I did wonder about who was asking the question though and I came to the conclusion that it couldn’t have been anyone who’s worked in the tech industry for any sustained period time.

Show me a senior technical person who has never made a mistake causing an outage and I’ll show you a fibber

People do not get fired for making one mistake, could you imagine? Everyone that I know in tech has made at least one error causing an outage, others (like me) have made more than one. OK, yes, if this was the latest in a line of mistakes that that person had made at GitLab then maybe, but I doubt that it was.

It comes down to the age old adage, learn from your mistakes. Bet that guy at Gitlab won’t make that mistake again πŸ™‚

Have a good (mistake free) week.

0

Friday Reading 2017-02-03

2017 is trundling along now, this week I’ve been reading…

The GitLab incident report
We’ve all had that moment of “what did I just do??” Here’s how the guys at Gitlab responded to such a moment.

Linux OS Fundamentals for the SQL Admin
I don’t know how I missed this webinar but thankfully it’s been uploaded to youtube. Anthony Nocentino (b|t) goes over linux basics for us SQL DBAs.

How six lines of code + SQL Server can bring Deep Learning to ANY App
Rimma Nehme (t) goes through the what, why & how of using ML with SQL Server.

Stopping or Postponing an upgrade to SQL Database V12
Need to stay on v11 for now? Read this.

Hyper-V & powershell
Good starting reference for anyone using Hyper-V wanting to get into powershell

Have a good weekend!

3

SQL Containers and Networking

I recently talked with the guys over at SQL Data Partners on their podcast about SQL Server and containers. It was real good fun and I enjoyed chatting with Carlos Chacon (b|t) and Steve Stedman (b|t)about container technology and my experiences with it so far. Would definitely like to go back on (if they’ll have me πŸ™‚ )

Anyway, during the podcast one of the questions that came up was “How do containers interact with the network resources on the host server?”

To be honest, I wasn’t sure. So rather can try and give a half answer I said to the guys that I didn’t know and I’d have to come back to them.

Career Tip – when working with technology it’s always better to say you don’t know but will research and come back with an answer, than it is to try and blag your way through.

Once the podcast recording was over I started to think about it. Now there’s a bit of a clue in the code when you run a container:-

docker run -d -p 15798:1433 --name TestContainer ImageName

The -p 15798:1433 part of the code specifies which port on the host server maps to a port in the container. So there’s a NAT network in there somewhere?

I went off and did a bit of research and I found the following diagram which details how the containers interact with the host at the network layer:-

container_networks
Image source

In essence the container host’s network connectivity is extended to containers via a Hyper-V virtual switch which containers connect to via either the Host virtual NIC (this is for windows server containers) or a synthetic VM NIC (for Hyper-V containers).

The containers themselves can connect to the host network via different modes.The default is a NAT network that is created by the docker engine onto which container endpoints are automatically attached and this allows for port forwarding from the Host to the containers (which we see in the code earlier in this blog).

This can all be seen by running the following commands:-

To list the docker networks:-

docker network ls

dockernetworks
And there’s our NAT network.

To get the network adapters of a server:-

Get-NetAdapter

networkadapter
There’s the vNIC that the containers use to connect to the virtual switch (I’m running my docker engine in a VM, hence the other hyper-v NIC).

To get the virtual switches of a hyper-v host (remember some hyper-v elements are installed when the container feature is enabled):-

Get-VMSwitch

virtualswitch
And there’s the virtual switch.

So there’s how it works! Thanks for reading.

0

Monday Coffee 2017-01-30

Wow, what a week last week was.

The biggest thing that happened was that I got a session at SQL Saturday Iceland! They had loads of submissions and could only pick around 20 so very chuffed to have been one of those selected, cue smug face.

The event is on the 17th of March in Reykjavik and I’ll be talking about one of my favourite subjects, containers. I’ve pretty much written the presentation at this point but I’ve still got over a month to polish it. One thing I am going to do is get my demos down, I’ve got an Azure account so I’ll be building an environment there to use. However from the advice that I’ve been given I’ll also be recording videos of each of the demos so if the presentation technical gremlins raise their heads I won’t have to worry.

It feels like I’ve lived and breathed containers over the last year, it’s a subject that I feel passionate about. I don’t want to go over the top but I think that they’re a game changer, especially when it comes to Dev & Test environments.

Say you have 20 dev and test guys, all working with apps that reference databases in SQL Server. Now whenever a release goes out to production, those environments will also have to be updated to make sure that everyone is working on the same version. There’s tonnes of software out there to automate deployments but what if you could run a powershell script and bam! everyone is on the working on exactly the same version of the database(s) within minutes.

That’s what containers give you, the ability to quickly and easily spin up custom instances of SQL Server.

Another good example of when containers come into their own is patching. Microsoft now recommends applying every CU to your production environment. Are you really going to have to get all those other instances of SQL up to the same patch level as well? You should, no point in testing on one patch level of SQL and then deploying to another.

If your dev guys are using containers it’s no problem. They can blow away their old containers and deploy new ones at the higher patch level. Great stuff eh?

There are other advantages, hey there are disadvantages too but I’m not going to go into all of them here. You’ll have to come to my session πŸ™‚

Have a good week!

0

Friday Reading 2017-01-26

Is it really still January? It seems like this month is dragging on a bit. Anyway, this week I’ve been reading…

Nearly everything has changed for SQL Server Powershell
The Scripting Guys at Technet go over the changes to SQL Server Powershell.

Learning Redis the hard way
Interesting post about the problems that Trivago had implementing Redis in their production environment.

Hack attaching a SQL Server Database
Argenis Fernandez details a way of hack-attached database with NORECOVERY, handy bit of knowledge to have.

How to secure your passwords with Powershell
Shawn Melton goes through how to store a password to be used in powershell scripts

Did someone say SQL Server AUTOPILOT?
Garry Bargsley takes us through using the undocumented DBCC AUTOPILOT command, cool stuff

And finally, why it’s called a patch

Have a good weekend!