Windows Azure 网站开发Stacks支持

WAWS团队为.NET、PHP、Node.js和Python等Web应用提供版本控制与可扩展性支持。开发人员可通过多种配置文件定制环境,利用平台内置功能或自定义运行时版本。

编辑人员注释:本文章由 Windows Azure 网站团队的项目经理 Daria Grigoriu 和 Windows Azure 网站开发人员体验合作伙伴共同撰写。

Windows Azure 网站 (WAWS) 团队积极投资开发了一款用于开发Stacks的支持模型,可使您的 Web 应用程序快速开始运行,并为您的 Web 应用程序提供增长空间。本博客文章重点介绍了我们用于开发Stacks版本控制和可扩展性的几个基本原则,以及这些原则如何应用到您的 Web 应用程序。

目前我们支持 .NETPHPNode.jsPython Stacks。Windows Azure 开发中心(网址为:http://www.windowsazure.com/en-us/develop)为以上每种Stacks均提供了良好的知识库。您创建网站后即可上传您的内容,只需最少的信息输入,我们就能使其投入运行。

WAWS 开发Stacks版本控制

我们支持的某些开发Stacks(如 PHP)被设计为支持并行版本。对于这些开发Stacks,我们提供了一系列经过验证适用于我们的平台的当前版本。我们还建立了一个默认版本,因此除非您出于兼容性原因更喜欢特定版本,否则无需输入。

其他开发Stacks(如 .NET)被设计为提供某些版本(如 .NET 4.5)的就地升级。在这种情况下,我们努力维护开发Stacks的当前状态,并为您提供最新版本的功能和优势。

对于支持的每个开发Stacks,随 WAWS 提供的版本及相应的版本默认设置摘要可从此链接获取:https://github.com/projectkudu/kudu/wiki/Azure-Web-Sites-Development-Stacks

开发Stacks可扩展性

如果您需要自定义,我们可为每个开发Stacks所提供的扩展点提供支持。

.NET

.NET Framework 已与 WAWS 平台深入集成。

配置

可以使用 web.config 文件指定配置。某些开发人员习惯使用的 apphost.config 文件无法使用 WAWS 直接编辑,但可以使用 XML 文档转换 (XDT) 声明进行修改。apphost.config 中的某些设置(如默认文档),可通过 Azure 门户在网站的 CONFIGURE 选项卡中进行编辑。

可扩展性

可以将可进行 Bin 部署的组件(如 MVC 或网页)添加到您的 Web 应用程序文件夹中。

Node.js

配置

以下是与在 WAWS 上部署的 Node.js 应用程序相关的主要配置文件:

·    package.json

这是一个与跨平台相关的特定于 Node.js 的配置文件。示例用法包括指定 Node.js 模块依赖项(如 Express.js)以及运行时版本号。

·    iisnode.yml

这是由特定的 iisnode 自定义 IIS 模块使用的配置文件。示例用法包括指定用于启动 node.exe 的命令、iisnode 将创建的 node.exe 进程数以及日志记录配置。

·    web.config

这是由 WAWS 平台使用的 IIS 配置文件。此文件会捕获所需的处理程序注册,并允许使用 URL 重写以进行静态文件使用性能优化。

可扩展性

与 WAWS 集成的 Node.js 开发Stacks包括 http://nodejs.org/api 中所述的核心功能。https://npmjs.org 中所述的 NPM 模块生态系统可用于扩展核心开发Stacks功能。package.json 配置文件可用于指定要包括在 Web 应用程序中的模块。如果使用与 WAWS 平台集成的基于 GIT 的源代码版本控制,npm install 会在 GIT push 操作期间运行以提取和安装依赖项。如果使用其他开发机制(如 FTP),则可以在本地开发期间下载和配置模块,并将整个 Web 应用程序上传到 WAWS。请记住,NPM 模块包括跨平台兼容的 Javascript 模块和设计用于特定平台的本机模块 – 对您的应用程序进行测试始终是个好主意。

运行时版本

可以选择 WAWS 平台中包括的任一 Node.js 版本,或者上传和配置自定义 Node.js 运行时版本。可通过 Windows Azure 开发人员中心获取相关说明,网址为:http://www.windowsazure.com/en-us/develop/nodejs/common-tasks/specifying-a-node-version

PHP

配置

在 WAWS 上部署的与 PHP 应用程序相关的主配置文件是标准的 PHP .user.ini 文件。此文件可用于设置可更改的 PHP 指令,如用于诊断的 display_errors。

可扩展性

默认情况下,WAWS 支持一系列核心 PECL 扩展。我们也欢迎您进行自定义扩展。要启用自定义扩展,请在 FTP 根目录下引入 DLL,并在 CONFIGURE 选项卡下添加 PHP_EXTENSIONS 应用程序设置, 其值应设置为 PHP 扩展的位置 (到应用程序根目录的相对位置)。

运行时版本和自定义

通过 Azure 门户访问网站的 CONFIGURE 选项卡时可以进行版本选择。

WAWS 还支持基于 FastCGI 的自定义 PHP 开发Stacks。将开发Stacks上传到网站的根目录下。访问网站的 CONFIGURE 选项卡,并将新的脚本处理器(通常为 php-cgi.exe)与 *.php 扩展名相关联。脚本处理器需要使用绝对路径:例如D:\home\site\wwwroot\php5.5\php-cgi.exe,其中 D:\home\site\wwwroot 表示站点的根目录。

 

Python

配置

与在 WAWS 上部署的 Python 应用程序相关的主要配置文件为 web.config。此文件会捕获所需的处理程序注册,并允许使用 URL 重写以进行静态文件使用性能优化。是否使用 web.config 文件是可选的,还可以通过 Azure 门户中的 CONFIGURE 选项卡指定处理程序映射。Windows Azure 开发人员中心提供了更多信息,网址为:http://www.windowsazure.com/en-us/develop/python/tutorials/web-sites-configuration

可以通过 Azure 门户中 CONFIGURE 选项卡下方的“应用程序设置”更新某些配置选项:

· WSGI_LOG:用于捕获应用程序和配置错误的日志文件的绝对路径

· WSGI_HANDLER:可调用的应用程序对象WSGI协议接受环境时, 还有start_response 函数都会用到它.

此处指定的值必须为模块/程序包名称,后跟要使用的模块中的属性 - 例如 mypackage.mymodule.handler(添加括号以指示应调用该属性)。

· WSGI_RESTART_FILE_REGEX:用于指定文件名的正则表达式

默认情况下,这指的是所有 *.py 和 *.config 文件:.*((\\.py)|(\\.config))$

可扩展性

您可以将程序包放在应用程序根目录下方,并通过 web.config 或应用程序设置配置 PYTHONPATH,以将程序包添加到部署中。WAWS 当前不支持 Virtualenv。

要支持部署任意程序包,请首先创建目录将程序包存储在网站的根目录下方。这类似于在您的 Python lib 文件夹中创建 site-packages 目录,但它位于您的 Web 应用程序中,并部署到 Windows Azure 网站。将程序包复制到此新目录,并将此目录的绝对路径添加到 web.config(例如 D:\home\site\wwwroot\my-packages)的 PYTHONPATH 中。现在,这些程序包可以在 Web 应用程序中导入了。

例如,可以将 Django 包括在应用程序中。首先下载 Django 或将其安装到现有的 Python 安装中。接下来,将 Django 程序包(通常是名为 django 的文件夹,其中包括 __init__.py 文件)复制到应用程序中的某个目录。默认情况下,应用程序根目录会包括在搜索程序包的目录的列表中。如果希望在子目录(例如 mypackages\django)中包括它,可以将父目录添加到 web.config 中的 PYTHONPATH – 在这种情况下,位置应该为 D:\home\site\wwwroot\mypackages。

Windows Azure 开发人员中心提供了更多信息,网址为:http://www.windowsazure.com/en-us/develop/python/tutorials/web-sites-with-django

运行时版本和自定义

欢迎使用基于 FastCGI 的自定义 Python 开发Stacks。可以将自定义的开发Stacks上传到网站的根目录下,并将网站处理程序映射配置为包括基于 FastCGI 的脚本处理器的绝对路径。

我们一如既往地期待您的反馈,请通过论坛反馈告诉我们如何更好地满足您的开发Stacks需求。

本文翻译自:

http://blogs.msdn.com/b/windowsazure/archive/2014/01/10/windows-azure-websites-development-stacks-support.aspx

首先简要介绍一下目前的站点功能吧。右图就是本站的主页效果,我得很简洁,没有用太多花哨的图片,也没有用走马灯。明眼人一看就知道这是基于ASP.NET MVC而开发的Web应用程序,使用了Bootstrap。不错,基本答对!需要强调的是,这个博客站点以及后端的RESTful服务,全部都是基于ASP.NET Core完成的,.NET Core运行时版本为1.1.0,运行在Docker容器中。哎,说着说着又到技术上了,功能还没介绍完呢。说到功能,目前功能很简单:主页列出了我自己原创或者翻译的所有文章,读者可以注册用户帐号,注册用户可以发表评论,也可以在用户管理页面中更改自己的昵称。好了,目前功能就这么多,别看功能少,我可是前前后后陆陆续续花了2个月的时间,才到目前这个样子。当然,我会继续更新这个站点,让它的功能变得更加完善。提到ASP.NET Core,有没有吊起你的技术胃口呢?不用着急,接下来我就介绍一下整个站点中各部分的技术选型,看完后,或许你会知道为什么我花了2个月的业余时间,才整出来这么个简单的玩意儿。站点技术介绍整体架构整个网站所采用的所有基础设施全部运行在微软Windows Azure)中,使用了部分托管资源,以及一些非托管的Azure VM。大致情况如下:图片存储服务:由Azure Blob Storage Service托管数据库系统:由Azure SQL Database托管(未启用Geo-Replication,因为没钱)邮件服务:由Azure SendGrid Account托管(Pricing Tier为F1,每月可以免费发送25000封邮件)应用服务器:基于Azure构建的Ubuntu 16.04.1 LTS虚拟机,运行了两个Docker容器:blog-web和blog-service,分别托管前端Web站点和后端RESTful服务。后端RESTful API服务没有任何认证和授权,Web站点通过内部子网访问RESTful API服务,Docker容器运行在非托管环境中持续集成系统:Jenkins,基于Azure构建的Windows Server 2012 R2一台(Master),和一台Ubuntu 16.04.1 LTS(Slave)。站点的前端和后端都在后者(Ubuntu)中完成编译、打包以及Docker镜像的发布,实现了一步到位的部署方式代码库:Github有人会问:为什么使用了非托管的Azure VM环境运行应用系统?我也考虑过这个问题,理论上讲,基于的系统架构最好选用托管的PaaS服务,这样不仅可以得到纯天然的高可用性(包括灾备,比如AWS的跨AZ部署,某些服务跨区域的可用性,以及负载均衡),而且还可以得到专业的技术支持。只有当存在老系统向迁移的需求,并需要迎合老系统的特定运行环境要求时,才考虑使用IaaS服务。虽然虚拟机等这些资源是由Azure负责创建并运行的,在这一层面Azure可以保证虚机的可用性,但虚机内部运行的任何程序的状态,以及所使用的数据,Azure服务是无从得知的,对这部分东西的监控也会变得很麻烦。出于安全考虑,通常服务供应商是不会,也不应该获得类似虚机内部的客户程序的运行数据的,使用虚拟机服务所产生的程序运行风险,客户需要自己承担。这也就是著名的责任共担原则。看起来用虚拟机运行应用不是太靠谱嘛,然而我却选择这么使用了。有几个原因:为何不使用Azure Web App?一方面Jenkins自动化部署,直接把编译好的应用推送到Azure Web App中好像不是太顺手,要写一些PowerShell的代码,可是我的编译系统是Linux,不过现在已经有Linux版的PowerShell了,而且Azure SDK Command Line Interface也有Linux版,所以这个理由有点牵强,更合理的解释是:劳资不会!另一方面,我没有在服务端认证和授权,仅通过子网向外界提供服务,所以我希望我的Web App也运行在子网内部,然后向外暴露80端口供外界访问。这样一来,Azure Web App又如何部署到我自己的子网内?这是一个技术问题,我相信一定有解决方案,但是我也没太多时间和精力去细究如何实现,自己的第一反应也无非是将前后端全部部署在Azure Web App中,然后打开后端的认证机制。但这样又要花一些额外的工夫。好吧,还是这个理由:劳资不会为何不使用Azure Container Service?Azure Container Service会在你指定的Resource Group(资源组)中创建一整套网络部署,包括好几台虚拟机、公网IP、两个负载均衡器等等,我想你一定知道我为什么没有选择Azure Container Service了,原因就是:劳资没钱理由够充分吧?微软Windows Azure提供的这些服务都很赞,我没选不是说它们不好用,而是出于自己的实际情况考虑:某些服务的学习成本经济成本暂时没必要到99.99999%的高可用率即使应用挂了,恢复的成本很小:数据完全不需要恢复,托管的SQL Database、Blob Storage会保证我的数据不丢失,应用程序恢复也很简单:重新运行Docker容器就完事儿OK,从整体架构上看,我的选择即是如此而已,这样的选择当然不一定完全正确,但我觉得至少合适,仅供参考。下面附上本站点的整体架构图。作几点注解:三台VM位于同一个Virtual Network的subnet中,每台VM的虚拟网卡上都套有独立的Network Security Group(NSG),在NSG上设置了Inbound/Outbound Endpoints,严格限制了端口访问的IP地址。三台VM之间使用subnet IP地址访问Windows Server 2012 VM宿主了Jenkins Master,以及Seq日志服务。它向公网暴露8080端口和5342端口,分别用于访问Jenkins服务和Seq管理界面第一台Ubuntu VM运行了Jenkins Slave,它不向公网暴露任何端口,仅向Jenkins Master机器暴露22端口,用于Jenkins Slave Agent的执行调度第二台Ubuntu VM运行了博客系统的两个Docker容器:前端应用程序blog-web和后端RESTful API服务程序blog-service。web通过子网IP地址访问service,VM仅向公网暴露80端口,后台service无法从公网访问两个Docker容器所运行的应用(blog-web和blog-service)都可以访问托管的Azure SQL database、Azure Storage blob和SendGrid Account服务整个部署的拓扑结构有可能不太合理,比如没有负载均衡,没有使用托管的应用宿主服务(比如Azure Web App、Container Service等),没有使用Scaleset。因为目前没必要而且没钱更多说明,详见作者的博客:http://daxnet.me/blogposts/post/221 标签:daxnet
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值