Skip to main content

云效+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的社区建工作中。