Communication with Kentico AWS API

7.4 Communication with Kentico AWS API

After EC2Manager launches new instance with user data the control on client side, KAM, is transferred to InstanceManager, an asynchronous service running in the background that is responsible for monitoring newly-created instance and notifying user about current installation status. In order to achieve this goal, InstanceManager uses three different ways of obtaining information. The very first step is to query instance status, which can be accomplished with AWS API and thus with our SDK for .NET. Upon its launch every instance’s status says pending, which is why InstanceManager repeats the query every ten seconds until the instance is running. Once this occurs, AWS begin to prepare the instance, configure software and its environment, generate firewall rules, generate administrator password and execute user scripts. Unfortunately, as of now, there is no direct way to track user data execution progress with AWS API. For Windows instances Amazon only creates a snapshot after the instance has finished preparing and can be logged into. Once this happens, InstanceManager notifies the user that CMS installation is in progress. For the last part, displaying installation status, it is needed to propagate the information from KAI to KAM. In order to achieve this, we need Kentico AWS API.

KAA is yet another tool from Kentico AWS Utilities and a necessary part of CMS installation process. It serves as messaging service relaying current status of configuration and installation. Kentico AWS API is downloaded asynchronously by Kentico AWS Installer and deployed on IIS (once the feature is enabled) after which it starts listening to incoming traffic from KAI. Every single action that KAI performs is being logged both in memory (using concurrent queue) and in the main log file. Once KAA is successfully deployed, Kentico AWS Installer begins sending it all the messages that have been added to the queue while retaining the ordering. This background task transfers every log from KAI to KAA and also takes care of potential network failures by resending the batch until it receives confirmation from KAA. At the end of the transfer a control token is sent to KAA. This token is not meant to be displayed to the user but rather notify KAA that installation of Kentico has either succeeded or failed. Additionally, to make sure that KAA doesn’t get attacked by a third party by having someone else than KAI sending messages to it, Kentico AWS API only accepts POST requests from local ULR.

As the messages are being successfully transferred and stored by Kentico AWS API, they are safe to be accessed by InstanceManager in Kentico AWS Manager. In order to allow this, however, one additional step has to be taken. While launching new instance the user defines port 8080 as a permission in EC2 security group. This indicates to AWS firewall that it should allow traffic flowing through this port. However, Windows Server native firewall is set by default to block any communication port other then 80 (HTTP), 1433 (MS SQL Server) and 3389 (RDP). As such, an exception has to be made by adding an incoming firewall rule. This can be easily accomplished with a simple netsh command (performed by KAI), which enables InstanceManager to finally start receiving installation status messages. To keep the impression of real-time installation, InstanceManager doesn’t display all the messages at once but uses buffer to store them first. Then, based on the buffer size, it calculates speed with which the messages are being displayed on screen. This way KAM copies the speed of CMS installation process on EC2 virtual machine and minimizes the delay between these two operations. Last message that InstanceManager receives is our control token. Upon receiving it, Instance-Manager determines that the installation process is over and based on its value it transfers control to one of the two views. This is the very last step in the whole EC2 scenario.

In a rare case of failure (failure token received), the application displays fail screen. Because the installation failed, our new instance can’t be relied on and as such the application doesn’t allow creating AWS AMI out of it. On the other hand, KAM offers the user two options. He can decide to terminate the instance on the spot or he can try to log in the instance in order to salvage it manually (if possible). To achieve the latter, KAM displays a panel with instance access information for Remote Desktop. This panel contains instance’s public DNS²⁶ (endpoint), user name – Administrator – and password (either the one the user specified or a randomly generated one). To make it even simpler, KAM allows the user to download RDP script, an executable file with all the necessary information already predefined. Upon its execution, this script automatically connects the user to his instance without requiring any additional steps.

In the much more common case of success, a different view is displayed. Here, the user is informed that the installation has succeeded and exposes URL under which the user can access his first CMS website. Much like in the case of failure, this view also displays the panel with Remote Desktop access information and downloads a script option. And most importantly, it allows the user to turn his new instance into an AMI. If the user decides to use this option he is required to specify a name for his AMI as well as brief description. Then EC2Manager begins the process of creating a new AMI by stopping the running instance and creating a snapshot of the operating system as well as storage volume. Once the AMI is created, KAM redirects the user to its main view and the scenario finishes. Newly-created AMI is then available for the user and can be used to launch new instances with Kentico CMS at any time in the future.