Serverless

Serverless
Serverless

Serverless

原文：https://docs.gitlab.com/ee/user/project/clusters/serverless/

Overview
Knative
Prerequisites
Installing Knative via GitLab’s Kubernetes integration
Using an existing installation of Knative
Supported runtimes
- GitLab-managed runtimes
- OpenFaaS runtimes
Deploying functions
Deploying Serverless applications
Configuring logging
Enabling TLS for Knative services
Using an older version of gitlabktl

Serverless

在 GitLab 11.5 中引入.

警告： Serverless 目前处于alpha 状态 .

Overview

无服务器架构为运营商和开发人员提供了在不配置单个服务器的情况下编写高度可扩展的应用程序的能力.

GitLab 支持在 Kubernetes 环境和主要的云 FAAS 环境中部署无服务器应用程序的几种方法.

目前，我们支持：

Knative ：在 GKE 和 EKS 上使用 Knative 和gitlabktl构建 Knative 应用程序.
AWS Lambda ：通过无服务器框架和 GitLab CI / CD 创建无服务器应用程序.

Knative

使用Knative在 Kubernetes 上运行无服务器工作负载.

Knative 扩展了 Kubernetes 以提供一组中间件组件，这些组件对于构建现代的，以源为中心的，基于容器的应用程序很有用. Knative 通过其主要组件带来了一些明显的好处：

服务：请求驱动的计算，可扩展为零.
事件：事件的管理和交付.

有关 Knative 的更多信息，请访问Knative docs 资源库 .

借助 GitLab Serverless，您可以部署功能即服务（FaaS）和无服务器应用程序.

Prerequisites

要在 GitLab 上运行 Knative，您需要：

现有的 GitLab 项目：您将需要一个 GitLab 项目来关联所有资源. 最简单的入门方法：
- 如果您打算部署功能，请克隆功能示例项目以开始使用.
- 如果您打算部署无服务器应用程序，请克隆示例Knative Ruby App以开始使用.
Kubernetes 集群：部署 Knative 需要启用 RBAC 的 Kubernetes 集群. 最简单的入门方法是使用 GitLab 的GKE 集成添加集群. 建议的运行 Knative 的最低建议群集规格为 3 个节点，6 个 vCPU 和 22.50 GB 内存.
GitLab 运行程序：运行 CI 作业需要运行程序，该作业会将无服务器的应用程序或功能部署到您的集群上. 您可以将 GitLab Runner 安装到现有的 Kubernetes 集群上. 有关更多信息，请参见安装应用程序 .
域名： Knative 将使用 Istio 提供自己的负载平衡器. 它将为 Knative 服务的所有应用程序提供一个外部 IP 地址或主机名. 系统将提示您输入一个通配符域，将在其中提供您的应用程序. 配置您的 DNS 服务器以使用该域的外部 IP 地址或主机名.
.gitlab-ci.yml ： GitLab 使用Kaniko来构建应用程序. 我们还使用GitLab Knative 工具 CLI 来简化向 Knative 部署服务和功能.
serverless.yml （仅适用于功能）：使用 lessserver 部署功能时， serverless.yml文件将包含存储库中托管的所有功能的信息以及所使用的运行时的引用.
Dockerfile （仅适用于应用程序）：Knative 需要Dockerfile才能构建您的应用程序. 它应该包含在项目存储库的根目录中，并公开端口8080 . 如果您打算使用我们的运行时来构建无服务器功能，则不需要Dockerfile .
Prometheus （可选）：安装 Prometheus 可使您监视无服务器功能/应用程序的规模和流量. 有关更多信息，请参见安装应用程序 .
日志记录 （可选）：配置日志记录可让您查看和搜索无服务器功能/应用程序的请求日志. 有关更多信息，请参见配置日志记录 .

Installing Knative via GitLab’s Kubernetes integration

注意：运行 Knative 的最小建议群集大小是 3 节点，6 vCPU 和 22.50 GB 内存. 必须启用 RBAC.

