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… 😀
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. 😉
A few days ago my connectors arrived for my latest PoC on Azure. So today I’m writing about my experience in using a RaspberryPi with a temperature & humidity sensor and to save the telemetry data in Azure. For this we’ll be using Azure Event Hub as an ingress mechanism, and Azure Functions to storage the events towards an Azure Storage Account. My next venture will be to use this data to create reports and maybe (on the long run) do some machine learning. For the latter, I’m pondering about linking this system to my ebus system of my heating system. That way I could correlate the data from the various censors (RPi, Thermostat & outside sensor) in combination with the heater information & heating schedules. Basically… creating my own Google Nest. 🙂
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 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.
So today I was installing an VSTS agent on Ubuntu and I got the following error message ;
Failed to initialize CoreCLR, HRESULT: 0x80131500
I received this error message when trying to run the “config.sh” command ;
So how to fix this? Apparently the agent has a hard dependency towards “libicu52”. By default my system (ubuntu 16.04 LTS) had libicu55 on it. You can find the “old” package on the following location. And install it?
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 ;
Last week we did a quick demo on Azure Functions in combination with the event hub. Today I wanted to explore what would happen if I wanted to use “custom” libraries. Could I install libraries on functions? Let’s try it out shall we!
Install NPM Module in
First thing we’ll do is install the extra npm module we need. We can do this via the “kudu“-console ;
Did you know that the “Dev/Test Labs” service in Azure had a neat feature where you could schedule the shutdown of servers? No, or yes… Now this features has been integrated in all virtual machines. Nice!
So just go to the details blade of a virtual machine and click on the “Auto-Shutdown”-tile. Here you can enable / schedule a shutdown.
Via this method, you configure it per VM. You can always use Azure automation / runbooks and do it per resource groups.
Why do this? In Azure you are billed per minute for your compute runtime. So shutting down (and deallocating) will safe you a great bunch!
Azure functions is the “serverless” offering on Azure. Serverless doesn’t mean there aren’t any servers, but it’s rather a platform service where you can run your own snippets of code. Each code can be triggered, where it then can have an in and/or output. In terms of billing, you pay for the amount of runtime you consume.
Imagine having a stateless web front end which publishes state onto a queue or storage account. Then Azure functions is being triggered and your business logic starts. Sounds familiar? Yes, because that’s a typical flow you normally do in your application stacks. Now you can segment that even more into services you do not need to manage.
Today I’m going to show you a very brief demo on using an Azure Event Hub as trigger/input for an Azure function. So what’s the flow we’ll be doing?
A client will put a message on the event hub queue
This will trigger an Azure function
The function will save the contents of the message onto a storage account
Sound simple right? And it actually is that simple to do too!