Test deploying to Windows Azure

[ErisDS]

We don't imagine it's going to work, but it would be good to know what the blockers are and whether they can be mitigated in some way.

[gotdibbs]

Summary

I tried this tonight against the a 30 day azure trial account. The frontend of the blog seems to run ok out of the box. It's the admin side of things that is borked. Deploy itself goes fairly smoothly.

Specific Issues Encountered

1. Azure uses iisnode to spin up nodejs and manage its lifecycle. IISNode wants you to name your "entry point" server.js and not index.js. This can be resolved by overriding the web.config (eww), or just creating a server.js file that simply requires index.
2. Azure seems to allow file access ok, but I think I'm "paying" for that at the moment. In other words, if you had just a free account, you wouldn't have file access and things like SQLite and uploading images would break altogether.
3. THE BIG ONE. This issue prevented me from really testing too much further. Whenever I try to access anything on the admin side of things (signup, signin, et all), I get this error: "Error: the partial navbar could not be found". The first time I ran it, it couldn't find the notifications partial. I investigated this for quite a while and it seems like node is able to find the partials in the right folder and load them, but something chokes around registering them with handlebars as the handlebars.partials dictionary remains empty. I cannot reproduce on my machine, but I think @cgiffard said he could as well ... so this issue may not be azure specific.

Specifically What Works

These are the things that I noted as working after I removed the partials referenced in default.hbs in the admin views.

1. The blog and it's default theme. Caveat: I haven't looked, but I don't think casper uses partials, so that may not work as well for themes.
2. Content viewing and editing, including image uploads.
3. User settings.
4. Blog settings.

So as you can see really about 95% of it works, its just those darn partials. Might be worth trying to find someone at Microsoft who can help us take a look, or possibly seeing if @cgiffard has some time to step through the express-hbs module on his machine.

Summary of Setup Steps

These are the steps I took to deploy to Azure from my Windows 8 box. Pretty close to the standard deployment notes here.

1. Get latest from GitHub.
2. Run grunt build.
3. Take the build output and place in another folder.
4. Go to that folder, create a file called server.js.
5. In the server.js file, all you need is one line: var GhostServer = require('./index');.
6. Open core\server.js and find the line for server.listen. Swap ghost.config().server.port for process.env.PORT || ghost.config().server.port.
7. Register for Windows Azure.
8. Add a new website using Quick Create, select Local Git Respository as the deployment method.
9. Navigate to the build output copied in step 3.
10. Open a command prompt in the current folder.
11. Run git init.
12. Run git add --all && git commit -m "Initial Deployment".
13. Run git remote add azure [URL OF DEPLOYMENT]. Note the git url in the screenshot below.
    
14. Run git push azure master.
15. Access the website.
16. Profit. 💸

[ErisDS]

I have one question - lots of the platforms like nodejitsu etc work fine until you redeploy. Redeploying overwrites whatever you had in terms of DB & uploaded images.

Any idea whether that's the case with azure?

[gotdibbs]