Add a Kubernetes cluster.
选择” 应用程序”选项卡，然后向下滚动到” Knative 应用程序”部分. 输入要用于您的应用程序/功能的域（例如example.com ），然后单击Install .
Knative 安装完成后，您可以等待 IP 地址或主机名显示在Knative Endpoint字段中，或手动检索 Istio Ingress 端点 .

注意：在集群上运行kubectl命令需要首先设置对集群的访问. 对于在 GKE 上创建的集群，请参见GKE 集群访问，对于其他平台，请安装 kubectl .
入口现在在此地址可用，并将基于请求中的 DNS 名称将传入请求路由到适当的服务. 为此，应为所需的域名创建通配符 DNS 记录. 例如，如果您的 Knative 基础域是knative.info则需要创建一个 A 记录或 CNAME 记录，其域*.knative.info指向 Ingress 的 IP 地址或主机名.

注意：可以在给定项目上部署功能或无服务器应用程序，但不能两者都部署. 当前实现利用了的serverless.yml文件发信号 FAAS 项目.

Using an existing installation of Knative

Introduced in GitLab 12.0.

注意：添加现有的 Knative 安装时，GitLabless server 的”调用”监视功能将不起作用.

也可以将 GitLab Serverless 与已经安装 Knative 的现有 Kubernetes 集群一起使用.

您必须执行以下操作：

按照步骤添加现有的 Kubernetes 集群 .
确保 GitLab 可以管理 Knative：
- 对于非 GitLab 托管群集，请确保提供的令牌的服务帐户可以管理serving.knative.dev API 组中的资源.
- 对于 GitLab 托管群集，如果您在GitLab 12.1 或更高版本中添加了群集，则 GitLab 将已经具有所需的访问权限，您可以继续进行下一步.
  
  否则，您需要手动授权 GitLab 的服务帐户具有管理serving.knative.dev API 组中资源的能力. 由于每个 GitLab 服务帐户都具有edit集群角色，因此最简单的方法是通过将默认规则添加到默认edit集群角色的聚合 ClusterRole ：首先，将以下 YAML 保存为knative-serving-only-role.yaml ：
```
 apiVersion : rbac.authorization.k8s.io/v1 kind : ClusterRole metadata : name : knative-serving-only-role labels : rbac.authorization.k8s.io/aggregate-to-edit : " true" rules : - apiGroups : - serving.knative.dev resources : - configurations - configurationgenerations - routes - revisions - revisionuids - autoscalers - services verbs : - get - list - create - update - delete - patch - watch
```
  然后运行以下命令：
```
 kubectl apply -f knative-serving-only-role.yaml
```
  如果您希望基于每个服务帐户授予权限，则可以使用特定于服务帐户和名称空间的Role和RoleBinding来执行此操作.
请按照以下步骤将功能或无服务器应用程序部署到群集上.

Supported runtimes

GitLab 的无服务器功能可以使用以下命令运行：

GitLab-managed runtimes.
OpenFaaS runtimes.

如果所需的编程语言无法使用运行时，请考虑部署无服务器应用程序 .

GitLab-managed runtimes

当前，以下 GitLab 管理的运行时可用：

go （概念证明）
nodejs
ruby

如果未指定运行时，则必须提供一个Dockerfile来运行无服务器功能.

OpenFaaS runtimes

在 GitLab 12.5 中引入 .

OpenFaaS 经典运行时可与 GitLab 无服务器一起使用.

OpenFaas 运行时可用于以下语言：

C#
Go
NodeJS
PHP
Python
Ruby

使用以下模式指定运行时： openfaas/classic/<template_name> . 下面的示例示出了如何定义一个函数serverless.yml使用 OpenFaaS 运行时：

hello:
  source: ./hello
  runtime: openfaas/classic/ruby
  description: "Ruby  function  using  OpenFaaS  classic  runtime"

handler is not needed for OpenFaaS functions. The location of the handler is defined by the conventions of the runtime.

有关使用 OpenFaaS 运行时的函数示例，请参见ruby-openfaas-function项目.

Deploying functions

在 GitLab 11.6 中引入.

您可以在功能示例项目中找到并导入此文档中引用的所有文件.

请按照以下步骤将使用 Node.js 运行时的功能部署到您的 Knative 实例（如果您已克隆示例项目，则可以跳过以下步骤）：

