玄奘之旅——道路在脚下,修行在心中

从敦煌回来已经有一周了,总的来说,这次戈壁行收获满满!

回想刚开始阿里的同学邀请我作为MVP代表参与本次戈壁行的时候,我还有点犹豫。有点担心100多公里,3天半我能不能走下来?后来想了想,走路我也没怕过谁,毕竟也是靠运动减了50斤肉的男人,就这样毅然决然的踏上了前往敦煌的路。

南京直飞敦煌,大约5小时,在快到敦煌的时候透过窗户看地面,大地只有一个颜色——土黄,作为一个从小生长在江南的人感觉很惊奇,也很感慨造物神奇。images出了机场坐车90分钟后到了据说是榆林县最豪华的酒店——榆林宾馆,办好手续入住。

这天晚上,阿里的HR同学和玄奘之旅线路的栋哥给我们做了动员,也和我们讲述了 “沙克尔顿”的故事,其内涵就是:作为一个团队,一个都不能少!

作为6队的一员,我们一起制作队旗,构思口号,这一刻我们的凝聚力开始酝酿!(PS:队长金童,灵魂画手)

从这个故事开始,戈壁之行就蒙上了一层非凡的色彩,让我从心里明白,前方的路不好走,这不是一次旅游、散心!这是一次大自然对你的考验,也是一场走进心灵的修行。

那一晚,我睡的不太沉,也不知道是对新环境的不适应,还是对第二天的憧憬……

到达敦煌的第二天,也是戈壁行的第一天。

早上起来后,用早饭。大家各自背包,在背包里装上3公斤的水,带上一袋干粮,领上GPS、对讲机之后就准备出发了。出发前我是这样的造型:

images

其实不论男女,每个人的包至少都有5公斤的份量,我看着本次活动仅有的几个女同学,真有点替她们担心,心里还想着是不是在她们不行的时候帮衬一把,展示一下我的绅士风度。

大巴90分钟,到达了戈壁行的起点,感觉良好,微风拂过还蛮舒服,太阳也不是很大,一切都预示着这是一个良好的开端。大家把装备穿戴整齐,在起点合影后就出发了。

我不仅和6队的同学拍了合影,还和其他几位阿里云MVP合影留念了,毕竟这也是MVP团体第一次深度参与到阿里云的团建活动中,意义非凡。

images

一路走走停停,聊聊天,靠着郊游心态,不知不觉的我们队就排在了最后,反正风和日丽,体感舒适,谁在乎快慢呢?还看到了当地的野生滋补品——锁阳。

images

但是,意外很快就出现了,走了快2小时的时候开始起风了,并且越来越大。这时戈壁上尘土飞扬,路开始有点难走了。

勉强走了30分钟后,我们遭遇了本次戈壁行最艰辛的8公里,整整逆风顶着沙尘暴走了3个小时。用一句阿里云风格的话概括就是:“6队全体成员全量承接了本次沙尘暴的所有流量”。其他队因为走得比我们快,只被沙尘暴蹭了一下,倒没什么大碍。

这就是戈壁给我的第一课,也许前一刻看上去风平浪静,但是下一秒就是黄沙漫天。想到自己刚跨到了金融行业,又何尝不是如此,市场瞬息万变,没有永远的晴天。

放张图,给大家感受一下沙尘暴:

images

走完了沙尘暴,我们还经历了下雨,虽然雨不大,但是小概率事件全让我们遇上了也是奇葩。就这样,磕磕碰碰,我花了10个小时,赶在晚上6点前到达了营地。看到营地的那一刹有种热泪盈眶的感觉。在夕阳下,搭好了自己的帐篷,大家做做活动,拉伸拉伸。

images

images

拉伸完,大家开开心心吃了顿晚饭,伙食不错,羊肉不限量供应,烧的又好吃。酒足饭饱之后,回到帐篷里,就休息了。

这里晚上9点钟,太阳还在头顶,而早上6点天就亮了,所以白天时间很长,夜晚很短,稍微有些不适应,加上大家的帐篷太密集,半夜呼声震天,在戈壁的第一晚,睡得并不是很好。

戈壁第二天,6点就吹集结号喊起床了,大家的状态都不如第一天好了,加上第二天的公里数最长,有将近33公里,所以大家脸上的笑容也逐渐消失。

惯例每人三公斤水,一包干粮就上路了。

当天要走33公里,我以为已经很糟糕了。

