Skip to main content

17 posts tagged with "serverless"

View All Tags

Serverless Desktop介绍

hanxie-crypto

hanxie-crypto

Serverless Desktop

上周我们在serverless meetup 杭州站上给大家初步展示了一下我们的新客户端工具ServerlessDesktop ,Serverless Desktop 也是Serverless 工具链产品中首个具备全方位Serverless开发能力的可视化工具,涵盖了应用初始化,开发,部署,压测,调试,运维等完整的开发能力。 本篇详细展开来跟大家介绍一下 这个桌面客户端的详细内容,包括为什么选择客户端而非web,以及整体功能方面的介绍等。 ​

为什么选择桌面的方式#

在当前B/S 模式盛行的今天,选择destkop 这种 C/S 的形式看起来是有些逆历史潮流,并且单纯从追求技术的角度讲选择桌面应用的开发挑战性更高,相对而言带来的交付风险也更高。然而从我们的需求侧出发去看的话,又必须选择原生桌面应用的方式,项目初始化,调用terminal, 本地压测,端云调试,组件可视化等等能力皆需要跟用户自己的PC做大量的交互,这个时候web本身的能力就已经无法满足了。另外真正从用户的使用体验上看,桌面应用的方式是要好于web的,更稳定,更流畅一些,所以功能性要求和追求更好的用户体验,让我们最终中选择了桌面应用的形态。 ​

UI#

image.png 如上图给大家呈现的UI 库在是 我们阿里云云原生前端团队阿里云设计中心以及阿里云全球交付前端团队联袂打造的一款精美的基础组件库 B-designimage.png

目前也是完全开放给外部开发者使用的。组件库API目前完全兼容 阿里巴巴开源的 Fusion组件库,另外 Ant-design的组件库支持也正在紧张研发,相信过不久就能够跟大家见面,欢迎大家下载使用。后续我们也会准备更多的B-design中后台模板发放到 Serverless Hub上供大家使用。 ​

重要功能介绍#

Serverless Hub#

也就是我们的应用市场,这个是个典型的需要GUI化的场景,相比Serverless cli 的列表展示要有更丰富的表现力

应用初始化#

image.png vs image.png 这里面我们提供了4个页签 【S优选】 // 官方提供的优选项目,如jamstack 和精选应用框架 【S新品】 // 顾名思义,由开发者发布的最新应用 【S热门】 // 这个显示的是下载量最大的应用,比如最近的怀旧游戏 【S收藏】 // 收藏量最大,这边收藏需要用户登录才能完成 ​

用户在Serverless Hub上选中自己需要的应用后,紧接着进行项目目录选择 image.png 这里需要您准备一个空的目录进行下载(命令行则会引导创建新目录),好处是你可以可视化的掌握自己项目路径。 目录选取后确定,接下来SDesktop会帮助完成项目download,部分项目需要预先填写一些配置,比如这里的jamstack项目,根据提示填写即可 image.png

应用配置#

应用配置是专门为部署服务的,主要包含了基本配置和服务配置,他们都可以折叠 image.png 一般情况下我们会尽量要求应用的作者将其配置项进行最简化,所以进入界面后您可以直接点击“全量操作” 进行部署或者其他的操作。 image.png

如果您只想对某个单项的服务做部署或者其他动作,可以在具体服务上找到 “执行”按钮 进行操作 image.png全量操作和单个服务的执行在 单服务情形下效果等同。 ​

image.png 比如这里直接针对单个服务进行操作,SDesktop会调动S执行器内核进行构建部署,并将最终结果输出到界面上。 值得一提的是,应用配置的可视化部分和代码编辑部分是双向的,修改左侧表单,右侧的yaml配置会随之改变,修改右侧yaml ,左侧表单也会发生变化。 当你只需要改动小部分配置的时候用左侧表单最保险,进行大规模注释,则用有半部分更合理testview.gif

工作空间-用户视角#

工作空间是用户对应用最主要的维护界面,会展示用户作为使用者所拥有的应用,也可以展示用户作为应用贡献者所拥有的应用,可以通过切换【用户视角/开发者视角】来查看 image.png

进入具体的应用详情后,会看到一个全方位的面板,涵盖基本信息,配置信息,可观测,压测,端云调试,终端,六个面板。 image.png

基本信息#

  • 应用信息列举了项目的本地路径,如果项目是有域名的也会帮助展示出来,这样及时你在部署的是时候忘记观察自己的域名也可以在这里继续查看,另外我们还提供了一些站点的小工具,比如前端性能监控 和 站点性能检测。
  • 资源信息则会把本次应用部署所利用的云端资源全部列出,比如 使用的cdn,oss,fc等,方便用户查看,以前这部分都是黑盒的我们现在希望完全的透明化
  • 操作记录会展示每一次用户通过配置信息板块操作的结果记录,方便定位问题

配置信息#

这部分同上面的应用配置,不再赘述 ​

可观测#

你可以通过此面板查看函数调用信息,当然可以配置压测能力验证系统的承压水位 image.png

压测#

Serverless Devs 工具链中提供的压测有别于传统的压测,除了能够兼容 传统的 http 协议,还能够针对事件驱动类型的函数进行施压测试,那么压测的启动也非常的简单,按照面板的提示,选择秘钥,地域,服务,函数。然后添加好模拟的参数,启动压测即可。 st.gif 压测结束后会有一份压测报告展现出来。

端云调试#

端云调试也是我们的一个比较大的亮点,具备较高的实战价值,一般而言其他云商会提供线上调试,但真正的开发场景中本地调试云上才是更好的体验。这里展示一下调试的demo,demo。模板来源是start-node-proxied-invokedebug.gif

终端#

本身Serverless Desktop 也是把终端集成进来的,所以对于喜欢使用终端的开发者用户依然可以在这里进行命令行操作。

工作空间-开发者视角#

除了上面作为一个用户去使用工具,以及应用模板构建自己的应用以外,我们Serverless Desktop也是专门给开发者提供了一个体验良好的工作台,下面展示一下如果使用它构建自己的组件和应用 ​

创建组件#

我们先初始化一个组件的模板,并进行项目的编辑 image.png 然后编写一些代码逻辑并对他进行测试 developcomponentcode.gif

当你的组件开发好之后可以通过2中方式被使用 第一种 是通过 s cli \<component> \<method> 比如我想使用刚才本地写好的组件,调用他的deploy 方法,可以这么用 s cli <本地组件的目录地址> deploy use.gif 这种用法适合在系统的集成, 比如你在gitaction 或者自己的系统里面,通过指令就能完成某些复杂逻辑的处理 ​

第二种 用过应用编排 这里就需要进一步开发应用了,应用本身其实不带逻辑执行,他是资源的编排和资源的定义,主要的逻辑执行是在组件。 可以用过 s init 指令选择最后的应用模板进行初始化 image.png image.png

这时在 s.yaml目录下执行 s deploy ,可以看到本地组件被正常调用,并且通过 props 属性传入了name 和 region

组件中心#

因为组件是S 生态重要的一等公民,这里把组件单独拿出来,是为了更好的让用户复用组件的逻辑能力,我们提供组件的说明文档等,部分组件,比如fc-api 还提供了可视化的操作,方便用户查询api component.gif

登录github#

login.gif 授权登录github 可以对应用进行收藏,这里因为国内网络的问题,授权登录可能会失效,可以多次尝试一下 ​

秘钥管理#

通过Serverless Desktop 你可以很方便的管理你的秘钥信息,请务必注意保管好自己的秘钥信息,防止泄露。如有必要可以通过官网控制台禁用秘钥。 ak.gif

未来展望#

接下来我们还会技术深入打磨 Serverless Desktop 除了继续优化本身的使用体验外,还会继续增加更多的新能力和特色,比如会由我们超优秀的设计师同学给出新的视觉和交互方案(笔者做为程序员现在已经到极限),加入高质量技术文章板块, 开放专业开发者认证机制,power tuning,低代码搭建等等。 除了平台建设,我们也会更加专注于开发者实战场景,重点打造 jamstack 建站, api 开发 ,以及多个 serverless 应用场景解决方案等。 我们希望能够为Serverless 开发基建贡献自己的力量,也欢迎大家加入不管是作为开发者还是用户,我们都非常欢迎。 ​

助力帮助#

如果您对Serverless Devs 感兴趣,请帮助我们的项目增加star 吧,点击访问github项目地址

Serverless Desktop介绍

hanxie-crypto

hanxie-crypto

Serverless Desktop

上周我们在serverless meetup 杭州站上给大家初步展示了一下我们的新客户端工具ServerlessDesktop ,Serverless Desktop 也是Serverless 工具链产品中首个具备全方位Serverless开发能力的可视化工具,涵盖了应用初始化,开发,部署,压测,调试,运维等完整的开发能力。 本篇详细展开来跟大家介绍一下 这个桌面客户端的详细内容,包括为什么选择客户端而非web,以及整体功能方面的介绍等。 ​

为什么选择桌面的方式#

在当前B/S 模式盛行的今天,选择destkop 这种 C/S 的形式看起来是有些逆历史潮流,并且单纯从追求技术的角度讲选择桌面应用的开发挑战性更高,相对而言带来的交付风险也更高。然而从我们的需求侧出发去看的话,又必须选择原生桌面应用的方式,项目初始化,调用terminal, 本地压测,端云调试,组件可视化等等能力皆需要跟用户自己的PC做大量的交互,这个时候web本身的能力就已经无法满足了。另外真正从用户的使用体验上看,桌面应用的方式是要好于web的,更稳定,更流畅一些,所以功能性要求和追求更好的用户体验,让我们最终中选择了桌面应用的形态。 ​

UI#

image.png 如上图给大家呈现的UI 库在是 我们阿里云云原生前端团队阿里云设计中心以及阿里云全球交付前端团队联袂打造的一款精美的基础组件库 B-designimage.png

目前也是完全开放给外部开发者使用的。组件库API目前完全兼容 阿里巴巴开源的 Fusion组件库,另外 Ant-design的组件库支持也正在紧张研发,相信过不久就能够跟大家见面,欢迎大家下载使用。后续我们也会准备更多的B-design中后台模板发放到 Serverless Hub上供大家使用。 ​

重要功能介绍#

Serverless Hub#

也就是我们的应用市场,这个是个典型的需要GUI化的场景,相比Serverless cli 的列表展示要有更丰富的表现力

应用初始化#

image.png vs image.png 这里面我们提供了4个页签 【S优选】 // 官方提供的优选项目,如jamstack 和精选应用框架 【S新品】 // 顾名思义,由开发者发布的最新应用 【S热门】 // 这个显示的是下载量最大的应用,比如最近的怀旧游戏 【S收藏】 // 收藏量最大,这边收藏需要用户登录才能完成 ​

用户在Serverless Hub上选中自己需要的应用后,紧接着进行项目目录选择 image.png 这里需要您准备一个空的目录进行下载(命令行则会引导创建新目录),好处是你可以可视化的掌握自己项目路径。 目录选取后确定,接下来SDesktop会帮助完成项目download,部分项目需要预先填写一些配置,比如这里的jamstack项目,根据提示填写即可 image.png

应用配置#