创建一个目录来容纳该函数. 在此示例中，我们将在项目的根目录创建一个名为echo的目录.
创建将包含功能代码的文件. 在此示例中，我们的文件名为echo.js ，位于echo目录中. 如果您的项目是：
- 公开，继续下一步.
- 私有的，您将需要使用gitlab-deploy-token作为名称和read_registry范围创建一个 GitLab 部署令牌 .
.gitlab-ci.yml ：这定义了用于部署功能的管道. 它必须包含在存储库的根目录中：
```
include:
  - template: Serverless.gitlab-ci.yml
functions:build:
  extends: .serverless:build:functions
  environment: production
functions:deploy:
  extends: .serverless:deploy:functions
  environment: production
```
这个.gitlab-ci.yml创建的作业会调用一些预定义的命令来构建功能并将其部署到集群中.

Serverless.gitlab-ci.yml is a template that allows customization. You can either import it with include parameter and use extends to customize your jobs, or you can inline the entire template by choosing it from 套用范本 dropdown when editing the .gitlab-ci.yml file through the user interface.

serverless.yml ：此文件包含您的功能的元数据，例如名称，运行时和环境.

它必须包含在存储库的根目录中. 下面是一个示例echo函数，它显示了文件所需的结构.

您可以在功能示例项目中找到该项目的相关文件.

service: functions
description: "GitLab  Serverless  functions  using  Knative"
provider:
  name: triggermesh
  envs:
    FOO: value
  secrets:
    - my-secrets
functions:
  echo-js:
    handler: echo-js
    source: ./echo-js
    runtime: gitlab/runtimes/nodejs
    description: "node.js  runtime  function"
    envs:
      MY_FUNCTION: echo-js
    secrets:
      - my-secrets

上面使用的字段的说明：

`service`

Parameter	Description
`service`	服务该功能的 Knative 服务的名称.
`description`	在的简短描述`service` .

`provider`

Parameter	Description
`name`	指示使用哪个提供程序来执行`serverless.yml`文件. 在这种情况下，使用 TriggerMesh 中间件.
`envs`	包括要在文件中所有函数的函数执行过程中传递的环境变量，其中`FOO`是变量名， `BAR`是变量内容. 您可以将其替换为自己的变量.
`secrets`	包含 Kubernetes 机密的内容作为环境变量，可访问该变量作为文件中所有函数的函数执行的一部分进行传递. 机密应采用 INI 格式.

`functions`

在上面的serverless.yml示例中，函数名称为echo ，随后的行包含函数属性.

Parameter	Description
`handler`	函数的名称.
`source`	具有功能源的目录.
`runtime` (optional)	用于执行功能的运行时. 这可以是运行时别名（请参阅运行时别名），也可以是自定义运行时存储库的完整 URL. 当未指定运行`Dockerfile` ，我们假定`Dockerfile`存在于`source`指定的函数目录中.
`description`	功能的简短描述.
`envs`	仅为特定功能设置环境变量.
`secrets`	将 Kubernetes 机密的内容作为环境变量包含在内，这些变量只能作为特定函数的函数执行的一部分进行传递. 机密应采用 INI 格式.

Deployment

Runtime aliases

可选的runtime参数可以引用以下运行时别名之一（另请参阅受支持的运行时）：

运行时别名	维护者
`gitlab/runtimes/go`	GitLab
`gitlab/runtimes/nodejs`	GitLab
`gitlab/runtimes/ruby`	GitLab
`openfaas/classic/csharp`	OpenFaaS
`openfaas/classic/go`	OpenFaaS
`openfaas/classic/node`	OpenFaaS
`openfaas/classic/php7`	OpenFaaS
`openfaas/classic/python`	OpenFaaS
`openfaas/classic/python3`	OpenFaaS
`openfaas/classic/ruby`	OpenFaaS

经过gitlab-ci.yml模板已添加和serverless.yml文件被创建，推动提交到您的项目将导致 CI 管道被执行，而部署的每个功能的 Knative 服务. 部署阶段完成后，该功能的其他详细信息将显示在” 操作”>”无服务器”下 .

