Hosting Node.js Applications on Windows Server 2012, Complete with Git Deployment and Remote Debugging - Part 1
Quick Links
- Part 1 - Setting up Virtual Machine
- Part 2 - Installing IIS, Git, Node.js, and IISNode
- Part 3 - Installing Kudu
[WS2012-Kudu] coming soon
I love JavaScript, I love Node.js, I love Windows Server 2012, and I love Git. Loving Nodes.js and Windows can be pretty lonely sometimes; the Windows Node community is practically non-existent. Because of this, it is really difficult to find great tutorials for properly setting up Node.js on a Windows Server. Pretty much every article out there assumes you are using Linux as your host machine and a lot of the awesome tools they link to are Linux-only.
What makes me a strange dichotomy is that I do a lot of .NET development in addition to my Node.js development. I also hate paying more than I need to for hosting so I'd like to host my Node.js applications side by side with my .NET applications. If you didn't know, Windows Azure provides Node.js "support". I put support in quotes because while their platform will run Node applications it can be a source of a lot of pain because of a lack of good documentation. One big reason to use Azure to host your Node applications is that they support web sockets. Even Heroku as of this writing has yet to implement web socket support. However, I ran into issues while using socket.io with Windows Azure Websites.
Trying to debug issues with your Node.js application that only show up when you push to Azure Websites is nothing short of infuriating. Behind the scenes Azure uses two different open source projects called Kudu and IISNode. Kudu interacts closely with IIS to manage your applications and allows you to deploy your apps using Git. It even has hooks available to enable continuous deployment from Github and other Git providers. It is obvious when setting up Kudu that it is highly optimized for .NET applications, but it also provides support for Node.js applications. To accomplish this Kudu takes advantage of an open source IIS extension called IISNode. This extension allows IIS to pass requests to Node.exe when needed. It even allows Node to take advantage of multiple CPU cores whereas vanilla Node does not do this out of the box.
Rebuilding Azure Websites in a Virtual Machine
Another great thing about IISNode is that it comes bundled with a Node.js debugger called node inspector. This allows you to debug your Node applications on the live server, which I'll admit is pretty sexy. Unfortunately, Azure Websites hides this debugger for some reason, making debugging issues that only show up on Azure Websites a huge pain.
After finding out that nearly everything Azure Websites uses is open source I decided that my own Azure Virtual Machine configured with all these tools would solve a lot of problems for me. Albeit, after a pretty complicated setup process. This way I could setup Kudu, IISNode, and even provide access to the bundled node inspector tool while staying in total control of every part of the process. In this blog post I'm going to walk you through setting up a Windows Azure Virtual Machine running Windows Server 2012. Then I'll walk you through configuring your new VM to work with Kudu and deploy both a .NET and a Node.js sample application.
Throughout this process I think it's important to keep in mind that Kudu is very much designed to work with Windows Azure Websites so setting it up is somewhat involved and requires a few modifications to the source code.
Setting up your Virtual Machine
First log into your Windows Azure Management Portal. Once in simply click on "+ New" in the bottom left corener.
Next go to COMPUTE > VIRTUAL MACHINE > QUICK CREATE and you should see a form to fill out.
The DNS NAME can be whatever you choose, it just has to be unique. Windows Server 2012 should be the default selected image, but if it's not then be sure to select the right one. For now just leave the size at the lowest setting (1 core, 1.75 GB); you can always change this later if your VM needs more resources. Next choose a username, password, and pick the location you'd like your VM to be hosted.
When you're finished click "CREATE A VIRTUAL MACHINE" to continue. You will see your virtual machine appear in the list. It will take quite some time for the STATUS column to show that it's running so be patient.
Once your VM is finally provisioned and running click on it's name. You should see a "Quick Start" screen. At the top there are some navigation tabs. Click on "ENDPOINTS" and you should see a screen like the following.
At the very bottom you should see an "ADD" button. Click it to bring up a dialog allowing you to add a new endpoint. Endpoints are basically just port forwarding. The only ports on your VM that can be seen from the public internet are the ports you specify here. Select "ADD ENDPOINT" and click the next arrow. We are going to expose port 80 so we can host web applications.
Now that we've exposed the proper ports to our virtual machine we can finally log into it using Remote Desktop (RDP). To do that you'll need to navigate to the "DASHBOARD" section. Once there click "CONNECT" at the very bottom of the screen.
This will prompt you to download a "vmname.rdp" file. This file contains all the information you need to connect to your VM with Remote Desktop. All you have to do is double-click the file once it's downloaded. When you are asked to enter credentials simply enter the same username and password that you created when setting up the virtual machine.
Now that you're logged into your VM with RDP this concludes part 1 of the tutorial.