应用配置是专门为部署服务的,主要包含了基本配置和服务配置,他们都可以折叠 image.png 一般情况下我们会尽量要求应用的作者将其配置项进行最简化,所以进入界面后您可以直接点击“全量操作” 进行部署或者其他的操作。 image.png

如果您只想对某个单项的服务做部署或者其他动作,可以在具体服务上找到 “执行”按钮 进行操作 image.png全量操作和单个服务的执行在 单服务情形下效果等同。 ​

image.png 比如这里直接针对单个服务进行操作,SDesktop会调动S执行器内核进行构建部署,并将最终结果输出到界面上。 值得一提的是,应用配置的可视化部分和代码编辑部分是双向的,修改左侧表单,右侧的yaml配置会随之改变,修改右侧yaml ,左侧表单也会发生变化。 当你只需要改动小部分配置的时候用左侧表单最保险,进行大规模注释,则用有半部分更合理testview.gif

工作空间-用户视角#

工作空间是用户对应用最主要的维护界面,会展示用户作为使用者所拥有的应用,也可以展示用户作为应用贡献者所拥有的应用,可以通过切换【用户视角/开发者视角】来查看 image.png

进入具体的应用详情后,会看到一个全方位的面板,涵盖基本信息,配置信息,可观测,压测,端云调试,终端,六个面板。 image.png

基本信息#

  • 应用信息列举了项目的本地路径,如果项目是有域名的也会帮助展示出来,这样及时你在部署的是时候忘记观察自己的域名也可以在这里继续查看,另外我们还提供了一些站点的小工具,比如前端性能监控 和 站点性能检测。
  • 资源信息则会把本次应用部署所利用的云端资源全部列出,比如 使用的cdn,oss,fc等,方便用户查看,以前这部分都是黑盒的我们现在希望完全的透明化
  • 操作记录会展示每一次用户通过配置信息板块操作的结果记录,方便定位问题

配置信息#

这部分同上面的应用配置,不再赘述 ​

可观测#

你可以通过此面板查看函数调用信息,当然可以配置压测能力验证系统的承压水位 image.png

压测#

Serverless Devs 工具链中提供的压测有别于传统的压测,除了能够兼容 传统的 http 协议,还能够针对事件驱动类型的函数进行施压测试,那么压测的启动也非常的简单,按照面板的提示,选择秘钥,地域,服务,函数。然后添加好模拟的参数,启动压测即可。 st.gif 压测结束后会有一份压测报告展现出来。

端云调试#

端云调试也是我们的一个比较大的亮点,具备较高的实战价值,一般而言其他云商会提供线上调试,但真正的开发场景中本地调试云上才是更好的体验。这里展示一下调试的demo,demo。模板来源是start-node-proxied-invokedebug.gif

终端#

本身Serverless Desktop 也是把终端集成进来的,所以对于喜欢使用终端的开发者用户依然可以在这里进行命令行操作。

工作空间-开发者视角#

除了上面作为一个用户去使用工具,以及应用模板构建自己的应用以外,我们Serverless Desktop也是专门给开发者提供了一个体验良好的工作台,下面展示一下如果使用它构建自己的组件和应用 ​

创建组件#

我们先初始化一个组件的模板,并进行项目的编辑 image.png 然后编写一些代码逻辑并对他进行测试 developcomponentcode.gif

当你的组件开发好之后可以通过2中方式被使用 第一种 是通过 s cli \<component> \<method> 比如我想使用刚才本地写好的组件,调用他的deploy 方法,可以这么用 s cli <本地组件的目录地址> deploy use.gif 这种用法适合在系统的集成, 比如你在gitaction 或者自己的系统里面,通过指令就能完成某些复杂逻辑的处理 ​

第二种 用过应用编排 这里就需要进一步开发应用了,应用本身其实不带逻辑执行,他是资源的编排和资源的定义,主要的逻辑执行是在组件。 可以用过 s init 指令选择最后的应用模板进行初始化 image.png image.png

这时在 s.yaml目录下执行 s deploy ,可以看到本地组件被正常调用,并且通过 props 属性传入了name 和 region

组件中心#

因为组件是S 生态重要的一等公民,这里把组件单独拿出来,是为了更好的让用户复用组件的逻辑能力,我们提供组件的说明文档等,部分组件,比如fc-api 还提供了可视化的操作,方便用户查询api component.gif

登录github#

login.gif 授权登录github 可以对应用进行收藏,这里因为国内网络的问题,授权登录可能会失效,可以多次尝试一下 ​

秘钥管理#

通过Serverless Desktop 你可以很方便的管理你的秘钥信息,请务必注意保管好自己的秘钥信息,防止泄露。如有必要可以通过官网控制台禁用秘钥。 ak.gif

未来展望#

接下来我们还会技术深入打磨 Serverless Desktop 除了继续优化本身的使用体验外,还会继续增加更多的新能力和特色,比如会由我们超优秀的设计师同学给出新的视觉和交互方案(笔者做为程序员现在已经到极限),加入高质量技术文章板块, 开放专业开发者认证机制,power tuning,低代码搭建等等。 除了平台建设,我们也会更加专注于开发者实战场景,重点打造 jamstack 建站, api 开发 ,以及多个 serverless 应用场景解决方案等。 我们希望能够为Serverless 开发基建贡献自己的力量,也欢迎大家加入不管是作为开发者还是用户,我们都非常欢迎。 ​

助力帮助#

如果您对Serverless Devs 感兴趣,请帮助我们的项目增加star 吧,点击访问github项目地址

云效+Serverless Devs快速实现.NET5函数计算代码更新

GotzeWong

GotzeWong

Serverless Devs

笔者在Serverless Devs技术大牛们帮助下,成功实现了云效+Serverless Devs发布.NET5 Web API到函数计算。下文将对流水线开发的流程进行分享,希望能够抛砖引玉,给大家提供一些思路和避免一下坑。本文基于已创建好Custom Runtime的函数计算前提下,具体创建流程可参考阿里云官网。本文云效流水线主要流程如下:

Git Clone -> Build -> Zip -> OSS Upload -> Serverless Deploy Function

由于本文Web API使用了ABP Framework,因此编译后文件在压缩前已经超过100Mb限制,选择使用OSS方式部署。

一、构建#

  1. Build

因为FC暂时不支持.NET5 Runtime,因此选择Custom Runtime并选择self-contained部署。

dotNET restore $BUILD_PATH
dotNET publish $BUILD_PATH --runtime linux-x64 --framework NET5.0 --self-contained true -c Release -o out
  1. 重命名

函数计算冷启动Custom Runtime时,会默认调用bootstrap文件启动您自定义的HTTP Server。详情见函数计算Custom Runtime基本原理

mv out/$PROJECT_NAME out/bootstrap
  1. 压缩代码包

安装zip并压缩编译后的文件。

#
apt-get update
apt-get install zip unzip
cd out && zip -qr $PROJECT_NAME.zip .

二、OSS上传#

使用官方oss cli-ossutil传输代码包到oss。

  1. 下载部署包
curl -L $PACKAGE -o /tmp/down.tgz
tar -C /tmp -xzf /tmp/down.tgz
  1. 安装和配置ossutil命令行工具
wget http://gosspublic.alicdn.com/ossutil/1.7.5/ossutil64
chmod 755 ossutil64
  1. 配置OSS
ossutil config [-e endpoint] [-i id] [-k key] [-t token] [-L language] [--output-dir outdir] [-c file]
  1. 上传OSS
ossutil cp /tmp/$PROJECT_NAME.zip oss://$OSS_BUCKET [-c file]

三、发布FC#

update Function#

在笔者使用时,云效目前Serverless devs版本为2.0.50,而新版本已经是2.0.67。 0. 查看版本

s -v

而云效默认Serverless devs版本没法正常执行s cli fc-api updateFunction,因此需要自行更新CLI版本。

  1. 版本升级
curl -o- -L http://cli.so/install.sh | bash
  1. 配置serverless
s config add --AccountID [AccountID] --AccessKeyID [AccessKeyID] --AccessKeySecret [AccessKeySecret] -a [alias]
  1. 更新函数
s cli fc-api updateFunction --access [alias] --region [region] --serviceName [Service Name] --functionName [Function Name] --code '{"ossBucketName": "", "ossObjectName": ""}'

总结#

基于Serverless架构集成云效 CI/CD,搞定自动化部署,轻松实现一键发布。希望通过本文,能够对.NET 开发者有所帮助。笔者云开发时间不长,针对文中部署步骤有更好的建议,欢迎分享探讨。

阿里云函数计算组件感知线上“异动”:让发布更安全

Anycodes

Anycodes

Serverless Devs

从我做Serverless工具开始,就经常会遇到有人问这样一个问题:如何保证Serverless业务部署更新的一致性。

所谓的一致性在这里指的是:我们通过工具在本地进行项目部署,此时再有人通过其他途径(例如控制台等),对项目进行过更新等操作,此时我再在本地进行项目部署,是不是会直接覆盖?

例如,当用户A在本地更新了业务,因为一些特殊情况,导致出现了一个线上异常x,此时用户B重新更新,将这个内容修复了,但是B没有及时同步给A这个事情,A又更新了新的功能,直接覆盖了B的内容,这个时候之前的异常x又出现了,如果此时在A更新的时候,可以感知到线上资源已经变动,那么这种事情就不会再次发生。

目前基于Serverless Devs的阿里云函数计算组件,已经支持了线上“异动”的感知能力,包括了以下几个情况:

  1. 本地新建并部署一个线上没有的资源
  2. 本地部署完成,线上更新,本地再次部署
  3. 本地新建并部署一个线上已经有的资源

实验准备#

通过s init创建一个函数(选择Alibaba Cloud Serverless, 选择HTTP Function - Python3 Example):

image

此时我们查看一下s.yaml

image

该项目部署到线上之后的表现就是在cn-hangzhou区创建一个fc-deploy-service服务,以及http-trigger-function函数

本地新建并部署一个线上没有的资源#

此时,我们确定一下线上并没有对应资源,所以我们部署一下:

image

部署完成,很顺利:

image

打开浏览器,查看反馈给我们的自定义地址:

image

此时,我们可以在本地,更新一下这个函数代码:

image

保存部署:

image

完成之后,再查看线上资源:

image

整个过程,还是比较贴近传统的基本流程,也没有触发线上异动,算是中规中矩的理想过程。

本地部署完成,线上更新,本地再次部署#

此时,我们对线上资源进行变更,首先在控制台找到函数:

image

修改代码,并部署。

image

部署完成之后,我们刷新一下刚才的地址:

image

可以看到已经更新。此时,我们再从本地进行部署:

image

可以看到,系统已经感知到我们的代码变化,此时,我们选择yes,完成之后在查看线上资源:

image

此处需要额外说明的是,只要是函数计算的服务,函数,触发器发生变化,此处都可以进行感知,不管是配置还是代码。

本地新建并部署一个线上已经有的资源#

此时,我们再进行最后的实验,我们将本地项目删除,重新建设。然后执行部署,由于刚刚实验过的原因,我们已经在线上存在了这些资源,所以此时算是部署一个线上的资源。

image

此时可以看到,系统感知到这个资源本地没部署过,线上并且已经存在,所以此时需要确定是否覆盖。

总结#

代码在其他场景被更新,需要我们在当前得到感知,这个事情其实是非常重要的,和代码的安全发布密不可少。而此时,通过Serverless Devs是可以做到的。