更糟糕的是,太阳很大,温度极高。

最糟糕的是,早上我忘记带干粮了!

所以,走到16公里休息站的时候,我靠着大伙和工作人员的施舍勉强填饱了肚子。很感动!

感动不是他们给了你一个苹果、几块个牛肉干、半个饼。感动的是他们也是负重前行,带着食物走出十几公里,却毫不犹豫的分享给了你。

最后4公里,是沙漠。回来的同学都说,这是整个行程里,最不好走的路。地面很烫,脚会陷进去,尘土大,没有遮阴休息的地方,沙丘林立看不见导向旗,体力消耗大。

images

我却觉得,整个行程最有意思的就是这4公里。

你,孤身上路。

你,弹尽粮绝。

你,只能行走,不知终点何处。

这一刻我感觉,人生种种,不过如此,整个人突然之间很豁达。

以前遇到事情的时候,总是困在心里走不出去,这一刻我抬头看万里晴空,低头看茫茫沙漠,淡然一笑,原来,也不过如此。

我找到了,戈壁给我的第二课,就是我一直欠缺的心境,一种乘风破浪,直面苍穹的勇气。

images

最终花了12个小时整,到达营地。到了营地之后,我还在想,起初还想着路上有条件照顾一下几个女同学,没想到我走了2天从头到尾连她们影子都没看见。她们连续3天都进前三甲,普遍在前十名,啪啪打脸。

这是戈壁给我的第三课,不要小瞧任何人,越是不可能,越是创造不可能。

晚上,还有一个插曲,因为当天没有手机信号,只有在一个小山的山顶上才有微弱的信号可以打电话。有位同学,走了一天回到营地不仅没休息,又爬上了这座山,到达山顶后,不是为了看山下的风景,而是为了有手机信号开一个电话会议。

这一刻,我看到了阿里人身上的光芒!

戈壁第三天,穿过一片绿洲,感觉还是很神奇的,茫茫戈壁,土黄土黄的山脉中居然藏了一片净土,真的是造物神奇,钟林神秀。

戈壁第四天,也就是最后一天,早上4点30就起床了,因为今天是个人赛,会分别给男女前三甲发放奖牌,所以很多人提前一晚就开始摩拳擦掌了。

因为我这几天状态都不错,完全没感觉到特别累,脚也好好的,没起泡没受伤,出发前有一刹那我甚至在想,要不今天拼一把夺个名次?直到我看到哨声一响,有几个人和兔子一样快跑前进时,我就放弃了这个不切实际的想法。

我们6队有一位队员,第一天就伤了膝盖,每天都是以大毅力走回营地,坚决不上车。虽然每天名次不高,但是能这样坚持下来,我们都觉得非常不容易,所以我们全队决定个人赛放弃名次,我们要发扬“沙克尔顿”精神,一个都不能少!我们要全队到达终点!

所以我们沿途都是这样走的:

images

对受伤走不动的队员,我们就用登山杖拉,用手推着爬坡,用肩膀托着下坡,就这样我们不仅把本队的伤员带回了终点,甚至还把5队的伤员也一起带回来了。

能和6队的兄弟分在一组,我倍感荣幸。特别是在行程结束后,这种感觉更强烈了。

也许,我们6队在这次戈壁行中成绩不是最出彩的,但是我们一定是最团结,最富有“沙克尔顿”精神的团队!

很感谢阿里巴巴提供了这样的一个机会!最后献上我们6队的一张合影,和我在沙漠中的囧照!

images

从戈壁回来后1个礼拜,我时常在想,当年玄奘法师的成就究竟是得自佛国经文,还是源自西行之旅的一路修行。所以,也就有了这篇名为《玄奘之旅——道路在脚下,修行在心中》的游记,至终将西行的你。

居然得了水痘,很逗!

可能是最近在高铁站被别人传染了,回来发了2天的烧,然后一个个出疹子。去医院看,不收治,只能去江宁的传染病医院看,折腾一上午,开了几盒药。

张老师说,人在艰难时,会出现心理倒退现象,所以可能会从心理层面反馈到生理层面,否则成人的免疫力很难得水痘的。说的也有点道理吧,哈哈。

过分在意主流意见的弊端

