Managing Your Windows Azure Services from OS X, Linux, or Windows Using the Command Line Interface (CLI)
A lot of exciting things were announced at today’s Meet Windows Azure event, and one of the things I wanted to share with you is how you can now use our cross-platform Windows Azure Command Line Interface (CLI), part of our Node SDK, to administer your hosted services, VMs, and websites all from the comfort of your favorite terminal.
For the purposes of this blog post I’m going to use iTerm on OS X as my terminal of choice and I’ve also run all of these commands off of the DOS / PowerShell terminals in Windows 7.
Installing the CLI
The Windows Azure CLI is written in Node.JS, so it’s cross-platform by design. To install it you need to have Node.JS and NPM (node package manager) installed.
Once you have both of those, you can just install the CLI using Git and NPM:
How to Build a Real-Time Chat Service with Socket.IO, Express, and the Azure SDK–Part 2: Setting Up Express and Session-Handling
So if you read part 1 of this series, then you’ve had a chance to grok the requirements for our little chat service and see all of the NPM packages and front-end tools we’re going to use for building it. In this portion I’m going to explain how to set up Express and all of the session-handling requirements we have.
If you recall from the previous post, we need to ensure that all users participating in the chat room are signed in with a registered chat handle before they can participate. We’re going to accomplish that using the Express web framework and its rich user-session support.
Step 1: Install Express and its dependencies
The first thing we need to do is install Express itself, which is pretty straightforward – do the following:
This past weekend I ran a Node Bootcamp on behalf of Microsoft and in partnership with the fine folks at Cloud9 IDE – the goal of these camps is to help teach newbies Node.JS and to get some Node.JS-on-Azure business from attendees who have a good experience.
So I decided to build a sample Socket.IO application that leverages our platform and would give our attendees a base to work from when it came time for them to participate in the Node Bootcamp Hackathon. I’ve done a lot of work with Express on Node but had never really done much with Socket.IO, so I was curious to see how hard it was to pick up.
Total time to build and deploy this application from end-to-end, including learning Socket.IO: about 5 hours.
All I wanted to build was a basic chatroom – a simple version of...
This is a simple blog engine that I wrote in about three days time. I wanted to show off the power of Node.JS on Windows Azure, and also take advantage of our recent support for MongoDB in Replica Sets on Windows Azure.
Here are some of the tools I used
- Foundation - a bad ass rapid proto-typing CSS framework that even a terribad designer like me can use to make awesome stuff. The design for this site took less than two hours.
The bottom line when working with busy people is to preempt as much of the mental overhead of working with you as possible; all it really takes is some brevity and thoughtfulness on your part. If you form the eight behaviors I list below (and others I may be forgetting) into habits, you'll be much easier to work with and you'll get better results.
One of the transformational things my job at Microsoft has done for me is help me appreciate what it is like to be extremely busy and how hard it can be to work with other extremely busy people.
“Busy-ness” isn’t a measure of how much time someone spends working, although there’s typically a strong correlation; it’s really a measure of the total amount of concern a particular individual has to manage at any point in time. The busier you are, the...
One thing that is a little dicey about the Windows Azure SDK for Node [footnote:“azure” is the name of the associated npm package] is that it by default it depends on being run inside of Azure itself or the compute emulator.
The Azure npm package looks for environment variables parsed from web.config and won’t find them if you run your node application via the node [entrypoint].js commandline.
So why would you want to run your Node application outside the Azure emulator if you’re utilizing the Azure npm package? If you’re using Cloud9 to develop and deploy Node applications to Windows Azure, then that’s one reason.
Another is that IIS eats any error messages your Node application throws by default[footnote: I’m sure there’s a way to change that behavior in the IISnode configuration settings] and on some occasions errors don’t always get logged to server.js/logs/[n].txt, so occasionally you have...
This past weekend at SoCal Code Camp I gave two presentations back-to-back on Node.JS: “Intro to Node.JS” and “Building Web Apps with Express.”
I don’t have much to add on what I did at the sessions other than to mention just how surprised I was at how enthusiastic people were to see Microsoft involved with the Node effort and how eager everyone was to learn Node. I was thoroughly impressed.
Below are links to my slides and code samples for both talks – enjoy!
Intro to Node.JS
Building Web Apps with Express
One major advantage of developing Node applications for Windows Azure is the ability to have your Node apps managed directly by IIS via iisnode.
You can read more about the benefits of iisnode here, but I want to call out these two points specifically from the iisnode wiki:
Scalability on multi-core servers. Since node.exe is a single threaded process, it only scales to one CPU core. The iisnode module allows creation of multiple node.exe processes per application and load balances the HTTP traffic between them, therefore enabling full utilization of a server’s CPU capacity without requiring additional infrastructure code from an application developer.
Process management. The iisnode module takes care of lifetime management of node.exe processes making it simple to improve overall reliability. You don’t have to implement infrastructure to start, stop, and monitor the processes.
Scalability on multicore servers with Node typically requires developers to...
Troubleshooting “500 Internal Server Errors” in the Windows Azure Emulator when Working with Node.JS
On my primary development machine, where I have tweaked and prodded IIS multiple times for many projects over the past couple of years, I get the following 500 – Internal Server Error message when I try to fire up even the simplest “Hello World” Node.JS project included in the default template for each Windows Azure Node Web Role:
However, when I push the default “Hello World” Node.JS app to a production on Windows Azure, I have no issues whatsoever! So what’s the problem?
The issue is that the Windows Azure emulator:
Following Microsoft’s announcements regarding first-class Node.JS support on Windows Azure, I thought it would be helpful to walk newbie Node.JS and Windows Azure developers through the process of getting their Node.JS development environment set up, building their first simple Node.JS application, and then learning how to take advantage of popular NPM packages like Express to build actual web applications on Windows Azure.
Setting Up Your Node.JS + Windows Azure Environment
First, a big disclaimer: all of the Windows Azure deployment and packaging components require Windows in order to work. You will not be able to deploy your application to Windows Azure without a Windows Vista / 7 box.
That being said, the rest of the setup...