那么问题来了,如果我已经有了一个项目,我想集成到cd流程,我不想出现交互式操作,应该如何处理呢?

此时我们提供一个--use-local参数,用来强行覆盖线上配置,通过这样的指令就可以实现无交互的,本地优先。

每一个工具的诞生,都要有一个成长的过程,Serverless Devs正在不断的成长。期待更多更好的功能出现。

Serverless Devs - SAE与Github Action珠合璧联,让CD从未如此简单

Anycodes

Anycodes

Serverless Devs

前言#

SAE是什么?在阿里云官方给的解释是:

Serverless 应用引擎(简称 SAE)是首款面向应用的Serverless PaaS,提供成本更优、效率更高的一站式应用托管方案。支持Spring Cloud/Dubbo/HSF应用零改造上云,提供监控诊断、自动构建镜像、Java全链路加速、多发布策略、秒级自动弹性等能力,支持Jenkins/云效/插件等部署应用,还能通过Docker镜像部署任何语言的应用。

由此可见,SAE实际上是Serverless架构的另一种形态。他将会对镜像,Java等项目有着更好的支持。但是可惜的是,在SAE的官方文档中,最佳实践中,并没有看到与Github Action结合进行自动化发布等相关的描述:

image

Github Action这么有趣,怎么可以少的了Github Action的案例呢?所以本文将会是首个,基于Serverless Devs,并且让SAE和Github Action有机结合的实战案例。

整个案例分为几个部分:

  • Github操作
    • 创建Github仓库
    • 配置密钥等信息
  • 本地创建应用
    • 创建一个应用
    • 编写Dockerfile
    • 编写s.yaml(用Serverless Devs进行托管)
    • 编写action所必须的Yaml
  • 启动🚀
    • 将代码推动到Github,触发CD流程,进行自动化部署

关于编写action所必须的Yaml,主要包括了几个流程:

  • 登陆阿里云ACR
  • Docker Build
  • Docker Push
  • 设置Push后的镜像地址到环境变量
  • 安装Serverless Devs
  • 配置Serverless Devs密钥信息
  • 启动部署操作🚀

Github 操作#

首先进行仓库的创建:

image

例如,我创建的仓库就是:https://github.com/anycodes/SAE-Container-Action-Demo

创建完仓库开始进行密钥的配置,可以参考文档:http://www.serverless-devs.com/blog/serverless-devs-ci-cd-github-action-usage#%E8%B4%A6%E5%8F%B7%E4%BF%A1%E6%81%AF%E9%85%8D%E7%BD%AE

主要就是在Settings->Secrets中进行信息配置:

image

配置完成:

image

本地创建应用#

由于本次实践,主要是看Build,Push镜像之后,部署到SAE,所以我就在本地随便准备了一个代码,仅供测试使用:

image

完成之后,我们针对这个项目,象征性编写一个Dockerfile:

FROM node:14.5.0-alpine3.11
# Create app directory
WORKDIR /usr/src/app
# Install app dependencies
# A wildcard is used to ensure both package.json AND package-lock.json are copied
# where available (npm@5+)
COPY package*.json ./
RUN npm install
# If you are building your code for production
# RUN npm ci --only=production
# Bundle app source
COPY . .
EXPOSE 8080
ENTRYPOINT [ "node", "server.js" ]