前段时间,《缝纫机乐队》和《羞羞的铁拳》同时上映,我先看的缝纫机,感觉很好,算得上用心。但是看完在淘票票里发现清一色的说垃圾,不如铁拳云云,当时觉得心情有点复杂,我如果先看到了评论,我还会去看嘛?我还会觉得好看吗?这是值得反思的,内心强大的人可以不被别人影响,但是你可以时时刻刻不被别人影响吗?很难。

如同我看完《妖猫传》,觉得是一部精品,陈凯歌这次的作品还算可以,演员偶有瑕疵,可以理解,整体的盛唐气息,贵妃气度,都表现的淋漓尽致。但是评论还是清一色的喷,但据说最近头条风气开始变了,觉得这片子分数能涨点。

所以,过分在意主流意见未必是好事,因为主流意见是可以被引导的。生活是如此,技术也是如此。

云效(原RDC)如何构建一个基于Maven的Java项目

最近在将公司的持续集成架构做一个系统的调整,调整过程中受到了RDC团队大量的帮助,所以利用国庆时间写了几篇RDC的分享,希望能让更多的人了解和用好RDC这个产品。

我会把我最近3个月的使用体会分成5个部分:使用RDC的动机、PHP项目集成、JS项目集成、JAVA项目集成、Docker类项目集成这5个分支来写

因为近期RDC的迭代比较频繁,所以我的分享会比较的浅,点到为止,仅供参考,目录:

1、RDC如何耦合进我们的业务

2、如何构建一个基于Composer的PHP项目

3、如何构建一个基于NodeJS的前后端项目

4、如何构建一个基于Maven的Java项目

5、RDC + 容器服务完成持续集成


一、RDC基础操作

在开始一切之前您需要熟悉RDC的一些基础操作,创建一个项目,然后在这个项目中创建一个应用,然后让这个应用关联某个代码分支。这样基础工作就完成了,我这里不再赘述了,因为比较简单,只需要注册个阿里云账号,然后去 rdc.aliyun.com 创建/加入个企业就行了。

本文所有的体验均基于【自由模式】的应用。

值得一提的是,应用代码源目前支持的是阿里云的代码仓库,基于gitlab,地址是 code.aliyun.com,从我2年的使用经验来看,还算好用,也不收费,较为靠谱。

在创建应用时,我们需要选择对应的配置

创建完应用后,进入【项目】–》【流水线】,找到刚才创建应用的【同名流水线】

点击流水线名称可以看到具体的流水线运行情况和对应节点

可以看到有4个面板:构建、日常、预发、正式。

分别对应的是:构建打包、发布到日常环境、发布到预发环境、发布到正式环境。

RDC在创建应用时自动的为你生成了一个标准模板流水线,但是我们一般用不着,所以需要对流水线进行修改,去除无用的节点,添加我们自己的配置。点击界面上的【编辑流水线】按钮就可以进入修改界面。

我们先从构建开始,所以先暂时删除日常、预发、正式这3个部署节点,仅保留构建这一个节点即可。下面的配置暂时不进行调整。删除完毕后保存流水线即可,效果如下:

至此我们已经完成了基础的准备工作,下一步就开始进行代码的构建工作了。

在开始下一步工作之前,请重新git pull一下您的代码到本地,会看到一个由RDC服务自动生成的配置文件:xxx.release 这个文件相当重要,请注意,下面将会说明如何通过此文件完成个性化构建。


二、基于Maven的Java项目构建

因为java类项目一般都通过maven来维护第三方库,并且一般会通过maven来进行构建,所以在RDC构建时需要完成依赖下载及编译的相关工作。

这里需要找到我们上一章节中提到的:xxx.release 文件,xxx代表你的应用名,所以我这里看到的文件名是:ms-autotags.release

这个文件的配置规范可以参考:https://help.aliyun.com/document_detail/59293.html

打开这个文件可以看到,已经有一些预先定义好的配置:

# 构建源码语言类型
code.language=scripts

# 应用部署脚本
deploy.appctl.path=deploy.sh

# Docker镜像构建之后push的仓库地址
docker.repo=registry.cn-hangzhou.aliyuncs.com/xxx/abced

上面的配置是不能用的,我们需要将其修改为如下内容:

# 语言类型,需要修改,否则无法调用对应的构建环境
code.language=java

# JDK版本
baseline.jdk=jdk-1.8

# 构建打包所用的maven版本
build.tools.maven=maven3.2.5

#产出物
build.output=target/ms-autotags-1.0-jar-with-dependencies.jar
# 应用部署脚本,先注释掉,暂时用不上
# deploy.appctl.path=deploy.sh

