In the past I’ve already done several posts about containers. This by using various orchestrators & workflow management tools. Today’s post will be about deploying a Linux container with Service Fabric… The main goals is to provide you with the look & feel of the initial steps. In a future posts, I’ll delve into the more advanced stuff (like data persistence & inter-container connectivity).
Continue reading “Azure Service Fabric : Deploying your first container…”
The Azure Container Instances (ACI) have just been announced. Today we’ll take a quick glance on how it looks in reality. Though what are ACIs?
Azure Container Instances offers the fastest and simplest way to run a container in Azure, without having to provision any virtual machines and without having to adopt a higher-level service.
Want to try it yourself? Check out the ACI Quickstart!
Let’s see how it looks?
In contrast to the quick start, I’m going to use the portal… This is currently not the preferred way, though let’s see how that one looks at the moment.
Continue reading “A quick glance at the newly announced Azure Container Instances”
In an earlier blog post I discussed the decision criteria in selecting a VM. In that post I also showed a tool called “VMchooser“. Today’s post will be on the architecture I used to build this one. As you might have guessed, it’s built on Azure components. Let’s get to it and check the anatomy of this application.
High Level Architecture
VMchooser has the following high level architecture ;
- Web App : The front-end of the application is hosted on an Azure Web App.
- Azure Functions : The back-end API & batch parser are built with Azure Functions. Which unlocks insane scaling possibilities.
- Storage Account : The storage account serves as decoupled/central storage component for the batch parsing. And it could also be used for hosting the “database” (flat file).
- Application Insights : Application insights is used to have the needed insights into the usage & other metrics.
- Github : All code for this project is open-source and publically hosted. You can run your own VMchooser if you want… 😉 Every change is immediately pushed towards the front-end, back-end & database.
- API Management : As the back-end API is decoupled from the application, I’ve also linked this api with api management. This would provide me with the option to allow 3th party application integrations via an API subscription plan.
Continue reading “The anatomy of “vmchooser”… Adding some serverless into the architecture!”
When I was working on the “CSV import” of VMchooser, I noticed that long jobs sometimes had issues. After some investigation, it quickly became apparent that I was hitting the time-out. So I had a need to increase it…
Logic Apps Time-out = 2 minutes
As a bit of back story, I first started off with my async parsing flow by using the combination of logic apps & functions. Where I at first thought it was due to the time-out on the functions side, it actually appeared to be on the logic apps side. And that one cannot be changed…
Azure Functions Time-out
So I browsed the web, and encountered two variables, which I both set on my platform ;
To reach set these, click on your functions bar (“kvaesvmapi” here), then “Platform Features”, and then “Application Settings” ;
But let’s get back to the variables… From various posts I saw these two popping up. Where I set them both to be safe, I started investigating a bit. The first one ;
WEBJOBS_IDLE_TIMEOUT – Time in seconds after which we’ll abort a running triggered job’s process if it’s in idle, has no cpu time or output (Only for triggered jobs).
This is actually the one you need for your function. As it’s clearly described in the kudu docs. Where the second one apparently is only related to the deployment phase; hence the “SCM_”-prefix.
Set the “WEBJOBS_IDLE_TIMEOUT” in your “Application Settings” ;
And don’t be distracted by the “SCM_COMMAND_IDLE_TIMEOUT”. 😉
Remember the last time you went shopping for a shirt? Then you surely also recall the moment in time when you were looking to find the right shirt size for yourself…
You probably also noticed that sizes might differ a bit depending on the context. A woman’s size vs & men’s size is totally different. There are geographical differences… and some people just like to wear cloths that have more “free space”.
So is today’s post about buying cloths? Hell no… 😉 But it’s to point out that there are analogies between finding the right shirt for you, and finding the right Azure Virtual Machine. Today we’ll delve into the aspects that will guide you a given T-shirt size in Azure ; for instance, why choose an FS1 above an A1_V2, where they both have 1 core & 2GB of memory. Though there is a price difference of 10€ per month on them.
Continue reading “What Azure Virtual Machine size should I pick?!?”
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”