文档

基础开发

更新时间:

本文介绍Serverless 应用引擎 SAE(Serverless App Engine)源码部署的工作原理、环境配置、构建流程、源代码导入等信息。

整体工作原理

作为Serverless 应用引擎 SAE(Serverless App Engine)中,降低用户运维负担的重要一环,源码部署提供了直接从用户源码到应用上线的能力。本功能是接受用户触发的构建事件后,根据用户提供的源代码,自动检测构建所需的环境,自动化完成代码构建到部署的完整流程(配置运行时环境、安装依赖管理工具、安装第三方依赖、打包镜像、推送到个人仓库)。

在具体的实现方式上,SAE将构建流程和部署流程隔离,仅会导出与产物运行相关的运行环境,因此可以大大减少产物镜像的体积,提高应用部署和启动速度。但是,需要注意的是,在这种模式下,在依赖构建环境中安装的某些依赖可能不存在于应用部署镜像中。

SAE源码部署功能支持构建产物镜像的导出和下载,遵循云原生Buildpack规范。

基础环境配置

当前,构建时只支持使用Ubuntu 22.04作为基础镜像,并基于此构建build image和run image,作为构建时和应用启动时的基础镜像。build image和run image的不同点在于build image会包含更多仅与应用构建相关的库,功能更加强大,但是体积较大,不适合部署使用。

当前的构建机配额为2核CPU、4 GB内存、30 GB磁盘。如果您有特殊的构建需求,请联系阿里云技术团队。更多信息,请参见联系我们

源码部署的构建主流程

提交代码后会根据自动探测结果进行构建,选择运行时、运行时版本、第三方包管理工具版本。环境配置完毕后,将自动执行构建命令。

根据运行时进行个性化配置

当前需要手动选择运行时语言、运行时版本,不支持指定第三方包管理工具版本。

支持的版本列表

运行时版本列表

当前支持Ubuntu 22.04作为基础环境。支持Go、Java、Node.js、Python和PHP语言的应用,此外还支持静态页面和基于Dockerfile构建的应用。支持的版本列表和额外需要的信息如下所示:

运行时语言

支持的版本

额外需要的信息

Go

全部版本

Java(OpenJDK)

8、11、16、17、18

Node.js

14、16、18、19、20

Python

3.8、3.9、3.10、3.11

输入(例如python main.py

PHP

8.1、8.2

静态页面应用

不涉及

Dockerfile

不涉及

第三方包管理工具版本

第三方包管理的判定和下载由源码部署的探测逻辑完成,当前不能通过用户直接选择。版本列表如下:

包管理工具

版本

Graalvm

21.0.0

Gradle

基于工程文件检测或8.2.1

Maven

基于工程文件检测或3.9.3

Pnpm

基于工程文件检测或最新版本

Yarn

基于工程文件检测或最新版本

Pip

跟随Python版本

Go mod

不涉及

Composer

2.1.3

注意事项

Python

对于大多数情况来说,Python没有确定的启动方式。因此,推荐在构建Python应用时指定应用程序的启动命令。可能的启动命令如下:

python main.py
gunicorn -p :8080 main:app

在使用Python 11构建有Numpy依赖的代码时,会产生构建错误,降低版本为3.8即可。

Java

在使用Maven或Gradle进行编译时,如果工程项目中存在mvnwgradlew脚本文件时,可能会产生额外的行为,进而导致编译失败。在不影响正常编译的前提下,建议删除工程文件中的该类文件后再提交源码部署流程。

Go

由于老版本的Go(小于1.13)不支持Go proxy的功能,因此如果应用的工程文件中的go.mod文件指定了一个偏小的版本,经常会导致无法利用到阿里镜像源的加速能力,导致依赖拉取失败。推荐在不影响工程构建的前提下,尽量升级工程文件中指定的Go运行时版本。

当前,在工程中没有go.mod时,不会使用goproxy

读取静态文件时,请使用embedFS

高级配置:源码部署的构建配置

通过配置文件指定构建行为

可以通过在代码的构建目录写入Procfile或app.yaml的方式提供程序启动命令。

说明

通过控制台设置的ENTRYPOINT优先级更高,不会被配置文件的设置覆盖。

Procfile

Procfile文件能够指定应用程序启动时执行的命令。可以使用Procfile声明各种进程类型。在源码部署中,需要将process-type指定为web,并添加应用启动命令。

  • 格式如下:

    web: <用户entrypoint>
  • 示例如下:

    web: python app.py -p 9000

app.yaml

app.yaml是用于应用部署的应用配置文件,包含了启动命令和运行时配置。当前只使用其设置应用启动命令。

  • 格式如下:

    entrypoint: <用户entrypoint>
  • 示例如下:

    entrypoint: gunicorn -b :$PORT main:app

源代码导入

当前,源码部署过程只允许通过从源代码托管平台导入的方式上传代码。用户需要首先将自己的代码推送到代码仓库,在应用创建时的授权界面授权后才可以接入到SAE的源码部署流程中。

当前支持接入的代码平台

支持以下代码托管平台作为代码源:

触发器事件

支持以下构建触发模式:

  • Push到指定分支:每次新提交代码到指定分支时,系统都会自动构建应用的新版本。

  • 手动触发构建:选择手动触发时,系统不会自动执行持续部署。

  • Tag/Release事件:在GitHub中该类事件用Release表示,在GitLab中用Tag表示。

仓库授权方式

源代码仓库的授权使用OAuth 2.0授权协议。需要授予平台的权限范围如下表所示:

重要

请全部授权,否则会导致应用构建部署失败。

平台名称

权限代码

权限范围描述

GitHub

  1. repo

  2. admin:repo_hook

  3. admin:org

  1. 代码仓库权限

  2. Webhook管理权限

  3. 组织管理权限

Gitee

  1. user_info

  2. projects

  3. hook

  1. 访问用户的个人信息、最新动态

  2. 查看、创建、更新用户的项目

  3. 查看、部署、更新用户的Webhook

GitLab

  1. read_user

  2. read_repository

  3. write_repository

  1. 读取授权用户的个人信息

  2. 代码仓库读权限

  3. 代码仓库写权限(仅用于创建Webhook)

Codeup

  1. read:repo

  2. read:repo:branch

  3. read:user

  4. read:repo:tag

  5. read:repo:commit

  6. read:repo:webhook

  7. write:repo:webhook

  8. read:org

  1. 代码仓库读权限

  2. 代码仓库分支读权限

  3. 授权用户的个人信息读权限

  4. 代码仓库标签读权限

  5. 代码仓库提交历史记录读权限

  6. 代码仓库Webhook读权限

  7. 代码仓库Webhook写权限

  8. 组织的读权限