↓↓↓↓ 配置说明:

code.language=java

代表使用的是java作为代码语言类型。支持以下枚举(因为RDC经常更新,请以官方为准):

php5.6,php7.0,node6.x,node7.x,node8.x,oracle-jdk1.7,oracle-jdk1.8, oracle-jdk1.9,scripts

如果有使用过jenkins的同学,那么应该比较好理解,RDC的构建是通过Docker容器技术实现的,类似于配置好环境的jenkins构建机,RDC团队针对各种语言准备了不同的镜像作为构建宿主。


build.tools.maven=maven3.2.5

使用3.2.5版本的maven。


build.output=target/ms-autotags-1.0-jar-with-dependencies.jar

指明一个产出物,可以是目录也可以是具体的文件,比如jar包或者war包。如果执行完构建后此目录、文件不存在,则代表构建失败,无法进入工作流下一环。


简单maven项目不需要设置 build.command,除非你需要设置特别的maven打包参数或有多行打包命令。


我们已经完成了应用的创建+流水线的修改,那么我们运行一次构建试一下,只需要点击【运行流水线】按钮即可,运行后等几秒刷新一下页面,效果如下:

image

可以看到执行时间、版本号、日志、操作人等信息。

如果构建失败了,可以通过构建流程—-日志详情面板看到具体的错误原因,有日志排查起来不太难,但是RDC的构建还是偏向黑盒,所以尽量熟练或在本地先把相关命令跑通后再上传到xxx.release文件里去进行RDC构建。

可以看到初始的版本号是:v0.0.1-1,如果你的构建一直失败,版本号会变成v0.0.1-3、v0.0.1-8、v0.0.1-18、v0.0.1-N。

如果你的流水线全流程跑完了,则会自动叠加一个小版本号变为v0.0.2-1,所以这种构建方式清晰明了,还算好用。


三、如何输出为一个Docker镜像

我们已经完成了代码的打包编译工作,下一步我们需要把完整的代码封装成一个Docker镜像,我们需要对xxx.release文件做如下改动:

# 语言类型,需要修改,否则无法调用对应的构建环境
code.language=java

# JDK版本
baseline.jdk=jdk-1.8

# 构建打包所用的maven版本
build.tools.maven=maven3.2.5

#产出物
build.output=target/ms-autotags-1.0-jar-with-dependencies.jar

# Docker 构建配置
docker.file=Dockerfile

# Docker镜像构建之后push的仓库地址
docker.repo=registry.cn-hangzhou.aliyuncs.com/xxx/abced

docker.tag=ci-${PACKAGE_LABEL} 

# 应用部署脚本,先注释掉,暂时用不上
# deploy.appctl.path=deploy.sh

相对于单纯的构建,如果需要生成Docker镜像则需要补充几个配置项,拆解说明如下:

docker.file=Dockerfile

指明dockerfile文件的位置和文件名,默认就是根目录下的Dockerfile文件。


docker.repo=registry.cn-hangzhou.aliyuncs.com/xxx/abced

指定你的docker镜像仓库,建议使用阿里云提供的仓库,免费,速度快,可以加速docker hub的内容,无缝对接RDC服务,地址是 dev.aliyun.com ,此处的xxx对应的是你的名称空间,abced对应的是你的镜像名称。


docker.tag=ci-${PACKAGE_LABEL}-${TIMESTAMP}

这里指定你的docker镜像的tag名,使用了环境变量进行拼接。

${PACKAGE_LABEL}代表的是包名,这个参数在流水线配置里可以改,默认是default。

${TIMESTAMP}代表的是当前时间戳,格式是:20171008224350 这种样子。

有的项目一份代码可能产生多个docker镜像就需要通过这种方式来动态生成tag名,防止覆盖,也便于回滚。

关于构建传参,可以参考这个文章: https://help.aliyun.com/document_detail/59297.html

那么此处最终生成的tag名是这样的: ci-default-20171008224350

结合仓库名和镜像名,最终会生成镜像tag地址为:

registry.cn-hangzhou.aliyuncs.com/xxx/abced:ci-default-20171008224350


四、后记

NodeJS构建 + Docker构建就说到这里,因为主要是为了介绍RDC,所以Docker部分就挑重点讲了,如何编写Dockerfile文件请自行学习。

输出成Docker镜像后,如何使用RDC部署到容器相关问题我会单独开一个文章来分享。