该页面包含可用于项目的所有功能，访问功能的描述以及（如果有）功能的运行时信息. 详细信息来自于项目的每个 Kubernetes 集群中的 Knative 安装. 单击每个功能以获得详细的规模和调用数据.

可以从集群上的 Knative 直接检索函数详细信息：

kubectl -n "$KUBE_NAMESPACE" get services.serving.knative.dev

现在可以使用任何简单的POST调用从任何 HTTP 客户端触发示例函数：

使用 curl（将最后一行的 URL 替换为应用程序的 URL）：

curl \
--header "Content-Type: application/json" \
--request POST \
--data '{"GitLab":"FaaS"}' \
http://functions-echo.functions-1.functions.example.com/

使用基于 Web 的工具（例如 Postman 或 Restlet）

Secrets

要从函数内部访问 Kubernetes 机密，应在无服务器部署的名称空间下创建该机密，并在上述serverless.yml文件中指定这些机密. 您可以通过多种方式创建机密. 以下各节显示了一些示例.

CLI example

kubectl create secret generic my-secrets -n "$KUBE_NAMESPACE" --from-literal MY_SECRET=imverysecure

Part of deployment job

您可以扩展.gitlab-ci.yml以在部署期间使用安全存储在 GitLab 项目下的环境变量来创建秘密.

deploy:function:
  stage: deploy
  environment: production
  extends: .serverless:deploy:functions
  before_script:
    - kubectl create secret generic my-secret
        --from-literal MY_SECRET="$GITLAB_SECRET_VARIABLE"
        --namespace "$KUBE_NAMESPACE"
        --dry-run -o yaml | kubectl apply -f -

Running functions locally

在本地运行功能是在开发过程中快速验证行为的好方法.

在本地运行功能需要：

转到 1.12 或更高版本.
Docker Engine 已安装并正在运行.

使用 Go 软件包管理器安装的gitlabktl ：

GO111MODULE=on go get gitlab.com/gitlab-org/gitlabktl

要在本地运行功能：

导航到您的 GitLab 无服务器项目的根目录.
将功能构建到 Docker 映像中：
```
gitlabktl serverless build
```

在 Docker 中运行您的函数：

docker run -itp 8080:8080 <your_function_name>

调用您的功能：
```
curl http://localhost:8080
```

Deploying Serverless applications

在 GitLab 11.5 中引入.

无服务器应用程序是无服务器功能的替代方法 . 它们在现有运行时不能满足应用程序需求的情况下很有用，例如以一种没有可用运行时的语言编写的应用程序. 请注意，尽管无服务器应用程序应该是无状态的！

注意：您可以参考并导入示例Knative Ruby 应用程序以开始使用.

将以下.gitlab-ci.yml添加到存储库的根目录中（如果您先前已经克隆了上述示例Knative Ruby App，则可以跳过此步骤）：

include:
  - template: Serverless.gitlab-ci.yml
build:
  extends: .serverless:build:image
deploy:
  extends: .serverless:deploy:image

Serverless.gitlab-ci.yml是允许自定义的模板. 您可以使用include参数导入它，并使用extends来自定义作业，或者可以通过在通过用户界面编辑.gitlab-ci.yml文件时从Apply a template下拉列表中选择它来内联整个模板.

部署无服务器应用程序时，不需要serverless.yml文件.

Deploy the application with Knative

一切就绪后，下次运行 CI 管道时，将部署 Knative 应用程序. 导航到CI / CD>管道 ，然后单击最新的管道.

Function details

转到操作>无服务器页面以查看功能的最终 URL.

Invocation metrics

On the same page as above, click on one of the function rows to bring up the function details page.

容器数将为您提供在给定集群上运行无服务器功能实例的容器数.

为了显示 Knative 函数调用，必须安装 Prometheus .

一旦安装了 Prometheus，可能会出现一条消息，指示度量标准数据正在加载或当前不可用. 它会在首次访问该页面时显示，但应在几秒钟后消失. 如果该消息没有消失，则可能是 GitLab 无法连接到集群上运行的 Prometheus 实例.

Configuring logging

在 GitLab 12.5 中引入 .

Prerequisites

