Serverless

Knative
Installing Knative via GitLab’s Kubernetes integration
Supported runtimes
- OpenFaaS runtimes
Enabling TLS for Knative services

Serverless

在 GitLab 11.5 中引入.

警告： Serverless 目前处于 .

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

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

目前，我们支持：

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

Knative

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

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

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

有关 Knative 的更多信息，请访问 .

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

Prerequisites

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

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

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

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

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

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

Using an existing installation of Knative

in GitLab 12.0.

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

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

您必须执行以下操作：

按照步骤添加现有的 Kubernetes 集群 .
确保 GitLab 可以管理 Knative：
- 对于非 GitLab 托管群集，请确保提供的令牌的服务帐户可以管理serving.knative.dev API 组中的资源.
- 对于 GitLab 托管群集，如果您在添加了群集，则 GitLab 将已经具有所需的访问权限，您可以继续进行下一步.
  
  否则，您需要手动授权 GitLab 的服务帐户具有管理serving.knative.dev API 组中资源的能力. 由于每个 GitLab 服务帐户都具有edit集群角色，因此最简单的方法是通过将默认规则添加到默认edit集群角色的聚合 ClusterRole ：首先，将以下 YAML 保存为knative-serving-only-role.yaml ：
  
  然后运行以下命令：
```
 kubectl apply -f knative-serving-only-role.yaml
```
  如果您希望基于每个服务帐户授予权限，则可以使用特定于服务帐户和名称空间的Role和RoleBinding来执行此操作.
请按照以下步骤将或无服务器应用程序部署到群集上.

Supported runtimes

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

GitLab-managed runtimes.
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 运行时的函数示例，请参见项目.

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

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

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

`provider`

`functions`

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

Runtime aliases

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

经过模板已添加和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 映像中：

在 Docker 中运行您的函数：

docker run -itp 8080:8080 <your_function_name>

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

Deploying Serverless applications

在 GitLab 11.5 中引入.

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

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

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

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.

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

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

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

Configuring logging

在 GitLab 12.5 中引入 .

Prerequisites

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

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

GKE，请参阅GKE 群集访问
其他平台，请参阅 .

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.
导航到 .

Or:

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

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

完成此操作的最简单方法是使用 . 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 工具将引导您完成通过在这些域中创建 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 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

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块中. 例如：

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

Serverless

Serverless

Serverless

Knative

Prerequisites

Using an existing installation of Knative

Supported runtimes

OpenFaaS runtimes

service

provider

functions

Runtime aliases

Secrets

CLI example

Part of deployment job

Running functions locally

Deploying Serverless applications

Deploy the application with Knative

Function details

Configuring logging

Prerequisites

Enable request log template

Enable request logs

Viewing request logs

Using an older version of gitlabktl

`service`

`provider`

`functions`

Using an older version of `gitlabktl`