云效(原RDC)如何构建一个基于NodeJS的前后端项目

最近在将公司的持续集成架构做一个系统的调整,调整过程中受到了RDC团队大量的帮助,所以利用国庆时间写了几篇RDC的分享,希望能让更多的人了解和用好RDC这个产品。

我会把我最近3个月的使用体会分成5个部分:使用RDC的动机、PHP项目集成、JS项目集成、JAVA项目集成、Docker类项目集成这5个分支来写

因为近期RDC的迭代比较频繁,所以我的分享会比较的浅,点到为止,仅供参考,目录:

1、RDC如何耦合进我们的业务

2、如何构建一个基于Composer的PHP项目

3、如何构建一个基于NodeJS的前后端项目

4、如何构建一个基于Maven的Java项目

5、RDC + 容器服务完成持续集成


一、RDC基础操作

在开始一切之前您需要熟悉RDC的一些基础操作,创建一个项目,然后在这个项目中创建一个应用,然后让这个应用关联某个代码分支。这样基础工作就完成了,我这里不再赘述了,因为比较简单,只需要注册个阿里云账号,然后去 rdc.aliyun.com 创建/加入个企业就行了。

本文所有的体验均基于【自由模式】的应用。

值得一提的是,应用代码源目前支持的是阿里云的代码仓库,基于gitlab,地址是 code.aliyun.com,从我2年的使用经验来看,还算好用,也不收费,较为靠谱。

在创建应用时,我们需要选择对应的配置,如下图:

image

创建完应用后,进入【项目】–》【流水线】,找到刚才创建应用的【同名流水线】

image

点击流水线名称可以看到具体的流水线运行情况和对应节点,如下图:

image

可以看到有4个面板:构建、日常、预发、正式。

分别对应的是:构建打包、发布到日常环境、发布到预发环境、发布到正式环境。

RDC在创建应用时自动的为你生成了一个标准模板流水线,但是我们一般用不着,所以需要对流水线进行修改,去除无用的节点,添加我们自己的配置。点击界面上的【编辑流水线】按钮就可以进入修改界面。

image

我们先从构建开始,所以先暂时删除日常、预发、正式这3个部署节点,仅保留构建这一个节点即可。下面的配置暂时不进行调整。删除完毕后保存流水线即可,效果如下:

image

至此我们已经完成了基础的准备工作,下一步就开始进行代码的构建工作了。

在开始下一步工作之前,请重新git pull一下您的代码到本地,会看到一个由RDC服务自动生成的配置文件:xxx.release 这个文件相当重要,请注意,下面将会说明如何通过此文件完成个性化构建。


二、基于NodeJS的前后端项目构建

因为node类项目一般都通过NPM来维护第三方库,并且一般会通过webpack来进行构建、合并、压缩,所以在RDC构建时需要完成依赖包下载及webpack编译的相关工作。

这里需要找到我们上一章节中提到的:xxx.release 文件,xxx代表你的应用名,所以我这里看到的文件名是:ms-autotags.release

这个文件的配置规范可以参考:https://help.aliyun.com/document_detail/59293.html

打开这个文件可以看到,已经有一些预先定义好的配置:

# 构建源码语言类型
code.language=scripts

# 应用部署脚本
deploy.appctl.path=deploy.sh

# Docker镜像构建之后push的仓库地址
docker.repo=registry.cn-hangzhou.aliyuncs.com/xxx/abced

上面的配置是不能用的,我们需要将其修改为如下内容:

# 语言类型,需要修改,否则无法调用对应的构建环境
code.language=node8.x

#构建命令
build.command=sh build.sh

# 应用部署脚本,先注释掉,暂时用不上
# deploy.appctl.path=deploy.sh

↓↓↓↓ 配置说明:

code.language=nodejs

代表使用的是nodejs作为代码语言类型。支持以下枚举:

php5.6,php7.0,node6.x,node7.x,node8.x,oracle-jdk1.7,oracle-jdk1.8, oracle-jdk1.9,scripts

如果有使用过jenkins的同学,那么应该比较好理解,RDC的构建是通过Docker容器技术实现的,类似于配置好环境的jenkins构建机,RDC团队针对各种语言准备了不同的镜像作为构建宿主。


build.command=sh build.sh