由 GitLab 管理的集群.
kubectl已安装并正在运行.

在集群上运行kubectl命令需要首先设置对集群的访问权限. 对于在以下位置创建的集群：

GKE，请参阅GKE 群集访问
其他平台，请参阅安装和设置 kubectl .

Enable request log template

运行以下命令以启用请求日志：

kubectl edit cm -n knative-serving config-observability

将logging.request-log-template从data._example字段复制到层次结构中上一层的数据字段.

Enable request logs

运行以下命令以将 Elasticsearch，Kibana 和 Filebeat 安装到kube-logging命名空间中，并配置所有节点以使用 Filebeat 转发日志：

kubectl apply -f https://gitlab.com/gitlab-org/serverless/configurations/knative/raw/v0.7.0/kube-logging-filebeat.yaml
kubectl label nodes --all beta.kubernetes.io/filebeat-ready="true"

Viewing request logs

要查看请求日志：

Run kubectl proxy.
导航到Kibana UI .

Or:

打开Kibana UI .
单击” 发现” ，然后从左侧的下拉列表中选择filebeat-* .
在搜索框中输入kubernetes.container.name:"queue-proxy" AND message:/httpRequest/ .

Enabling TLS for Knative services

默认情况下，将通过http提供 GitLab 无服务器部署. 为了通过https提供服务，您必须手动获取并安装 TLS 证书.

完成此操作的最简单方法是使用Certbot 手动获取 Let’s Encrypt 证书 . Certbot 是一个免费的开源软件工具，可用于在手动管理的网站上自动使用 Let’s Encrypt 证书来启用 HTTPS.

注意：以下说明与在安装了 Python 3 且不能在其他操作系统或其他版本的 Python 上运行的 Linux 服务器上安装和运行 Certbot 有关.

通过运行certbot-auto wrapper 脚本安装 Certbot. 在服务器的命令行上，运行以下命令：

wget https://dl.eff.org/certbot-auto
sudo mv certbot-auto /usr/local/bin/certbot-auto
sudo chown root /usr/local/bin/certbot-auto
sudo chmod 0755 /usr/local/bin/certbot-auto
/usr/local/bin/certbot-auto --help

要检查certbot-auto脚本的完整性，请运行：

wget -N https://dl.eff.org/certbot-auto.asc
gpg2 --keyserver ipv4.pool.sks-keyservers.net --recv-key A2CFB51FA275A7286234E7B24D17C995CD9775F2
gpg2 --trusted-key 4D17C995CD9775F2 --verify certbot-auto.asc /usr/local/bin/certbot-auto

The output of the last command should look something like:

gpg: Signature made Mon 10 Jun 2019 06:24:40 PM EDT
gpg:                using RSA key A2CFB51FA275A7286234E7B24D17C995CD9775F2
gpg: key 4D17C995CD9775F2 marked as ultimately trusted
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2027-11-22
gpg: Good signature from "Let's Encrypt Client Team <letsencrypt-client@eff.org>" [ultimate]

运行以下命令以使用 Certbot 在授权过程中使用 DNS 质询来请求证书：

/usr/local/bin/certbot-auto certonly --manual --preferred-challenges dns -d '*.<namespace>.example.com'

其中<namespace>是 GitLab 为您的无服务器项目创建的名称空间（由<project_name>-<project_id>-<environment> ），而example.com是用于项目的域. 如果不确定项目的名称空间是什么，请导航至项目的” 操作”>”无服务器”页面，然后检查为功能/应用程序提供的端点.

在上图中，项目的名称空间为node-function-11909507 ，域为knative.info ，因此证书申请行如下所示：

./certbot-auto certonly --manual --preferred-challenges dns -d '*.node-function-11909507.knative.info'

Certbot 工具将引导您完成通过在这些域中创建 TXT 记录来验证您拥有的每个域的步骤. 此过程完成后，输出应如下所示：

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
  /etc/letsencrypt/live/namespace.example.com/fullchain.pem
  Your key file has been saved at:
  /etc/letsencrypt/live/namespace.example/privkey.pem
  Your cert will expire on 2019-09-19\. To obtain a new or tweaked
  version of this certificate in the future, simply run certbot-auto
  again. To non-interactively renew *all* of your certificates, run
  "certbot-auto renew"
