-
-
Save benmccallum/226ae1b428157b9d5998a5ba27eadf59 to your computer and use it in GitHub Desktop.
Previously this gist had a series of files showing a working setup, but, | |
@burkeholland found a much easier way and demonstrates it here: | |
https://github.com/burkeholland/nuxt-appservice-windows | |
Essentially, you'll: | |
1. add a .deployment file to instruct kudu to run `npm install` for you, | |
2. leverage npm tasks' `postinstall` hook in package.json to trigger the full nuxt build, | |
3. add a server.js file in the root that `require`s the default server\index.js file that a nuxt app will already have | |
Step 3 will be noticed by kudu, which will: | |
* auto-create you a default web.config for iisnode (if no web.config exists), and | |
* use that server.js as the entry point, which you've now redirected over to nuxt's default server.js cleanly | |
Notes: | |
* For step 3, you'll only have a `server\index.js` if you've chosen a server-side framework in the `npm create nuxt-app xyz` setup. | |
I had success with express. | |
* Don't forget to make sure your Azure app is on a high enough node version for both running AND building. | |
You can now create apps from the portal with a version picker which is nice. | |
Otherwise you'll wanna configure it with the app setting for runtime and in the .deployment config file for kudu/building. | |
Kudus to Burke! (pun intended) |
Ah! That's a great point! I forgot about the scaffolding and that people might choose other servers. In that case, this is going to depend on where their entry point is.
On the .deployment
file, the reason for specifying the minimum Node version in there is that not all entry points to creating an application prompt for a Node version. For instance, you can create a Windows AppService instance via the VS Code extension and it never asks. Even if you specify an engines
node in your package.json
, Kudu will STILL use the default Node version and that can be confusing.
Great suggestions on the music. I'll check these out!
Hi,
I try to deploy a nuxt app on Azure, in a virtual app and i've got an error code 500. If i deploy in wwwroot instead of my virtual app, all work fine. Have you a tips about that ?
Eek, a virtual app? That's going to be nasty I'd imagine. Can you repro in IIS locally? If you can do that then put the code in a repository here on GitHub, then we could troubleshoot it that way.
We have a solution. / point on an empty folder. Then, subfolder work fine.
We also updated Nuxt to the last version (2.10.2).
Thanks,
Thanks for the guide! Finally I was able to run my nuxt app on Azure (Windows machine). What it bothers me a bit is the fact I had to add express package. I would like to know how to accomplish the same but without using express. I guess it should be possible, right? Since I was able to develop and run on my local Windows machine.
PS: I skipped the deployment part of the guide, since my first goal is to check the process manually.
Hi @julen-folky, unfortunately my knowledge here is very lacking. I checked the Nuxt docs again, and still, IMO, they've never explained well the choice you need to make for the integrated server-side framework. I wouldn't expect them to do a full comparison, but at least a one of two line about each and whether or not you can use the built-in server for most/few cases. Sorry I can't help. Perhaps we should submit an issue to the nuxt repo.
Hi, ben. Where should the issube bet submitted to? Point is the question is not an issue but just a question.
@julen-folky, here maybe: https://github.com/nuxt/docs/issues
I can post something tomorrow if I get some time.
Thanks ben!
No worries @julen-folky. How's this? Feel free to chip in any thoughts.
https://cmty.app/nuxt/docs/issues/c243 and associated GitHub issue.
Wow! The post perfectly describes the problem. Thanks again!
@julen-folky, no worries. It's easy to describe because I come from the same place and have always wondered the same. I'm a dotnet dev, not a node dev :P Hopefully we get a good answer and some action on it!
I posted on Stackoverflow on the neccesity or not to restart the node process with every deployment.
Sorry if this is not the appropriate thread, I thought it may be of interested for the people following it.
I think it's a good question and happy for it to be in this thread. I guess my thinking is that as long as you get your built files inside the wwwroot, then IIS / AppPool doesn't really have an impact, it's just a thin web server layer handling requests and routing them to the node app.
If IIS/AppPool was doing something else, like in-memory caching or the like, depending on the mechanism, you may need to start thinking about an app pool recycle / cache bust, but if the web.config doesn't have anything like that, it's safe to say you'll be fine without one.
Looks like is like you say @benmccallum. Today I checked by chance the page on Azure of the nuxt guide; in the web.config example, by the end there is an explanation about defining a set of files to be watch and recyle the server if they change.
Nevertheless, I would ask for further clarification to a NodeJS/Express expert.
Good spot! I guess if you were doing in-memory caching (inside your node app of config files or something) then it makes sense that you'd need to configure watching of those files to restart the app. Since they haven't indicated anything in particular I'd say that nuxt itself doesn't do anything like this or can handle those kinds of filesystem changes. Static assets (those picked up by the static rewrite rule) will cache bust themselves as part of standard IIS if you had static asset caching I imagine (which isn't demonstrated here but should probably be turned on).
FYI, I didn't need the .deployment files' config line for node version as I picked a node version that was supported on windows in the App Service setup experience. That being said, I do think that it's a good idea to set this in .deployment and likely also in the app setting so you've got explicit build and runtime versions being used.
PS. Lots of metal. If you want something else, particularly some Aussie music which you may not have heard of: