2022-07-06

FC - Custom Container 运行环境下的 Gin 自动部署

又是没找到工作的一天，所以又开始尝试一些新东西，这篇文章讲在阿里云 Serverless 架构的 FC 产品，Custom Container 环境下如何跑起 Gin 应用。

Serverless 架构一开始是在腾讯云的 SCF 先接触的，我的博客涉及到 Serverless 的文章应该说是非常多的，近年来也越来越多的人开始进行更多的接触，把更多的业务放上来。一开始我们更多是依赖厂商对特定语言预制好了的环境，比如 Node 、 PHP 这些热门的，但这些版本是固定的，而且你要是想增加一些底层依赖库其实是很麻烦的。

然后又出现了 Custom Runtime 来更好解决这个问题，但是阿里云提供的 Funcraft 工具，我是没跑通官方迁移文档中的 Laravel 、 ThinkPHP 迁移流程，后面排查是 FC 语言提供的默认环境和用 Funcraft 的不一样，少了很多底层依赖库，要自己加进去也麻烦，所以我就放弃了，哈哈哈。阿里云现在又抛弃了这个 Funcraft 工具，开始推 Serverless Devs，然后这个工具的压测功能我也是没跑起来，继续使用 wrk，哈哈哈。

Custom Runtime 其实可以让我们更好去做一些业务，比如我最近做的反代，部署在香港地域，nginx 代理到指定的网站，比如 GitHub 、GitHub API 等，现在支持了很多常用域名。其实做这个是非常简单的，nginx 判断二级目录是不是支持的域名，然后 proxy_pass 过去，写一个 Dockerfile + nginx.conf 就可以了。

我之前这方面也写过一篇文章的，因为我要借助 Funcraft 来生成 nginx 环境的那些文件，所以整体流程其实是非常麻烦的，而且最重要的是，那个方法现在已经不行了，没仔细去排查，应该是后面版本迭代升级了然后影响到了，我自身没有去控制好版本号。

用 Custom Runtime 来完成反代需求，呈现的效果是非常棒的，让我对这块有了不一样的期望，那就是能不能把整一个应用更便捷部署上来。

Custom Runtime 有什么优势呢？

容器镜像，可以更好的实现我们业务的运行环境，不过 FC 不支持多阶段构建，go 的 Dockerfile 都是编译后，就放在 scratch 中去跑，但测试后发现是不行的。
低成本迁移，因为我们可以用 Dockerfile 来构建环境。
镜像加速，实例的镜像拉取可能是通过已启动的实例，不是每次都走源站，相当于启动速度会快很多，毕竟不支持多阶段构建，编译后基本都 200M+ 了。
自动部署，在控制台配置好后，监听到代码仓库的变化，自动进行构建后部署到 FC。
权限，不需要向之前打包一样，还是在 linux 下加上执行权限然后再打包。

业务的灰度是实现不了的，但可以做测试环境、生产环境的区分，相当于两个函数去监听两个不同的分支。

接着我们来简单的部署一个，Gin 官方的 Demo 稍微改一下，我们在代码中要写死监听端口的，经过打印 env 的排查，这边 FC 是没有在环境变量中提供 FC_SERVER_PORT 的。

main.go

package main

import (
    "github.com/gin-gonic/gin"
    "net/http"
)

func main() {
    r := gin.Default()

    r.GET("/ping", func(c *gin.Context) {
        c.JSON(http.StatusOK, gin.H{
            "message": "pong",
        })
    })

    err := r.Run(":9000")

    if err != nil {
        return
    }
}

Dockerfile

FROM golang:1.18-alpine as build

# 时区
RUN apk --no-cache add tzdata

ENV TZ=Asia/Shanghai

WORKDIR /code

COPY go.mod go.sum ./

# 下载依赖
RUN go mod download && go mod verify

COPY . .

# 编译
RUN env GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o main main.go

# 清除缓存
RUN go clean --modcache

EXPOSE 9000

# 执行
CMD ["./main"]