-----BEGIN PRIVATE KEY-----
- Your account credentials have been saved in your Certbot
  configuration directory at /etc/letsencrypt. You should make a
  secure backup of this folder now. This configuration directory will
  also contain certificates and private keys obtained by Certbot so
  making regular backups of this folder is ideal.

创建证书和私钥文件. 使用 Certbot 返回的文件的内容，我们将创建两个文件以创建 Kubernetes 机密：

运行以下命令以查看fullchain.pem的内容：

sudo cat /etc/letsencrypt/live/node-function-11909507.knative.info/fullchain.pem

输出应如下所示：

创建一个名称为cert.pem的文件，其中包含整个输出的内容.

创建cert.pem ，运行以下命令以查看privkey.pem的内容：

sudo cat /etc/letsencrypt/live/namespace.example/privkey.pem

输出应如下所示：

使用整个输出的内容创建一个名称为cert.pk的新文件.

创建一个 Kubernetes 机密以保存您的 TLS 证书cert.pem和私钥cert.pk ：

注意：在集群上运行kubectl命令需要首先设置对集群的访问. 对于在 GKE 上创建的集群，请参阅GKE 集群访问 . 对于其他平台，请安装kubectl .
```
kubectl create --namespace istio-system secret tls istio-ingressgateway-certs \
--key cert.pk \
--cert cert.pem
```
其中cert.pem和cert.pk是您的证书和私钥文件. 请注意， istio-ingressgateway-certs秘密名称是必需的.

配置 Knative 以使用为 HTTPS 连接创建的新密码. 运行以下命令以编辑方式打开 Knative 共享gateway ：

kubectl edit gateway knative-ingress-gateway --namespace knative-serving

更新网关以包括以下 tls：部分和配置：

tls:
  mode: SIMPLE
  privateKey: /etc/istio/ingressgateway-certs/tls.key
  serverCertificate: /etc/istio/ingressgateway-certs/tls.crt

Example:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  # ... skipped ...
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - "*"
      port:
        name: http
        number: 80
        protocol: HTTP
    - hosts:
        - "*"
      port:
        name: https
        number: 443
        protocol: HTTPS
      tls:
        mode: SIMPLE
        privateKey: /etc/istio/ingressgateway-certs/tls.key
        serverCertificate: /etc/istio/ingressgateway-certs/tls.crt

After your changes are running on your Knative cluster, you can begin using the HTTPS protocol for secure access your deployed Knative services. In the event a mistake is made during this process and you need to update the cert, you will need to edit the gateway knative-ingress-gateway to switch back to PASSTHROUGH mode. Once corrections are made, edit the file again so the gateway will use the new certificates.

Using an older version of `gitlabktl`

在某些情况下，您想运行旧版本的gitlabktl . 这需要在.gitlab-ci.yml文件中设置较旧版本的gitlabktl映像.

要设置较旧的版本，请将image:添加到functions:deploy块中. 例如：

functions:deploy:
  extends: .serverless:deploy:functions
  environment: production
  image: registry.gitlab.com/gitlab-org/gitlabktl:0.5.0

通过更改注册表 URL 末尾的版本标签（格式为registry.gitlab.com/gitlab-org/gitlabktl:<version>可以使用不同的版本.

有关可用gitlabktl版本的完整清单，请参见gitlabktl项目的容器注册表 .

Serverless

Serverless

Serverless

Overview

Knative

Prerequisites

Installing Knative via GitLab’s Kubernetes integration

Using an existing installation of Knative

Supported runtimes

GitLab-managed runtimes

OpenFaaS runtimes

Deploying functions

service

provider

functions

Deployment

Runtime aliases

Secrets

CLI example

Part of deployment job

Running functions locally

Deploying Serverless applications

Deploy the application with Knative

Function details

Invocation metrics

Configuring logging

Prerequisites

Enable request log template

Enable request logs

Viewing request logs

Enabling TLS for Knative services

Using an older version of gitlabktl

`service`

`provider`

`functions`

Using an older version of `gitlabktl`