Running a VM in Azure is simple. Create it and it just works.
But if you need an RDP or SSH connection to it, you have to know about the security implications.
Enabling RDP or SSH on a VM will open an inbound port for the communication. And this is an invitation for hackers to try to get in using these ports.
A temporary solution is creating a really difficult password/key to get in or changing the port number on which the SSH/ RDP service is listening. But still, this is ‘like playing with fire’. Smart hackers can work around this.
What we need is some kind of terminal session to the VM without opening inbound ports.
Luckily, Microsoft offers a few solutions for this.
First of all, you can make use of the serial console page of the VM instance (as seen in a previous blog).
This is a simple solution but the console form factor is not that great and sometimes random logging messages are written over your shell access which makes it hard to do actual, serious work in this pane.
Recently, Microsoft offers a new and better solution called Azure Bastion.
Bastion enables seamless secure RDP/SSH connectivity to Azure Virtual Machines in your Azure Virtual Networks directly in your web browser and without the need of public IP on your Virtual Machines.
The relationship with VMs looks like this:
VM’s are made part of a virtual network containing a subnet called ‘AzureBastionSubnet’. Next to the VMs this Azure Bastion resource is running and that one makes it possible to create a secure SSH connection.
Note: you need to create an Azure portal connection ‘as a second channel’.
The holy grail of IoT Edge compute is zero-touch configuration and monitoring.
If we look at the life cycle of an edge device, these are the phases where the device is rolled out to production:
The only time when we want to have a person near that edge device is during the initial deployment (Plan, Register), during decommission (Retire) and during physical changes or while repairing the device.
To make zero-touch possible we first need to have a secure cloud connection that supports both sending telemetry to the cloud and retrieving commands from the cloud. And that is supported by Azure IoT Edge by default.
But still, we also need a second communication channel to log-in remotely in a secure way. This is typically done by hand to look at local settings, to check logging, to check connections, or to make repairs to eg. the operating system or the Azure IoT Edge runtime. This could be done using SSH and/or a Remore Desktop connection (RDP). Because this is typically an outbound connection, this is usually provided using a ‘jump box’ or a VPN connection so the connection is set up in a more secure way.
As said, this is done by hand… so far for zero-touch.
Now, if we look at what tasks are performed on the IoT Edge device using an SSH connection:
Checking the log of running modules
Restarting modules if their performance is not thusted or to force picking up settings
Checking the cloud connectivity
What if exactly these three tasks could be performed from the cloud? What if these task could automated?
As seen in the last couple of blogs, Azure IoT Edge is useful as a deployment vehicle for Docker containers.
The idea is that the default available edgeAgent module makes an outbound connection with the cloud so it can retrieve updated deployment manifests.
Once such a manifest is received, it will pull new or updated containers from their container repository (eg. hub.docker.com or your own Azure Container Registry).
Relying on Docker modules is smart: it’s flexible and reliable.
But there is one drawback: the size of containers. Containers on their own can have substantial sizes, one hundred megabytes in size is not uncommon.
Docker is a little bit smarter to cope with these sizes. Docker makes use of layers. Layers already downloaded are not downloaded again.
But still, if you are limited in the daily communication size (like on a satellite channel) or if you have to pay for the transfer of files over a metered network (like 3G/4G), it would be nice if you could ‘side-load’ these images to your Edge device.
The easiest way to side-load is during the assembly of your edge device while it’s made ready for shipping to the production site. Next to installing the Azure IoT Edge runtime and the moby container logic, you can already try to pull your containers as much as possible.
Once shipped, your containers are already in the local repository.
After that, you are NOT on your own.
Azure IoT Edge has a nice setting for controlling the pull mechanism.
In my previous blog, I showed how regular Docker containers can be rolled out using Azure IoT Edge.
But what about databases, can these be deployed too?
Yes, I showed how to deploy and connect to SQL Server in the past and it works very well if you like SQL Server.
But what about MySql, can we connect to this database too?
Many of the world’s largest and fastest-growing organizations including Facebook, Google, Adobe, Alcatel Lucent, and Zappos rely on MySQL to save time and money powering their high-volume Web sites, business-critical systems, and packaged software.