这一行的意思是,使用一个特定的脚本来进行自定义构建,因为构建有时候需要处理的东西很多,一行命令解决不了,所以需要一个自定义构建脚本,此处我设置的脚本在代码根目录下,创建一个build.sh脚本。如果你的构建只有1句话,可以直接写在“=”号后面,使用自定义脚本是为了更清晰和更灵活。

↓↓↓↓ build.sh脚本内容:

echo "##### npm to taobao"
npm install -g cnpm --registry=https://registry.npm.taobao.org

echo "##### cnpm install --save"
cnpm install --save

echo "##### cnpm build"
cnpm run build

逐句解释:

npm install -g cnpm --registry=https://registry.npm.taobao.org

使用npm的中国全量资源,cnpm由淘宝维护,国内最快的镜像站点。切换的目的就是为了构建快一些,因为RDC目前暂时不支持海外构建,所以不改可能会导致构建很慢。


cnpm install --save

最核心的一句话,安装所有第三方库依赖,这一句执行后如果正确,就会生成node_modules文件夹了。也意味着如果你使用开源框架,你的angularjs、vue等框架就安装成功了。


cnpm run build

这句话是使用webpack完成打包工作,前端项目通常是生成dist文件夹,此文件夹为项目的产出物。


我们已经完成了应用的创建+流水线的修改,那么我们运行一次构建试一下,只需要点击【运行流水线】按钮即可,运行后等几秒刷新一下页面,效果如下:

image

可以看到执行时间、版本号、日志、操作人等信息。

如果构建失败了,可以通过构建流程—-日志详情面板看到具体的错误原因,有日志排查起来不太难,但是RDC的构建还是偏向黑盒,所以尽量熟练或在本地先把相关命令跑通后再上传到xxx.release文件里去进行RDC构建。

可以看到初始的版本号是:v0.0.1-1,如果你的构建一直失败,版本号会变成v0.0.1-3、v0.0.1-8、v0.0.1-18、v0.0.1-N。

如果你的流水线全流程跑完了,则会自动叠加一个小版本号变为v0.0.2-1,所以这种构建方式清晰明了,还算好用。


三、如何输出为一个Docker镜像

我们已经完成了代码的打包编译工作,下一步我们需要把完整的代码封装成一个Docker镜像,我们需要对xxx.release文件做如下改动:

# 语言类型,需要修改,否则无法调用对应的构建环境
code.language=node8.x

#构建命令
build.command=sh build.sh

# Docker 构建配置
docker.file=Dockerfile

# Docker镜像构建之后push的仓库地址
docker.repo=registry.cn-hangzhou.aliyuncs.com/xxx/abced

docker.tag=ci-${PACKAGE_LABEL} 

# 应用部署脚本,先注释掉,暂时用不上
# deploy.appctl.path=deploy.sh

相对于单纯的构建,如果需要生成Docker镜像则需要补充几个配置项,拆解说明如下:

docker.file=Dockerfile

指明dockerfile文件的位置和文件名,默认就是根目录下的Dockerfile文件。


docker.repo=registry.cn-hangzhou.aliyuncs.com/xxx/abced

指定你的docker镜像仓库,建议使用阿里云提供的仓库,免费,速度快,可以加速docker hub的内容,无缝对接RDC服务,地址是 dev.aliyun.com ,此处的xxx对应的是你的名称空间,abced对应的是你的镜像名称。


docker.tag=ci-${PACKAGE_LABEL}-${TIMESTAMP}

这里指定你的docker镜像的tag名,使用了环境变量进行拼接。

${PACKAGE_LABEL}代表的是包名,这个参数在流水线配置里可以改,默认是default。

${TIMESTAMP}代表的是当前时间戳,格式是:20171008224350 这种样子。

有的项目一份代码可能产生多个docker镜像就需要通过这种方式来动态生成tag名,防止覆盖,也便于回滚。

关于构建传参,可以参考这个文章: https://help.aliyun.com/document_detail/59297.html

那么此处最终生成的tag名是这样的: ci-default-20171008224350

结合仓库名和镜像名,最终会生成镜像tag地址为:

registry.cn-hangzhou.aliyuncs.com/xxx/abced:ci-default-20171008224350


四、后记

NodeJS构建 + Docker构建就说到这里,因为主要是为了介绍RDC,所以Docker部分就挑重点讲了,如何编写Dockerfile文件请自行学习。

输出成Docker镜像后,如何使用RDC部署到容器相关问题我会单独开一个文章来分享。