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”
So what did my setup look like?
- Orchestrator : Kubernetes for Windows (Azure Container Service)
- Registry : Private (Azure Container Registry)
- Image : Windows Nano Based
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?
Apparently this one forces the switch to “windows container mode” (or something like that…). As it seems very similar to the following thread…
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.
About two weeks ago the public preview was announced for an Azure-to-Azure site recovery service (DR). This was a highly anticipated service to me. So I’m glad it was announced! Today’s post will be on doing a quick setup of the service to get an insight into the look & feel.
What will we be doing today? We’re going to replicate a machine from “West Europe” to “South UK”.
What will the flow be? We’ll have a “Site Recovery Vault” in the target destination. Why? This to ensure that we can leverage the service when the source region went offline. In the source region, we’ll have our VM + Storage Account / Disks, but also a storage account used for caching. All changes make to the disk, will be stored in that cache. On the target side, we’ll have a storage account where a replica (and retention points) of the VM will be kept. Sound pretty easy? Let’s find out…
Continue reading “Testdriving the Azure-to-Azure (A2A) variant of the Azure Site Recovery (ASR) services”
During the weekend I saw the following tweet passing by …
Apparently, a hosting company (allegedly) got all their data wiped by an ex-admin. Now I can imagine people thinking that this is something that is part of the territory when it boils down to cloud. So I wanted to write a blog post entailing what you do to set up a governance structure in Azure. Here I’m aware that the above tweet is more related to the security aspect of governance, it’s a part of it nevertheless.
Let’s get started on our scope… IT Governance can cover a lot of ground. In essence, the goal is to assure that the investment in IT generates business value and the risks that are associated with IT projects are mitigated. Though I found that CIO.com has a nice definition on it ;
Simply put, it’s putting structure around how organizations align IT strategy with business strategy, ensuring that companies stay on track to achieve their strategies and goals, and implementing good ways to measure IT’s performance. It makes sure that all stakeholders’ interests are taken into account and that processes provide measurable results. An IT governance framework should answer some key questions, such as how the IT department is functioning overall, what key metrics management needs and what return IT is giving back to the business from the investment it’s making.
So let’s take a look at how we can put an enterprise-grade structure around the management of Azure!
TL;DR = Azure Enterprise Scaffold
For those who want to skip the post below… When talking about governance in Azure, the best place that summarizes it the following page in our documentation ; “The Azure Enterprise Scaffold“.
Continue reading “Azure : IT Governance in the cloud”