In part one of this series, we had a quick overview of the Windows Azure Pack websites feature, and in part two we looked at getting the prerequisites in place. In this post we’ll go through the deployment process.
Although there are a lot of moving parts in the websites feature, the deployment process is very simple. The general process goes something like this:
- Deploy the controller using the Web Platform Installer
- Configure the controller using the website, which provisions the management (REST) server and optionally configures the file server
- Register the management server with the Azure Pack admin portal
- Deploy the remaining roles (Front Ends, Workers & Publisher) from the Azure Pack admin portal
To start with part 1 you can install the Web Platform Installer and then select the controller component which is called “Windows Azure Pack: Web Sites v2”
Since I prefer to do as much as possible from the command line, to deploy the controller you can execute the following once you have WebPI installed:
Cd “C:\Program Files\Microsoft\Web Platform Installer\”
.\webpicmd.exe /install /products:HostingPrimaryControllerBootstrapper_v2 /AcceptEula
Once installation is finished, Internet Explorer will start and you will be taken to the configuration page. The first thing you’ll need to do is ignore the certificate warnings and then get on with configuration.
Start by configuring the database connection, and your custom DNS suffix. Be aware that there doesn’t seem to be a way to change the custom DNS suffix after installation, so make sure you get it right first.
Next define the server name for the server that is going to be the websites management server (REST API server). Provide a username & password to configure the management server, the file server, front ends & publisher. In the prerequisite post I mentioned that you need to set the credentials to be the same on all these roles. You’ll also provide the credentials to install the worker roles.
You’ll also need to set the registration credentials for the REST API server – default is CloudAdmin and whatever password you want.
For the file server, you get options about whether you’re going to let the setup process configure the file server for you (this works if you are just going to have a single server), or you are going to preconfigure a Windows file server, or if you are going to use a non-Windows file server (like a NAS or your SAN). Either way you’ll need to provide the server name, and the three sets of credentials (FileShareOwner, FileShareUser, CertificateShareUser). The share paths will be automatically populated for you based on the servername, but change them if you need to.
Choose to join the CEIP, and whether to use Microsoft Update. You should join Microsoft Update, as updates to the websites components are provided through Windows Update.
Finalise the setup process and everything going well you’ll get three green ticks.
Now you have three configured components – the controller, the management server and the file server.
The next step is to head to the Azure Pack Admin portal and register the management server. Log in to the Admin portal, and choose “Web Site Clouds” from the left hand bar. Click the link below “Connect to a web site cloud”
Enter a meaningful display name, the name of your management server (prefixed with https) and then the CloudAdmin credentials you created during deployment. Assuming you got everything right, you’ll get a green tick beside the password, and you’ll be able to connect.
Now when you click the “Clouds” link at the top you’ll see your registered web site cloud. All that remains is to provision the rest of the roles.
To do this, click your web site cloud from the Clouds pane and you’ll be taken into the detailed view. You’ll be able to see the current roles provisioned and what status they are in. Note that if you chose either the preconfigured Windows file server, or non-Windows file server options during deployment, your file servers will not show here.
To provision the roles, just click the “Add Role” button at the bottom of the screen. You can choose to add a new worker, frontend, or publisher.
Each following option is basically the same – enter the name of the server you wish to add. The web worker role has an additional option that allows you to choose what sort of worker you wish to provision – shared or reserved.
Once you click the tick, a process will be triggered on the controller that will deploy the selected role to the selected server. Do this for each server that you are deploying. If you want to see where things are at with the deployment of a role, you can highlight the server in the list and click the “Role Log” button. This will bring up a log of what the controller is attempting to do.
The deployment is reasonably resilient, and if it fails it will attempt to autorepair as best it can. It will retry a number of times, and then reboot the server if things are still failing. This does seem to be quite normal, and if the controller is able to reboot the VM it tends to be able to finish deployment. Where you’ll run into trouble is if you haven’t enabled the required firewall rules so the controller can’t talk to the server or transfer the required files. The deployment is agent based – the first thing that happens is that the controller pushes the source files for the Web Farm Agent to C:\windows\temp on the destination server, and then installs it. From then it appears to do all communication via the Web Farm Agent (which is an HTTP listener on port 8173).
That’s it for deployment, in the next post we’ll briefly look at the post-deployment tasks.