编写完成之后,我们再根据SAE组件(可以参考 https://github.com/devsapp/sae ),编写一个s.yaml:

edition: 1.0.0 # 命令行YAML规范版本,遵循语义化版本(Semantic Versioning)规范
name: sae-app # 项目名称
access: publish_access # 秘钥别名
services:
sae-test: # 服务名称
component: devsapp/sae
props:
Region: cn-beijing
Namespace:
NamespaceId: cn-beijing:test
NamespaceName: serverless-devs
NamespaceDescription: namespace desc
Application:
AppName: serverless-devs-app
AppDescription: This is a test description.
Code:
Image: ${env(DOCKER_IMAGE)}
Cpu: 500
Memory: 1024
Replicas: 1
AutoConfig: true
SLB:
Internet: [{"port":80,"targetPort":8080,"protocol":"TCP"}]

这里面有一个叫做Image的字段,他是容器镜像的地址,此时使用的是一个环境变量作为引入,也就是说,之后在Github Action实例中,推送镜像之后,将结果打入ENV即可读取到。

关于这种方法的妙用还有很多:

例如,当我们需要配置一下密钥信息等,是不是也可以通过这种方法,将密钥放入环境变量,然后在Yaml中直接引用?

接下来还需要编写一个Github Action相关的Yaml:

name: Build and Deploy to SAE
on:
push:
branches: [ master ]
# Environment variables available to all jobs and steps in this workflow.
env:
REGION_ID: cn-beijing
REGISTRY: registry.cn-beijing.aliyuncs.com
NAMESPACE: custom-container
IMAGE: sae
TAG: ${{ github.sha }}
jobs:
build:
runs-on: ubuntu-latest
environment: production
steps:
- name: Checkout
uses: actions/checkout@v2
# 1.1 Login to ACR
- name: Login to ACR with the AccessKey pair
uses: aliyun/acr-login@v1
with:
region-id: "${{ env.REGION_ID }}"
access-key-id: "${{ secrets.ACCESS_KEY_ID }}"
access-key-secret: "${{ secrets.ACCESS_KEY_SECRET }}"
# 1.2 Buid and push image to ACR
- name: Build and push image to ACR
run: |
docker build --tag "$REGISTRY/$NAMESPACE/$IMAGE:$TAG" .
docker push "$REGISTRY/$NAMESPACE/$IMAGE:$TAG"
# 1.3 et Docker Image to Env
- name: Set Docker Image to Env
run: echo "DOCKER_IMAGE=$REGISTRY/$NAMESPACE/$IMAGE:$TAG" >> $GITHUB_ENV
# 2.1 Install Serverless Devs
- name: Install Serverless Devs
uses: actions/setup-node@v2
with:
node-version: 12
registry-url: https://registry.npmjs.org/
- run: npm install -g @serverless-devs/s
# 2.2 Config Serverless Devs
- name: Config Serverless Devs
run: s config add --AccountID ${{secrets.Account_ID}} --AccessKeyID ${{secrets.ACCESS_KEY_ID}} --AccessKeySecret ${{secrets.ACCESS_KEY_SECRET}} -a publish_access
# 2.3 Deploy to SAE
- name: Deploy to SAE
run: s deploy

至此,我们完整了所有的基础准备。

在上面的Yaml中,每一个过程都有注释,整体来说,下载Serverless Devs,到部署项目,其实只有3条命令:

npm install -g @serverless-devs/s
s config add --AccountID ${{secrets.Account_ID}} --AccessKeyID ${{secrets.ACCESS_KEY_ID}} --AccessKeySecret ${{secrets.ACCESS_KEY_SECRET}} -a publish_access
s deploy

这里要注意,s.yaml中指定的密钥要和我们创建(s config add)时的密钥保持一致。

image

启动🚀#

完成之后我们将代码推动到Github:

image

推送完成,可以看到线上的代码已经更新,并触发了CD流程:

image

此时,我们可以移步到SAE控制台( https://sae.console.aliyun.com/ ):

image

此时正在创建/更新应用

image

稍等片刻,即在进行SLB等相关的绑定。再稍等片刻,即可看到Github这头的Action已经完成:

image

此时,我们在看SAE控制台,整个项目算是完成了创建/更新:

image

总结#

这个是一个典型的SAE+Github ACtion实现CD的案例。希望通过这样一个案例,可以帮助更多人学习和了解Serverless Devs,可以将其应用到自己的项目中。

阿里云Custom Container的CI/CD最佳实践案例

Anycodes

Anycodes

Serverless Devs

在实际生产过程中,我们往往会遇到这样一个通用的项目持续发布的流程:

Git Clone -> Docker Build -> Docker Push -> Deploy Function

这样一个简单的流程,却在很多工具中难以实现,或者过于复杂,那么在Serverless架构下,通过Serverless devs如果来解决这个流程呢?

本文参考:https://github.com/devsapp/fc/tree/add-custom-container-example/examples/custom-container-function

准备一个Github仓库#

这个仓库包括了以下的内容:

  • 用户的代码
  • 构建镜像所需要的Dockerfile
  • 部署所需要的资源描述文件
  • 一些流程脚本

以仓库anycodes/CustomContainerDemo 为例,可以看到这是一个Node.js的项目,其中:

  • 用户的代码
    • server.js
    • package.json
  • 构建镜像所需要的Dockerfile
    • Dockerfile
  • 部署所需要的资源描述文件
    • s.yaml
  • 一些流程脚本
    • setup.sh
  • 其他文件
    • Github Action文件
    • version(描述景象tag的文件)

关于一些流程#

在整个项目中,包括两个流程:

  • Github Action的流程
  • 自定义Setup.sh流程

Github Action的流程#

这个流程主要是一些环境的初始化等:

name: Publish
on:
push:
branches: [ main ]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: 12
registry-url: https://registry.npmjs.org/
- run: npm install -g @serverless-devs/s
- run: s config add --AccountID ${{secrets.AccountID}} --AccessKeyID ${{secrets.AccessKeyID}} --AccessKeySecret ${{secrets.AccessKeySecret}} -a publish_access
- run: chmod +x ./setup.sh
- run: ./setup.sh

整个过程为确定nodejs环境,安装Serverless Devs,配置密钥信息(可以参考如何通过Github Action使用Serverless Devs做CI/CD - 账号信息配置

完成上述的初始化和密钥配置之后,可以直接执行我们的流程./setup.sh

自定义Setup.sh流程#

该流程也是比较简单的,主要做了几个事情:

  1. 明确我的镜像registry地址和tag(此处tag是从version文件读取的)
  2. 通过serverless devs fc组件提供的build能力,进行构建操作
  3. 通过deploy方法进行项目部署
#!/usr/bin/env bash
# git clone && cd repo
version=$(cat version)
registry='registry.cn-shanghai.aliyuncs.com/custom-container/test:'
export image=$registry$version
s build --use-docker
s deploy --push-registry acr-internet --use-local -y

这里有一个问题:谁给我进行的docker build以及谁给我进行的docker push?

  • 在本例子中docker build行为是由serverless devs帮做的,但是此出也可以不选择s build,可以选择更为原生的docker build
  • 在本例子中,在进行s deploy的时候,会有一个参数叫做--push-registry acr-internet,此时可以注意该参数有两个可选:
Deploy
Deploy a serverless application.
Usage
$ s deploy <options>
Options
--use-remote Deploy resource using remote config.
--use-local Deploy resource using local config.
--push-registry <registry> Specify registry or registry type of the image when use custom container
runtime.
Registry type includes 'acr-internet' and 'acr-vpc'
Global Options
-y, --assume-yes Assume that the answer to any question which would be asked is yes.
-h, --help Display help for command.
Examples with Yaml
$ s deploy
$ s <ProjectName> deploy
$ s deploy --use-remote
$ s exec -- deploy --use-remote
$ s exec <ProjectName> -- deploy --use-remote
Examples with CLI
You can refer to the usage of fc-api and execute [s cli fc-api -h] for help

可以根据自己需求,选择:

  • 'acr-internet': 目标 registry 地址设为公网地址。
  • 'acr-vpc': 目标 registry 地址设为专有网络(vpc)地址。
  • '${registry url}': 自定义 registry 地址。

关于上述整个操作的基本流程:

整个流程基本是:

image

项目测试#

由于我在Github Action中声明的是:

on:
push:
branches: [ main ]

所以,此时我只需要push代码,即可触发发布流程:

image

部署后的地址效果:

image

注意的点#

在上面的步骤中,我们进行了密钥的配置:

s config add --AccountID ${{secrets.AccountID}} --AccessKeyID ${{secrets.AccessKeyID}} --AccessKeySecret ${{secrets.AccessKeySecret}} -a publish_access

这里面其实最后有一个参数是-a publish_access,它的含义是为当前密钥指定一个别名,因为Serverless Devs支持多密钥的,所以为当前密钥配置一个别名,在以后的使用过程中可以指定,例如在当前的Yaml中,第三行有:

access: publish_access

用来指定使用该密钥,测试的Yaml配置如下:

edition: 1.0.0
name: fcDeployApp
access: publish_access
services:
HelloWorld:
component: fc
props:
region: cn-shanghai
service:
name: custom-container-test
description: demo for custom-container-test
function:
name: custom-container-function
runtime: custom-container
caPort: 8080
codeUri: ./
timeout: 60
customContainerConfig:
image: ${env(image)}
command: '["node"]'
args: '["server.js"]'
triggers:
- name: httpTrigger
type: http
config:
authType: anonymous
methods:
- GET
- POST
customDomains:
- domainName: auto
protocol: HTTP
routeConfigs:
- path: /*

完整的Yaml配置可以参考:https://github.com/devsapp/fc/blob/main/docs/Others/yaml.md

在上面的Yaml中,其实可以看到image: ${env(image)},其实Serverless Devs的Yaml支持多种形式的变量:

  • 获取当前机器中的环境变量:${env(环境变量)},例如${env(secretId)}
  • 获取外部文档的变量:${file(路径)},例如${file(./path)}
  • 获取全局变量:${vars.*}
  • 获取其他项目的变量:${projectName.props.*}
  • 获取Yaml中其他项目的结果变量:${projectName.output.*}

实战举例,例如当我需要访问数据库等,此时我并不想把密钥明文配置到Yaml中,此时可以考虑,将密钥配置到环境变量中,进行直接使用。

关于 构建 问题:

如果使用 s build --use-docker 构建镜像,则需要确保 s.yml 中的 codeUri 字段指向的目录中包含 Dockerfile

关于 权限 问题:

如果配置的密钥权限不够(例如是子账号),则可能会导致用户无法创建某些权限,进而导致部署不成功,这个时候可以考虑让主账号创建好相关的Role,并且在此处指定: image

关于密钥最小权限:

  • AliyunFCFullAccess
  • AliyunContainerRegistryFullAccess

关于所绑定的Role的最小权限:

  • AliyunContainerRegistryReadOnlyAccess

通过Gitee+Serverless Devs快速实现函数代码更新与版本发布

Anycodes

Anycodes

Serverless Devs

在上一篇文章中,我们介绍了如何通过Github + Github Action进行单纯的代码更新以及版本发布,在本篇文章中,将会分享如何通过Gitee + Gitee Go实现:

  1. 单纯更新函数代码
  2. 进行版本发布

实践准备#

首先,我们在开始正式实践之前,我们要做几个事情:

  1. 安装Serverless开发者工具
  2. 部署一个函数到线上

安装Serverless开发者工具#

通过 npm 包管理安装:适用于已经预装了 npm 的 Windows、Mac、Linux 平台。在 Windows、Mac、Linux 平台执行以下命令安装 Serverless Devs Tool工具。

$ npm install @serverless-devs/s -g

或者 通过 yarn 进行安装

$ yarn global add @serverless-devs/s

说明:

  • 如果在 Linux 或 MacOS 下执行该命令报错且报错信息为 未找到命令,请执行命令 ln -s serverless-devs安装位置 /usr/bin,serverless-devs安装位置可以通过find / -name s 查找。
  • 如果在 Linxu 下执行该命令报错且报错信息为 Error: EACCES: permission denied,请执行命令 sudo npm install @serverless-devs/s -g
  • 如果安装过程较慢,可以考虑使用淘宝 npm 源,安装命令为 npm --registry=https://registry.npm.taobao.org install @serverless-devs/s -g

部署一个函数到线上#

  1. 在本地初始化一个基于nodejs运行时的koa项目
s init nodejs-koa

初始化的时候会让我们填写相关内容,例如项目目录,选择密钥等:

image

如何配置阿里云密钥信息,可以参考:http://www.serverless-devs.com/docs/provider-config/alibabacloud

  1. 进入到项目目录,并进行部署操作:

image

稍等片刻,即可看到项目已经完成部署:

image

我们打开项目页面:

image

至此,我们的准备环节完成。

基于Gitee的CD能力建设#

在这一步,我们需要做几个事情:

  1. 有一个Gitee仓库
  2. 在仓库中push我们的代码
  3. 配置环境变量
  4. 开启Gitee Go
  5. 更新代码

Gitee仓库的准备#

创建一个Gitee仓库:

image

push代码到仓库#

image

推送后:

image

配置环境变量#

此时,我们将阿里云的密钥等信息配置到环境变量:

image

例如配置:

image

配置后的效果:

image

开启Gitee Go#

此时开启Gitee Go:

image

然后:

image

点击创建流水线,并输入流水线内容:

image

流水线文件名:deploy.yml

流水线配置:

name: koa-cicd
displayName: 'KOA自动部署流水线'
triggers: # 流水线触发器配置
push: # 设置 master 分支 在产生代码 push 时精确触发(PRECISE)构建
- matchType: PRECISE
branch: master
commitMessage: '' # 通过匹配当前提交的 CommitMessage 决定是否执行流水线
stages: # 构建阶段配置
- stage: # 定义一个 ID 标识为 deploy-stage ,名为「 Deploy Stage 」的阶段
name: deploy-stage
displayName: 'Deploy Stage'
failFast: false # 允许快速失败,即当 Stage 中有任务失败时,直接结束整个 Stage
steps: # 构建步骤配置
- step: npmbuild@1 # 采用 npm 编译环境
name: deploy-step # 定义一个 ID 标识为 deploy-step ,名为「 Deploy Step 」的阶段
displayName: 'Deploy Step'
inputs: # 构建输入参数设定
nodeVersion: 14.15 # 指定 node 环境版本为 14.15
goals: | # 安装依赖,配置相关主题、部署参数并发布部署
node -v
npm -v
npm install -g @serverless-devs/s
s config add --AccountID $ACCOUNTID --AccessKeyID $ACCESSKEYID --AccessKeySecret $ACCESSKEYSECRET -a default
cd src && npm install
s cli fc-api updateFunction --region cn-hangzhou --serviceName koademo --functionName http-trigger-function --code '{"zipFile":"./"}'
s cli fc-api publishVersion --region cn-hangzhou --serviceName koademo

其实核心部分只有5句话:

npm install -g @serverless-devs/s
s config add --AccountID $ACCOUNTID --AccessKeyID $ACCESSKEYID --AccessKeySecret $ACCESSKEYSECRET -a default
cd src && npm install
s cli fc-api updateFunction --region cn-hangzhou --serviceName koademo --functionName http-trigger-function --code '{"zipFile":"./"}'
s cli fc-api publishVersion --region cn-hangzhou --serviceName koademo
  1. npm install -g @serverless-devs/s: 安装Serverless Devs工具
  2. s config add --AccountID $ACCOUNTID --AccessKeyID $ACCESSKEYID --AccessKeySecret $ACCESSKEYSECRET -a default: 根据刚才配置的环境变量,取环境变量内容配置密钥
  3. cd src && npm install: 进入src目录,并安装依赖
  4. s cli fc-api updateFunction --region cn-hangzhou --serviceName koademo --functionName http-trigger-function --code '{"zipFile":"./src/"}' : 更新函数代码
  5. s cli fc-api publishVersion --region cn-hangzhou --serviceName koademo : 发布函数版本

更新代码#

此时,我们可以对Index.js内容进行更改:

image

然后保存,稍等片刻,可以在流水线中看到这个发布流程:

image

此时,我们可以点到流程中查看详情:

image

稍等片刻,可以看到CD流程完成:

image

完成之后,我们可以点击查看线上的代码:

image

总结#

基于Serverless架构进行项目开发,与CI/CD的集成,搞定自动化发布等是必不可少的“课程”,希望通过本文,读者可以对相关的流程有进一步的思路,可以应用到自己的项目中。

只更新代码,然后发布版本:基于Serverless Devs原子化操作阿里云函数计算

Anycodes

Anycodes

Serverless Devs

众所周知,随着时间的发展,Serverless命令行工具也逐渐的玩出了更多的花样,就目前来看,常见的形态有两种,一种是通过Yaml来进行资源的描述,另外一种是纯粹的命令行操作,而不依赖这些内容。

第一种通过Yaml来进行资源描述,其好处不言而喻,目前主流的Serverless开发者工具均是类似的模式,例如阿里云的Funcraft,著名的开源项目Serverless Framework等,通过Yaml,使用者可以通过简单的命令,进行复杂的操作,例如开发者在Yaml中描述好服务、函数等配置,描述好代码位置,只需要deploy就可以将本地项目部署到线上,非常方便。但是这里有一个非常明显的劣势,在很多时候我们的企业管理者,给每个人分配的权限是固定的,例如运维人员只能更新某些内容,开发人员只能更新某些代码,某些负责可以发布版本等,那么这个时候"一把梭"的行为就显得非常尴尬,想为开发者做更多,但是有些开发者不需要你做更多,那么"高阶能力"和"原子能力"的平衡就显得至关重要的。

第二种模式,虽然是不需要依赖Yaml,在很多时候使用起来可能会稍微复杂一些,例如我们创建一个函数可能涉及到很多流程:创建服务,创建函数,创建触发器...,相对比上面所说的一条指令而言,确实复杂很多,但是这种无Yaml的模式,更适合做原子操作,可以最大程度解决上述问题,同时这种做法也可以在一定程度上进行更多的拓展,例如某些本不需要依赖Yaml的行为:查询服务列表,查询函数列表......

所以这两种模式各有优缺点,我们在使用的时候完全可以组合来使用,达到最大的一个生产效能。那么一个新问题来了,以阿里云函数计算为例,如何同时拥有这两种模式的使用方法呢?

其实Serverless Devs天然支持Yaml描述和非Yaml描述的能力,例如阿里云函数计算的FC组件就是一个可以依靠Yaml描述进行资源操作的组件,而FC-API组件则是API相关的原子性操作。

本文将会以这样一个案例/场景为例,为读者介绍这两者的使用方法:

  1. 通过Serverless Devs快速创建一个服务/函数/触发器
  2. 通过无Yaml的模式对其中的代码部分进行单独的更新
  3. 更新之后发布一个版本
  4. 通过Git+Github Action实现一个代码自动化发布和版本自动化发布的能力

快速创建函数#

我们只需要通过s init并且选择阿里云函数计算的Python3 Http函数即可:

image

创建完成之后,我们只需要进入到对应的文件夹,并且执行s deploy,即可将项目快速部署到线上。在进入到项目后,我们可以在项目下看到一个s.yaml的文件,这个文件就是资源描述文件:

image

其完整的描述:https://github.com/devsapp/fc/blob/main/docs/Others/yaml.md

此时我们可以通过s deploy进行项目的部署:

image

部署完成,我们可以打开系统分配给我们的域名,我们可以看到内容:

image

通过无Yaml模式更新函数#

此时,我们可以编辑index.py,将Hello world!变为Hello world Serverless Devs!

image

然后我们就要接触一个新的组件FC-API:https://github.com/devsapp/fc-api

我们可以执行帮助文档:s cli fc-api -h

image

此时我们需要明确的是,当我们执行s cli的时候,系统就不去读Yaml,而直接进行相关方法的调用。

如果我们对这个方法还是不清楚,我们可以:s cli fc-api updateFunction -h

image

此时我们只需要按照规范,填写好地区,服务名,函数名,以及要更新的字段即可:

s cli fc-api updateFunction --region cn-hangzhou --serviceName fc-deploy-service --functionName http-trigger-function --code '{"zipFile": "./"}'

完成之后,我们可以再去看一下之前的页面是否同步更新了:

image

此处可能有疑问,你的帮助文档写的是:--code string [JSON String] The code of the function. The code must be packaged into a ZIP file. 你是怎么知道传递--code '{"zipFile": "./"}'的?

因为在我们看帮助文档的时候,题已经提醒了我们这是一个JSON String,同时在帮助文档最上面是有链接地址:

Usage
s cli fc-api updateFunction
API Document: https://help.aliyun.com/document_detail/189986.html
Options
--region string The region of fc endpoint.
--access string Specify the key name.
--props string The json string of props.
--serviceName string The name of the service.
--functionName string The description of the function.
--code string [JSON String] The code of the function. The code must be packaged into a ZIP file.

此时,我们可以打开https://help.aliyun.com/document_detail/189986.html:

image

image

此时为了方便,Serverless devs支持本地路径,会帮助你进行打包等操作。

当然,我们还可以更刺激一些,修改其他内容,例如单纯修改一些timeout:

s cli fc-api updateFunction --region cn-hangzhou --serviceName fc-deploy-service --functionName http-trigger-function --timeout 70

image

通过无Yaml模式发布版本#

和上面一样,我们可以用s cli fc-api -h 查看一下版本发布的方法:s cli fc-api publishVersion -h

image

尝试拼接参数:

s cli fc-api publishVersion --region cn-hangzhou --serviceName fc-deploy-service --description "This is a test version"

得到结果:

image

CI/CD组件的使用#

当我们想要把上面只更新代码,发布版本的能力集成到CI/CD,或者某些自动化流程中,如何操作呢?

以Github Action为例,我们可以直接执行s cli cicd:

image

接下来,我们对./.github/workflow/serverless-devs.yml进行自定义编辑:

name: Serverless Devs Project CI/CD
on:
push:
branches: [ master ]
jobs:
serverless-devs-cd:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: 12
registry-url: https://registry.npmjs.org/
- run: npm install
- run: npm install -g @serverless-devs/s
# 默认密钥配置指令是阿里云密钥配置指令,更多可以参考:
# 如何通过Github Action使用Serverless Devs做CI/CD:http://short.devsapp.cn/cicd/github/action/usage
# Serverless Devs的官网是通过Serverless Devs部署的: http://short.devsapp.cn/cicd/github/action/practice
- run: s config add --AccountID ${{secrets.AccountID}} --AccessKeyID ${{secrets.AccessKeyID}} --AccessKeySecret ${{secrets.AccessKeySecret}} -a default
- run: s cli fc-api updateFunction --region cn-hangzhou --serviceName fc-deploy-service --functionName http-trigger-function --code '{"zipFile":"./"}'
- run: s cli fc-api publishVersion --region cn-hangzhou --serviceName fc-deploy-service

其实,我们只是在最后加了两个人run,一个是发布代码,一个是发布版本,此时我们可以创建一个Github仓库,尝试一下:

image

创建完成之后,我们可以按照案例提醒,进行密钥的配置:

# 默认密钥配置指令是阿里云密钥配置指令,更多可以参考:
# 如何通过Github Action使用Serverless Devs做CI/CD:http://short.devsapp.cn/cicd/github/action/usage
# Serverless Devs的官网是通过Serverless Devs部署的: http://short.devsapp.cn/cicd/github/action/practice

image

image

接下来, 我们通过git init等一系列指令,完成代码推到仓库:

image

此时,我们再次修改代码:

image

修改完成之后,我们将代码push到测试仓库,可以看到,我们在Action中可以看到一个workflow在执行::

image

稍等片刻,当这个流程完成:

image

我们打开之前的页面,可以看到,网页内容已经顺利被更新:

image

总结#

本文以阿里云为例,通过在Github上使用Servelress devs单纯对代码进行更新,并进行版本发布,该流程是比较常见的,也是比较通用的,希望读者可以发挥想象力,将这个流程应用到自己的项目中。

从玩具到生产力 2: 从脚手架到快速部署

Anycodes

Anycodes

Serverless Devs

从刚开始接触一个工具,到通过这个工具把一个东西部署到线上要多久?这一直是我在思考的一个问题,就我个人而言,如果这个时间超过1小时,就会大大折扣开发者的耐性,甚至让开发者直接放弃这个工具的使用,更甚之,这个时间不能超过30分钟,10分钟,5分钟。

那么Serverless Devs从脚手架到快速部署要多久呢?

部署一个Hello World#

当我们通过npm install -g @serverless-devs/s完成了Serverless的安装,我们只需要s init,选择一个云厂商(例如Alibaba),就可以看到Hello world的模板了:

image

此时,我们可以快速选择一个Hello world的模板:

image

此时脚手架发挥作用,会引导我们选择文件目录,所需密钥信息等,完成之后,我们就可以直接进入项目目录,并且执行s deploy部署项目:

image

此时系统会为我们默认分配一个域名,我们可以直接打开:

image

部署一个Zblog/Wordpress#

部署一个Zblog/Wordpress有多简单?也许在传统服务器上,宝塔等工具已经让我们部署这类PHP框架非常简单的,但是在Serverless架构下,由于天然分布式原因,由于一些目录不可写原因,这些框架的部署,还是挺受考验的。

但是Serverless devs可以提供非常简单的部署方案:

image

根据各种提醒,即可完成项目创建:

image

这里需要额外说明一下,阿里云Serverless Devs提供的传统CMS,BLOG等项目的部署到Serverless架构,默认采用了NAS的模式,即函数计算本身是一个单纯的环境,所有代码等放在NAS中,这样可以保证代码最小改造,以目前的所示的Zblog案例,理论上是可以做到0改造部署到Serverless架构,Wordpress同样。Wordpress的初始化方法为:s init start-wordpress

完成之后,同样可以获得到一测试地址,快速体验。

更多的部署#

  • 快速创建案例项目:
    • 快速创建WordPress: s init start-wordpress
    • 快速创建ZBlog: s init start-zblog
    • 快速创建Discuz: s init start-discuz
    • 快速创建企业网站: s init start-metinfo
    • 快速创建问答系统: s init start-whatsns
    • 快速创建电商系统: s init start-ecshop
  • 快速创建静态项目:
    • react应用 s init devsapp/website-react
    • vue应用 s init devsapp/website-vue
    • hexo应用 s init devsapp/website-hexo
    • docusaurus应用 s init devsapp/website-docusaurus
    • vuepress应用 s init devsapp/website-vuepress

创建完成之后,可以直接进入项目,执行s deploy进行项目部署

总结#

Serverless Devs提供了强大的脚手架能力和快速部署的能力,通过这些能力,对我们:

  • 创建一个初始化项目快速体验有极好的帮助
  • 对我们快速创建一个示例项目有很好的支持
  • 对于我们快速开发,上手项目有比较好的效果

如何通过Github Action使用Serverless Devs做CI/CD

Anycodes

Anycodes

Serverless Devs

当我们在体验Serverless之后,欲将项目真真实实的部署到Serverless架构时,CI/CD是我们很多人绕不开的话题,那么基于Serverless Devs这款工具,如何快速的和Github Action进行有机结合,实现CI/CD的能力呢?

CI/CD的“脚手架”#

现在有很多的脚手架,但是Serverless CI/CD的脚手架应该还是少数的,而Serverless Devs为我们提供了一个CI/CD的脚手架,以Github Action为例,我们可以执行代码,快速在项目下初始化CI/CD模板。

例如,当前我的项目结构:

image

此时,我只需要告诉Serverless Devs,我要生成一个Github Action模板即可:

s cli cicd github

image

我们可以看到,系统会在当前项目创建相对应的CI/CD模板:

image

至此,我们完成了第一个步骤,初始化一个CI/CD的模板。

流程配置#

Yml文件配置#

系统所为我们生成的模板文件实际上是一个非常简单的案例:

name: Serverless Devs Project CI/CD
on:
push:
branches: [ master ]
jobs:
serverless-devs-cd:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: 12
registry-url: https://registry.npmjs.org/
- run: npm install
- run: npm install -g @serverless-devs/s
# 默认密钥配置指令是阿里云密钥配置指令,更多可以参考:
# 如何通过Github Action使用Serverless Devs做CI/CD:http://short.devsapp.cn/cicd/github/action/usage
# Serverless Devs的官网是通过Serverless Devs部署的: http://short.devsapp.cn/cicd/github/action/practice
- run: s config add --AccountID ${{secrets.AccountID}} --AccessKeyID ${{secrets.AccessKeyID}} --AccessKeySecret ${{secrets.AccessKeySecret}} -a default
- run: s deploy

整个核心流程是:

  1. 下载serverless-devs
  2. 配置密钥信息
  3. 项目部署(执行s deploy命令)

但是在实际生产过程中,我们可能需要自定义使用一些功能,此时可以参考Github Action的文档:https://docs.github.com/cn/actions

例如,我在下载serverless-devs之后,配置密钥之后,我需要进行build等操作,操作之后,我在删除临时生成的文件夹"./abc",此时我们可以:

...
- run: npm install
- run: npm install -g @serverless-devs/s
# 默认密钥配置指令是阿里云密钥配置指令,更多可以参考:
# 如何通过Github Action使用Serverless Devs做CI/CD:http://short.devsapp.cn/cicd/github/action/usage
# Serverless Devs的官网是通过Serverless Devs部署的: http://short.devsapp.cn/cicd/github/action/practice
- run: s config add --AccountID ${{secrets.AccountID}} --AccessKeyID ${{secrets.AccessKeyID}} --AccessKeySecret ${{secrets.AccessKeySecret}} -a default
- run: s build
- run: rm -rf ./abc
- run: s deploy

所以,具体的流程,我们完全可以根据需求自定义。

账号信息配置#

在上一个流程中,我们涉及到密钥信息的配置,我们可以使用Serverless Devs为我们提供的s config add命令进行。

例如,阿里云的账号体系需要AccountID,AccessKeyID,AccessKeySecret等内容,此时我们可以:

  1. 将密钥信息配置到Github Secrets中

image

我们创建多对密钥信息:

image

例如,我此处配置了三对密钥:

  • ALIYUN_ACCOUNT_ID对应阿里云密钥体系中的AccountID
  • ALIYUN_ACCESS_KEY_ID对应阿里云密钥体系中的AccessKeyID
  • ALIYUN_ACCESS_KEY_SECRET对应阿里云密钥体系中的AccessKeySecret

image

我此时则可以对应配置:

s config add --AccountID ${{secrets.ALIYUN_ACCOUNT_ID}} --AccessKeyID ${{secrets.ALIYUN_ACCESS_KEY_ID}} --AccessKeySecret ${{secrets.ALIYUN_ACCESS_KEY_SECRET}} -a website_access

当然,不同厂商可能需要不同的密钥信息配置,部分情况下厂商可能还需要配置临时密钥,此时可以通过s config add -h获取密钥配置的帮助文档:

jiangyu@ServerlessSecurity ~ % s config add -h
Usage: s config add [commands] [name]
You can add an account
Example:
$ s config add
$ s config add --AccessKeyID ****** --AccessKeySecret ****** --AccountID ******
$ s config add --AccessKey ****** --SecretKey ******
Configuration parameters for cloud vendors:
alibaba: AccountID, AccessKeyID, AccessKeySecret
aws: AccessKeyID, SecretAccessKey
baidu: AccessKeyID, SecretAccessKey
huawei: AccessKey, SecretKey
google: PrivateKeyData
tencent: AccountID, SecretID, SecretKey
🧭 How to get the key: https://github.com/Serverless-Devs/docs/tree/master/zh/others/provider-config
Options:
--AccountID [AccountID] AccountID of key information
--AccessKeyID [AccessKeyID] AccessKeyID of key information
--AccessKeySecret [AccessKeySecret] AccessKeySecret of key information
--SecretAccessKey [SecretAccessKey] SecretAccessKey of key information
--AccessKey [AccessKey] AccessKey of key information
--SecretKey [SecretKey] SecretKey of key information
--SecretID [SecretID] SecretID of key information
--PrivateKeyData [PrivateKeyData] PrivateKeyData of key information
-kl , --keyList [keyList] Keys of key information, like: -kl key1,key2,key3
-il , --infoList [infoList] Values of key information, like: -kl info1,info2,info3
-a , --aliasName [name] Key pair alias, if the alias is not set, use default instead
-h, --help Display help for command

如何配置自定义Key-Value的密钥,例如某个组件是我自己开发的,我需要配置一个Key为tempToken1,Value为tempValue1,和Key为tempToken2,Value为tempValue2,别名为demo的密钥对? 此时可以通过参数-kl , --keyList [keyList]-il , --infoList [infoList]自定义添加,例如:s config add -kl tempToken1,tempToken2 -il tempValue1,tempValue2 -a demo image

密钥中的别名有什么? 密钥中的别名,是为了帮助Serverless Devs更快的识别出你要用的密钥信息,主要是在Yaml中体现,例如: image 在此处配置的密钥信息(默认是default),如果此处配置了密钥别名是"default",那么系统就会在执行相关操作的时候,去获取名为"default"的密钥信息;

我的一个应用中,涉及到部署到多个平台,需要多个密钥信息,如何配置?
例如,当存在项目: image 此时,该app中涉及到两个Service,分别用了不同的组件以及不同的密钥内容website_access, fc_access
我们可以通过配置多个密钥信息来进行CI/CD的配置

  1. 在Github Secrets处配置对应的Key-Value
  2. 在生成的.github/workflow/serverless-devs.yml文件中配置密钥信息:
s config add -kl tempToken1,tempToken2 -il tempValue1,tempValue2 -a website_access
s config add -kl tempToken3,tempToken4 -il tempValue3,tempValue4 -a fc_access

Others#

Best practices:

透过指令集设计去看Serverless Devs 的扩展能力

hanxie-crypto

hanxie-crypto

Serverless Devs

希望通过本篇文章帮助你理解serverless devs 的指令集设计思想,并且希望你能够更好的使用serverless devs工具提升自己的开发生产力

静态指令和动态指令#

目前serverless devs 开发者工具的静态指令集非常简单只有5个 image.png

  • 配置云商秘钥的【config】
  • 初始化应用/组件的 【init】
  • 以及无配置式执行指令的 【cli】
  • 数据源设置【set】
  • 以及可以用来支持 复杂指令执行的 【exec】

以上的静态指令集主要可以帮助新用户快速使用s工具,掌握s工具的基本能力。 除了上面的静态指令,还有就是检测到有配置文件s.yaml会自动生成的动态指令,这些动态指令是根据具体执行组件的方法来确认的。举个例子,如果有一个配置文件如下,他包含了一个标准服务 component-demo,服务所关联的逻辑组件是s-demo

edition: 1.0.0 # 命令行YAML规范版本,遵循语义化版本(Semantic Versioning)规范
name: component-demo # 项目名称
vars: # [全局变量,提供给各个服务使用]
logo: https://image.aliyun.com/xxxx.png
domain: xxxx.yyy.com
services:
component-demo: # 服务名称
component: s-demo # 这里引入的是相对路径,正式配置替换成你自己的component名称即可
props:
name: ${component-test2.props.name}
otherInput: ${component-test2.output.hello}
envshow: ${env(USER)}

那么在这个配置文件的同目录下你去查看s 的输出指令,会发现新增了一个 component-demo的指令 image.png 然后你可以通过 s component-demo -h 查看其具体的使用方法 image.png 实现的原理是输入了 s component-demo test 指令后s工具会去找到 component-demo 关联的 组件s-demo,然后对他进行实例化,再把配置文件中的props 参数以及 内置的秘钥信息参数统一传到 s-demo 的 test 方法中,并且会代为执行test 方法,并把该方法的结果进行格式化输出。
这样的好处就是,s工具不关心具体的组件实现逻辑,只负责编排和解析,而把具体的执行逻辑交给组件也就是具体由开发者实现,从而极大的扩展了工具的能力范围。 假设你的配置文件下有多个services

edition: 1.0.0 # 命令行YAML规范版本,遵循语义化版本(Semantic Versioning)规范
name: component-demo # 项目名称
vars: # [全局变量,提供给各个服务使用]
logo: https://image.aliyun.com/xxxx.png
domain: xxxx.yyy.com
services:
component-demo: # 服务名称
component: s-demo # 这里引入的是相对路径,正式配置替换成你自己的component名称即可
props:
name: s1
component-demo2: # 服务名称
component: s-demo # 这里引入的是相对路径,正式配置替换成你自己的component名称即可
props:
name: s2

如果你不希望通过输入 s component-demo test , s component-demo2 test 这样一个一个的去执行,也可以通过 s test 去全量执行 image.png 系统会提示要执行的全量服务,并且会把最终结果做汇总,一起输出,这样的好处是简化了多服务并且之间有依赖关系的执行方式,是应用编排能力的具体实现。 即使只有一个服务也可以 使用 s test,最起码输入的字符更少,更加节省时间。

cli - 无配置执行组件的指令#

单独把这个指令拿出来说是因为他是本篇文章的主角,体现Serverless devs 强大扩展能力的关键点之一。#

我们知道,随着一个工具支持的能力越来越多,他的使用复杂度也会越来越高,我们一直想在设计上做一个平衡,既能够让新用户快速上手,不让那些复杂的指令迷人眼,也能够支持老用户的进阶,满足他们更高层次的需求。 配置式的指令执行方式固然有着他自己的强大和独到之处,但是相关的依赖也让很多自动化的流程变的更加的复杂,所以团队考虑再三决定推出无配置的指令集 s cli image.png

实际上有了cli指令,我可以在数小时或半天之内扩展一个新的功能点,并且对用户而言无需更新他们的工具集,即可使用我开发的功能。

真实组件例子#

platform - 登录,注册,发布#

拿 platform 组件举例子来说,platform 组件是为了方便开发者贡献用用或者组件,快速发布到我们的serverless hub上,从开发测试到发布使用只用了半天不到。 已经安装好s工具的开发者不需要做任何的升级改变,就可以 通过 s cli platform register 注册 serverless hub账号; 以及 s cli platform login 登录 serverless hub; 然后再通过s cli platform publish 发布已经写好的应用/组件。

init - 已有项目初始化s配置, cicd配置, api 配置#

再比如当前我们的 s init 只能针对新项目初始化配置,对于已有项目,例如我已经有一个使用create-react-app开发的前端项目,想把他部署到 云服务上。是没有办法处理的,这时如果通过修正代码,增加逻辑分支支持固然也可以应对这种需求,但这必须要求我修改核心功能并且进行一次发布,然后让开发者用户更新他们的命令行工具。一方面流程变得很长,并且存在变动导致的功能异常风险,另外一方面在整个用户体验上也不够友好,如果功能不停的增加意味着开发者用户要不停的升级。
我采取的方案是通过cli 组件扩展

  • 1.使用 s init 初始化一个组件模板,命名为 init ,
  • 2.然后开发初始化逻辑,比如对已有项目初始化配置文件,支持添加cicd配置文件,添加api文件等
  • 3.使用 s cli platform publish(其实已经内置到组件模板的npm publish指令了,可以直接使用npm run publish) 发布到应用市场。

之后其他的开发者就能够使用这个组件 ,通过 s cli init 引导式的初始化配置,并且 使用s deploy将自己的静态站点发布,整个过程行云流水,效率奇高,并且核心模块完全不受影响,完全不用担心影响到其他的功能使用

关于如何快速开发自己的组件请戳这里#

未来的扩展#

除了platform,init 这些官方的能力,我们也欢迎更加优秀的场景方案透出到指令设计上。这边我可以把场景大家分享一下,具体实现可以交给大家

场景1#

企业内部系统自动化流程构建, 比如我们提交代码,触发集成测试,然后继续构建部署Serverless服务到指定的云商,最后把部署结果通过钉钉等IM 端通知到开发者。 这个时候你可以在自己的CI,CD 服务器上部署 s 工具,然后开发 对应的组件,在执行脚本里面通过 s cli <自定义组件> <自定义方法> 处理流程,最终完成这个流程 ​

场景2#

企业内容serverless 开发脚手架初始化 ,通过包装s 工具完成内部常用开发工程的选择,初始化配置 ,部署测试等工作。 比如你经常做中后台开发, 可以为内部其他开发同学提供多个主题选择,将s工具用于部署和调试阶段会减少对这方面的开发量 ​

其他更多的场景取决于你的想象力。

写在最后#

我们最近一直在思考,工具最终要做成什么样子,最后觉得是能够帮助到更多的开发者,让他们享受serverless红利,或者优化自己的工作流都是好的,当然这个过程离不开广大开发者的支持,我们也希望不仅仅是我们自己在主导这个项目,希望更多的人参与进来加入社区,通过社区去主导他,只有集众所长,才有能把serverless devs 建设的更好。 社区也正在招募优秀开发,欢迎你的加入, 提pr,提issue,点star 都可以。

项目地址 https://github.com/Serverless-Devs/Serverless-Devs

阿里云Cloudshell助力Serverless Devs快速体验

Anycodes

Anycodes

Serverless Devs

如果想要体验命令行工具需要那几步骤?下载客户端->配置密钥信息->下载模板项目->配置相关的资源->部署项目。

在Serverless Devs中,这个过程可以非常简单:通过Cloudshell,直接初始化项目,并且快速入门Serverless,快速体验Serverless Devs。

首先,可以参考我们基于Cloudshell创建的帮助仓库:https://github.com/devsapp/devsapp-cloudshell-example

例如,我们想要体验Django项目:

image

此时,可以点击这个链接,并登陆阿里云账号,可以看到一个在线执行工具就出现了:

image

此时点击“确定”按钮即可:

image

完成每一步骤,点击右下角的"下一步"即可,当完成最后一步,我们可以看到系统会给我们返回默认的域名,此时我们就完成了项目的“初体验”。

Serverless devs是一款重快速体验的产品,虽然开源没多久,但一直在提升用户体验的道路上不断的努力,这次与阿里云Cloudshell结合,赋能阿里云相关的组件/应用快速部署,极速体验,这是具有非常跨越性的“体验提升”。也非常希望更多云厂商可以参与到Serverless的社区建工作中。

从玩具到生产力 1:Serverless Devs的新手引导

Anycodes

Anycodes

Serverless Devs

Serverless devs在上个月末,在中国上海,发布了2.0版本,对于很多看热闹的人可能就是一个开源工具的升级更新,但是对于我个人来说,这是Serverless Devs从玩具到生产力的转变。

在Serverless Devs 1.0版本,我们是完全的在摸索一条Serverless开发者工具的路,这条路很黑,我们在艰难前进。经过几个月的努力,我们逐渐的看到了光亮,于是在Serverless devs 2.0版本正式发布。

相对于1.0版本,2.0在很多层面上都有了十足的优化。

“无休止”的引导#

Serverless devs 2.0版本,增加了很多的引导,以至于一个超级小白,都可以快速入手体验。

当我们通过npm install -g @serverless-devs/s完成了Serverless devs的安装,我们仅需要一个s就可以开始Serverless之旅:

image

非常明显的s init,带着我们迈向开始的第一步, 选择一个hello world

image

此时我们还没有配置过密钥信息,所以会让我们配置:

image

我们选择Alibaba Cloud即可再次看到引导:

image

打开引导,不仅可以看到密钥的获取方法:

image

还可以看到安全建议:

image

密钥配置成功之后,依旧可以看到下一步的引导:

image

当我们输入:

cd /Users/jiangyu/Desktop/untitled/start-fc/src/mytest/myhello
s -h

之后,我们可以看到金手指:

image

此时只需要按照提示执行命令即可看到帮助文档:

image

完成之后,我们就可以大胆的执行:s deploy进行项目部署。

至此,我们完成了一个新手入门的案例。

也许,有人会觉得上面的步骤有些多,好像并不是十分的方便。其实,上面的过程是我们在完全无额外帮助的前提下,仅仅通过一个s开始的。如果说我们写文档如何引导大家开始第一个hello world呢?

三步开始Serverless devs:

  • 下载Serverless devs:npm install -g @serverless-devs/s
  • 初始化项目,并进入到项目文件夹:s init devsapp/start-fc
  • 部署项目:s deploy

显然三步能说明的问题,我为啥要用上面的整个过程来描述呢?

因为,我们不仅仅希望用户在文档的帮助下,在新手引导文档的帮助下,可以三步开始,我们更希望,开发者可以在任何情况下,哪怕没有文档说明,仅仅通过一个s就开始顺利开始自己的Serverless旅程。

在新版的Serverless Devs中,出现的绝大部分错误,都会给出可能的解决方案:

例如Yaml的格式有问题,我们会告诉你出问题的位置,同时也会告诉你要用标准的Yaml格式: image

再比如,没有找到你要初始化的案例,会告诉你注意源的配置,并且给你两个可能的解决方案: image

再再再比如,当出现错误,我们都会努力给出引导:

😈 If you have questions, please tell us: https://github.com/Serverless-Devs/Serverless-Devs/issues

我们希望的是,用户在使用Serverless Devs的时候,无论何时,都不会因为出现错误而手忙脚乱,因为“Serverless Devs”和广大的社区开发者,一直就在你的身边,陪伴你解决一切问题,让问题不再是问题。

未来章节预告:

  • 《从玩具到生产力 2: 从脚手架到快速部署》
  • 《从玩具到生产力 3: 也许Serverless Devs的CI/CD方案更有趣》
  • 《从玩具到生产力 4: 拥抱容器,让一切容易》
  • 《从玩具到生产力 5: 命令行的可观测性,让“方便”更加“方便”》
  • 《从玩具到生产力 6: 吃自己的狗粮》
  • 《从玩具到生产力 7: 前端开发神器 Rocket》
  • 《从玩具到生产力 8: 简单与感动》

简单几步完成Serverless架构下的Blog建设

Anycodes

Anycodes

Serverless Devs

前言#

在日常生活中,我们经常需要记录一些自己的日常,包括一些想法、状态,或者是学习的某些技术,这个时候,就需要有一个博客系统来满足需求。但是无论是自己开发的博客系统,还是用已经开源的博客软件或者一些CMS系统,只要涉及到自己搭建博客功能,就离不开服务器等云资源,涉及到服务器、数据库等云资源,就势必离不开成本的支出,包括资金成本和运维成本等。此时,如果可以有一个可以保证博客安全、稳定、高性能的同时,又能低运维、低成本的运行博客的云端服务/云产品,显得尤为重要。而随着Serverless架构越来越火热,其按量付费,弹性伸缩... 等很多优质特性,都让人眼前一亮,不得惊叹云计算为我们带来的便利,也让很多人逐渐的开始思考,自己的项目应该如何和Serverless架构有交集,或者如何让Serverless为自己的项目赋能,体验Serverless架构带来的技术红利。

一个博客对于一个人而言可能会承载很多事情,尤其是一个技术博客对于一个程序员而言,不仅仅是自己学习、成长的见证,也是自己的工作、生活的一个见证,甚至在很多的技术面试过程中,拥有一个自己的技术博客都是一个非常不错的加分项。但是传统意义上的很多研发同学建设的技术博客都会面临服务器的问题,因为技术博客往往并没有太大的流量,也很难产生很大的收入,单纯为了自己的兴趣、爱好来购买服务器,并且进行一些后期运维工作,在成本支出、精力支出上确实不太合适。所以基于Serverless架构的博客系统就显得非常重要了,因为基于Serverless架构建设的博客系统,不仅仅可以体验学习进技术,也可以直接得到Serverless架构带来的技术红利

安装Serverless Devs开发者工具#

通过 npm 包管理安装:适用于已经预装了 npm 的 Windows、Mac、Linux 平台。在 Windows、Mac、Linux 平台执行以下命令安装 Serverless Devs Tool工具。

$ npm install @serverless-devs/s -g

或者 通过 yarn 进行安装

$ yarn global add @serverless-devs/s

说明:

  • 如果在 Linux 或 MacOS 下执行该命令报错且报错信息为 Error: EACCES: permission denied,请执行命令 sudo npm install @serverless-devs/s -g。
  • 如果安装过程较慢,可以考虑使用淘宝 npm 源,安装命令为 npm --registry=https://registry.npm.taobao.org install @serverless-devs/s -g。

快速部署博客系统#

Serverless devs提供了多种类型的博客系统:

  • Zblog
  • Wordpress
  • Hexo
  • Vuepress
  • Django Blog

在部署过程中可能需要获取阿里云密钥信息,可以参考:https://config.devsapp.net/account/alibaba

Zblog#

Zblog是一款轻量级的PHP开源框架,拥有独立的后台管理能力,支持Sqlite和Mysql等数据库。
使用该博客系统涉及到阿里云函数计算、容器镜像、硬盘挂载等产品。

部署流程:

  • 初始化一个模版项目:s init devsapp/start-zblog
  • 进入项目:cd start-zblog
  • 部署项目:s deploy

Typecho#

Typecho是一款PHP开源框架,拥有独立的后台管理能力,支持Sqlite和Mysql等数据库。
使用该博客系统涉及到阿里云函数计算、容器镜像、硬盘挂载等产品。

部署流程:

  • 初始化一个模版项目:s init devsapp/start-typecho
  • 进入项目:cd start-typecho
  • 部署项目:s deploy

Wordpress#

Wordpress是一款PHP开源框架,拥有独立的后台管理能力,支持Mysql等数据库。
使用该博客系统涉及到阿里云函数计算、容器镜像、硬盘挂载等产品。

部署流程:

  • 初始化一个模版项目:s init devsapp/start-wordpress
  • 进入项目:cd start-wordpress
  • 部署项目:s deploy

Hexo#

Hexo是一款轻量级的前端开源框架。

部署到函数计算#

针对该博客系统,您可以选择把他部署在函数计算上,涉及到阿里云函数计算、容器镜像、硬盘挂载等产品。

部署流程:

  • 初始化一个模版项目:s init devsapp/start-hexo
  • 进入项目:cd start-hexo
  • 部署项目:s deploy

部署到对象存储#

您也可以选择把他部署在对象存储上,涉及到阿里云函数计算、对象存储、CDN等产品。

部署流程:

  • 初始化一个模版项目:s init devsapp/website-hexo
  • 进入项目:cd website-hexo
  • 部署项目:s deploy

Vuepress#

Vuepress可以作为一款轻量级的前端博客系统。
使用该博客系统涉及到阿里云函数计算、对象存储、CDN等产品。

部署流程:

  • 初始化一个模版项目:s init devsapp/website-vuepress
  • 进入项目:cd website-vuepress
  • 部署项目:s deploy

Django Blog#

Django Blog是一款基于Python Django框架编写的博客系统,拥有独立的后台管理能力,支持Sqlite和Mysql等数据库。
使用该博客系统涉及到阿里云函数计算、容器镜像、硬盘挂载等产品。

部署流程:

  • 初始化一个模版项目:s init devsapp/django-blog
  • 进入项目:cd django-blog
  • 部署项目:s deploy

默认信息:

  • 默认登录后台:/admin
  • 默认账号:blog
  • 默认密码:myblog12345!

Serverless Devs的官网是通过Serverless Devs部署的

Anycodes

Anycodes

Serverless Devs

只有自己吃自己的狗粮,自己做的东西才不“🐶”。Serverless Devs自发展之处到现在,已经经历了几个月的时间,在这几个月,Serverless Devs的成长是迅速的,这很大一部分的原因是“我们在吃自己的狗粮”,我们相信,如果自己都用不爽的东西,大家一定很难用的起来。

今天这篇文章,是一个关于Serverless Devs官网建设的文章,文章很简单,也很有趣。

Serverless Devs与Docusaurus#

众所周知,开源项目的官网不宜太复杂,其实简简单单的就好,所以我们经过了很长时间的对比,最终选择了Docusaurus作为官网的框架选型。那么问题来了,我们选型结束之后,我们要如何来建设官网?

经过一些简单的调研,我们决定用Serverless Devs建设Serverless Devs官网,并将其部署到Serverless架构上,很绕嘴是吧?但是,这个过程却真的很“经典”:

我们通过Serverless devs初始化了Docusaurus:s init devsapp/website-docusaurus,这一部分可以参考文档:https://github.com/devsapp/website-example

讲真,虽然也就是一行代码的事情,但是整个初始化还是比较“赏心悦目”的,作为一个Serverless应用全生命周期的工具,Serverless Devs在脚手架和引导层面还是下了很多功夫的:

image

可以看到,初始化的时候,系统引导式的让我们填写了项目名,存储桶名,以及需要的密钥信息,同时完成之后,还告诉我们:

You could [cd /Users/jiangyu/Desktop/start-fc/website/serverless-website] and enjoy your serverless journey!

感觉还是很贴心的。

接下来,按照指引:

image

可以看到帮助文档:

image

当执行s website-starter -h之后,首次运行帮助信息,可能涉及到组件加载过程,稍等片刻,可以看到帮助信息:

image

此时,我们要将项目部署到线上,只需要执行s deploy即可。

当然,我们还需要对项目进行一定的配置,以及对我们的官网进行一定的建设。

关于网站建设,可以参考Docusaurus的官网文档,关于Serverless Devs的website组件配置,可以参考上图给我们🧭 More information: https://github.com/devsapp/website

image

在文档中可以了解更多的配置内容,最终生成我们的s.yaml

edition: 1.0.0
access: website_access
services:
website:
component: devsapp/website
actions:
pre-deploy:
- run: npm install
path: ./
- run: npm run build
path: ./
props:
bucket: serverless-devs-website
src:
codeUri: ./
publishDir: ./build
index: index.html
subDir:
type: index
region: cn-hongkong

CD与Serverless Devs#

当我们建立好了网站页面,在本地也可以正常运行,通过本地的s deploy也可以顺利部署了,这个时候面临了新的问题:我如何更新我的网站?每次都要手动的在本地发布么?是否可以利用Github Action,接入自动化的能力呢?

所以:

  1. 我创建了一个仓库:https://github.com/Serverless-Devs/website
  2. 我将代码推送到仓库之后,创建了一个Github Action的配置:
name: Website Publish
on:
push:
branches: [ master ]
jobs:
publish-website:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: 12
registry-url: https://registry.npmjs.org/
- run: npm install
- run: npm install -g @serverless-devs/s
- run: s config add --AccountID ${{secrets.ALIYUN_ACCOUNT_ID}} --AccessKeyID ${{secrets.ALIYUN_ACCESS_KEY_ID}} --AccessKeySecret ${{secrets.ALIYUN_ACCESS_KEY_SECRET}} -a website_access
- run: s deploy

此时我再push代码,就可以自动将网站发布出来了。

这里面的核心点:

  1. 安装Serverless Devs: run: npm install -g @serverless-devs/s
  2. 配置密钥信息:run: s config add --AccountID ${{secrets.ALIYUN_ACCOUNT_ID}} --AccessKeyID ${{secrets.ALIYUN_ACCESS_KEY_ID}} --AccessKeySecret ${{secrets.ALIYUN_ACCESS_KEY_SECRET}} -a website_access
  3. 部署:run: s deploy

整个效果:

image

部署后的页面:

image

这里要说明,此处配置密钥信息,使用了Github的Secrets功能,这个功能还是比较基础的,所以不多赘述,主要就是将发布的所需要的密钥信息配置到Secrets里面。

总结#

其实,目前来说很多人的博客,部分的官网都是通过静态网站等进行部署,通过Serverless Devs走这一套还是比较方便的:

  1. 得益于Serverless Devs的行为描述,我们可以更简单的将npm installnpm run build等指令集成到项目中;
  2. 得益于Serverless Devs的引导能力,包括创建,入门,以及密钥配置时的获取链接,Serverless devs确实在不断的从细节出发,为便利而努力;
  3. 得益于Serverless Devs的灵活性,只需要两三行代码,就可以配置出Github的CD能力,将网站持续发出去,我觉得这个还是挺爽的;

当然,目前来看还是有一些问题等待去做的:

  1. Serverless Devs的场景还是有待丰富的;
  2. 这个社区官网只有CD,没有CI其实还是有一定风险的,要慢慢的完善起来;

命令行工具升级:不仅仅是更多的Emoji

Anycodes

Anycodes

Serverless Devs

安装完一个工具,第一步做什么?敲一下工具的名称,看看这个工具的“葫芦里卖的什么药”:

image

在这个页面我们做了这样几个事情:

  1. 提供了一个极客的logo:serverless
  2. 提供了工具的简介,并提供了部分的url入口:包括Documents、Discussions、Issues
  3. 提供了快速入门的指令:🍻 Can perform [s init] fast experience
  4. 提供了指令说明,包括自定义命令,例如: 👉 This is a customer command please use [s fc-deploy-test -h] obtain the documentation

当我们入门执行s init之后,你会发现:

image

我们提供了:Hello World Example、Web Framework Example、Static Website、Serverless Dev template等十余个案例的模板,如果觉得这些模板不够有趣,还可以直接使用已有的模板。那么问题来了,已有的模板在哪里看呢?

当然,在这个页面已经告诉大家了:🚀 More: https://github.com/Serverless-Devs/package-awesome

So.... 我们可以初始化一个,假如说,我们要初始化一个zblog-example:

image

不要惊慌,仔细看一下错误信息:No application found?,下面附带了几个解决方案:

1️⃣ Start quickly with 's init'
2️⃣ See some cases on GitHub: https://github.com/Serverless-Devs/package-awesome
😬 Give us an issue to solve: https://github.com/Serverless-Devs/Serverless-Devs/issues

Get新技能,打开 https://github.com/Serverless-Devs/package-awesome搜索一下zblog,发现zblog案例叫做start-zblog,果然名字不能瞎猜,要看文档,接下来s init start-zblog,爽歪歪 ....

image

Serverless Devs 开源之夏 2021

Anycodes

Anycodes

Serverless Devs

Serverless Devs 目前已经在参加 开源之夏 2021 的活动。

在开源之夏中,我们将会提交以下项目,欢迎同学们积极报名:

  • Serverless Devs测试用例的完善: Serverless Devs现在的包括主仓库和组件库两个部分。 例如Serverless Devs repo:https://github.com/serverless-devs 在这个repo中,由于Serverless Devs项目是发展中的,所以测试用例目前并不完善。所以该项目的工作是为该项目编写测试用例。 主要包括: https://github.com/serverless-devshttps://github.com/devsapp
  • Serverless 调试&依赖安装优化: Serverless架构很新,很热,被很多人关注,但是其被吐槽的点还是有一些的,例如调试复杂,安装依赖复杂。所以通过该项目进行调试和依赖安装的相关调研,并参与到开源项目中,提供行业的解决方案。
  • Serverless架构环境划分方案探索: Serverless架构发展速度很快,但是也有很多问题,例如环境划分(开发环境,线上环境,测试环境)等,希望通过该项目,可以通过工具链层面提供一种环境划分的方案,并将其实现成Serverless Devs的组件。
  • Serverless Devs 云厂商组件开发:Serverless devs是一个无厂商锁定的Serverless开发者工具,目前已经支持阿里云、腾讯云、AWS等多家云厂商的Serverless产品,希望通过本项目可以进一步拓展云厂商的组件。
  • Serverless与前端的碰撞:Serverless架构被称为是云计算的下一个十年,更是被很多前端工程师视为“改变命运的转折点”,通过Serverless架构,“前端不再是单纯的前端”,通过Serverless架构,“人人都是全栈工程师”,那么Serverless架构和前端的碰撞到底是什么样子的?希望通过该项目,更多的同学可以对Serverless有一个更深入的了解,对Serverless架构有一个更深刻的认识,同时希望可以进一步探索Serverless架构与前端的结合点,并做出一些有趣的事情吧!
  • Serverless工具链新形态的探索:Serverless架构是一个比较新的话题,Serverless架构的工具链更是比较受关注的点,那么Serverless架构的工具链和传统的例如K8S工具,和一些监控告警工具有什么区别呢?Serverless架构的工具更应该注意什么问题呢?它长什么样子呢?目前Serverless Devs作为Serverless的工具链开源项目,包括Serverless CLI,Serverless Desktop,Serverless Cloud以及Serverless Hub,Serverless Registry等几个部分,那么这些模块又是如何划分,有什么作用呢?通过本项目,希望大家可以对Serverless有一定的了解,对Serverles是架构工具链有一定的自主思考能力,并且参与到Serverless架构工具链的创新中。
  • Serverless CI/CD探索:Serverless架构是相对来说比较新的技术,也是目前比较火热的技术,随着时间的不断发展,其也被更多人所重视,成为更多企业技术选型的首选。通过Serverless架构虽然在一定程度上做到了降本提效,但是却可能产生更细腻的资源,这些资源的管理,持续集成/发布,逐渐的成为了比较重要的关注点,所以本项目将会是Serverless CI/CD的探索,主要包括Serverless架构下的CI/CD是什么样子的,Serverless本身是否可以做CI/CD,Serverless架构工具链和CI/CD结合后是什么样子的。

我们期待你#

如果需要参加上面所述的项目,您需要具备以下基础条件:

  • 基础的前端知识,例如HTML,Javascript,CSS等;
  • 对后端语言等有一定的了解,尤其是Node.js/Typescript;
  • 有一颗积极探索的心,不断的发现问题,不断的创新挑战;
  • 有积极负责的态度,不仅仅要学习,更要有对一件事的执着,愿意探索新鲜事物;

加分项:

  • 对Serverless有一定了解
  • 对CI/CD,环境划分等有一定了解
  • 开发过完整项目,有过开源贡献经验;

我们将会提供#

  • 相关的Serverless资料,包括Serverless的学习路径
  • Serverless Devs的相关资料
  • 强大的导师阵容
    • 寒斜:阿里云智能云原生中间件前端负责人,2016年加入阿里中间件从事云产品企业控制台研发工作,目前带队负责中间件20多款云产品的前端研发工作,主要技术栈为大前端通用技术,包括不限于Node.js, TypeScript, React , Electron, ReactNative等。对前端研发效能提升,前端数字化体验管理体系建设有多年的实践经验,目前专注在Serverless 开发者工具链的建设,是云原生Serverless Dev研发负责人。关注前端最新技术动态,关注云原生技术对前端群体的影响,致力于向前端群体推广普及云原生理念
    • 西流:阿里云智能云原生函数计算技术专家,负责阿里云函数计算产品功能开发(runtime开发、事件源集成以及企业级sereverless解决方案落地等),目前专注在Serverless 开发者工具链的建设,是云原生Serverless Dev Tools研发负责人之一,主导了S/fc 组件的开发工作。关注Serverless最新技术动态以及在企业级解决方案的落地,致力于推动 Serverless 在开发者群体的流行
    • 江昱:NUDT在读博士,阿里云Serverless产品体验侧负责人,开源社区Serverless Framework国内贡献者,Serverless Devs项目发起人,Serverless架构布道师,阿里云CIO学院特聘讲师,纸质图书《Serverless架构》、《Serverless工程实践》作者,电子书《架构师特刊:人人都能学会的Serverless实践》作者;

希望的样子#

  • 你可以对Serverless有更加深刻的认识;
  • 你可以参与到Serverless Devs社区工作中来;
  • 可以开发出对应项目的组件,以帮助Serverless生态中的更多人,让大家一起玩转Serverless;

总结#

Serverless是非常前沿的技术,Serverless devs是非常重要的工具链体系,我们愿意和大家一起努力,一起奋进,为推动Serverless的发展而不断前行。