Issue : Failed to pull image : rpc error: code = 2 desc = unknown blob

Introduction

When you are deploying an image, which is hosted on a private registry, to a kubernetes (k8s) cluster with windows nodes… Then you might get the following error ;

Failed to pull image “kvaes.azurecr.io/kvaes2017:v1“: rpc error: code = 2 desc = unknown blob

Error syncing pod, skipping: failed to “StartContainer” for “private-reg-container” with ErrImagePull: “rpc error: code = 2 desc = unknown blob”

 

Context

So what did my setup look like?

• Orchestrator : Kubernetes for Windows (Azure Container Service)
• Registry : Private (Azure Container Registry)
• Image : Windows Nano Based

 

Technical Check

Let’s deploy two pods…

The first I’ll deploy via yaml, which is basically the example from the kubernetes docs on pulling an image from a private repo…

Now the second one is an adaptation of the example flow from the Azure Container Service documentation ;

Now let’s see how that one went…

The first one failed, and the second one passed! What was the difference?

 "nodeSelector": {
    "beta.kubernetes.io/os": "windows"
    }

Apparently this one forces the switch to “windows container mode” (or something like that…). As it seems very similar to the following thread…

 

TL;DR

When deploying windows containers to a kubernetes cluster. be sure to the set the “nodeSelector” or you might end up with errors on pulling the image.

How to try out the experimental windows 2016 support in the Rancher 1.3.0 release candidate?

Introduction

Yesterday Rancher commented on my github request for windows support ;

Tested with rancher-server version – v1.3.0-rc1 with catalog “library” set to vnext branch in https://github.com/rancher/rancher-catalog

Able to add “Windows Server 2016 Standard Evaluation” hosts successfully to rancher environment with orchestration set to “windows”.

Able to launch containers in “nat” network and “transparent” network.

@kvaes , Windows 2016 support will be available as experimental feature in rancher-server 1.3.0 release.

Great news! Let’s take it out for a spin… 😀

 

Rancher Host

Installing the host(s) is the same as any other time…  Though the host will still be a Linux machine off course ;

sudo docker run -d –restart=unless-stopped -p 8080:8080 rancher/server:v1.3.0-rc1

Though notice that I specified the v1.3.0-rc1 tag… And let the system do its magic!

(Update : For the stable, release you can omit the -rc1 part!)

Note ; Be aware that this is an early release candidate. Do not use this for your production! There is for instance a bug with the GUI, where the “Auto”-theme is malfunctioning. So switch to light or dark to get that one fixed. 😉

Using Visual Studio Team Services & Rancher for continuous deployment for your docker containers

Introduction

Today I’m going to show you how you can leverage the combination of Visual Studio Team Services & Rancher to kickstart your continuous deployment of your docker containers. So every time we update our containers, we want a smooth upgrade process on our container setup. What do you think? Let’s see what this can look like?

 

The flow

The scenario of today will have the following flow ;

• We’ll use a git(hub) repository to store our docker-compose & rancher-compose file that powers our solution.
• Next up, we’ll be using VSTS as the orchestrator for your CI/CD-pipeline.
• Rancher is our preferred container workflow / management tool, and we’ll be using the “rancher-compose” on our VSTS build agent.

Testdriving the Azure Container Registry Service with Rancher

Introduction

A few weeks ago there was an announcement that the Azure Container Registry has went into public preview. That is great to hear! So let’s test drive it today… We’re going to set up the registry in Azure. Push a container image into it. And pull/run it via rancher towards our cluster. (To do this, I basically followed a lot of the following guide.

 

Setting up the Azure Container Registry (ACR)

So start by searching for the “Container Registry” in the marketplace ;

Running the Powershell AzureRM module in a Linux Docker container

Introduction

Given my affinity towards containers & azure, it will not come as a surprise when I say I published a small container from which you can launch AzureRM commands!

 

Repositories

• Docker Hub (build) : https://hub.docker.com/r/kvaes/docker-powershell-azure/
• GitHub (source) : https://github.com/kvaes/docker-powershell-azure

 

Getting Started

First of all, we’ll launch the container ;

docker run -ti kvaes/docker-powershell-azure

Next up you do the device login ;

Login-AzureRmAccount

And check out which commands are available…

get-command *azure*”

As you notice, the current preview release is quite limited in available commands. Expect more to be added over time off course!

 

TL;DR

• Powershell on Linux works
• The AzureRM module is in preview, and limited in commands
• It all works inside a container too! 😀

Deploying OMS for Docker via Rancher

Introduction
Today we’ll be deploying Microsoft Operations Management Suite (OMS) for Docker via Rancher… Sound cool? It is! Basically we’re going to do the following guide and add Rancher to the twist.

For those unfamiliar with the Microsoft offering and more knowledgeable  in the OSS community. Imaging OMS as being the Microsoft counterpart of a typical ELK stack. The advantage is that it’s managed and that there are already a lot of integrations possible.

Behind the scenes : Creating a Microsoft SQL Server as a Windows / Docker Container

Introduction

This post is the first of a series in my journey to build a flexible / production ready MSSQL windows container. I thought this would have been a breeze with my experience on Docker for Linux, though I must admit running into multiple issues… This post will not provide you with a working container, as I’m still developing that one.

Once I deem it as production ready, it’ll be released to the community to be used freely. Though I want it to meet my personal quality standards, being that it should be stable and flexible enough to run in production mode.

 

Blueprint Braindump

For those who have been following me for a while (real life, twitter, yammer, linkedin, …); you probably know I’ve been preaching about MSSQL as a container for way too long. My personal vision was to have a MSSQL run in a container. The data should be located outside of the container, which would enable a (more/relative) easy path for the changes you want to implement.

So where volume mapping would be an option… I was also considering an integration with an external storage service. As an Azure fanatic, I (also) want to leverage the option of storing my data/temp files on Azure storage. This would provide my with total host independent storage persistence on Docker! For those who have been playing with Docker for a while, this is truly a powerful combination.

As a long term goal, I would like to see this running on a “serverless” platform. From what I have seen in the market, this is still an unreachable utopia/Walhalla at this point. So my current objective in that areas is to investigate the option of deploying this setup on a Service Fabric or to leverage the power of Rancher with Windows containers.