Azure VM – Ubuntu w/ssh keys for putty

Create Azure VM – Unbuntu w/ssh key access

tl;dr;

Create Azure Ubuntu VM – select from gallery – uploading public SSH key so it’s ready when instance is ready.

Create new VM

Create a new VM via the portal manager:
- Select ‘New’ – ‘From Gallery’. Select platform image Ubuntu Server 13.04 for example
- Ensure you check Upload ssh key **(.cer or *.pem) for authentication – and provide a password

Create X.509 certificate (.cer or .pem format)

Create a Private Key on Windows
- Type in the following command at a DOS prompt, with access to openssl.exe
openssl.exe req -x509 -nodes -days 365 -newkey rsa:2048 -keyout myPrivateKey.key -out myCert.pem
Answer the questions that are asked – most can be skipped and use defaults provided if you wish.
- Two files should have been created: myPrivateKey.key and myCert.pem
- If you are going to use the API directly and NOT use the Management Portal, convert the myCert.pem to myCert.cer (DER encoded X509 certificate) using the following command:
openssl.exe x509 -outform der -in myCert.pem -out myCert.cer
- Now you must create a putty compatible PPK (download putty if you haven’t already)
- Run puttygen.exe
- Click the menu: Conversions > Import Key
- Find your private key, which would we named myPrivateKey.key above.
- Click Open. You should see a dialog box saying ‘Sucessfully imported foreign key….’
- Click OK
- Click Save Private Key
Save as myPrivateKey.ppk
Use this key for Putty’s SSL Authorization key

Build and deploy Node.js to Windows Azure Web Site

Node.js on Azure

I’ve been putting this off for far too long, so I finally spent a little time to setup a sample Node.js application running on a Windows Azure Web Site (WAWS). I think my original hesitation came from a (misguided) perception that the project would be limited to specific versions of Node or to certain packages. Don’t worry dear reader, none of this is true. Read on, I think you’ll find it fairly painless.

The plan is to grow this sample into supporting one of my OSS projects SocketIO4Net.Client, so it might include Node packages you don’t care about – include or exclude them as you find appropriate for your particular needs. I will include any updates and descriptions on this blog – so check back later.

So what’s it going to take?

It’s pretty straight forward, you’re only going to need a few things.

  • package.json – you already maintain a package file for your Node app, right?
  • a directory with the version of Node you wish to run – if you want a version other than one of the defaults supplied.
  • iisnode.yml – specific for Azure – we’re going to tell it where our specific version of Node lives.

I’m going to assume that you already know how to setup a empty Web Site on Azure, and configure a deployment option (github in my particular case) for that site. This is all geared for a Windows development environment, so your particular setup could be different. Anyway, here are a couple of screen shots creating the new Azure Web Site for reference:
Create New Site
Deployment options

The complete setup

Working directory / application space

Setup a working directory / repository space in your local development environment. For me, I created a new github repository and “cloned to windows”. You can see my particular setup in the ‘Sample’ branch on github.

The package.json file is the definition file for your Node.js application. Here is where your set the name, version, description and such in a JSON format. The package can also specify dependent and development packages as well – added/updated automatically from npm when you install those packages.

package.json

{
"name": "node-socketio4net",
"title": "Demo Node Server for socketio4net.client",
"description": "Demo Node.js Server for socketio4net.client",
"author": {
"name": "James W Stott",
"email": "@gmail.com"
},
"version": "0.1.0",
"engines": {
"node": "0.8.x || 0.10.x"
},
"dependencies": {
"azure": "~0.7.7",
"express": "~3.2.6"
}
}

I created the package.json by hand, using an empty “dependencies” object definition. From the command line, I then ran the following to install the “azure” and “express” packages (the sample itself doesn’t have dependencies on these packages just yet – but I wanted to set the stage now):


c:\node-socketio4net>npm install azure --save
c:\node-socketio4net>npm install express --save

iisnode.yml

Currently, Azure includes support for the following Node.js versions:

  • 0.6.17
  • 0.6.20
  • 0.8.2
  • 0.8.19

To support a different version (I wanted the latest 0.10.x), so you’ll need to create a iisnode.yml file deployed with the application. Node.js apps in Azure Web Sites are running within iisnode. As such, you can control several configuration options for issnode in a YAML file.

Create a iisnode.yml file in the same directory as your server.js file with the contents:

nodeProcessCommandLine: "D:\home\site\wwwroot\bin\node.exe"

Download the distribution version of node.exe (Windows version) to a bin directory created off of your project root (you can use curl, or download / ftp as you’d like). It is recommended to place the node.exe in the ‘bin’ folder simply to prevent IIS (as a convention) from serving it up as static file.


c:\node-socketio4net>mkdir bin
c:\node-socketio4net>cd bin
c:\node-socketio4net\bin>curl -O http://nodejs.org/dist/v0.10.8/node.exe

That’s It!

That’s about all it takes – so let’s setup a test server.js file and see how things worked out.

server.js

Create a server.js file in your project with the following contents:

var http = require('http');
http.createServer(function(req,res) {
res.writeHead(200, {'Content-Type': 'text/html'});
res.end('Hello from Windows Azure running node version: ' + process.version + '');
}).listen(process.env.PORT || 3000);

If you commit and push your code (assuming again you’ve setup deployment on azure against a repository) – open a browser to your website url.

You should see the following:

Hello from Windows Azure running node version: v0.10.8

You can grab the project files from the ‘Sample’ branch on github.

Keep in Mind

The server.js source is about as simple as you’ll find, but there are some things to keep in mind:

  • No console ‘logging’
  • The port number is retrieved from the process.env port, any application that uses iisnode must explicitly listen on that port.

The default filename iisnode will execute is server.js. If you decide to use a something different, you will need to modify the configuration information in a web.config file. At a minimum, you’ll need to add your new file name to the list of handlers:


<configuration>
<system.webServer>
<handlers>
<add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
<add name="iisnode" path="index.js" verb="*" modules="iisnode"/>
</handlers>
</system.webServer>
</configuration>

 

grunt-azureblob – Grunt task for Azure blob table storage

I released a new Grunt task for copying html assets to azure blob/cdn storage. You can find the package at https://npmjs.org/package/grunt-azureblob

grunt-azureblob is a multi task that implicity iterates over all of its name sub-properties (targets). In addition to the default properties , task specific properties are also available inside each task function. Options are essentially available globally (across tasks), but can be overridden / set at each task level as needed.

To install:

npm install grunt-azureblob

If you are new to Grunt – it’s a javascript task runner. ¬†Think automation for any of the work you have to do like minification, unit testing, linting etc. ¬†Grunt has hundreds of plugins to help automate just about anything you could want in your build/workflow process.

If you try it out, I’d love to hear about it…