@ErisDS I have deployed to it about a dozen times, and in the middle I created a post with an image in it. My user account remained valid throughout the duration (evidenced by the fact when I would hit /ghost/signup/ it would always redirect to /ghost/ before crapping out on the partials. Also, my custom post and image in it were maintained throughout the last 3-4 deploys.

Mind you I did not have the database or any images in the deploy and that I was deploying via git, meaning that git was also taking into account the .gitignore file before copying files to the server.

In summary, my understanding is that Azure actually deploys changesets when possible, as opposed to copying everything. If you were to use dropbox as your deployment source on Azure, I couldn't say that we would see the same behavior -- I can test this tomorrow though and update the item.

[ErisDS]

👍 If you could test that tomorrow, that would be fab, the more info we have the easier it is to fix. Left open in 0.4 til that bit is done then will close.

[ErisDS]

Someone on twitter says they have this working.

[gotdibbs]

Thought I had updated the issue. I confirmed the dropbox deployment didn't overwrite anything.

I did see notes on the howtoinstallghost.com site for azure, but the method they used was basically utilizing a VPS. What I was testing out was the shared hosting aspect. Maybe leave this issue open for the shared hosting aspect?

[gotdibbs]

@ErisDS Looks like someone on twitter was able to pinpoint the issue I described. It turns out the __dirname variable is a UNC path for Azure and node-glob does not seem to handle those types of paths well, thus leading to express-hbs not handling those types of paths well.

I think we have a couple of options:

1. We can try submitting a PR against node-glob for a fix, then hoping it gets applied to express-hbs.
2. We can try submitting a PR against express-hbs and try to get them to switch from glob to something like readdirp.
3. We can create our own fork/version of express-hbs

I feel like this would be actually pretty simple to include our own fork/version of express-hbs. Meanwhile, we can also try opening up channels to both the problematic repos' owner's and see if we can't get it fixed in there so we could switch back eventually.

[ErisDS]

@jgable and I have both submitted PR's to express-hbs and had them accepted within a few hours. Providing the PR comes with an explanation of why the change has been made I believe that is the best course of action.

[jbillmann]

I'm actually the guy from Twitter who worked with @gotdibbs on this and unearthed #875 and #876. 👍

I did write up a post on my blog on how to get 0.3.0 up and running, but assuming these fixes work in 0.3.2 (I haven't tested them yet, but am planning on it), the set of steps I described (in conjunction with those above) could be optimized for easier public consumption.

I've actually done a lot of Azure work in my day job (shhh,don't tell anybody 😉 ) and could help put together a doc - including answers to questions about the shared hosting, pricing and file storage limitations.

[gotdibbs]

Welcome @jbillmann!! Glad to have someone else from Microsoft-land around! Funnily enough I literally just was trying out 0.3.2 and it seems to still be balking on loading partials :(

I think it might actually be because of the bump to express 3.4.x. Express is passing the _express3 function in express-hbs an options object which now appears to have options.cache set to true. In looking at express-hbs's source, it appears as though it expects that to be falsey before cachePartials is invoked.

I'm actually heading out for USA v. Jamaica and for the weekend but if you have time to dive into it a bit further and possibly come up with a fix to submit to express-hbs that would be awesome. Assuming that options.cache originally intended to denote that the partials had been cached already, my guess would be that the fix is going to be to use a different variable to check if the partials are already cached and to actually set that variable.

Edit: I just looked briefly looked at express and connect's updates and don't see anything, so this may be something we've done to ourselves.

[jbillmann]

Thanks! 😄

Actually, I also have to head out tonight for a weekend mini-trip - but I can certainly take a look at this on Sunday night.

I do know that bumping express to 3.4.x worked with out 0.3.0 - we'll see.

Keep ya posted or vice versa.

[jbillmann]

@gotdibbs Having NODE_ENV set to production will have an incoming options.cache, within express-hbs, set to true via express. The reason this isn't a problem with version 0.2.2 of express-hbs is that prior to your PR, TryGhost/express-hbs@2b0e370, it would always invoke cachePartials within express3 if there was a partialsDir regardless of options.cache.

if (partialsDir) cachePartials();

Looking at the history of hbs.js within express-hbs, it seems as though this line was intentionally added at some point, but I'm unsure of the context?

Here's where things get really odd. If I add that line of code back in just for proof, fs.realpath within readdirp gets goofy. It does not fire the callback if NODE_ENV is set to production and the path consists of many directories (>7, just like you would see in Azure)... otherwise it always seems to work? Facepalm. I'm at a loss for why this is occurring?

@ErisDS Looking at the comments surrounding the reopen of #875, I think we can take comfort in knowing that it looks as though version 3.4.0 of express is not at odds with version 0.3.0 of express-hbs for this particular issue, rather the PR above unearthed some odd logic with express-hbs caching partials that would be at odds with mostly any version of express.

[gotdibbs]

@jbillmann I just took the latest and pushed it to azure websites and it seems to be working for me with a slightly modified version of express-hbs v0.3.0. Nothing but the defaults in iisnode.yml or in web.config (env set to prod of course). To set the startup script I just did the server.js + require('./index') as mentioned above. Also interesting is that I didn't have to do anything with express 3.4...

I tried two different modifications (both of which worked), the first was stripping out the check for options.cache in the loadDefaultLayout function. The second was setting a local isCached variable to true after paritals have been cached and changing the check in loadDefaultLayout to be if (options.cache && !isCached && partialsDir). Edit: for clarity's sake, here's my last update to hbs.js in gist form: https://gist.github.com/gotdibbs/70e7c53f65cb49c58480

Not sure if maybe you just needed to stop and start your website after making a change earlier? You can see my test instance working here. Username is ghost@tryghost.org and password is Sl1m3rson.