Building a CoreOS Virtual Machine in Microsoft Azure - Step by Step
This post is a follow up to my previous post for building Linux machines in the cloud, so if you need to catch up first follow the blog post here then proceed below.
CoreOS is one of the newer Linux distributions on Microsoft Azure. Now let’s continue building out your virtual machine.
1) In the Microsoft Azure portal choose New, Compute, Virtual Machine, then From Gallery. It should bring you to this screen. For this exercise we will be deploying the CoreOS Stable distribution. Select this and then tap the right arrow at the bottom of the screen.
2) Notice that if you drop down the Version Release Date menu there are a few patch releases to choose from. In this example we will be choosing the most recent release, and as of this writing that is 12/4/14. Next we need to name our virtual machine. Enter a name for the virtual machine, I recommend adding a prefix or suffix to it that goes along with the previous article such as contoso-cs01. Next we will need to enter in a unique username for the VM, one is provided but I like to change it up a bit just to keep a prospective\ hacker guessing. :) Now you have the choice of uploading your own SSH key or letting the system randomly generate one for you. Unless you already have a key, unselect the checkbox for Upload Compatible SSH Key For Authentication. Now select the checkbox for Provide a Password. Enter in a new password matching in both fields then select the right arrow to continue.
3) As this is the first VM in this particular solution we will need to create a cloud service. As virtual machines are deployed through the new VM creation wizard, PowerShell, or the Azure CLI you will be prompted for names, not only for the VM but also for the Cloud Service. Cloud Services can share the same name as the VM so long as no one else in the Azure framework has utilized that name already. You see, cloud services are uniquely named because each service needs to be accessible via the Internet for administrative access, monitoring, and possibly user access. So in best practice a cloud service will most likely need to have a name similar to the actual service being provided and not necessarily the virtual machine name. We named the first virtual machine contoso-cs01 however the cloud service would be titled contosocsweb, since we might also be possibly adding a future virtual machine named contoso-cs02 which would be running the same web service to this new cloud service. When building out the subsequent VMs for this service a drop down menu will appear allowing the administrator to select that particular cloud service created during the original VM's creation. The cloud service will ultimately have a name that looks like this: contosocsweb.cloudapp.net. So provide a unique name for your cloud service before continuing.
4) We will then need to select our virtual network which for this lab was contosovnet01.
5) Select the proper storage account, created in the previous post. Remember if you do not do this, one will be created for you with a highly randomized name so it would become difficult to manage later.
6) Select Create and Availability Set. Creating an availability set allows for redundancy as each virtual machine in the availability set will reside on separate hardware in the event of a server or rack outage. Note that all VMs in an Availability Set should run identical workload types, for instance web services. Now below this please enter a new availability set name, this name can be the same as the cloud service but in more complicated scenarios you may want to differentiate the two. Important note: VMs must reside in an availability set in order to meet the Microsoft Azure SLA requirements.
7) Notice that the endpoint for SSH is already setup by default. Endpoints are a means of allowing network traffic from the outside world into this virtual machine. In this case we are keeping the default for port 22 however you may change this if you wish. Your screen should look similar to this when complete, if so click on the right arrow to proceed.
8) Now for the last step, the box for the VM Agent is already pre-selected. This agent allows an Azure admin to perform actions within the VM from the PowerShell console for Azure. Leave this selected and click on the checkmark in the bottom right corner.
9) Watch the portal to see when the VM has completed the setup. It should start out as Starting (Provisioning) and then progress to Running.
10) Once the VM is complete open up your favorite SSH client application and connect to the virtual machine utilizing the cloud service name provided in the steps above or the unique IP address assigned to the VM during creation which can be found going to the status screen for this VM in the Azure portal. For this example I will use PuTTY. The configuration should look similar to this:
or:
11) You will be prompted to trust the server, click Yes.
12) You should now be able to login with the username and password provided during the setup and be ready to setup your applications. IN future blog posts I will enable load balancing on this cloud service with an extra VM so stay tuned!
