As indicated in my last blog post this is the first of two posts describing my experiences and learning in connection with setting up a Minecraft server.
In this one we will look at Azure Automation and create a small scheduled runbook or job that will ensure the server is closed down for the night (to save on the pocket money).
If you don’t have an Azure subscription, you can get a free trial.
I will not go into details of how to actually set up the Minecraft server as Jon Buckley has already created this excellent instruction video. If you know Azure and don’t want to see the whole video, the steps are the following:
- Create a new VM using the Windows Server gallery image.
- Create a new endpoint opening up port 25565.
- Open up the Windows firewall on the VM to allow traffic to this port.
- Download Minecraft.
To leverage Azure Automation, you’ll need to activate the preview feature. This can be done from the Preview Features page.
It may take a few minutes for the feature to be activated. Once available you will see a new menu item in the left navigation bar.
Select this and click the Create button at the bottom of the page to create a new Automation account.
I have create one called strobaek. Note, that the Automation feature is currently only available in the region East US.
Azure Automation authenticates to Microsoft Azure subscriptions using certificate-based authentication. You can create a new management certificate in a number of ways. I usually open up a Visual Studio command-prompt and issue the following command
makecert -sky exchange -r -n CN=KarstenCert -pe -a sha1 -len 2048 -ss My "KarstenCert.cer"
This will insert a new certificate in the Personal certificate store
Export this certificate twice, both without the private key (as DER encoded binary X.509 .CER) and with the private key (as .pfx file).
You should end up with something like this:
Now that we have a management certificate we need to upload it to the Azure Management Portal.
Log in – if you are not already – and select Settings in the left navigation bar; it is the last menu item.
Select Management Certificates from the top menu and click Upload at the bottom of the screen. Browse for you CER-file and select OK.
Make a note of the Subscription and Subscription ID as we will need these later (I have blanked out some of my subscription ID in the figure below)
OK, that was one part of the deal using the .CER file. Now for the second part using the .PFX file you also created. For your Azure Automation account to be able to authenticate to your Azure subscription, you’ll need to upload the certificate .PFX file. You’ll create what is known as an Asset in the Azure Automation account. This way it can be consistently leveraged across multiple runbooks.
Click on the Automation item in the left navigation bar and enter the Azure Automation account you created earlier. Click on the Assets tab and then Add Setting at the bottom. When prompted, select Add Credential.
On the Define Credential page, select Certificate in the Credential Type list and enter a name
Click the Next button and browse to the .PFX file to upload the certificate. Enter the password used while exporting the certificate and press OK.
Your new asset has now been created
Next step is to create a connection asset. Doing so allows you to easily relate your Azure subscription name, subscription ID and management certificate together as a centralized definition for use in all of your runbooks.
Again click Add Setting, but this time select Add Connection
On the Configure connection page, select Azure as the Connection Type and enter a Name that matches your Azure subscription name recorded earlier.
Click Next
Enter the name of the management certificate asset previously uploaded/created and enter your Azure subscription ID (which you should also have recorded previously).
We are now ready to create the actual runbook.
There is a few lines of code that are used to connect a runbook to your Azure subscription using the management certificate asset and connection asses that were previously defined. To promote easy maintenance of runbooks, it is recommended to centralize this code into one runbook, called e.g. Connect-Azure, that other runbooks can reference.
The Azure Automation team has made this approach super-easy by providing us with a standard runbook template on the Azure Automation Script Center.
Go to the script center and download the Connect-Azure runbook template.
On the details page of your Azure Automation account, click the Runbooks tab.
At the bottom of the page click the Import button. Browse to the Connect-Azure.ps1 file just downloaded and click OK to import the template.
On the Runbooks tab click on Connect-Azure to drill into the details of the runbook.
Then click the Author tab and click the Publish button at the bottom of the page to publish the runbook. Until this is done the runbook is in “draft” mode and can be edited, but not used.
When prompted select Yes to confirm that you really want to publish the runbook.
We now have the fundamentals for creating our own runbook.
Click New | App Services | Automation | Runbook | Quick Create
Enter a name, e.g. Stop-VMs and a description, e.g. ‘Stop all VMs at night’. Select your automation account from the drop down and verify the subscription is correct. Then click Create.
Note that runbook automation scripts are defined using PowerShell workflows. As such, the recommended practice is to name runbooks using a PowerShell verb-noun cmdlet naming convention.
On the runbook page you should see the new runbook after creation is done.
Drill into the detailed property pages of the runbook.
Click the Author tab and then the Draft tab to begin editing the PowerShell code for the new runbook.
The first thing to do is leverage the Connect-Azure runbook to connect to your Azure subscription. Inside the Workflow code block enter the following:
workflow Stop-VMs
{
# Specify Azure Subscription Name
$subName = '[Enter your Azure subscription name]'
# Connect to Azure Subscription
Connect-Azure -AzureConnectionName $subName
Select-AzureSubscription -SubscriptionName $subName
}
Now that we are connected to the subscription we can enter the code to actually stop and deallocate the VMs.
$vmList = ('App1','App2','App3','DC')
$svcName = 'mycloudservice'
foreach($vm in $vmList)
{
$anon = Get-AzureVM -ServiceName $svcName -Name $vm
Write-Output $anon.Name $anon.InstanceStatus
if ($anon.InstanceStatus -eq 'ReadyRole')
{
Stop-AzureVM -ServiceName $svcName -Name $anon.Name -Force
}
}
Update the two variables $vmList and $svcName with the name of the virtual machines you wish to stop and the name of the cloud service they live in.
The whole script is shown below for your convenience.
workflow Stop-MyVMs
{
# Specify Azure Subscription Name
$subName = '[Enter your Azure subscription name]'
# Connect to Azure Subscription
Connect-Azure -AzureConnectionName $subName
Select-AzureSubscription -SubscriptionName $subName
$vmList = ('App1','App2','App3','DC')
$svcName = 'mycloudservice'
foreach($vm in $vmList)
{
$anon = Get-AzureVM -ServiceName $svcName -Name $vm
Write-Output $anon.Name $anon.InstanceStatus
if ($anon.InstanceStatus -eq 'ReadyRole')
{
Stop-AzureVM -ServiceName $svcName -Name $anon.Name -Force
}
}
}
Click the Save button at the bottom of the page.
Once the runbook is saved you can test it to confirm that it runs successfully.
Click the Test buttton next to the Save button. NOTE: When you test the runbook it is actually executed against your subscription, hence if you test the new Stop-VMs runbook, your virtual machines will be stopped.
When the runbook is tested and confirmed that it executes successfully, it can be published.
Click the Publish button on the bottom toolbar (and confirm when prompted) and then click the Published tab to confirm that is has been published successfully.
The final step is to create a schedule and attach it to the runbook. This is to make sure the Minecraft server is automatically stopped and deallocated when not being used (read: when the kids are supposed to sleep). To execute a runbook on a scheduled basis, we can link the runbook to a recurring schedule.
Next to the Author tab you can see the Schedule tab. Click this.
Click Link to a New Schedule and give the schedule a name
and click next.
On the Configure Schedule page set type as Daily and a start time, e.g. 21:00. Note, the time is not adjusted for daylight saving. However, the time entered seems to be based on the time on the work station creating the schedule. If I enter 21:00 the runbook is executed at 21:00 CET which is my local daylight saving adjusted time.
Click OK and you are done!
The next post will look at how to use the Azure Management Libraries from a small .NET library to start and stop our virtual machine.
Hey Little Angel by Éric Serra