# Serverless
> 原文：[https://docs.gitlab.com/ee/user/project/clusters/serverless/](https://docs.gitlab.com/ee/user/project/clusters/serverless/)
* [Overview](#overview)
* [Knative](#knative)
* [Prerequisites](#prerequisites)
* [Installing Knative via GitLab’s Kubernetes integration](#installing-knative-via-gitlabs-kubernetes-integration)
* [Using an existing installation of Knative](#using-an-existing-installation-of-knative)
* [Supported runtimes](#supported-runtimes)
* [GitLab-managed runtimes](#gitlab-managed-runtimes)
* [OpenFaaS runtimes](#openfaas-runtimes)
* [Deploying functions](#deploying-functions)
* [`service`](#service)
* [`provider`](#provider)
* [`functions`](#functions)
* [Deployment](#deployment)
* [Runtime aliases](#runtime-aliases)
* [Secrets](#secrets)
* [CLI example](#cli-example)
* [Part of deployment job](#part-of-deployment-job)
* [Running functions locally](#running-functions-locally)
* [Deploying Serverless applications](#deploying-serverless-applications)
* [Deploy the application with Knative](#deploy-the-application-with-knative)
* [Function details](#function-details)
* [Invocation metrics](#invocation-metrics)
* [Configuring logging](#configuring-logging)
* [Prerequisites](#prerequisites-1)
* [Enable request log template](#enable-request-log-template)
* [Enable request logs](#enable-request-logs)
* [Viewing request logs](#viewing-request-logs)
* [Enabling TLS for Knative services](#enabling-tls-for-knative-services)
* [Using an older version of `gitlabktl`](#using-an-older-version-of-gitlabktl)
# Serverless[](#serverless "Permalink")
在 GitLab 11.5 中引入.
**警告：** Serverless 目前处于[alpha 状态](https://about.gitlab.com/handbook/product/#alpha) .
## Overview[](#overview "Permalink")
无服务器架构为运营商和开发人员提供了在不配置单个服务器的情况下编写高度可扩展的应用程序的能力.
GitLab 支持在 Kubernetes 环境和主要的云 FAAS 环境中部署无服务器应用程序的几种方法.
目前，我们支持：
* [Knative](#knative) ：在 GKE 和 EKS 上使用 Knative 和`gitlabktl`构建 Knative 应用程序.
* [AWS Lambda](aws.html) ：通过无服务器框架和 GitLab CI / CD 创建无服务器应用程序.
## Knative[](#knative "Permalink")
使用[Knative](https://cloud.google.com/knative/)在 Kubernetes 上运行无服务器工作负载.
Knative 扩展了 Kubernetes 以提供一组中间件组件，这些组件对于构建现代的，以源为中心的，基于容器的应用程序很有用. Knative 通过其主要组件带来了一些明显的好处：
* [服务](https://github.com/knative/serving) ：请求驱动的计算，可扩展为零.
* [事件](https://github.com/knative/eventing) ： [事件的](https://github.com/knative/eventing)管理和交付.
有关 Knative 的更多信息，请访问[Knative docs 资源库](https://github.com/knative/docs) .
借助 GitLab Serverless，您可以部署功能即服务（FaaS）和无服务器应用程序.
## Prerequisites[](#prerequisites "Permalink")
要在 GitLab 上运行 Knative，您需要：
1. **现有的 GitLab 项目：**您将需要一个 GitLab 项目来关联所有资源. 最简单的入门方法：
* 如果您打算[部署功能](#deploying-functions) ，请克隆[功能示例项目](https://gitlab.com/knative-examples/functions)以开始使用.
* 如果您打算[部署无服务器应用程序](#deploying-serverless-applications) ，请克隆示例[Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app)以开始使用.
2. **Kubernetes 集群：**部署 Knative 需要启用 RBAC 的 Kubernetes 集群. 最简单的入门方法是使用 GitLab 的[GKE 集成](../add_remove_clusters.html)添加集群. 建议的运行 Knative 的最低建议群集规格为 3 个节点，6 个 vCPU 和 22.50 GB 内存.
3. **GitLab 运行程序：**运行 CI 作业需要运行程序，该作业会将无服务器的应用程序或功能部署到您的集群上. 您可以将 GitLab Runner 安装到现有的 Kubernetes 集群上. 有关更多信息，请参见[安装应用程序](../index.html#installing-applications) .
4. **域名：** Knative 将使用 Istio 提供自己的负载平衡器. 它将为 Knative 服务的所有应用程序提供一个外部 IP 地址或主机名. 系统将提示您输入一个通配符域，将在其中提供您的应用程序. 配置您的 DNS 服务器以使用该域的外部 IP 地址或主机名.
5. **`.gitlab-ci.yml` ：** GitLab 使用[Kaniko](https://github.com/GoogleContainerTools/kaniko)来构建应用程序. 我们还使用[GitLab Knative 工具](https://gitlab.com/gitlab-org/gitlabktl) CLI 来简化向 Knative 部署服务和功能.
6. **`serverless.yml`** （ [仅](#deploying-functions)适用于[功能](#deploying-functions) ）：使用 lessserver 部署功能时， `serverless.yml`文件将包含存储库中托管的所有功能的信息以及所使用的运行时的引用.
7. **`Dockerfile`** （ [仅](#deploying-serverless-applications)适用于[应用程序](#deploying-serverless-applications) ）：Knative 需要`Dockerfile`才能构建您的应用程序. 它应该包含在项目存储库的根目录中，并公开端口`8080` . 如果您打算使用我们的[运行时](https://gitlab.com/gitlab-org/serverless/runtimes)来构建无服务器功能，则不需要`Dockerfile` .
8. **Prometheus** （可选）：安装 Prometheus 可使您监视无服务器功能/应用程序的规模和流量. 有关更多信息，请参见[安装应用程序](../index.html#installing-applications) .
9. **日志记录** （可选）：配置日志记录可让您查看和搜索无服务器功能/应用程序的请求日志. 有关更多信息，请参见[配置日志记录](#configuring-logging) .
## Installing Knative via GitLab’s Kubernetes integration[](#installing-knative-via-gitlabs-kubernetes-integration "Permalink")
**注意：**运行 Knative 的最小建议群集大小是 3 节点，6 vCPU 和 22.50 GB 内存. **必须启用 RBAC.**
1. [Add a Kubernetes cluster](../add_remove_clusters.html).
2. 选择" **应用程序"**选项卡，然后向下滚动到" Knative 应用程序"部分. 输入要用于您的应用程序/功能的域（例如`example.com` ），然后单击**Install** .
[](img/install-knative.png)
3. Knative 安装完成后，您可以等待 IP 地址或主机名显示在**Knative Endpoint**字段中，或[手动检索 Istio Ingress 端点](../../../clusters/applications.html#determining-the-external-endpoint-manually) .
**注意：**在集群上运行`kubectl`命令需要首先设置对集群的访问. 对于在 GKE 上创建的集群，请参见[GKE 集群访问](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl) ，对于其他平台，请[安装 kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) .
4. 入口现在在此地址可用，并将基于请求中的 DNS 名称将传入请求路由到适当的服务. 为此，应为所需的域名创建通配符 DNS 记录. 例如，如果您的 Knative 基础域是`knative.info`则需要创建一个 A 记录或 CNAME 记录，其域`*.knative.info`指向 Ingress 的 IP 地址或主机名.
[](img/dns-entry.png)
**注意：**可以在给定项目上部署[功能](#deploying-functions)或[无服务器应用程序](#deploying-serverless-applications) ，但不能两者都部署. 当前实现利用了的`serverless.yml`文件发信号 FAAS 项目.
## Using an existing installation of Knative[](#using-an-existing-installation-of-knative "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58941) in GitLab 12.0.
**注意：**添加现有的 Knative 安装时，GitLabless server 的"调用"监视功能将不起作用.
也可以将 GitLab Serverless 与已经安装 Knative 的现有 Kubernetes 集群一起使用.
您必须执行以下操作：
1. 按照步骤[添加现有的 Kubernetes 集群](../add_remove_clusters.html#add-existing-cluster) .
2. 确保 GitLab 可以管理 Knative：
* 对于非 GitLab 托管群集，请确保提供的令牌的服务帐户可以管理`serving.knative.dev` API 组中的资源.
* 对于 GitLab 托管群集，如果您在[GitLab 12.1 或更高版本中](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30235)添加了群集，则 GitLab 将已经具有所需的访问权限，您可以继续进行下一步.
否则，您需要手动授权 GitLab 的服务帐户具有管理`serving.knative.dev` API 组中资源的能力. 由于每个 GitLab 服务帐户都具有`edit`集群角色，因此最简单的方法是通过将默认规则添加到默认`edit`集群角色的[聚合 ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles) ：首先，将以下 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`来执行此操作.
3. 请按照以下步骤将[功能](#deploying-functions)或[无服务器应用程序](#deploying-serverless-applications)部署到群集上.
## Supported runtimes[](#supported-runtimes "Permalink")
GitLab 的无服务器功能可以使用以下命令运行：
* [GitLab-managed](#gitlab-managed-runtimes) runtimes.
* [OpenFaaS](#openfaas-runtimes) runtimes.
如果所需的编程语言无法使用运行时，请考虑部署[无服务器应用程序](#deploying-serverless-applications) .
### GitLab-managed runtimes[](#gitlab-managed-runtimes "Permalink")
当前，以下 GitLab 管理的[运行时](https://gitlab.com/gitlab-org/serverless/runtimes)可用：
* `go` （概念证明）
* `nodejs`
* `ruby`
如果未指定运行时，则必须提供一个`Dockerfile`来运行无服务器功能.
### OpenFaaS runtimes[](#openfaas-runtimes "Permalink")
在 GitLab 12.5 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/29253) .
[OpenFaaS 经典运行时](https://github.com/openfaas/templates#templates-in-store)可与 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`](https://gitlab.com/knative-examples/ruby-openfaas-function)项目.
## Deploying functions[](#deploying-functions "Permalink")
在 GitLab 11.6 中引入.
您可以在**[功能示例项目中](https://gitlab.com/knative-examples/functions)**找到并导入此文档中引用的所有文件.
请按照以下步骤将使用 Node.js 运行时的功能部署到您的 Knative 实例（如果您已克隆示例项目，则可以跳过以下步骤）：
1. 创建一个目录来容纳该函数. 在此示例中，我们将在项目的根目录创建一个名为`echo`的目录.
2. 创建将包含功能代码的文件. 在此示例中，我们的文件名为`echo.js` ，位于`echo`目录中. 如果您的项目是：
* 公开，继续下一步.
* 私有的，您将需要使用`gitlab-deploy-token`作为名称和`read_registry`范围[创建一个 GitLab 部署令牌](../../deploy_tokens/index.html#creating-a-deploy-token) .
3. `.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.
4. `serverless.yml` ：此文件包含您的功能的元数据，例如名称，运行时和环境.
它必须包含在存储库的根目录中. 下面是一个示例`echo`函数，它显示了文件所需的结构.
您可以在[功能示例项目中](https://gitlab.com/knative-examples/functions)找到该项目的相关文件.
```
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`[](#service "Permalink")
| Parameter | Description |
| --- | --- |
| `service` | 服务该功能的 Knative 服务的名称. |
| `description` | 在的简短描述`service` . |
### `provider`[](#provider "Permalink")
| Parameter | Description |
| --- | --- |
| `name` | 指示使用哪个提供程序来执行`serverless.yml`文件. 在这种情况下，使用 TriggerMesh 中间件. |
| `envs` | 包括要在文件中**所有**函数的函数执行过程中传递的环境变量，其中`FOO`是变量名， `BAR`是变量内容. 您可以将其替换为自己的变量. |
| `secrets` | 包含 Kubernetes 机密的内容作为环境变量，可访问该变量作为文件中**所有**函数的函数执行的一部分进行传递. 机密应采用 INI 格式. |
### `functions`[](#functions "Permalink")
在上面的`serverless.yml`示例中，函数名称为`echo` ，随后的行包含函数属性.
| Parameter | Description |
| --- | --- |
| `handler` | 函数的名称. |
| `source` | 具有功能源的目录. |
| `runtime` (optional) | 用于执行功能的运行时. 这可以是运行时别名（请参阅[运行时别名](#runtime-aliases) ），也可以是自定义运行时存储库的完整 URL. 当未指定运行`Dockerfile` ，我们假定`Dockerfile`存在于`source`指定的函数目录中. |
| `description` | 功能的简短描述. |
| `envs` | 仅为特定功能设置环境变量. |
| `secrets` | 将 Kubernetes 机密的内容作为环境变量包含在内，这些变量只能作为特定函数的函数执行的一部分进行传递. 机密应采用 INI 格式. |
### Deployment[](#deployment "Permalink")
#### Runtime aliases[](#runtime-aliases "Permalink")
可选的`runtime`参数可以引用以下运行时别名之一（另请参阅[受支持的运行时](#supported-runtimes) ）：
| 运行时别名 | 维护者 |
| --- | --- |
| `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 服务. 部署阶段完成后，该功能的其他详细信息将显示在" **操作">"无服务器"下** .
[](img/serverless-page.png)
该页面包含可用于项目的所有功能，访问功能的描述以及（如果有）功能的运行时信息. 详细信息来自于项目的每个 Kubernetes 集群中的 Knative 安装. 单击每个功能以获得详细的规模和调用数据.
可以从集群上的 Knative 直接检索函数详细信息：
```
kubectl -n "$KUBE_NAMESPACE" get services.serving.knative.dev
```
现在可以使用任何简单的`POST`调用从任何 HTTP 客户端触发示例函数：
1. 使用 curl（将最后一行的 URL 替换为应用程序的 URL）：
```
curl \
--header "Content-Type: application/json" \
--request POST \
--data '{"GitLab":"FaaS"}' \
http://functions-echo.functions-1.functions.example.com/
```
2. 使用基于 Web 的工具（例如 Postman 或 Restlet）
[](img/function-execution.png)
### Secrets[](#secrets "Permalink")
要从函数内部访问 Kubernetes 机密，应在无服务器部署的名称空间下创建该机密，并在上述`serverless.yml`文件中指定这些机密. 您可以通过多种方式创建机密. 以下各节显示了一些示例.
#### CLI example[](#cli-example "Permalink")
```
kubectl create secret generic my-secrets -n "$KUBE_NAMESPACE" --from-literal MY_SECRET=imverysecure
```
#### Part of deployment job[](#part-of-deployment-job "Permalink")
您可以扩展`.gitlab-ci.yml`以在部署期间使用安全存储在 GitLab 项目下的[环境变量](../../../../ci/variables/README.html)来创建秘密.
```
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[](#running-functions-locally "Permalink")
在本地运行功能是在开发过程中快速验证行为的好方法.
在本地运行功能需要：
* 转到 1.12 或更高版本.
* Docker Engine 已安装并正在运行.
* 使用 Go 软件包管理器安装的`gitlabktl` ：
```
GO111MODULE=on go get gitlab.com/gitlab-org/gitlabktl
```
要在本地运行功能：
1. 导航到您的 GitLab 无服务器项目的根目录.
2. 将功能构建到 Docker 映像中：
```
gitlabktl serverless build
```
3. 在 Docker 中运行您的函数：
```
docker run -itp 8080:8080 <your_function_name>
```
4. 调用您的功能：
```
curl http://localhost:8080
```
## Deploying Serverless applications[](#deploying-serverless-applications "Permalink")
在 GitLab 11.5 中引入.
无服务器应用程序是[无服务器功能](#deploying-functions)的替代[方法](#deploying-functions) . 它们在现有运行时不能满足应用程序需求的情况下很有用，例如以一种没有可用运行时的语言编写的应用程序. 请注意，尽管无服务器应用程序应该是无状态的！
**注意：**您可以参考并导入示例[Knative Ruby 应用程序](https://gitlab.com/knative-examples/knative-ruby-app)以开始使用.
将以下`.gitlab-ci.yml`添加到存储库的根目录中（如果您先前已经克隆了上述示例[Knative Ruby App，](https://gitlab.com/knative-examples/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[](#deploy-the-application-with-knative "Permalink")
一切就绪后，下次运行 CI 管道时，将部署 Knative 应用程序. 导航到**CI / CD>管道** ，然后单击最新的管道.
### Function details[](#function-details "Permalink")
转到**操作>无服务器**页面以查看功能的最终 URL.
[](img/function-list_v12_7.png)
### Invocation metrics[](#invocation-metrics "Permalink")
On the same page as above, click on one of the function rows to bring up the function details page.
[](img/function-details-loaded.png)
容器数将为您提供在给定集群上运行无服务器功能实例的容器数.
为了显示 Knative 函数调用， [必须安装 Prometheus](../index.html#installing-applications) .
一旦安装了 Prometheus，可能会出现一条消息，指示度量标准数据*正在加载或当前不可用.* 它会在首次访问该页面时显示，但应在几秒钟后消失. 如果该消息没有消失，则可能是 GitLab 无法连接到集群上运行的 Prometheus 实例.
## Configuring logging[](#configuring-logging "Permalink")
在 GitLab 12.5 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/33330) .
### Prerequisites[](#prerequisites-1 "Permalink")
* 由 GitLab 管理的集群.
* `kubectl`已安装并正在运行.
在集群上运行`kubectl`命令需要首先设置对集群的访问权限. 对于在以下位置创建的集群：
* GKE，请参阅[GKE 群集访问](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl)
* 其他平台，请参阅[安装和设置 kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) .
### Enable request log template[](#enable-request-log-template "Permalink")
运行以下命令以启用请求日志：
```
kubectl edit cm -n knative-serving config-observability
```
将`logging.request-log-template`从`data._example`字段复制到层次结构中上一层的数据字段.
### Enable request logs[](#enable-request-logs "Permalink")
运行以下命令以将 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[](#viewing-request-logs "Permalink")
要查看请求日志：
1. Run `kubectl proxy`.
2. 导航到[Kibana UI](http://localhost:8001/api/v1/namespaces/kube-logging/services/kibana/proxy/app/kibana) .
Or:
1. 打开[Kibana UI](http://localhost:8001/api/v1/namespaces/kube-logging/services/kibana/proxy/app/kibana) .
2. 单击" **发现"** ，然后从左侧的下拉列表中选择`filebeat-*` .
3. 在搜索框中输入`kubernetes.container.name:"queue-proxy" AND message:/httpRequest/` .
## Enabling TLS for Knative services[](#enabling-tls-for-knative-services "Permalink")
默认情况下，将通过`http`提供 GitLab 无服务器部署. 为了通过`https`提供服务，您必须手动获取并安装 TLS 证书.
完成此操作的最简单方法是使用[Certbot 手动获取 Let's Encrypt 证书](https://knative.dev/docs/serving/using-a-tls-cert/#using-certbot-to-manually-obtain-let-s-encrypt-certificates) . Certbot 是一个免费的开源软件工具，可用于在手动管理的网站上自动使用 Let's Encrypt 证书来启用 HTTPS.
**注意：**以下说明与在安装了 Python 3 且不能在其他操作系统或其他版本的 Python 上运行的 Linux 服务器上安装和运行 Certbot 有关.
1. 通过运行[`certbot-auto` wrapper 脚本](https://certbot.eff.org/docs/install.html#certbot-auto)安装 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]
```
2. 运行以下命令以使用 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`是用于项目的域. 如果不确定项目的名称空间是什么，请导航至项目的" **操作">"无服务器"**页面，然后检查为功能/应用程序提供的端点.
[](img/function-endpoint.png)
在上图中，项目的名称空间为`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.
```
3. 创建证书和私钥文件. 使用 Certbot 返回的文件的内容，我们将创建两个文件以创建 Kubernetes 机密：
运行以下命令以查看`fullchain.pem`的内容：
```
sudo cat /etc/letsencrypt/live/node-function-11909507.knative.info/fullchain.pem
```
输出应如下所示：
```
-----BEGIN CERTIFICATE-----
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b4ag==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
K2fcb195768c39e9a94cec2c2e30Qg==
-----END CERTIFICATE-----
```
创建一个名称为`cert.pem`的文件，其中包含整个输出的内容.
创建`cert.pem` ，运行以下命令以查看`privkey.pem`的内容：
```
sudo cat /etc/letsencrypt/live/namespace.example/privkey.pem
```
输出应如下所示：
```
-----BEGIN PRIVATE KEY-----
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
-----BEGIN CERTIFICATE-----
fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
4f294d1eaca42b8692017b4262==
-----END PRIVATE KEY-----
```
使用整个输出的内容创建一个名称为`cert.pk`的新文件.
4. 创建一个 Kubernetes 机密以保存您的 TLS 证书`cert.pem`和私钥`cert.pk` ：
**注意：**在集群上运行`kubectl`命令需要首先设置对集群的访问. 对于在 GKE 上创建的集群，请参阅[GKE 集群访问](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl) . 对于其他平台， [请安装`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/) .
```
kubectl create --namespace istio-system secret tls istio-ingressgateway-certs \
--key cert.pk \
--cert cert.pem
```
其中`cert.pem`和`cert.pk`是您的证书和私钥文件. 请注意， `istio-ingressgateway-certs`秘密名称是必需的.
5. 配置 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`[](#using-an-older-version-of-gitlabktl "Permalink")
在某些情况下，您想运行旧版本的`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`项目的[容器注册表](https://gitlab.com/gitlab-org/gitlabktl/container_registry) .
- GitLab Docs
- Installation
- Requirements
- GitLab cloud native Helm Chart
- Install GitLab with Docker
- Installation from source
- Install GitLab on Microsoft Azure
- Installing GitLab on Google Cloud Platform
- Installing GitLab on Amazon Web Services (AWS)
- Analytics
- Code Review Analytics
- Productivity Analytics
- Value Stream Analytics
- Kubernetes clusters
- Adding and removing Kubernetes clusters
- Adding EKS clusters
- Adding GKE clusters
- Group-level Kubernetes clusters
- Instance-level Kubernetes clusters
- Canary Deployments
- Cluster Environments
- Deploy Boards
- GitLab Managed Apps
- Crossplane configuration
- Cluster management project (alpha)
- Kubernetes Logs
- Runbooks
- Serverless
- Deploying AWS Lambda function using GitLab CI/CD
- Securing your deployed applications
- Groups
- Contribution Analytics
- Custom group-level project templates
- Epics
- Manage epics
- Group Import/Export
- Insights
- Issues Analytics
- Iterations
- Public access
- SAML SSO for GitLab.com groups
- SCIM provisioning using SAML SSO for GitLab.com groups
- Subgroups
- Roadmap
- Projects
- GitLab Secure
- Security Configuration
- Container Scanning
- Dependency Scanning
- Dependency List
- Static Application Security Testing (SAST)
- Secret Detection
- Dynamic Application Security Testing (DAST)
- GitLab Security Dashboard
- Offline environments
- Standalone Vulnerability pages
- Security scanner integration
- Badges
- Bulk editing issues and merge requests at the project level
- Code Owners
- Compliance
- License Compliance
- Compliance Dashboard
- Create a project
- Description templates
- Deploy Keys
- Deploy Tokens
- File finder
- Project integrations
- Integrations
- Atlassian Bamboo CI Service
- Bugzilla Service
- Custom Issue Tracker service
- Discord Notifications service
- Enabling emails on push
- GitHub project integration
- Hangouts Chat service
- Atlassian HipChat
- Irker IRC Gateway
- GitLab Jira integration
- Mattermost Notifications Service
- Mattermost slash commands
- Microsoft Teams service
- Mock CI Service
- Prometheus integration
- Redmine Service
- Slack Notifications Service
- Slack slash commands
- GitLab Slack application
- Webhooks
- YouTrack Service
- Insights
- Issues
- Crosslinking Issues
- Design Management
- Confidential issues
- Due dates
- Issue Boards
- Issue Data and Actions
- Labels
- Managing issues
- Milestones
- Multiple Assignees for Issues
- Related issues
- Service Desk
- Sorting and ordering issue lists
- Issue weight
- Associate a Zoom meeting with an issue
- Merge requests
- Allow collaboration on merge requests across forks
- Merge Request Approvals
- Browser Performance Testing
- How to create a merge request
- Cherry-pick changes
- Code Quality
- Load Performance Testing
- Merge Request dependencies
- Fast-forward merge requests
- Merge when pipeline succeeds
- Merge request conflict resolution
- Reverting changes
- Reviewing and managing merge requests
- Squash and merge
- Merge requests versions
- Draft merge requests
- Members of a project
- Migrating projects to a GitLab instance
- Import your project from Bitbucket Cloud to GitLab
- Import your project from Bitbucket Server to GitLab
- Migrating from ClearCase
- Migrating from CVS
- Import your project from FogBugz to GitLab
- Gemnasium
- Import your project from GitHub to GitLab
- Project importing from GitLab.com to your private GitLab instance
- Import your project from Gitea to GitLab
- Import your Jira project issues to GitLab
- Migrating from Perforce Helix
- Import Phabricator tasks into a GitLab project
- Import multiple repositories by uploading a manifest file
- Import project from repo by URL
- Migrating from SVN to GitLab
- Migrating from TFVC to Git
- Push Options
- Releases
- Repository
- Branches
- Git Attributes
- File Locking
- Git file blame
- Git file history
- Repository mirroring
- Protected branches
- Protected tags
- Push Rules
- Reduce repository size
- Signing commits with GPG
- Syntax Highlighting
- GitLab Web Editor
- Web IDE
- Requirements Management
- Project settings
- Project import/export
- Project access tokens (Alpha)
- Share Projects with other Groups
- Snippets
- Static Site Editor
- Wiki
- Project operations
- Monitor metrics for your CI/CD environment
- Set up alerts for Prometheus metrics
- Embedding metric charts within GitLab-flavored Markdown
- Embedding Grafana charts
- Using the Metrics Dashboard
- Dashboard YAML properties
- Metrics dashboard settings
- Panel types for dashboards
- Using Variables
- Templating variables for metrics dashboards
- Prometheus Metrics library
- Monitoring AWS Resources
- Monitoring HAProxy
- Monitoring Kubernetes
- Monitoring NGINX
- Monitoring NGINX Ingress Controller
- Monitoring NGINX Ingress Controller with VTS metrics
- Alert Management
- Error Tracking
- Tracing
- Incident Management
- GitLab Status Page
- Feature Flags
- GitLab CI/CD
- GitLab CI/CD pipeline configuration reference
- GitLab CI/CD include examples
- Introduction to CI/CD with GitLab
- Getting started with GitLab CI/CD
- How to enable or disable GitLab CI/CD
- Using SSH keys with GitLab CI/CD
- Migrating from CircleCI
- Migrating from Jenkins
- Auto DevOps
- Getting started with Auto DevOps
- Requirements for Auto DevOps
- Customizing Auto DevOps
- Stages of Auto DevOps
- Upgrading PostgreSQL for Auto DevOps
- Cache dependencies in GitLab CI/CD
- GitLab ChatOps
- Cloud deployment
- Docker integration
- Building Docker images with GitLab CI/CD
- Using Docker images
- Building images with kaniko and GitLab CI/CD
- GitLab CI/CD environment variables
- Predefined environment variables reference
- Where variables can be used
- Deprecated GitLab CI/CD variables
- Environments and deployments
- Protected Environments
- GitLab CI/CD Examples
- Test a Clojure application with GitLab CI/CD
- Using Dpl as deployment tool
- Testing a Phoenix application with GitLab CI/CD
- End-to-end testing with GitLab CI/CD and WebdriverIO
- DevOps and Game Dev with GitLab CI/CD
- Deploy a Spring Boot application to Cloud Foundry with GitLab CI/CD
- How to deploy Maven projects to Artifactory with GitLab CI/CD
- Testing PHP projects
- Running Composer and NPM scripts with deployment via SCP in GitLab CI/CD
- Test and deploy Laravel applications with GitLab CI/CD and Envoy
- Test and deploy a Python application with GitLab CI/CD
- Test and deploy a Ruby application with GitLab CI/CD
- Test and deploy a Scala application to Heroku
- GitLab CI/CD for external repositories
- Using GitLab CI/CD with a Bitbucket Cloud repository
- Using GitLab CI/CD with a GitHub repository
- GitLab Pages
- GitLab Pages
- GitLab Pages domain names, URLs, and baseurls
- Create a GitLab Pages website from scratch
- Custom domains and SSL/TLS Certificates
- GitLab Pages integration with Let's Encrypt
- GitLab Pages Access Control
- Exploring GitLab Pages
- Incremental Rollouts with GitLab CI/CD
- Interactive Web Terminals
- Optimizing GitLab for large repositories
- Metrics Reports
- CI/CD pipelines
- Pipeline Architecture
- Directed Acyclic Graph
- Multi-project pipelines
- Parent-child pipelines
- Pipelines for Merge Requests
- Pipelines for Merged Results
- Merge Trains
- Job artifacts
- Pipeline schedules
- Pipeline settings
- Triggering pipelines through the API
- Review Apps
- Configuring GitLab Runners
- GitLab CI services examples
- Using MySQL
- Using PostgreSQL
- Using Redis
- Troubleshooting CI/CD
- GitLab Package Registry
- GitLab Container Registry
- Dependency Proxy
- GitLab Composer Repository
- GitLab Conan Repository
- GitLab Maven Repository
- GitLab NPM Registry
- GitLab NuGet Repository
- GitLab PyPi Repository
- API Docs
- API resources
- .gitignore API
- GitLab CI YMLs API
- Group and project access requests API
- Appearance API
- Applications API
- Audit Events API
- Avatar API
- Award Emoji API
- Project badges API
- Group badges API
- Branches API
- Broadcast Messages API
- Project clusters API
- Group clusters API
- Instance clusters API
- Commits API
- Container Registry API
- Custom Attributes API
- Dashboard annotations API
- Dependencies API
- Deploy Keys API
- Deployments API
- Discussions API
- Dockerfiles API
- Environments API
- Epics API
- Events
- Feature Flags API
- Feature flag user lists API
- Freeze Periods API
- Geo Nodes API
- Group Activity Analytics API
- Groups API
- Import API
- Issue Boards API
- Group Issue Boards API
- Issues API
- Epic Issues API
- Issues Statistics API
- Jobs API
- Keys API
- Labels API
- Group Labels API
- License
- Licenses API
- Issue links API
- Epic Links API
- Managed Licenses API
- Markdown API
- Group and project members API
- Merge request approvals API
- Merge requests API
- Project milestones API
- Group milestones API
- Namespaces API
- Notes API
- Notification settings API
- Packages API
- Pages domains API
- Pipeline schedules API
- Pipeline triggers API
- Pipelines API
- Project Aliases API
- Project import/export API
- Project repository storage moves API
- Project statistics API
- Project templates API
- Projects API
- Protected branches API
- Protected tags API
- Releases API
- Release links API
- Repositories API
- Repository files API
- Repository submodules API
- Resource label events API
- Resource milestone events API
- Resource weight events API
- Runners API
- SCIM API
- Search API
- Services API
- Application settings API
- Sidekiq Metrics API
- Snippets API
- Project snippets
- Application statistics API
- Suggest Changes API
- System hooks API
- Tags API
- Todos API
- Users API
- Project-level Variables API
- Group-level Variables API
- Version API
- Vulnerabilities API
- Vulnerability Findings API
- Wikis API
- GraphQL API
- Getting started with GitLab GraphQL API
- GraphQL API Resources
- API V3 to API V4
- Validate the .gitlab-ci.yml (API)
- User Docs
- Abuse reports
- User account
- Active sessions
- Deleting a User account
- Permissions
- Personal access tokens
- Profile preferences
- Threads
- GitLab and SSH keys
- GitLab integrations
- Git
- GitLab.com settings
- Infrastructure as code with Terraform and GitLab
- GitLab keyboard shortcuts
- GitLab Markdown
- AsciiDoc
- GitLab Notification Emails
- GitLab Quick Actions
- Autocomplete characters
- Reserved project and group names
- Search through GitLab
- Advanced Global Search
- Advanced Syntax Search
- Time Tracking
- GitLab To-Do List
- Administrator Docs
- Reference architectures
- Reference architecture: up to 1,000 users
- Reference architecture: up to 2,000 users
- Reference architecture: up to 3,000 users
- Reference architecture: up to 5,000 users
- Reference architecture: up to 10,000 users
- Reference architecture: up to 25,000 users
- Reference architecture: up to 50,000 users
- Troubleshooting a reference architecture set up
- Working with the bundled Consul service
- Configuring PostgreSQL for scaling
- Configuring GitLab application (Rails)
- Load Balancer for multi-node GitLab
- Configuring a Monitoring node for Scaling and High Availability
- NFS
- Working with the bundled PgBouncer service
- Configuring Redis for scaling
- Configuring Sidekiq
- Admin Area settings
- Continuous Integration and Deployment Admin settings
- Custom instance-level project templates
- Diff limits administration
- Enable and disable GitLab features deployed behind feature flags
- Geo nodes Admin Area
- GitLab Pages administration
- Health Check
- Job logs
- Labels administration
- Log system
- PlantUML & GitLab
- Repository checks
- Repository storage paths
- Repository storage types
- Account and limit settings
- Service templates
- System hooks
- Changing your time zone
- Uploads administration
- Abuse reports
- Activating and deactivating users
- Audit Events
- Blocking and unblocking users
- Broadcast Messages
- Elasticsearch integration
- Gitaly
- Gitaly Cluster
- Gitaly reference
- Monitoring GitLab
- Monitoring GitLab with Prometheus
- Performance Bar
- Usage statistics
- Object Storage
- Performing Operations in GitLab
- Cleaning up stale Redis sessions
- Fast lookup of authorized SSH keys in the database
- Filesystem Performance Benchmarking
- Moving repositories managed by GitLab
- Run multiple Sidekiq processes
- Sidekiq MemoryKiller
- Switching to Puma
- Understanding Unicorn and unicorn-worker-killer
- User lookup via OpenSSH's AuthorizedPrincipalsCommand
- GitLab Package Registry administration
- GitLab Container Registry administration
- Replication (Geo)
- Geo database replication
- Geo with external PostgreSQL instances
- Geo configuration
- Using a Geo Server
- Updating the Geo nodes
- Geo with Object storage
- Docker Registry for a secondary node
- Geo for multiple nodes
- Geo security review (Q&A)
- Location-aware Git remote URL with AWS Route53
- Tuning Geo
- Removing secondary Geo nodes
- Geo data types support
- Geo Frequently Asked Questions
- Geo Troubleshooting
- Geo validation tests
- Disaster Recovery (Geo)
- Disaster recovery for planned failover
- Bring a demoted primary node back online
- Automatic background verification
- Rake tasks
- Back up and restore GitLab
- Clean up
- Namespaces
- Maintenance Rake tasks
- Geo Rake Tasks
- GitHub import
- Import bare repositories
- Integrity check Rake task
- LDAP Rake tasks
- Listing repository directories
- Praefect Rake tasks
- Project import/export administration
- Repository storage Rake tasks
- Generate sample Prometheus data
- Uploads migrate Rake tasks
- Uploads sanitize Rake tasks
- User management
- Webhooks administration
- X.509 signatures
- Server hooks
- Static objects external storage
- Updating GitLab
- GitLab release and maintenance policy
- Security
- Password Storage
- Custom password length limits
- Restrict allowed SSH key technologies and minimum length
- Rate limits
- Webhooks and insecure internal web services
- Information exclusivity
- How to reset your root password
- How to unlock a locked user from the command line
- User File Uploads
- How we manage the TLS protocol CRIME vulnerability
- User email confirmation at sign-up
- Security of running jobs
- Proxying assets
- CI/CD Environment Variables
- Contributor and Development Docs
- Contribute to GitLab
- Community members & roles
- Implement design & UI elements
- Issues workflow
- Merge requests workflow
- Code Review Guidelines
- Style guides
- GitLab Architecture Overview
- CI/CD development documentation
- Database guides
- Database Review Guidelines
- Database Review Guidelines
- Migration Style Guide
- What requires downtime?
- Understanding EXPLAIN plans
- Rake tasks for developers
- Mass inserting Rails models
- GitLab Documentation guidelines
- Documentation Style Guide
- Documentation structure and template
- Documentation process
- Documentation site architecture
- Global navigation
- GitLab Docs monthly release process
- Telemetry Guide
- Usage Ping Guide
- Snowplow Guide
- Experiment Guide
- Feature flags in development of GitLab
- Feature flags process
- Developing with feature flags
- Feature flag controls
- Document features deployed behind feature flags
- Frontend Development Guidelines
- Accessibility & Readability
- Ajax
- Architecture
- Axios
- Design Patterns
- Frontend Development Process
- DropLab
- Emojis
- Filter
- Frontend FAQ
- GraphQL
- Icons and SVG Illustrations
- InputSetter
- Performance
- Principles
- Security
- Tooling
- Vuex
- Vue
- Geo (development)
- Geo self-service framework (alpha)
- Gitaly developers guide
- GitLab development style guides
- API style guide
- Go standards and style guidelines
- GraphQL API style guide
- Guidelines for shell commands in the GitLab codebase
- HTML style guide
- JavaScript style guide
- Migration Style Guide
- Newlines style guide
- Python Development Guidelines
- SCSS style guide
- Shell scripting standards and style guidelines
- Sidekiq debugging
- Sidekiq Style Guide
- SQL Query Guidelines
- Vue.js style guide
- Instrumenting Ruby code
- Testing standards and style guidelines
- Flaky tests
- Frontend testing standards and style guidelines
- GitLab tests in the Continuous Integration (CI) context
- Review Apps
- Smoke Tests
- Testing best practices
- Testing levels
- Testing Rails migrations at GitLab
- Testing Rake tasks
- End-to-end Testing
- Beginner's guide to writing end-to-end tests
- End-to-end testing Best Practices
- Dynamic Element Validation
- Flows in GitLab QA
- Page objects in GitLab QA
- Resource class in GitLab QA
- Style guide for writing end-to-end tests
- Testing with feature flags
- Translate GitLab to your language
- Internationalization for GitLab
- Translating GitLab
- Proofread Translations
- Merging translations from CrowdIn
- Value Stream Analytics development guide
- GitLab subscription
- Activate GitLab EE with a license