Skip to main content

5 posts tagged with "cicd"

View All Tags

云效+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 开发者有所帮助。笔者云开发时间不长,针对文中部署步骤有更好的建议,欢迎分享探讨。

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单纯对代码进行更新,并进行版本发布,该流程是比较常见的,也是比较通用的,希望读者可以发挥想象力,将这个流程应用到自己的项目中。