Ранее на этой неделе Брайан опубликовал веб-сайты Windows Azure: перспективу PHP, которая содержит много полезной информации даже для разработчиков, не использующих PHP. На самом деле, вероятно, 90% этого полезны для всех, кто заинтересован в использовании новой функции веб-сайтов.
Но есть некоторые конкретные вещи, которые разработчики Node.js должны знать о новой функции веб-сайтов.
Обнаружение узла
Если вы изучили интерфейс портала для веб-сайтов, вы, возможно, заметили, что есть настройка для включения PHP, но нет настройки для узла. Вместо этого веб-сайт ищет наличие файла app.js или server.js в вашем развертывании и включает функциональность узла, если любой из этих файлов присутствует.
Когда app.js или server.js файл обнаружен, web.config , файл будет создан для развертывания , который содержит информацию о конфигурации , требуемой iisnode . Обратите внимание, что этот файл не добавляется в удаленный репозиторий git, поэтому, если вы извлекаете файл из git-репозитория веб-сайта, вы не получите этот файл. Вы можете использовать ftp для подключения к серверу и найти его в каталоге wwwroot, который содержит ваш веб-сайт.
Конечно, вы можете создать свой собственный файл web.config как часть вашего развертывания, который будет использоваться вместо автоматически сгенерированного.
Настройки приложения
На портале для вашего сайта, в разделе конфигурации , есть область настроек приложения, где вы можете ввести пары ключ / значение. Они отображаются как переменные среды в вашем приложении. Например, если я установлю ключ ‘foo’ со значением ‘bar’, то я смогу получить доступ к process.env.foo, чтобы получить значение ‘bar’ в моем приложении.
В этом есть одна хитрость, которую я всегда забываю; Вы должны нажать на значок сохранения в нижней части портала, чтобы сохранить настройки конфигурации.
Это одна из тех вещей, которая отлично подходит для установки значений, которые вы должны использовать, но хотите сохранить безопасность. Как строки подключения, имена пользователей и пароли и т. Д. Другой вариант — использовать его для значений, которые, как вы знаете, изменятся в будущем, но которые вы не хотите делать для полного повторного развертывания.
Серверная сторона npm
Так что же произойдет, если вы развернете проект, который не содержит папку node_modules ? Что ж, если у вас есть файл package.json, в котором перечислены необходимые модули, Windows Azure фактически запустит npm на вашем веб-сайте и попытается установить эти модули. Это можно увидеть, создав новый экспресс- сайт с помощью команды express, а затем развернув его на веб-сайте с помощью git. Вы увидите ожидаемый вывод из git, но затем вы увидите вывод, похожий на следующий:
remote: New deployment received. remote: Updating branch 'master'. remote: Preparing deployment for commit id '3f69628e8c'. remote: Preparing files for deployment. remote: Running NPM. remote: npm http GET http://registry.npmjs.org/jade remote: npm http GET http://registry.npmjs.org/express/2.5.8 remote: npm http 200 http://registry.npmjs.org/express/2.5.8 remote: npm http GET http://registry.npmjs.org/express/-/express-2.5.8.tgz remote: npm http 200 http://registry.npmjs.org/express/-/express-2.5.8.tgz remote: npm http 200 http://registry.npmjs.org/jade remote: npm http GET http://registry.npmjs.org/jade/-/jade-0.26.1.tgz remote: npm http 200 http://registry.npmjs.org/jade/-/jade-0.26.1.tgz remote: npm WARN excluding symbolic link lib\index.js -> jade.js remote: npm http GET http://registry.npmjs.org/mime/1.2.4 remote: npm http GET http://registry.npmjs.org/qs remote: npm http GET http://registry.npmjs.org/mkdirp/0.3.0 remote: npm http GET http://registry.npmjs.org/connect remote: npm http 200 http://registry.npmjs.org/mime/1.2.4 remote: npm http GET http://registry.npmjs.org/commander/0.5.2 remote: npm http GET http://registry.npmjs.org/mime/-/mime-1.2.4.tgz remote: npm http 200 http://registry.npmjs.org/qs remote: npm http 200 http://registry.npmjs.org/mkdirp/0.3.0 remote: npm http GET http://registry.npmjs.org/qs/-/qs-0.4.2.tgz remote: npm http GET http://registry.npmjs.org/mkdirp/-/mkdirp-0.3.0.tgz remote: npm http 200 http://registry.npmjs.org/connect remote: npm http GET http://registry.npmjs.org/connect/-/connect-1.8.7.tgz remote: npm http 200 http://registry.npmjs.org/connect/-/connect-1.8.7.tgz remote: npm http 200 http://registry.npmjs.org/qs/-/qs-0.4.2.tgz remote: npm http 200 http://registry.npmjs.org/mkdirp/-/mkdirp-0.3.0.tgz remote: npm http 200 http://registry.npmjs.org/mime/-/mime-1.2.4.tgz remote: npm http 200 http://registry.npmjs.org/commander/0.5.2 remote: npm http GET http://registry.npmjs.org/commander/-/commander-0.5.2.tgz remote: npm http 200 http://registry.npmjs.org/commander/-/commander-0.5.2.tgz remote: npm http GET http://registry.npmjs.org/formidable remote: npm http 200 http://registry.npmjs.org/formidable remote: npm http GET http://registry.npmjs.org/formidable/-/formidable-1.0.11.tgz remote: npm http 200 http://registry.npmjs.org/formidable/-/formidable-1.0.11.tgz remote: [email protected] ./node_modules/jade remote: ├── [email protected] remote: └── [email protected] remote: remote: [email protected] ./node_modules/express remote: ├── [email protected] remote: ├── [email protected] remote: ├── [email protected] remote: └── [email protected] ([email protected]) remote: SetConsoleTitleW: The operation completed successfully. remote: remote: Deploying Web.config to enable Node.js activation. remote: Deployment successful.
Однако следует обратить внимание на модули, использующие node-gyp для компиляции собственных битов во время установки. В среде веб-сайтов нет вещей, от которых зависит доступность узла (например, Python), поэтому переход к узлу завершится ошибкой. Обходной путь — установить и собрать собственный модуль в системе Windows, а затем развернуть папку node_modules как часть развертывания git. Таким образом, скомпилированные биты уже есть.
WebMatrix
Одной из наиболее интересных вещей для разработчиков узлов (которые используют Windows) является новый WebMatrix 2. Теперь он поддерживает создание приложений узлов, включая шаблоны для базового экспресс-сайта и «начального сайта». Начальный сайт основан на экспрессе, но также включает в себя Everyauth, socket.io, хорошую тему и функциональность чата. Это в значительной степени полнофункциональный сайт для вас, чтобы настроить и развивать. Существует руководство по использованию WebMatrix с Node, которое поможет вам создать простой экспресс-сайт.
Инструменты командной строки
Еще одна новая функция в этом выпуске — инструменты командной строки, которые реализованы в узле и, вероятно, должны работать на любой платформе, которая может использовать последнюю версию node.js. На сайте http://www.windowsazure.com/en-us/develop/nodejs/ доступны установщики, которые выполняют такие функции, как установка узла, если у вас его еще нет. Но если у вас уже есть узел, вы можете просто запустить npm install azure -g. После этого у вас есть доступ к команде Azure.
The azure command provides functionality for working with a bunch of stuff in Azure, but I’m going to focus on the web site related functionality since that’s what this article is about. The web site commands all start with ‘site’, for example azure site create creates a new site, while azure site delete deletes an existing one. You can get a list of the commands by entering azure site, or help with a specific command by using help such as azure help site create. For more information on the command-line tools, see How to use the Windows Azure Command-line tools.
Import subscription information
Before using the azure command to perform actions against Windows Azure, you have to first download and import your site configuration. You can do this by using azure account download command, which will open a browser and prompt you to login to your subscription and download a .publishsettings file. After you have the file, use azure account import [path to the .publishsettings file]. This stores your subscription information in a .azure directory under your user account home directory. This info is pretty sensitive, so you should secure the folder so only you have access to it, and delete the .publishsettings file after you’ve finished the import.
Work with web sites
One of the neat things you can do with this is to create a web site, initialize git both on the site and in the local directory, and automatically create an ‘azure’ remote. You can do this by using the —git parameter, like this:
azure site create mysite --git
You’ll be prompted for a few things, such as the username for your Windows Azure git configuration, and then it will initialize a local repo and setup a remote for the Windows Azure Web Site. One slight catch to all this; you can’t use the command-line tools to create your first web site. That currently has to be done using the web portal.
The other web site specific commands are pretty much what you’d expect; list, delete, etc. But there’s one more I’d like to call your attention to, the deployments command. You can use this to list out all the deployments that have been performed against a web site, view information for each specific deployment, and even roll back to one of the earlier deployments. For example, if you use azure site deployment list [sitename] you will see a response similar to the following:
info: Executing command site deployment list + Enumerating deployments data: Time Commit id Status Author Message data: ------------------- ---------- ------- ------------ -------------- data: 2012-06-14 13:02:40 701bf5deb6 Active Larry Franks updating view data: 2012-06-14 13:00:58 297712b7bc Success Larry Franks initial commit info: site deployment list command OK
This tells you that there have been two deployments, and the currently active one has a commit id of 701bf5deb6, but that there was a previous commit. If you want to see more information on that commit you can use azure site deployment show 701bf5deb6 [sitename]. You can specify a -d option to show detailed information also. Let’s say that the new deployment is somehow busted and you need to switch back to the previous one. To do that, you can use azure site deployment redeploy 297712b7bc [sitename] and enter Y when asked if you’re sure about the redeploy. This will process a little bit and return something similar to the following:
+ Redeploying deployment + Enumerating deployments data: Time Commit id Status Author Message data: ------------------- ---------- ------- ------------ -------------- data: 2012-06-14 13:02:40 701bf5deb6 Success Larry Franks updating view data: 2012-06-14 13:12:12 297712b7bc Active Larry Franks initial commit info: site deployment redeploy command OK
Note that the deployments are still listed in the order of newest to oldest, but that the older deployment, 297712b7bc, is now Active. Now, if you’re more of a UI type person, you can do the same thing from the Deployments section of your web site using the new preview portal. That will list off your deployments, and let you select and roll back to a previous one also.
In conclusion
That’s just a brief look at some of the Node.js specific things with Windows Azure Web Sites. The Web Sites feature is pretty neat, though still in preview. So expect it to gain functionality as we go along. We know there are things people want that aren’t quite there yet (like SSH for Git instead of HTTPS,) and are listening to your feedback on what you’d like to see with Windows Azure in the future. If you have a suggestion or feedback on how we can improve Windows Azure, go to http://www.mygreatwindowsazureidea.com/ and enter it.