Today the new “AKS” (Azure Kubernetes Services) was launched in preview. This is a managed container service. So where ACS used to rely on IaaS and used a set of best practices to deploy the cluster. AKS will go a step further, where it’ll managed the master nodes & provide upgrade tracks.
Let’s start with deploying an AKS cluster… Here we can select the k8s (kubernetes) version too.
Continue reading “A first glance at the preview AKS (Azure Kubernetes Service)”
Today’s post is conceptually a rather simple one… Let’s see how we can go from this ;
To here ;
By using a CI/CD pipeline.
Flow of the day
What will we be doing today?
- Kick-off a VSTS build once a change has been made to our Github repo
- Build a container via VSTS
- Publish the container to an ACR (Azure Container Registry)
- Kick-off a VSTS release once the build succeeded
- Use an ARM template to deploy an ACI (Azure Container Instance) with our docker container underneath
Sound cool? Let’s get to it!
Continue reading “From Github to ACI – A tale how to use Visual Studio Team Services & Azure Container Registry for Container CI/CD”
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”
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.
Today’s post is a brief one… Though it packs some punch! In the past I talked about storage patterns for docker/containers. Today we’ll touch how you can leverage the Azure File Storage as a shared & persistent storage for your container deployments. Kubernetes has been gaining a lot of traction, and that one has support for the Azure File Storage as a persistent volume too.
Want to run this yourself? Check out the following GitHub repository!
Continue reading “Azure Container Service : Using the Azure File Storage as a persistent (kubernetes) volume”
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
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… 😀
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
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. 😉
Continue reading “How to try out the experimental windows 2016 support in the Rancher 1.3.0 release candidate?”