Heroku 与 ASP.NET 5

更新于

Heroku

简单来讲,Heroku是一个支持多种语言、极易部署、多价位可免费的 Pass 平台,通过 Buildpack 搭建语言运行环境,
默认内建的大部分是 Web 开发中较为常见的语言,包括但不限于 RubyNode.jsPythonPHPJavaGo 等;
除此之外,还可自建 buildpack 来支持其他语言。

对于 ASP.NET 5 来说,未来应该也会默认集成,现在就只能手动设置了。

Heroku 写的 ASP.NET 5 Buildpack 的地址: https://github.com/heroku/dotnet-buildpack 。但是,目前还有一些问题,不会通过,后面会提到。

→_→私货,自己改动的 Buildpack https://github.com/noliar/dotnet-buildpack

ASP.NET 5 Buildpack 的前期准备

安装 Heroku Toolbelt 并使用

为啥要安装这个呢,主要还是现在的 dashboard 里没有设置 buildpack 的地方。

-=-这其实应该改善下。

安装完成后,登录 Heroku 账号

1
2
3
4
5
$ heroku login
Enter your Heroku credentials.
Email: adam@example.com
Password (typing will be hidden):
Authentication successful.

设置 Buildpack

根据文档介绍,通常我们有两种方式来设置。

新建 App 时设置

1
heroku create appname --buildpack https://github.com/noliar/dotnet-buildpack.git

已有 App 设置

1
heroku buildpacks:set https://github.com/noliar/dotnet-buildpack.git -a appname

设置完成后,就可以随意 git push 代码了

当然你也可以通过 dashboard 直接和 GitHub、Dropbox 连接,然后 Deploy。

ASP.NET 5 Buildpack 分析与说明

Buildpack 结构分析

.profile.d/buildpack-boot.sh

主要是运行环境的一些默认配置

bin/util

一些小套件集合

bin/detect

检验该项目是否为 ASP.NET 5 应用,也就是检测是否存在 project.json,因为 ASP.NET 5 的项目结构一般为
src/ProjectName/*,所以设置的是最多查找三层目录。

bin/compile

看名字就知道这个是编译用的,主要涉及到的是安装 libuvmonodnx-mono 等,编译运行应用。
为啥不选用dnx-coreclr,主要是由于 dnu 命令在*nix coreclr下,有 BUG,最近的 dev 好像修复了,没试过。

基本的使用说明

在项目根目录下新建一个 .deployment 文件,
并设置 project 值。当然你也可以直接设置 Heroku App 的环境变量 PROJECT,只不过我觉得这样改起来比较麻烦。

1
2
[config]
project = src/ProjectName

还要注意的是,别忘了在 project.json 中,添加 Kestrel (beta6)的引用,我就不说我卡在这里多少次了- -||

我的修改版本

目前的修改主要有以下几点:

设置 dnx 版本是稳定版(stable)还是日建版(unstable)

这个功能原版以前是没有的,最近才增加了相似的功能,实现方法也有所不同,当然共同点是默认的为 stable。

Heroku 写的那个目前是通过设置环境变量 UNSTABLE_TOOLCHAIN 值来判断的;
我这个还可以通过 .deployment 设置 stablefalse 来表示 dnx 版本为 unstable。

1
2
3
[config]
project = src/ProjectName
stable = false

修复一些错误

比如缺少的命令,bowergulp等,移除多余的包时的命令错误。
说实话,我都怀疑他本身就没测试过能不能成功运行,
或者只是测试了以前的版本 beta4 之类的,最新 beta6 的默认模板一般都是 gulp,没添加 grunt。
这是给的默认模板,实际上通常的做法可能是直接在 package.json 中添加相关的依赖

原版已修复缺少的命令,但还是没改 rm 多余的包的写法。(9月14日)

更改 Procfile 默认命令

这样的更改是把决定权给予项目所有者,主要是为了适应 ASP.NET 5 API 的不断更改。

主要也就是这种情况:stable beta6 的 Server 通常是 Kestrel,而 dev 的 Server 改成了 Microsoft.AspNet.Server.Kestrel

但这样的更改,导致的是 project.json 中必须要有名为 kestrel 的命令,而不单单是添加引用,忘了的话就会失败。

原版现已做此更改。(9月14日)→_→不过PR啥的都不处理,什么鬼。

从 global.json 读取目标 DNX SDK 版本(9月4日更新)

默认为latest

更新 dnu publish 命令 (9月5日更新)

当不指定 runtime 时,默认会发布依赖的所有运行时版本;当指定 runtime 时,除自身程序编写的依赖,只会发布兼容当前 runtime 的版本

增加 CoreCLR 版(9月16日更新)

coreclr 版在 beta7 出来时就一直在搞,就是没成功,实在不知道为啥,测试了二三十次,dnu publish 一直都会卡在 bower install 那不动,
问题我在 LinuxMint 本地搞他就没有卡啊,难道是因为本地是 NodeJs 4?

本来一直怀疑是它那个广告分析的提醒,所以花了好久这块,各种方法试了遍,他就是不行。
反正一股脑地全上,把NodeJs版本改成4.0,把CI设成true,不知道因为啥,现在是 bower 不卡了。

但是很坑爹的是,编译通过了,但是运行报错,报的啥错呢?说啥不能识别 appbase 路径,我真的很崩溃,
但是更坑人的是我在后面添加了&>err.log,他竟然运行不报错,也没生成这个文件,这是什么鬼,理解不能。

反正我是不动了,试了几次都能运行了,怪了。

不过需要注意的是,目前 coreclr 我没合并到 master 分支,所以必须重新设置 buildpack。

1
2
coreclr分支
heroku buildpacks:set https://github.com/noliar/dotnet-buildpack.git#coreclr -a appname

9月17日,将 coreclr 合并到 master 分支。
默认使用 mono ,若需要 CoreCLR,请在 .deployment 设置 coreclr 值为 true。如:

1
2
3
4
[config]
project = src/ProjectName
stable = true
coreclr = true

不过老实说,DNX CoreCLR beta7 的 BUG 还是有点多,只能指定兼容的 framework,如果project.json中有dnx451,dnx452
之类不兼容的framework,dnu publish 生成时会报错。如果第一个 framework 就是不兼容,dnu restore 就直接报错了。

最后

因为某些原因,heroku 有时会连不上→_→不知道绑域名会不会好点,早知道现在绑域名要先认证的话,
就不删除以前的域名绑定了- -

我一般就拿来测试和放 demo 的 =。=

顺带纪念一下,GitHub的年贡献终于到一百了→_→