Masaryk university faculty of informatics
CMS installation with Kentico AWS Installer
Download 150.94 Kb.
|
7.3 CMS installation with Kentico AWS InstallerAfter the user data script downloads the right version of KAI based on installed SQL Server Kentico AWS Installer begins to set up the environment and commences with the installation of all the necessary tools along with Kentico CMS. The first step in installation is to decode and deserialize user data in order to obtain values based on which Kentico silent auto-installer can be formed. Afterwards, it is necessary to verify whether Microsoft webserver, IIS, is installed on the machine. Most of the Amazon AMIs don’t come with preinstalled IIS and as such this task is left to KAI. Luckily, on Windows Servers (as well as standard Windows distributions) IIS can be easily enabled as a server feature. One of the easiest ways of automating this task is through PowerShell Cmdlet. After this operation is complete, it is still necessary to install IIS management tools. This yet another Windows Server feature exposes a set of tools and libraries that can be used to manage IIS web sites, application pools and managed runtime versions. Once both IIS and management tools are successfully enabled and configured, it is finally possible to proceed with the installation of Kentico CMS. One big issue associated with installation of IIS and management tools is the overall duration of this whole process as both of these tasks are very time-costly. Moreover, since installation of management tools depends on successful configuration of IIS these two tasks can’t run in parallel. This is why I decided to run as many necessary configuration tasks in parallel as possible. Since the preparation of IIS followed by CMS installation are delimiting factors in terms of duration of the execution we can have other tasks running on separate threads. As such, while IIS is being configured on one thread Kentico installer is being downloaded on another. This way KAI is effectively using resources at its disposal to distribute responsibilities and reduce total execution time. To install Kentico silently, an auto installer file must be generated. This file is essentially just an xml document containing configuration information for the soon-to-be-installed CMS. Each element corresponds to one installation step with each element’s attribute corresponding to one property. As such Kentico auto installer contains information on IIS configuration, SQL configuration, installation location, type of project, additional modules and templates, logging and even license details. After successful configuration of IIS and generation of auto installer the installation itself can finally commence. The process itself takes around ten to fifteen minutes. Once it is over, there are several other steps that need to be done in order to make Kentico run properly. Some of these are necessary only if the user decides to use Windows Server 2008 as an underlying AMI. By default, this distribution of OS only comes with .NET 3.5 preinstalled, which is not sufficient for Kentico CMS 7. For this reason, KAI uses Windows batch script to register ASP.NET 4.0 as well as sets the default IIS managed runtime to v4.0. Another necessary step, this time common to any distribution, is to create a user account with its own login that enables Kentico CMS to access SQL Server database by using Windows authentication. This is actually an issue with Kentico, which I believe should be incorporated in its native installer. The problem is that Kentico allows two types of connection to the database, one of them being Windows authentication. During the installation process, if the user specifies this option Kentico will use his Windows credentials in order to create Kentico database and populate it with all the objects necessary to run Kentico website. After the installer finishes new website is successfully deployed to IIS and started. Once the websites attempts to connect to the database, it fails with an error. This behavior is a result of how IIS implements access rights for deployed web applications and websites. In order to assure security and prevent unauthorized access of 3rd party to machine’s resources, each and every application is deployed within an application pool. Application pools are basically sets of URLs that are served by IIS worker process (or multiple processes). On top of that, each application or website is completely contained within its application pool allowing multiple applications to coexist without affecting each other. OS then treats these applications as separate users with separate access rights (which are usually only limited to directories containing the applications). As such, even though the user specifies to use Windows authorization i.e. his Windows account (presumably with administrator rights) to create a database, once the application is deployed and running, it can no longer use this account to access the database. For this reason, it is necessary to have KAI (running with administrator privileges) to create new database login (with user) for our new website and to give it explicit rights to access the database created by the installer. In order to achieve this result, I rely on management library that comes bundled with SQL Server encapsulating the complexity of configuring SQL Server by exposing simple yet powerful API. After the login is created our new website is loaded without a crash. Once we have Kentico up and running, we are still required to install the latest hotfix. Under usual circumstances the user utilizes KIM24, a desktop application that is installed along with CMS itself, to fetch information about the latest hotfix and then has KIM to take care of updating database and CMS version. However, as there is no way to automate this way of hotfixing, I had to use less frequent alternative – hotfixing Kentico CMS manually. As far as obtaining the latest hotfix goes, KAI makes use of WCF25 service provided directly by Kentico Software. This service allows us to query server for the list of available hotfixes. Each hotfix item contains information such as hotfix name, number and endpoint URL. Once the most recent hotfix is downloaded on local machine, it can be launched silently, which is the way of automating this task. In a first step, hotfix feature unpacks all the necessary files and scripts to chosen destination. In a second step, KAI launches hotfixing process from command line. Afterwards, it uses bundled SQL scripts to update the database and CMS has been successfully hotfixed. However, there is one minor issues present in the hotfixing procedure. Even when launched from the command line, hotfixing feature still launches as a desktop application and user interference is required in order to return control back to the calling program – KAI. To cope up with this situation, I had to hard-code how long should KAI wait for the hotfixing procedure to finish. Even though this work-around allows us to deal with the problem of process starvation, we have no guarantee that the hotfixing finished or that it was successful. Download 150.94 Kb. Share with your friends:
|