提交 a51e48d5 编写于 作者: Lab机器人's avatar Lab机器人

beta help docs

上级 60cd8b13
无法预览此类型文件
_book/
node_modules/
_book.zip
......@@ -41,6 +41,7 @@
* [WebIDE](docs/用户/项目/WebIDE.md)
* [项目设置](docs/用户/项目/项目设置.md)
* [与群组共享项目](docs/用户/项目/项目成员/与群组共享项目.md)
* [wiki](docs/用户/项目/wiki.md)
* [Issues](docs/用户/项目/issues.md)
* [机密Issue](docs/用户/项目/issues/机密Issue.md)
* [关联Issue](docs/用户/项目/issues/关联Issue.md)
......@@ -52,4 +53,24 @@
* [里程碑](docs/用户/项目/里程碑.md)
* [服务台](docs/用户/项目/服务台.md)
* [Issue排序](docs/用户/项目/issues/Issue排序.md)
* [用户](docs/用户.md)
* [举报用户](docs/用户/举报用户.md)
* [用户账号](docs/用户/用户账号.md)
* [登录日志](docs/用户/用户账号/登录日志.md)
* [用户权限](docs/用户/用户权限.md)
* [个人访问令牌](docs/用户/用户资料/个人访问令牌.md)
* [个人偏好](docs/用户/用户资料/个人偏好.md)
* [探讨](docs/用户/讨论.md)
* [SSH密钥](docs/SSH.md)
* [快捷键](docs/用户/快捷键.md)
* [Markdown](docs/用户/Markdown.md)
* [电子邮件通知](docs/用户/用户账号/电子邮件通知.md)
* [快速操作](docs/用户/项目/快速操作.md)
* [自动填充](docs/用户/项目/自动填充.md)
* [预留命名空间](docs/用户/预留命名空间.md)
* [搜索](docs/用户/搜索.md)
* [高级全局搜索](docs/用户/高级全局搜索.md)
* [高级语法搜索](docs/用户/高级语法搜索.md)
* [时间跟踪](docs/用户/项目/时间跟踪.md)
* [待办事项](docs/用户/待办事项.md)
# Snippets
> 原文:[https://docs.gitlab.com/ee/user/snippets.html](https://docs.gitlab.com/ee/user/snippets.html)
* [Personal snippets](#personal-snippets)
* [Project snippets](#project-snippets)
* [Create a snippet](#create-a-snippet)
* [Versioned Snippets](#versioned-snippets)
* [File names](#file-names)
* [Cloning snippets](#cloning-snippets)
* [Limitations](#limitations)
* [Discover snippets](#discover-snippets)
* [Snippet comments](#snippet-comments)
* [Downloading snippets](#downloading-snippets)
* [Embedded snippets](#embedded-snippets)
# Snippets[](#snippets "Permalink")
借助 GitLab 代码片段,您可以存储和与其他用户共享代码和文本.
[![GitLab Snippet](img/677d8f883392679f3fba97024a259665.png)](img/gitlab_snippet_v13_0.png)
可以使用[摘要 API](../api/snippets.html)来维护[摘要](../api/snippets.html) .
片段类型有两种:
* 个人摘要.
* 项目摘要.
## Personal snippets[](#personal-snippets "Permalink")
个人代码段与任何项目均无关,可以完全独立地创建. 可以设置 3 种可见性级别,公共,内部和私有. 有关更多信息,请参见[公共访问](../public_access/public_access.html) .
## Project snippets[](#project-snippets "Permalink")
项目摘要始终与特定项目相关. 有关更多信息,请参见[项目功能](project/index.html#project-features) .
## Create a snippet[](#create-a-snippet "Permalink")
要创建个人代码段,请点击加号图标( ),然后从下拉菜单中选择" **新建代码段** ":
[![New personal snippet from non-project pages](img/169af1eb67d287048e2bd4de1d3a178a.png)](img/new_personal_snippet_v12_10.png)
如果您在项目页面上,但要创建一个新的个人代码段,请点击加号图标( ),然后从下拉菜单的下部选择**新代码段** (在 GitLab.com 上为**GitLab** ;在自托管实例上为**您的**实例):
[![New personal snippet from project pages](img/ee04e8247fff074d8b122d6b5ec848f4.png)](img/new_personal_snippet_from_project_v12_10.png)
要创建项目摘要,请导航到您的项目页面,然后点击加号图标( ),然后从下拉菜单的上方选择**新建代码段****此项目** ).
[![New personal snippet from project pages](img/ea0e34b1e4e7a7a6379bc52995143bf9.png)](img/new_project_snippet_from_project_v12_10.png)
从那里添加**Title****Description**和带有适当扩展名的**文件**名(例如`example.rb``index.html` ).
**警告:**确保添加文件名以突出显示代码并避免此[粘贴错误](https://gitlab.com/gitlab-org/gitlab/-/issues/22870) .
## Versioned Snippets[](#versioned-snippets "Permalink")
在 GitLab 13.0 中[引入](https://gitlab.com/groups/gitlab-org/-/epics/239) .
从 13.0 开始,片段(个人片段和项目片段)默认都启用了版本控制.
这意味着在创建代码段时,所有代码段都将获得自己的基础存储库,并使用`master`分支进行初始化. 每当保存对代码段的更改时,都会记录对 master 分支的新提交. 提交消息是自动生成的. 该代码段的存储库默认情况下只有一个分支(母版),不支持将其删除或创建其他分支.
现有代码段将在 13.0 中自动迁移. 它们的当前内容将被保存为对代码段存储库的初始提交.
### File names[](#file-names "Permalink")
代码段支持基于为其提供的文件名和扩展名突出显示语法. 尽管可以在不指定文件名和扩展名的情况下提交代码段,但它需要一个有效的名称,以便可以将内容作为文件创建在代码段的存储库中.
如果用户未将文件名和扩展名归于代码段,则 GitLab 会自动以`snippetfile<x>.txt`格式添加文件名,其中`<x>`代表添加到文件的数字,从 1 开始.添加了更多没有属性文件名的代码段.
从早期版本的 GitLab 升级到 13.0 时,不支持文件名的现有代码片段将重命名为兼容格式. 例如,如果代码段的文件名是`http://a-weird-filename.me` ,它将被更改为`http-a-weird-filename-me` ,以包含在代码段的存储库中. 由于代码段是通过 ID 存储的,因此更改其文件名不会破坏该代码段的直接链接或嵌入式链接.
### Cloning snippets[](#cloning-snippets "Permalink")
可以使用 SSH 或 HTTPS 将片段克隆为常规的 Git 存储库. 单击摘要内容上方的" **复制"**按钮以复制您选择的 URL.
[![Clone Snippet](img/ed5a96971ab453e6d33b3ad9079bd47c.png)](img/snippet_clone_button_v13_0.png)
这使您可以获取代码段存储库的本地副本,并根据需要进行更改. 您可以提交这些更改并将其推送到远程 master 分支.
### Limitations[](#limitations "Permalink")
* 不支持二进制文件.
* 不支持创建或删除分支. 只有默认的*主人* . 使用分支.
* 代码段存储库中不支持 Git 标签.
* 片段的存储库仅限于一个文件. 尝试推送多个文件将导致错误.
* 修订在 GitLab UI 上对用户*尚不*可见,但计划在以后的迭代中添加. 有关更新,请参见[修订标签问题](https://gitlab.com/gitlab-org/gitlab/-/issues/39271) .
* 默认情况下, [摘要](../administration/snippets/index.html#snippets-content-size-limit)[最大大小为](../administration/snippets/index.html#snippets-content-size-limit) 50 MB.
## Discover snippets[](#discover-snippets "Permalink")
在 GitLab 中发现片段的主要方法有两种.
要浏览对您可见的所有代码片段,您可以通过顶部导航转到 GitLab 实例的代码片段仪表板. 对于 GitLab.com,您可以在[这里](https://gitlab.com/dashboard/snippets)找到它. 这会将您导航到一个概述,该概述显示您创建的摘要,并允许您浏览所有摘要.
如果要发现属于特定项目的摘录,则可以通过项目页面上的左侧导航导航到摘录页面. 项目片段被启用,默认情况下可用,但他们可以通过导航到项目的**设置** ,扩大**知名度,项目功能,权限**和向下滚动到**片段**被禁用. 从那里,您可以切换以禁用它们,或从下拉菜单中选择其他可见性级别.
## Snippet comments[](#snippet-comments "Permalink")
在 GitLab 9.2 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/12910) .
使用 GitLab 代码片段,您可以参与有关该代码段的对话,从而促进用户之间的协作.
## Downloading snippets[](#downloading-snippets "Permalink")
您可以下载代码段的原始内容.
默认情况下,将下载带有 Linux 样式的行尾( `LF` )的代码段. 如果要保留原始的行尾,则需要添加参数`line_ending=raw` (例如, `https://gitlab.com/snippets/SNIPPET_ID/raw?line_ending=raw` : `line_ending=raw` ). 如果使用 GitLab Web 界面创建了代码段,则原始行结尾类似于 Windows( `CRLF` ).
## Embedded snippets[](#embedded-snippets "Permalink")
在 GitLab 10.8 中引入.
公开片段不仅可以共享,还可以嵌入任何网站中. 这样,您可以在多个地方重用 GitLab 代码段,并且对源代码的任何更改都会自动反映在嵌入式代码段中.
To embed a snippet, first make sure that:
* 该项目是公开的(如果是项目摘要)
* 摘要是公开的
* 在" **项目">"设置">"权限"中** ,将片段权限设置为" **具有访问**权限的**所有人"**
满足以上条件后,"嵌入"部分将出现在您的代码片段中,您只需单击"复制"按钮即可. 这将复制一个单行脚本,您可以将其添加到任何网站或博客文章中.
示例代码如下所示:
```
<script src="https://gitlab.com/namespace/project/snippets/SNIPPET_ID.js"></script>
```
嵌入式代码段的外观如下:
嵌入的代码片段带有一个标题,该标题显示文件名(如果已定义),代码片段大小,到 GitLab 的链接以及实际的代码片段内容. 标头中的操作使用户可以查看原始格式的代码段并下载.
\ No newline at end of file
# Static Site Editor
> 原文:[https://docs.gitlab.com/ee/user/project/static_site_editor/](https://docs.gitlab.com/ee/user/project/static_site_editor/)
* [Use cases](#use-cases)
* [Requirements](#requirements)
* [How it works](#how-it-works)
* [Getting started](#getting-started)
* [Set up your project](#set-up-your-project)
* [Use the Static Site Editor to edit your content](#use-the-static-site-editor-to-edit-your-content)
* [Limitations](#limitations)
# Static Site Editor[](#static-site-editor "Permalink")
版本历史
* 在 GitLab 12.10 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28758) .
* 在 GitLab 13.0 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/214559)了所见即所得的编辑器.
* 支持通过 GitLab 13.1 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/216640)的 WYSIWYG 编辑器添加图像.
* Markdown 前端问题隐藏在 GitLab 13.1 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/216834)的 WYSIWYG 编辑器中.
* 支持 GitLab 13.2 中[引入的](https://gitlab.com/gitlab-org/gitlab/-/issues/223171) `*.md.erb`文件.
**危险:**在 GitLab 13.0 中,我们对静态站点编辑器的 URL 结构进行了[重大更改](https://gitlab.com/gitlab-org/gitlab/-/issues/213282) . 请按照此[代码段中](https://gitlab.com/gitlab-org/project-templates/static-site-editor-middleman/snippets/1976539)的说明使用最新更改来更新您的项目.
静态站点编辑器使用户可以在静态网站上编辑内容,而无需事先了解基础模板语言,站点体系结构或 Git 命令. 您的项目的贡献者可以快速编辑 Markdown 页面,并将更改提交审核.
## Use cases[](#use-cases "Permalink")
静态站点编辑器允许协作者无缝地将更改提交到静态站点文件. 例如:
* 非技术合作者可以直接从浏览器中轻松编辑页面; 他们不需要知道 Git 和您的项目的详细信息就能做出贡献.
* 最近雇用的团队成员可以快速编辑内容.
* 临时协作者可以从一个项目跳到另一个项目并快速编辑页面,而不必克隆或派生需要提交更改的每个项目.
## Requirements[](#requirements "Permalink")
* 为了使用静态站点编辑器功能,您的项目需要使用[静态站点编辑器 Middleman 模板](https://gitlab.com/gitlab-org/project-templates/static-site-editor-middleman)进行预配置.
* 该编辑器需要登录到 GitLab,并且必须是该项目的成员(具有 Developer 或更高权限级别).
## How it works[](#how-it-works "Permalink")
静态网站编辑器尚处于开发的早期阶段,目前仅适用于 Middleman 网站. 您必须使用特定的站点模板才能开始使用它. 项目模板配置为使用[GitLab Pages](../pages/index.html)部署[Middleman](https://middlemanapp.com/)静态网站.
网站启动并运行后,您将在其页面的左下角看到一个" **编辑此页面"**按钮:
[![Edit this page button](img/865915f0e39a0035ffc91de736f5a047.png)](img/edit_this_page_button_v12_10.png)
单击它后,GitLab 将打开一个编辑器窗口,从中可以直接编辑内容. 准备就绪后,只需单击一下按钮即可提交更改:
[![Static Site Editor](img/a7a0c433c6f01281a584ba08db57d159.png)](img/wysiwyg_editor_v13_0.png)
当编辑者在后台提交更改时,GitLab 会自动创建一个新分支,提交更改并打开合并请求. 编辑者将直接进入合并请求,然后可以将其分配给同事进行审查.
## Getting started[](#getting-started "Permalink")
首先,设置项目. 完成后,您可以使用静态站点编辑器轻松地编辑您的内容.
### Set up your project[](#set-up-your-project "Permalink")
1. 首先,从" [静态站点编辑器-中间人"](https://gitlab.com/gitlab-org/project-templates/static-site-editor-middleman)模板创建一个新项目. 您可以将其[派生](../repository/forking_workflow.html#creating-a-fork)[从模板创建一个新项目](../../../gitlab-basics/create-project.html#built-in-templates) .
2. 编辑`data/config.yml`文件,添加项目的路径.
3. 编辑文件将触发 CI / CD 管道,以使用 GitLab Pages 部署项目.
4. 管道完成后,从项目的左侧菜单转到**"设置">"页面"**以找到新网站的 URL.
5. 访问您的网站并查看屏幕的左下角,以查看新的" **编辑此页面"**按钮.
满足[要求的](#requirements)任何人都可以编辑页面内容,而无需事先了解 Git 或您网站的代码库.
**注意:**从 GitLab 13.1 开始,Markdown 文件的 YAML 前端问题被隐藏在 WYSIWYG 编辑器中,以避免意外更改. 要对其进行编辑,请使用 Markdown 编辑模式,常规的 GitLab 文件编辑器或 Web IDE.
### Use the Static Site Editor to edit your content[](#use-the-static-site-editor-to-edit-your-content "Permalink")
例如,假设您是一家大型公司的新近聘用的技术作家,并且该公司的产品已添加了新功能.
1. 您被分配了更新文档的任务.
2. 您访问页面并看到需要编辑的内容.
3. 单击生产站点上的" **编辑此页面"**按钮.
4. 该文件在"静态站点编辑器"中以" **所见即所得"**模式打开. 如果您想编辑原始 Markdown,则可以在右下角切换**Markdown**模式.
5. 您在此处编辑文件,然后单击" **提交更改"** .
6. 将自动创建一个新的合并请求,然后将其分配给您的同事进行审核.
## Limitations[](#limitations "Permalink")
* 静态站点编辑器仍然不能快速添加到现有的 Middleman 站点. 跟随此[史诗](https://gitlab.com/groups/gitlab-org/-/epics/2784)进行更新.
\ No newline at end of file
# Wiki
> 原文:[https://docs.gitlab.com/ee/user/project/wiki/](https://docs.gitlab.com/ee/user/project/wiki/)
* [First time creating the Home page](#first-time-creating-the-home-page)
* [Creating a new wiki page](#creating-a-new-wiki-page)
* [Attachment storage](#attachment-storage)
* [Special characters in page titles](#special-characters-in-page-titles)
* [Length restrictions for file and directory names](#length-restrictions-for-file-and-directory-names)
* [Editing a wiki page](#editing-a-wiki-page)
* [Adding a table of contents](#adding-a-table-of-contents)
* [Deleting a wiki page](#deleting-a-wiki-page)
* [Moving a wiki page](#moving-a-wiki-page)
* [Viewing a list of all created wiki pages](#viewing-a-list-of-all-created-wiki-pages)
* [Viewing the history of a wiki page](#viewing-the-history-of-a-wiki-page)
* [Viewing the changes between page versions](#viewing-the-changes-between-page-versions)
* [Wiki activity records](#wiki-activity-records)
* [Limitations](#limitations)
* [Enable or disable Wiki Events](#enable-or-disable-wiki-events-core-only)
* [Adding and editing wiki pages locally](#adding-and-editing-wiki-pages-locally)
* [Customizing sidebar](#customizing-sidebar)
# Wiki[](#wiki "Permalink")
每个 GitLab 项目都内置了一个称为 Wiki 的独立文档系统. 默认情况下,所有新项目都启用此功能,您可以在项目的**Wiki**下找到它.
如果您不想将文档保留在存储库中,但确实希望将其保留在代码所在的项目中,则 Wiki 非常方便.
您可以在 Web 界面中或[使用 Git 在本地](#adding-and-editing-wiki-pages-locally)创建 Wiki 页面,因为每个 Wiki 都是单独的 Git 存储库.
## First time creating the Home page[](#first-time-creating-the-home-page "Permalink")
首次访问 Wiki 时,系统将指示您创建主页. 必须创建主页,因为它是查看 Wiki 时的登录页面. 您只需要填写**内容**部分,然后单击**创建页面** . 您以后可以随时对其进行编辑,因此继续写欢迎信息.
[![New home page](img/909d20c0dd57155c8ac404a81c2a30cb.png)](img/wiki_create_home_page.png)
## Creating a new wiki page[](#creating-a-new-wiki-page "Permalink")
**注意:**需要开发者[权限](../../permissions.html) .
通过单击可在所有 Wiki 页面中找到的" **新页面"**按钮来创建新页面.
系统将要求您为新的 Wiki 页面填写标题.
您可以通过在标题中使用" /"指示子目录来为 Wiki 页面指定完整路径. 任何丢失的目录将自动创建. 例如, `docs/my-page`的标题将创建一个 Wiki 页面,其路径为`/wikis/docs/my-page` .
输入页面名称后,就该填写其内容了. GitLab Wiki 支持 Markdown,RDoc,AsciiDoc 和 Org. 对于基于 Markdown 的页面,所有[Markdown 功能](../../markdown.html)均受支持,对于链接,则存在一些[特定](../../markdown.html#wiki-specific-markdown)[Wiki 的](../../markdown.html#wiki-specific-markdown)行为.
在 Web 界面中,提交消息是可选的,但是 GitLab Wiki 是基于 Git 的,并且需要提交消息,因此如果您不输入消息,则会为您创建一条.
When you’re ready, click the **建立页面** and the new page will be created.
[![New page](img/0a61445809db70ca6bf85d986bf52223.png)](img/wiki_create_new_page.png)
### Attachment storage[](#attachment-storage "Permalink")
在 GitLab 11.3 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/33475) .
从 GitLab 11.3 开始,通过 GitLab 界面上载到 Wiki 的任何文件都将存储在 Wiki Git 存储库中,如果您在本地克隆 Wiki 存储库,该文件将可用. GitLab 11.3 之前的所有上传文件都存储在 GitLab 本身中. 如果希望它们成为 Wiki 的 Git 存储库的一部分,则必须再次上传它们.
### Special characters in page titles[](#special-characters-in-page-titles "Permalink")
Wiki 页面作为文件存储在 Git 存储库中,因此某些字符具有特殊含义:
* 存储页面时,空格会转换为连字符.
* 显示页面时,连字符( `-` )转换回空格.
* 不能使用斜杠( `/` ),因为它们用作路径分隔符.
### Length restrictions for file and directory names[](#length-restrictions-for-file-and-directory-names "Permalink")
在 GitLab 12.8 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/24364) .
许多常见的文件系统[的文件名和目录名限制为 255 个字节](https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits) ,尽管 Git 和 GitLab 都支持超出这些限制的路径,但是它们的存在使这些文件系统上的用户无法在本地检出 Wiki 存储库.
为了避免这种情况,通过 GitLab Web 界面和 API 编辑页面时会强制执行以下限制:
* 页面标题为 245 个字节(文件扩展名保留 10 个字节).
* 255 个字节的目录名称.
请注意:
* 非 ASCII 字符占用多个字节.
* 仍然可以通过 Git 在本地创建超出限制的文件和目录,但这可能会在其他人的计算机上中断.
## Editing a wiki page[](#editing-a-wiki-page "Permalink")
**注意:**需要开发者[权限](../../permissions.html) .
要编辑页面,只需单击" **编辑"**按钮. 从那里开始,您可以更改其内容. 完成后,单击" **保存更改"**以使更改生效.
### Adding a table of contents[](#adding-a-table-of-contents "Permalink")
要从 Wiki 页面中的标题生成目录,请使用`[[_TOC_]]`标签. 有关示例,请参阅[目录](../../markdown.html#table-of-contents) .
## Deleting a wiki page[](#deleting-a-wiki-page "Permalink")
**注意:**需要维护者[权限](../../permissions.html) .
仅在编辑页面时才能找到" **删除"**按钮. 单击它并确认您要删除页面.
## Moving a wiki page[](#moving-a-wiki-page "Permalink")
通过在[编辑](#editing-a-wiki-page)表单的 Wiki 页面标题中指定完整路径,可以将 Wiki 页面从一个目录移动到另一个目录.
[![Moving a page](img/7a0180479e056fe1c4aa11c3e8684906.png)](img/wiki_move_page_1.png)
[![After moving a page](img/70117ebf119dd375e0def463921cc363.png)](img/wiki_move_page_2.png)
为了将 Wiki 页面移动到根目录,必须在 Wiki 页面标题前加上斜杠( `/` )字符.
## Viewing a list of all created wiki pages[](#viewing-a-list-of-all-created-wiki-pages "Permalink")
每个 Wiki 都有一个侧边栏,从中可以找到所创建页面的简短列表. 该列表按字母顺序排列.
[![Wiki sidebar](img/03d3f984ea7608322b1fd6a7feba47c0.png)](img/wiki_sidebar.png)
如果页面很多,则不会在侧边栏中列出所有页面. 单击**查看所有页面****查看所有页面** .
## Viewing the history of a wiki page[](#viewing-the-history-of-a-wiki-page "Permalink")
Wiki 页面随时间的变化记录在 Wiki 的 Git 存储库中,您可以通过单击**Page history**按钮来查看它们.
从历史记录页面中,您可以看到页面的修订版(Git commit SHA),其作者,提交消息以及上次更新时间. 要查看页面的先前版本的外观,请在" **页面版本"**列中单击修订号.
[![Wiki page history](img/2fdc2024eee83764328fb015ffd4e392.png)](img/wiki_page_history.png)
### Viewing the changes between page versions[](#viewing-the-changes-between-page-versions "Permalink")
在 GitLab 13.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/15242) .
类似于版本化的差异文件视图,您可以看到在给定的 Wiki 页面版本中所做的更改:
1. 导航到您感兴趣的 Wiki 页面.
2. 单击**页面历史记录**以查看所有页面版本.
3. 单击" **更改"**列中的提交消息以获取您感兴趣的版本:
[![Wiki page changes](img/9cc2ca9eb5afc113cacfbc529374fe3b.png)](img/wiki_page_diffs_v13_2.png)
## Wiki activity records[](#wiki-activity-records "Permalink")
版本历史
* 在 GitLab 12.10 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/14902) .
* 它部署在功能标记后面,默认情况下处于禁用状态.
* 在 GitLab.com 上启用了它.
* 要在 GitLab 自管实例中使用它,请让 GitLab 管理员[启用它](#enable-or-disable-wiki-events-core-only) .
Wiki 事件(创建,删除和更新)由 GitLab 跟踪,并显示在[用户个人资料](../../profile/index.html#user-profile)[](../../group/index.html#view-group-activity)[项目](../index.html#project-activity)活动页面上.
### Limitations[](#limitations "Permalink")
只有在浏览器中或通过 API 进行的编辑才会记录其活动. 当前在活动列表中未列出通过 Git 进行和推送的编辑.
### Enable or disable Wiki Events[](#enable-or-disable-wiki-events-core-only "Permalink")
Wiki 事件活动正在开发中,尚未准备好用于生产. 它部署在**默认情况下禁用**的功能标志的后面. [有权访问 GitLab Rails 控制台的 GitLab 管理员](../../../administration/troubleshooting/navigating_gitlab_via_rails_console.html#starting-a-rails-console-session)可以为您的实例启用它. 欢迎您对其进行测试,但使用风险自负.
要启用它:
```
Feature.enable(:wiki_events)
```
禁用它:
```
Feature.disable(:wiki_events)
```
## Adding and editing wiki pages locally[](#adding-and-editing-wiki-pages-locally "Permalink")
由于 Wiki 基于 Git 存储库,因此您可以像在其他所有 Git 存储库中一样在本地克隆它们并进行编辑.
在右侧栏上,单击" **克隆存储库",**然后按照屏幕上的说明进行操作.
根据您要使用的标记语言,您在本地添加到 Wiki 的文件必须具有以下受支持的扩展名之一,否则当推送到 GitLab 时将不会显示这些文件:
* Markdown 扩展名: `.mdown``.mkd``.mkdn``.md``.markdown` .
* AsciiDoc 扩展名: `.adoc``.ad``.asciidoc` .
* 其他标记扩展名: `.textile``.rdoc``.org``.creole``.wiki``.mediawiki``.rst` .
## Customizing sidebar[](#customizing-sidebar "Permalink")
在项目的 Wiki 页面上,有一个右侧导航,默认情况下呈现带有层次结构的完整 Wiki 页面列表.
要自定义边栏,您可以创建一个名为`_sidebar`的文件以完全替换默认导航.
**警告:**除非您从自定义导航链接`_sidebar`文件,否则要进行编辑,必须输入以下内容直接从浏览器的地址栏中访问: `https://gitlab.com/<namespace>/<project_name>/-/wikis/_sidebar` : `_sidebar` /- `https://gitlab.com/<namespace>/<project_name>/-/wikis/_sidebar` (对于自我管理的 GitLab 实例,将`gitlab.com`替换为实例的 URL).
`_sidebar`示例(使用 Markdown 格式):
```
### [Home](home)
- [Hello World](hello)
- [Foo](foo)
- [Bar](bar)
---
- [Sidebar](_sidebar)
```
计划支持使用自定义侧面导航显示生成的目录.
\ No newline at end of file
# Project operations
> 原文:[https://docs.gitlab.com/ee/operations/](https://docs.gitlab.com/ee/operations/)
# Project operations[](#project-operations "Permalink")
manbetx 客户端打不开提供各种工具来帮助操作和维护您的应用程序:
* Collect [Prometheus metrics](../user/project/integrations/prometheus_library/index.html).
* 部署到不同的[环境](../ci/environments/index.html) .
* 管理您的[警报](../user/project/operations/alert_management.html)[事件](../user/incident_management/index.html) .
* 将您的项目连接到[Kubernetes 集群](../user/project/clusters/index.html) .
* 通过" [按代码实施](../user/infrastructure/index.html)基础[结构"](../user/infrastructure/index.html)管理基础[结构](../user/infrastructure/index.html) .
* 通过[错误跟踪](../user/project/operations/error_tracking.html)发现并查看由应用程序生成的[错误](../user/project/operations/error_tracking.html) .
* 创建,切换和删除[功能标记](feature_flags.html) .
* [跟踪](tracing.html)已部署应用程序的性能和运行状况.
* 更改" [监视仪表板](../user/project/operations/dashboard_settings.html) "的[设置](../user/project/operations/dashboard_settings.html) .
\ No newline at end of file
# Monitor metrics for your CI/CD environment
> 原文:[https://docs.gitlab.com/ee/operations/metrics/](https://docs.gitlab.com/ee/operations/metrics/)
* [Populate your metrics dashboard](#populate-your-metrics-dashboard)
* [Customize your metrics dashboard](#customize-your-metrics-dashboard)
* [Metrics dashboard visibility](#metrics-dashboard-visibility)
* [Adding custom metrics](#adding-custom-metrics)
* [Editing additional metrics from the dashboard](#editing-additional-metrics-from-the-dashboard)
* [Keyboard shortcuts for charts](#keyboard-shortcuts-for-charts)
# Monitor metrics for your CI/CD environment[](#monitor-metrics-for-your-cicd-environment "Permalink")
[为群集配置 Prometheus](../../user/project/integrations/prometheus.html)之后,GitLab 会尝试在成功部署的任何[环境中](../../ci/environments/index.html)检索性能指标.
GitLab 在 Prometheus 服务器上扫描来自 Kubernetes 和 NGINX 等已知服务器的指标,并尝试识别各个环境. 要了解有关支持的指标和扫描过程的更多信息,请参阅[Prometheus Metrics Library 文档](../../user/project/integrations/prometheus_library/index.html) .
要查看已[完成至少一个部署](#populate-your-metrics-dashboard)的环境的指标仪表板,请执行[以下操作](#populate-your-metrics-dashboard)
1. *如果指标仪表盘仅对项目成员可见,请以项目成员*身份登录到 GitLab. 了解有关[指标仪表板可见性的](#metrics-dashboard-visibility)更多[信息](#metrics-dashboard-visibility) .
2. 在您的项目中,导航到 **操作>指标** .
GitLab 显示环境的默认指标仪表板,如以下示例所示:
[![Example of metrics dashboard](img/b12f4326b7cccf6e82c375163842f58e.png)](img/example-dashboard_v13_1.png)
仪表板的顶部包含一个导航栏. 从左到右,导航栏包含:
* **仪表板** -项目可用的所有仪表板的下拉列表,其中加星标的仪表板排在最前面.
* **环境** -所有[环境的](../index.html)下拉列表,可在您键入时搜索所有环境.
* **范围** -要显示的数据的时间段.
* **刷新仪表板** -用当前数据重新加载仪表板.
* **设置刷新率** - Set a time frame for refreshing the data displayed.
* **明星仪表板** -单击以将仪表板标记为收藏夹. 已加星标的信息中心显示实心星 按钮,然后在" **仪表板"**下拉列表中首先显示. (在 GitLab 13.0 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/214582) .)
* **创建仪表板** - [为您的项目](dashboards/index.html#adding-a-new-dashboard-to-your-project)创建一个[新的自定义仪表板](dashboards/index.html#adding-a-new-dashboard-to-your-project) .
* **指标设置** -配置[此仪表板](dashboards/index.html#manage-the-metrics-dashboard-settings)[设置](dashboards/index.html#manage-the-metrics-dashboard-settings) .
## Populate your metrics dashboard[](#populate-your-metrics-dashboard "Permalink")
[为群集配置 Prometheus](../../user/project/integrations/prometheus.html)之后,您还必须为 **操作>指标**页面以包含数据. 设置[Auto DevOps](../../topics/autodevops/index.html)有助于快速创建部署:
1. 导航到您项目的 **操作> Kubernetes**页面.
2. 确保除了 Prometheus 外,还安装了 Runner 和 Ingress.
3. 安装 Ingress 后,复制其端点.
4. Navigate to your project’s **设置> CI / CD** page. In the **自动 DevOps** section, select a deployment strategy and save your changes.
5. 在同一页上的" **变量"**部分中,添加一个名为`KUBE_INGRESS_BASE_DOMAIN`的变量, `KUBE_INGRESS_BASE_DOMAIN`包含您先前复制的 Ingress 端点的值. 将类型保留为**Variable** .
6. 导航到您项目的 **CI / CD>管道**页面,然后在任何分支上运行管道.
7. 管道成功运行后,图表将在 **操作>指标**页面.
[![Monitoring Dashboard](img/1bce7244cd585ee6d059a7aa1903f194.png)](../../user/project/integrations/img/prometheus_monitoring_dashboard_v13_1.png)
## Customize your metrics dashboard[](#customize-your-metrics-dashboard "Permalink")
创建仪表板后,您可以对其进行自定义以满足您的需求:
* **添加自定义指标** :除了 GitLab 默认指标之外,您还可以[创建自定义指标](#adding-custom-metrics)并将其显示在指标仪表板上.
* **配置指标警报** :当环境性能超出您设置的范围时,为团队[配置自定义警报](alerts.html) .
* **通过警报触发操作**[为您的团队打开新问题](alerts.html#trigger-actions-from-alerts-ultimate) 当环境性能超出您设置的范围时.
## Metrics dashboard visibility[](#metrics-dashboard-visibility "Permalink")
在 GitLab 13.0 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/201924) .
您可以将指标仪表板的可见性设置为" **仅项目成员"**或" **具有访问权限的所有人"** . 当设置为" **具有访问权的所有人"时** ,指标仪表板对于已认证和未认证的用户都是可见的.
## Adding custom metrics[](#adding-custom-metrics "Permalink")
版本历史
*[GitLab Premium](https://about.gitlab.com/pricing/) 10.6 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3799) .
* [移至](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28527) [GitLab Core](https://about.gitlab.com/pricing/) 12.10\.
可以通过在监控仪表板页面上添加自定义指标来对其进行监控. 保存它们后,它们将显示在环境指标仪表板上,前提是:
* 使用具有匹配[环境范围的](../../ci/environments/index.html#scoping-environments-with-specs) [连接的 Kubernetes 群集](../../user/project/clusters/add_remove_clusters.html) ,并将[Prometheus 安装在群集上](../../user/project/integrations/prometheus.html#enabling-prometheus-integration) .
* Prometheus 是[手动配置的](../../user/project/integrations/prometheus.html#manual-configuration-of-prometheus) .
[![Add New Metric](img/ecb68ae545435c5eb9229937635a5aee.png)](../../user/project/integrations/img/prometheus_add_metric.png)
必须填写几个字段:
* **名称** :图表标题
* **类型** :指标的类型. 相同类型的指标将一起显示.
* **查询** :有效的[PromQL 查询](https://s0prometheus0io.icopy.site/docs/prometheus/latest/querying/basics/) .
* **Y 轴标签** :Y 轴标题显示在仪表板上.
* **单位标签** :查询单位,例如`req / sec` . 值旁边显示.
如果指标之间的**名称****类型****Y 轴标签**字段匹配,则可以在同一图表上显示多个指标. 例如,具有" **名称** `Requests Rate` ," `Business` **类型"****Y 轴标签** `rec / sec`度量标准将与另一个具有相同值的度量标准显示在同一图表上. 如果使用此功能,则建议使用**图例标签** .
## Editing additional metrics from the dashboard[](#editing-additional-metrics-from-the-dashboard "Permalink")
在 GitLab 12.9 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/208976) .
您可以通过以下方式为信息中心编辑现有的其他自定义指标: **更多操作**下拉菜单,然后选择**编辑指标** .
[![Edit metric](img/f0d4bcbd75dfae1dbbc867343090a4ca.png)](../../user/project/integrations/img/prometheus_dashboard_edit_metric_link_v_12_9.png)
## Keyboard shortcuts for charts[](#keyboard-shortcuts-for-charts "Permalink")
在 GitLab 13.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/202146) .
您可以使用键盘快捷键与当前关注的图表面板更快地进行交互. 要激活键盘快捷键,请使用键盘标签突出显示 **"更多操作"**下拉菜单,或用鼠标悬停在下拉菜单上,然后按与所需操作对应的键:
* **展开面板** - `e`
* **查看日志** `-l` (小写" L")
* **下载 CSV** - `d`
* **复制链接到图表** - `c`
* **Alerts** - `a`
\ No newline at end of file
# Set up alerts for Prometheus metrics
> 原文:[https://docs.gitlab.com/ee/operations/metrics/alerts.html](https://docs.gitlab.com/ee/operations/metrics/alerts.html)
* [Managed Prometheus instances](#managed-prometheus-instances)
* [External Prometheus instances](#external-prometheus-instances)
* [Trigger actions from alerts](#trigger-actions-from-alerts-ultimate)
# Set up alerts for Prometheus metrics[](#set-up-alerts-for-prometheus-metrics "Permalink")
[为 CI / CD 环境配置指标](index.html)后,您可以根据实例的位置为 Prometheus 指标设置警报,并在环境性能超出您设置的范围时[触发警报操作](#trigger-actions-from-alerts-ultimate)以通知您的团队.
## Managed Prometheus instances[](#managed-prometheus-instances "Permalink")
[GitLab Ultimate](https://about.gitlab.com/pricing/) 11.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6590)[自定义指标](index.html#adding-custom-metrics) ,在 11.3 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6590)[图书馆指标](../../user/project/integrations/prometheus_library/metrics.html) .
对于使用自动配置的托管 Prometheus 实例,您可以直接在[指标仪表板中](index.html) [配置指标警报](index.html#adding-custom-metrics) . 设置警报:
1. 在您的项目中,导航到 **操作>指标**
2. 确定要为其创建警报的指标,然后单击**省略号** 指标右上角的图标.
3. Choose **Alerts**.
4. 设置阈值和运算符.
5. 单击**添加**以保存并激活警报.
[![Adding an alert](img/659964d0e0d080d80881d6eb74aaaf7e.png)](../../user/project/integrations/img/prometheus_alert.png)
要删除警报,请在警报图标上返回所需的指标,然后单击" **删除"** .
## External Prometheus instances[](#external-prometheus-instances "Permalink")
版本历史
*[GitLab Ultimate](https://about.gitlab.com/pricing/) 11.8 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/9258) .
* 在 12.10 中[移至](https://gitlab.com/gitlab-org/gitlab/-/issues/42640) [GitLab Core](https://about.gitlab.com/pricing/) .
对于手动配置的 Prometheus 服务器,GitLab 提供了一个通知端点,用于 Prometheus Webhooks. 如果启用了手动配置,则会将" **警报"**部分添加到 **设置>集成> Prometheus** . 本部分包含您需要的**URL****授权密钥** . **重置密钥**按钮将使密钥无效并生成一个新密钥.
[![Prometheus service configuration of Alerts](img/510cd4b11aa5f23be76d594a9ad782d6.png)](../../user/project/integrations/img/prometheus_service_alerts.png)
要发送 GitLab 警报通知,请将**URL****授权密钥**复制到 Prometheus Alertmanager 配置的[`webhook_configs`](https://s0prometheus0io.icopy.site/docs/alerting/latest/configuration/)部分:
```
receivers:
name: gitlab
webhook_configs:
- http_config:
bearer_token: 9e1cbfcd546896a9ea8be557caf13a76
send_resolved: true
url: http://192.168.178.31:3001/root/manual_prometheus/prometheus/alerts/notify.json
...
```
为了使 GitLab 将警报与[环境](../../ci/environments/index.html)相关联,您必须在 Prometheus 中设置的警报上配置`gitlab_environment_name`标签. 此值应与您在 GitLab 中的环境名称匹配.
**Note:** In GitLab versions 13.1 and greater, you can configure your manually configured Prometheus server to use the [Generic alerts integration](../../user/project/integrations/generic_alerts.html).
## Trigger actions from alerts[](#trigger-actions-from-alerts-ultimate "Permalink")
版本历史
*[GitLab Ultimate](https://about.gitlab.com/pricing/) 11.11 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/4925) .
* [从 GitLab Ultimate 12.5 起](https://gitlab.com/gitlab-org/gitlab/-/issues/13401) ,当 GitLab 收到恢复警报时,它将自动关闭相关问题.
警报可用于触发操作,例如自动打开问题(自`13.1`默认禁用). 要配置操作:
1. 导航到您项目的 **设置>操作>事件** .
2. 启用该选项以创建问题.
3. 选择要从中创建问题的[问题模板](../../user/project/description_templates.html) .
4. (可选)选择是否将电子邮件通知发送给项目的开发人员.
5. Click **保存更改**.
启用后,当触发包含包含从[警报有效负载中](https://s0prometheus0io.icopy.site/docs/alerting/latest/configuration/)提取的值的警报时,GitLab 会自动打开一个问题:
* 问题作者: `GitLab Alert Bot`
* 问题标题:从`annotations/title``annotations/summary``labels/alertname`
* 警报`Summary` :属性列表
* `starts_at` :通过`startsAt`警报的开始时间
* `full_query` :从`generatorURL`提取的警报查询
*`annotations/*`提取的附加注释的可选列表
* Alert [GFM](../../user/markdown.html) :来自`annotations/gitlab_incident_markdown` GitLab 风味`annotations/gitlab_incident_markdown`
当 GitLab 收到**Recovery Alert 时** ,它将关闭相关问题. 该操作记录为关于该问题的系统消息,表明该操作已由 GitLab Alert 机器人自动关闭.
要进一步自定义问题,您可以在所选问题模板中添加标签,提及或任何其他受支持的[快速操作](../../user/project/quick_actions.html) ,该操作适用于所有事件. 要将快速操作或其他信息限制为仅特定类型的警报,请使用`annotations/gitlab_incident_markdown`字段.
[版本 12.2 开始](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63373) ,GitLab 会使用`incident`标签自动标记每个事件问题. 如果标签尚不存在,则会自动创建.
如果度量标准超过警报阈值超过 5 分钟,则 GitLab 会向该项目的所有[维护者和所有者](../../user/permissions.html#project-members-permissions)发送电子邮件.
\ No newline at end of file
# Embedding metric charts within GitLab-flavored Markdown
> 原文:[https://docs.gitlab.com/ee/operations/metrics/embed.html](https://docs.gitlab.com/ee/operations/metrics/embed.html)
* [Embedding GitLab-managed Kubernetes metrics](#embedding-gitlab-managed-kubernetes-metrics)
* [Embedding metrics in issue templates](#embedding-metrics-in-issue-templates)
* [Embedding metrics based on alerts in incident issues](#embedding-metrics-based-on-alerts-in-incident-issues)
* [Embedding cluster health charts](#embedding-cluster-health-charts)
# Embedding metric charts within GitLab-flavored Markdown[](#embedding-metric-charts-within-gitlab-flavored-markdown "Permalink")
您可以在[GitLab 风味降价](../../user/markdown.html#gitlab-flavored-markdown-gfm)字段中显示指标图表,例如发布或合并请求说明. GitLab 风味的 Markdown 字段中允许的最大嵌入图表数为 100.当与其他人共享应用程序事件或性能指标并且您想直接获得相关信息时,嵌入图表很有用.
## Embedding GitLab-managed Kubernetes metrics[](#embedding-gitlab-managed-kubernetes-metrics "Permalink")
在 GitLab 12.2 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29691) .
**Note:** Requires [Kubernetes](../../user/project/integrations/prometheus_library/kubernetes.html) metrics.
要显示度量图表,请在支持 GitLab 风格的 Markdown 的字段中包含`https://<root_url>/<project>/-/environments/<environment_id>/metrics`形式的链接:
[![Embedded Metrics Markdown](img/8f07bae8fce74cd6b8276b7dd9e59c2e.png)](../../user/project/integrations/img/embedded_metrics_markdown_v12_8.png)
GitLab 将链接展开为嵌入式指标面板:
[![Embedded Metrics Rendered](img/276614fbc4ef7b7b9f7a445dffbc5691.png)](../../user/project/integrations/img/embedded_metrics_rendered_v12_8.png)
您还可以嵌入一个图表. 要获取图表链接,请点击 图表右上角的" **更多操作"**菜单,然后选择" **将链接复制到图表"** ,如本示例所示:
[![Copy Link To Chart](img/6f52527c138db466f7fba27994ad67f8.png)](../../user/project/integrations/img/copy_link_to_chart_v12_10.png)
指标必须满足以下要求:
* `<environment_id>`必须与真实环境相对应.
* 普罗米修斯必须在监视环境.
* 必须将 GitLab 实例配置为从环境接收数据.
* 必须允许用户访问环境( [Reporter 或更高版本](../../user/permissions.html) )的监视仪表板.
* 仪表板必须在最近 8 小时内具有数据.
如果以上所有条件均成立,则该指标将展开,如下所示:
[![Embedded Metrics](img/0ff1ac0799b3b8867f4ebefa4e22d786.png)](../../user/project/integrations/img/view_embedded_metrics_v12_10.png)
公制图表也可能被隐藏:
[![Show Hide](img/cb4ff59b46134d4c61caedcf5a66a74f.png)](../../user/project/integrations/img/hide_embedded_metrics_v12_10.png)
您可以直接在浏览器中打开链接[以获取数据](dashboards/index.html#expand-panel)[详细视图](dashboards/index.html#expand-panel) .
## Embedding metrics in issue templates[](#embedding-metrics-in-issue-templates "Permalink")
您也可以在问题模板中嵌入默认仪表板指标或单个指标. 要使图表并排显示,请使用逗号或空格将指向整个指标仪表板或单个指标的单独链接分开.
[![Embedded Metrics in issue templates](img/b51efc1bf28d2363ac0b4e95c4318fbe.png)](../../user/project/integrations/img/embed_metrics_issue_template.png)
## Embedding metrics based on alerts in incident issues[](#embedding-metrics-based-on-alerts-in-incident-issues "Permalink")
对于由[GitLab 管理的警报规则](alerts.html) ,问题包括与警报相对应的查询的嵌入式图表. 该图表显示了事件开始点前后一个小时(前后 30 分钟)的一小时数据.
对于[手动配置的 Prometheus 实例](../../user/project/integrations/prometheus.html#manual-configuration-of-prometheus) ,如果满足以下要求,则可以包括与查询相对应的图表:
* 该警报对应于通过 GitLab 管理的环境.
* 警报对应于[范围查询](https://s0prometheus0io.icopy.site/docs/prometheus/latest/querying/api/) .
* 警报包含下表中列出的必需属性.
| Attributes | Required | Description |
| --- | --- | --- |
| `annotations/gitlab_environment_name` | Yes | 与警报对应的由 GitLab 管理的环境的名称 |
| `annotations/title``annotations/summary``labels/alertname` | Yes | 用作图表标题 |
| `annotations/gitlab_y_label` | No | 用作图表的 y 轴标签 |
## Embedding cluster health charts[](#embedding-cluster-health-charts "Permalink")
版本历史
*[GitLab Ultimate](https://about.gitlab.com/pricing/) 12.9 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/40997) .
* 在 13.2 中[移至](https://gitlab.com/gitlab-org/gitlab/-/issues/208224) GitLab 核心.
[Cluster Health Metrics](../../user/project/clusters/index.html#visualizing-cluster-health)也可以嵌入到[GitLab 风格的 Markdown 中](../../user/markdown.html) .
要嵌入度量标准图表,请在支持 GitLab 风格的 Markdown 的任何位置以`https://<root_url>/<project>/-/cluster/<cluster_id>?<query_params>`的形式包含指向该图表的链接. 要生成并复制到图表的链接,请遵循[Cluster Health Metric 文档中的说明](../../user/project/clusters/index.html#visualizing-cluster-health) .
指标必须满足以下要求:
* `<cluster_id>`必须与实际群集相对应.
* Prometheus 必须监视群集.
* 必须允许用户访问项目集群指标.
* 仪表板必须在" [集群运行状况"页面](../../user/project/clusters/index.html#visualizing-cluster-health)上报告数据
如果满足上述要求,则度量标准将展开,如下所示.
[![Embedded Cluster Metric in issue descriptions](img/f8c421bf7dd271d1aeee39c15aab183d.png)](../../user/project/integrations/img/prometheus_cluster_health_embed_v12_9.png)
\ No newline at end of file
# Embedding Grafana charts
> 原文:[https://docs.gitlab.com/ee/operations/metrics/embed_grafana.html](https://docs.gitlab.com/ee/operations/metrics/embed_grafana.html)
* [Embedding charts via Grafana Rendered Images](#embedding-charts-via-grafana-rendered-images)
* [Embedding charts via integration with Grafana HTTP API](#embedding-charts-via-integration-with-grafana-http-api)
* [Setting up the Grafana integration](#setting-up-the-grafana-integration)
* [Generating a link to a chart](#generating-a-link-to-a-chart)
# Embedding Grafana charts[](#embedding-grafana-charts "Permalink")
Grafana 指标可以嵌入到[GitLab 风味 Markdown 中](../../user/markdown.html) .
## Embedding charts via Grafana Rendered Images[](#embedding-charts-via-grafana-rendered-images "Permalink")
可以在问题中嵌入实时[Grafana](https://docs.gitlab.com/omnibus/settings/grafana.html)图表,作为[直接链接的渲染图像](https://grafana.com/docs/grafana/latest/reference/share_panel/#direct-link-rendered-image) .
Grafana 中的共享对话框提供了链接,如下所示.
[![Grafana Direct Linked Rendered Image](img/f406b88682259abab36d343539b1664c.png)](../../user/project/integrations/img/grafana_live_embed.png)
**注意:**为了使此嵌入正确显示,Grafana 实例必须可作为公共仪表板或在同一网络上供目标用户使用.
复制链接并在 Markdown 中将图像标签添加为[内联 HTML](../../user/markdown.html#inline-html) . 您可以根据需要调整查询参数. 例如,删除`&from=``&to=`参数将为您提供实时图表. 这是来自 GitLab 公共仪表板的实时图表的示例标记:
```
<img src="https://dashboards.gitlab.com/d/RZmbBr7mk/gitlab-triage?orgId=1&refresh=30s&var-env=gprd&var-environment=gprd&var-prometheus=prometheus-01-inf-gprd&var-prometheus_app=prometheus-app-01-inf-gprd&var-backend=All&var-type=All&var-stage=main&from=1580444107655&to=1580465707655"/>
```
这将呈现为:
[![Grafana dashboard embedded preview](img/b820c73810583190a0b1697c813fdda8.png)](../../user/project/integrations/img/grafana_embedded.png)
## Embedding charts via integration with Grafana HTTP API[](#embedding-charts-via-integration-with-grafana-http-api "Permalink")
在 GitLab 12.5 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/31376) .
每个项目可以支持与一个 Grafana 实例的集成. 此配置允许用户将链接复制到 Grafana 中的面板,然后将其粘贴到 GitLab Markdown 字段中. 该图表将以 GitLab 图表格式呈现.
从 Grafana 实例嵌入的先决条件:
1. 数据源必须是 Prometheus 实例.
2. 数据源必须是可代理的,因此 HTTP 访问设置应设置为`Server` .
[![HTTP Proxy Access](img/7896b9b275d92d4b9cb2001cc464e509.png)](../../user/project/integrations/img/http_proxy_access_v12_5.png)
## Setting up the Grafana integration[](#setting-up-the-grafana-integration "Permalink")
1. [Generate an Admin-level API Token in Grafana.](https://grafana.com/docs/grafana/latest/http_api/auth/#create-api-token)
2. 在您的 GitLab 项目中,导航至**设置>操作> Grafana 身份验证** .
3. 要启用集成,请选中"活动"复选框.
4. 对于" Grafana URL",输入 Grafana 实例的基本 URL.
5. 对于" API 令牌",输入您刚生成的 Admin API 令牌.
6. Click **保存更改**.
## Generating a link to a chart[](#generating-a-link-to-a-chart "Permalink")
1. 在 Grafana 中,导航到要嵌入面板的仪表板. [![Grafana 公制面板](img/eb191fa059117d5fb30958d7f6241704.png)](../../user/project/integrations/img/grafana_panel_v12_5.png)
2. 在页面的左上角,为图表中查询所需的每个变量选择一个特定值. [![选择查询变量](img/40834a63780a362f429e1902450a4a7a.png)](../../user/project/integrations/img/select_query_variables_v12_5.png)
3. 在 Grafana 中,单击面板的标题,然后单击" **共享"**以将面板的共享对话框打开到" **链接"**选项卡. 如果您单击*仪表板的*共享面板,则 GitLab 将尝试在仪表板上嵌入第一个受支持的面板(如果有).
4. 如果您的普罗米修斯查询使用 Grafana 的自定义模板变量,确保"模板变量"选项切换为**开** . 在 Grafana 全局模板变量中,目前仅支持`$__interval``$__from``$__to` . 切换**"**当前时间范围"选项来指定图表的时间范围. 否则,默认范围将是最近 8 小时. [![Grafana 共享对话框](img/ce9e5e0a216a3a51d412bcb3cb11f420.png)](../../user/project/integrations/img/grafana_sharing_dialog_v12_5.png)
5. 单击**复制**将 URL **复制**到剪贴板.
6. 在 GitLab 中,将该 URL 粘贴到 Markdown 字段中并保存. 该图表将需要一些时间来呈现. [![GitLab 渲染的 Grafana 面板](img/c67bf60334fcbd1f63dc0a6515d02eca.png)](../../user/project/integrations/img/rendered_grafana_embed_v12_5.png)
\ No newline at end of file
# Using the Metrics Dashboard
> 原文:[https://docs.gitlab.com/ee/operations/metrics/dashboards/](https://docs.gitlab.com/ee/operations/metrics/dashboards/)
* [Manage the metrics dashboard settings](#manage-the-metrics-dashboard-settings)
* [Chart Context Menu](#chart-context-menu)
* [View and edit the source file of a custom dashboard](#view-and-edit-the-source-file-of-a-custom-dashboard)
* [Expand panel](#expand-panel)
* [View Logs](#view-logs-ultimate)
* [Timeline zoom and URL sharing](#timeline-zoom-and-url-sharing)
* [Downloading data as CSV](#downloading-data-as-csv)
* [Dashboard Annotations](#dashboard-annotations)
* [Retention policy](#retention-policy)
* [Add related links to custom dashboards](#add-related-links-to-custom-dashboards)
* [Links Syntax](#links-syntax)
* [Defining custom dashboards per project](#defining-custom-dashboards-per-project)
* [Adding a new dashboard to your project](#adding-a-new-dashboard-to-your-project)
* [Navigating to a custom dashboard](#navigating-to-a-custom-dashboard)
* [Duplicating a GitLab-defined dashboard](#duplicating-a-gitlab-defined-dashboard)
* [Troubleshooting](#troubleshooting)
* [“No data found” error on Metrics dashboard page](#no-data-found-error-on-metrics-dashboard-page)
# Using the Metrics Dashboard[](#using-the-metrics-dashboard "Permalink")
## Manage the metrics dashboard settings[](#manage-the-metrics-dashboard-settings "Permalink")
在 GitLab 13.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/223204) .
要管理指标信息中心的设置,请执行以下操作:
1. 以具有项目维护者或管理员[权限](../../../user/permissions.html#project-members-permissions)的用户身份登录.
2. 导航至以下位置的信息中心 **操作>指标** .
3. 在资讯主页的右上角,按一下 **指标设置**
[![Monitoring Dashboard actions menu with create new item](img/0df7602f630bb279bdd6d7dc6a5dcf2f.png)](../../../user/project/integrations/img/metrics_settings_button_v13_2.png)
## Chart Context Menu[](#chart-context-menu "Permalink")
在信息中心的每个面板上,您都可以通过以下方式访问上下文菜单: 面板右上角上方的" **更多操作"**下拉框可采取与图表数据相关的操作.
[![Context Menu](img/1a3371a11e14e221f5c8e0e75e327d08.png)](../../../user/project/integrations/img/panel_context_menu_v13_0.png)
选项包括:
* [Expand panel](#expand-panel)
* [View logs](#view-logs-ultimate)
* [Download CSV](#downloading-data-as-csv)
* [Copy link to chart](../embed.html#embedding-gitlab-managed-kubernetes-metrics)
* [Alerts](../alerts.html)
### View and edit the source file of a custom dashboard[](#view-and-edit-the-source-file-of-a-custom-dashboard "Permalink")
在 GitLab 12.5 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/34779) .
查看项目的自定义仪表板时,可以通过单击" **编辑仪表板"**按钮来查看原始的`.yml`文件.
### Expand panel[](#expand-panel "Permalink")
在 GitLab 13.0 中[引入](https://gitlab.com/groups/gitlab-org/-/epics/3100) .
要查看较大的可视化版本,请点击 **更多操作**图标,然后选择**展开面板** .
要返回指标仪表板,请单击浏览器中的" **后退"**按钮,或按`Esc`键.
### View Logs[](#view-logs-ultimate "Permalink")
在 GitLab 12.8 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/122013) .
如果启用了[日志](../../../user/project/clusters/kubernetes_pod_logs.html) ,则可以通过单击右上角的上下文菜单从仪表板中的图表导航以查看日志.
如果使用图表底部的**时间轴缩放**功能,日志将缩小到您选择的时间范围.
### Timeline zoom and URL sharing[](#timeline-zoom-and-url-sharing "Permalink")
在 GitLab 12.8 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/198910) .
您可以使用图表底部的**时间轴缩放**功能来放大所选的日期和时间. 单击并拖动滑块以选择要显示的数据的其他开始或结束日期时,GitLab 会将所选的开始和结束时间添加到 URL,从而使您可以更轻松地共享特定的时间范围.
### Downloading data as CSV[](#downloading-data-as-csv "Permalink")
指标仪表板上 Prometheus 图表中的数据可以 CSV 格式下载.
## Dashboard Annotations[](#dashboard-annotations "Permalink")
版本历史
* 在 GitLab 12.10 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/211330) (由功能标志`metrics_dashboard_annotations`启用).
* 在 GitLab 13.0 中[删除](https://gitlab.com/gitlab-org/gitlab/-/issues/215224)[功能标志](https://gitlab.com/gitlab-org/gitlab/-/issues/215224) .
您可以使用" **指标仪表板注释"**通过在每个指标仪表板上添加注释来标记任何重要事件. 在查看仪表板时,分配给所选时间范围的注释条目将自动获取并显示在该仪表板内的每个图表上. 鼠标悬停时,每个注释都会显示其他详细信息,包括事件的确切时间及其描述.
您可以通过向[Metrics 仪表板注释 API](../../../api/metrics_dashboard_annotations.html)发出请求来创建注释
[![Annotations UI](img/afe1906c0ba8e9c44277342a20a48db6.png)](../../../user/project/integrations/img/metrics_dashboard_annotations_ui_v13.0.png)
### Retention policy[](#retention-policy "Permalink")
在 GitLab 13.01 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/211433) .
为了避免过时的注释浪费过多的存储空间,每天都会删除附加到超过两周时间段的记录. 此重复后台作业在本地服务器时间上午 1:00 运行.
## Add related links to custom dashboards[](#add-related-links-to-custom-dashboards "Permalink")
在 GitLab 13.1 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/216385) .
You can embed links to other dashboards or external services in your custom dashboard by adding **相关链接** to your dashboard’s YAML file. Related links open in the same tab as the dashboard. Related links can be displayed in the following locations on your dashboard:
* 在仪表板顶部,作为顶层[`links`仪表板属性](../../../operations/metrics/dashboards/yaml.html#dashboard-top-level-properties) .
* 在图表中,上下文菜单作为[面板](../../../operations/metrics/dashboards/yaml.html#panel-panels-properties)[`links`属性](../../../operations/metrics/dashboards/yaml.html#panel-panels-properties) .
相关链接可以包含以下属性:
* `url` :链接的完整 URL. 需要.
* `title` :描述链接的短语. 可选的. 如果未设置此属性,则将完整的 URL 用于链接标题.
* `type` :一个声明链接类型的字符串. 可选的. 如果设置为`grafana` ,则仪表板的时间范围值将转换为 Grafana 的时间范围格式并附加到`url` .
仪表板的时间范围作为 URL 参数附加到`url` .
以下示例显示了添加到仪表板的两个相关链接( `GitLab.com``GitLab Documentation` ):
[![Links UI](img/fe601ff47f99f0fd5220742f61007450.png)](../../../user/project/integrations/img/related_links_v13_1.png)
### Links Syntax[](#links-syntax "Permalink")
```
links:
- title: GitLab.com
url: https://gitlab.com
- title: GitLab Documentation
url: https://docs.gitlab.com
- title: Public Grafana playground dashboard
url: https://play.grafana.org/d/000000012/grafana-play-home?orgId=1
type: grafana
```
## Defining custom dashboards per project[](#defining-custom-dashboards-per-project "Permalink")
在 GitLab 12.1 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/59974) .
默认情况下,所有项目都包含一个由 GitLab 定义的 Prometheus 仪表板,其中包括一些关键指标,但是您也可以定义自己的自定义仪表板.
您可以从头开始创建新文件,也可以复制 GitLab 定义的 Prometheus 仪表板.
**注意:**[自定义指标](../index.html#adding-custom-metrics)不同,以下[定义的指标](../index.html#adding-custom-metrics)不支持警报.
### Adding a new dashboard to your project[](#adding-a-new-dashboard-to-your-project "Permalink")
GitLab 13.2 中[引入的](https://gitlab.com/gitlab-org/gitlab/-/issues/223204) UI 选项.
您可以通过将新的 YAML 文件添加到项目的`.gitlab/dashboards/`目录中来配置自定义仪表`.gitlab/dashboards/` . 为了将仪表板显示在项目的 **在"操作">"度量标准"**页面上,文件必须具有`.yml`扩展名,并且应存在于项目的**默认**分支中.
要从 GitLab 用户界面创建新的仪表板,请执行以下操作:
1. 以具有"维护者"或"所有者" [权限](../../../user/permissions.html#project-members-permissions)的用户身份登录到 GitLab.
2. 导航至以下位置的信息中心 **操作>指标** .
3. 在信息中心的右上角,点击 **在"操作"**菜单上,然后选择" **新建"**[![使用创建新项目的](img/b24c623173b50fdf9cd2676f1f311580.png)](../../../user/project/integrations/img/actions_menu_create_new_dashboard_v13_2.png)
4. 在模式窗口中,单击**打开存储库** ,然后按照说明从命令行创建新的仪表板.
要从命令行创建新的仪表板:
1. 在存储库的根目录下创建`.gitlab/dashboards/prom_alerts.yml` . 每个 YAML 文件都应定义仪表板的布局以及用于填充数据的 Prometheus 查询. 此示例仪表板显示一个面积图:
```
dashboard: 'Dashboard Title'
panel_groups:
- group: 'Group Title'
panels:
- type: area-chart
title: "Chart Title"
y_label: "Y-Axis"
y_axis:
format: number
precision: 0
metrics:
- id: my_metric_id
query_range: 'http_requests_total'
label: "Instance: {{instance}}, method: {{method}}"
unit: "count"
```
2. 保存文件,提交并推送到您的存储库. 该文件必须存在于您的**默认**分支中.
3. 导航到项目的" **操作">"指标",**然后从下拉列表中选择自定义仪表板.
**注意:**不支持嵌套在`.gitlab/dashboards`子目录下的配置文件,并且在 UI 中将不可用.
### Navigating to a custom dashboard[](#navigating-to-a-custom-dashboard "Permalink")
自定义仪表板通过其文件名唯一标识. 为了快速查看自定义仪表板,只需通过以下方式在 URL 中使用仪表板文件名: `https://gitlab-instance.example.com/project/-/metrics/custom_dashboard_name.yml` : `https://gitlab-instance.example.com/project/-/metrics/custom_dashboard_name.yml` .
### Duplicating a GitLab-defined dashboard[](#duplicating-a-gitlab-defined-dashboard "Permalink")
版本历史
* 在 GitLab 12.7 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/37238) .
*[GitLab 12.8 开始](https://gitlab.com/gitlab-org/gitlab/-/issues/39505) ,自定义指标也将在您复制仪表板时被复制.
您可以保存 GitLab 定义的仪表板的完整副本以及添加到其中的所有自定义指标. 可以对生成的`.yml`文件进行自定义并使其适合您的项目. 您可以决定将仪表板`.yml`文件保存在项目的**默认**分支或新分支中.
1. 在仪表板下拉菜单或操作菜单中,单击**重复仪表**板.
**注意:**您只能复制 GitLab 定义的仪表板.
2. 输入文件名和其他信息,例如新提交的消息,然后单击**Duplicate** .
如果选择**默认**分支,新的仪表板将立即可用. 如果选择另一个分支,则应首先将此分支合并到**默认**分支.
## Troubleshooting[](#troubleshooting "Permalink")
对托管的 Prometheus 应用程序的问题进行故障排除时, [查看 Prometheus UI](../../../development/prometheus.html#access-the-ui-of-a-prometheus-managed-application-in-kubernetes)通常很有用.
### “No data found” error on Metrics dashboard page[](#no-data-found-error-on-metrics-dashboard-page "Permalink")
如果继续出现"找不到数据"屏幕,则可能是由于:
* 此环境尚未成功部署.
* Prometheus 没有此环境的性能数据,或者指标未正确标记. 要对此进行测试,请连接到 Prometheus 服务器并[运行查询](../../../user/project/integrations/prometheus_library/kubernetes.html#metrics-supported) ,将`$CI_ENVIRONMENT_SLUG`替换`$CI_ENVIRONMENT_SLUG`您的环境名称.
* 您可能需要重新添加 GitLab 预定义的通用指标. 这可以通过运行[导入公用度量 Rake 任务来完成](../../../administration/raketasks/maintenance.html#import-common-metrics) .
\ No newline at end of file
# Dashboard YAML properties
> 原文:[https://docs.gitlab.com/ee/operations/metrics/dashboards/yaml.html](https://docs.gitlab.com/ee/operations/metrics/dashboards/yaml.html)
* [**Dashboard (top-level) properties**](#dashboard-top-level-properties)
* [**Templating (`templating`) properties**](#templating-templating-properties)
* [**Links (`links`) properties**](#links-links-properties)
* [**Panel group (`panel_groups`) properties**](#panel-group-panel_groups-properties)
* [**Panel (`panels`) properties**](#panel-panels-properties)
* [**Axis (`panels[].y_axis`) properties**](#axis-panelsy_axis-properties)
* [**Metrics (`metrics`) properties**](#metrics-metrics-properties)
* [Dynamic labels](#dynamic-labels)
* [Dashboard YAML syntax validation](#dashboard-yaml-syntax-validation)
# Dashboard YAML properties[](#dashboard-yaml-properties "Permalink")
仪表板包含几个组件:
* 模板变量.
* 面板组,由面板组成.
* 支持一个或多个指标的面板.
下表概述了预期属性的详细信息.
## **Dashboard (top-level) properties**[](#dashboard-top-level-properties "Permalink")
| Property | Type | Required | Description |
| --- | --- | --- | --- |
| `dashboard` | string | yes | 前往仪表板. 每个文件只能定义一个仪表板. |
| `panel_groups` | array | yes | 应在仪表板上的面板组. |
| `templating` | hash | no | 可以在其下添加模板相关选项的顶级键. |
| `links` | array | no | 添加链接以显示在仪表板上. |
## **Templating (`templating`) properties**[](#templating-templating-properties "Permalink")
| Property | Type | Required | Description |
| --- | --- | --- | --- |
| `variables` | hash | yes | 可以在这里定义变量. |
阅读有关[模板](templating_variables.html)的文档.
## **Links (`links`) properties**[](#links-links-properties "Permalink")
| Property | Type | Required | Description |
| --- | --- | --- | --- |
| `url` | string | yes | 链接的地址. |
| `title` | string | no | 显示链接的标题. |
| `type` | string | no | 链接的类型. 指定链接类型,可以是: `grafana` |
阅读有关[链接](index.html#add-related-links-to-custom-dashboards)的文档.
## **Panel group (`panel_groups`) properties**[](#panel-group-panel_groups-properties "Permalink")
| Property | Type | Required | Description |
| --- | --- | --- | --- |
| `group` | string | required | 前往面板组. |
| `priority` | number | 可选,默认为按文件顺序 | 命令显示在仪表板上. 数字越高意味着优先级越高,该页面上的优先级越高. 数字不必是连续的. |
| `panels` | array | required | 应在面板组中的面板. |
面板组中的面板排成一排,每行包含两个面板. 该规则的一个例外是一行上的单个面板:这些面板将采用其所在行的整个宽度.
## **Panel (`panels`) properties**[](#panel-panels-properties "Permalink")
| Property | Type | Required | Description |
| --- | --- | --- | --- |
| `type` | enum | 不,默认为`area-chart` | 指定要使用的面板类型,例如`area-chart``line-chart``anomaly-chart` . [查看所有面板类型的文档.](panel_types.html) |
| `title` | string | yes | 前往面板. |
| `y_label` | string | 不,但强烈鼓励 | 面板的 Y 轴标签. |
| `y_axis` | string | no | 面板的 Y 轴配置. |
| `max_value` | number | no | 分母值用于计算[基于百分位数的结果](panel_types.html#percentile-based-results) |
| `weight` | number | 否,默认为按文件顺序 | 顺序出现在分组中. 较低的数字表示较高的优先级,在页面上较高. 数字不必是连续的. |
| `metrics` | array | yes | 应在面板中显示的指标. 当`type``area-chart``line-chart` ,可以显示任意数量的度量标准,而当`type``anomaly-chart`时,只能显示 3 个度量标准. |
| `links` | array | no | 添加链接以显示在图表的[上下文菜单上](index.html#chart-context-menu) . |
## **Axis (`panels[].y_axis`) properties**[](#axis-panelsy_axis-properties "Permalink")
| Property | Type | Required | Description |   |
| --- | --- | --- | --- | --- |
| `name` | string | 不,但强烈鼓励 | 面板的 Y 轴标签. 如果设置,则替换`y_label` . |   |
| `format` | string | 否,默认为`engineering` | 使用的单位格式. 请参阅[单位](yaml_number_format.html)[完整列表](yaml_number_format.html) . |   |
| `precision` | number | 否,默认为`2` | 要显示在数字中的小数位数. |   |
## **Metrics (`metrics`) properties**[](#metrics-metrics-properties "Permalink")
| Property | Type | Required | Description |
| --- | --- | --- | --- |
| `id` | string | no | 用于将仪表板指标与数据库记录相关联. 在仪表板配置文件中必须唯一. [警报所](../alerts.html)必需(尚未启用支持,请参阅[相关问题](https://gitlab.com/gitlab-org/gitlab/-/issues/27980) ). |
| `unit` | string | yes | 定义查询的返回数据的单位. |
| `label` | string | 不,但强烈鼓励 | 定义查询的图例标签. 在面板指标内应唯一. 可以包含时间序列标签作为内插变量. |
| `query` | string | 是,如果没有定义`query_range` | 定义用于填充图表/面板的 Prometheus 查询. 如果定义,将使用[Prometheus API](https://s0prometheus0io.icopy.site/docs/prometheus/latest/querying/api/)`query`端点. |
| `query_range` | string | 是,如果未定义`query` | 定义用于填充图表/面板的 Prometheus 查询. 如果定义,将使用[Prometheus API](https://s0prometheus0io.icopy.site/docs/prometheus/latest/querying/api/)`query_range`端点. |
| `step` | number | 不,如果未定义,则计算值 | 定义查询解析步长(以秒为单位). 同一面板上的指标应使用相同的`step`值. |
## Dynamic labels[](#dynamic-labels "Permalink")
从 Prometheus 查询返回多个时间序列时,动态标签很有用.
当使用静态标签并且查询返回多个时间序列时,所有图例项将被标记为相同,这使得识别每个时间序列变得困难:
```
metrics:
- id: my_metric_id
query_range: 'http_requests_total'
label: "Time Series"
unit: "count"
```
这可能会生成如下图例:
[![repeated legend label chart](img/366832d79f753b4e66470fa923fa7acf.png)](../../../user/project/integrations/img/prometheus_dashboard_repeated_label.png)
为了使标签更明确,使用反映时间序列标签的变量是一个好习惯. 渲染图例时,变量将被时间序列标签的值替换:
```
metrics:
- id: my_metric_id
query_range: 'http_requests_total'
label: "Instance: {{instance}}, method: {{method}}"
unit: "count"
```
生成的渲染图例将如下所示:
[![legend with label variables](img/ef26fe9cbbfc0c1f060c6e7c578bd450.png)](../../../user/project/integrations/img/prometheus_dashboard_label_variables.png)
动态仪表板标签还有一个简写值,该标签仅使用一个时间序列标签:
```
metrics:
- id: my_metric_id
query_range: 'http_requests_total'
label: "Method"
unit: "count"
```
这可以通过降低`label`的值来实现,如果还有更多的单词用空格分隔,请用下划线( `_` )替换这些空格. 然后根据 Prometheus 查询返回的时间序列的标签检查转换后的值. 如果找到与转换后的值相等的时间序列标签,则将使用标签值并将其呈现在图例中,如下所示:
[![legend with label shorthand variable](img/def845e9e4d65228469b73dbc625c6cd.png)](../../../user/project/integrations/img/prometheus_dashboard_label_variable_shorthand.png)
## Dashboard YAML syntax validation[](#dashboard-yaml-syntax-validation "Permalink")
在 GitLab 13.1 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33202) .
要确认您的仪表板定义包含有效的 YAML 语法,请执行以下操作:
1. 导航 **存储库>文件** .
2. 导航到存储库中的仪表板文件.
3. 查看文件内容上方显示的有关文件的信息窗格.
具有有效语法的文件显示**Metrics 仪表板 YAML 定义有效** ,而具有无效语法的文件显示**Metrics Dashboard YAML 定义无效** .
[![Metrics Dashboard_YAML_syntax_validation](img/5f3552f35a06cac8dfa02c21fd48c852.png)](../../../user/project/integrations/img/prometheus_dashboard_yaml_validation_v13_1.png)
当" **指标仪表板" YAML 定义无效时** ,将至少显示以下消息之一:
1. `dashboard: can't be blank` [learn more](../../../operations/metrics/dashboards/yaml.html#dashboard-top-level-properties)
2. `panel_groups: should be an array of panel_groups objects` [learn more](../../../operations/metrics/dashboards/yaml.html#dashboard-top-level-properties)
3. `group: can't be blank` [learn more](../../../operations/metrics/dashboards/yaml.html#panel-group-panel_groups-properties)
4. `panels: should be an array of panels objects` [learn more](../../../operations/metrics/dashboards/yaml.html#panel-group-panel_groups-properties)
5. `title: can't be blank` [learn more](../../../operations/metrics/dashboards/yaml.html#panel-panels-properties)
6. `metrics: should be an array of metrics objects` [learn more](../../../operations/metrics/dashboards/yaml.html#panel-panels-properties)
7. `query: can't be blank` [learn more](../../../operations/metrics/dashboards/yaml.html#metrics-metrics-properties)
8. `query_range: can't be blank` [learn more](../../../operations/metrics/dashboards/yaml.html#metrics-metrics-properties)
9. `unit: can't be blank` [learn more](../../../operations/metrics/dashboards/yaml.html#metrics-metrics-properties)
10. `YAML syntax: The parsed YAML is too big`
当 YAML 文件大于 1 MB 时显示.
11. `YAML syntax: Invalid configuration format`
当 YAML 文件为空或不包含有效的 YAML 时显示.
指标仪表板 YAML 定义验证信息也可以作为[GraphQL API 字段获得](../../../api/graphql/reference/index.html#metricsdashboard)
\ No newline at end of file
# Metrics dashboard settings
> 原文:[https://docs.gitlab.com/ee/user/project/operations/dashboard_settings.html](https://docs.gitlab.com/ee/user/project/operations/dashboard_settings.html)
* [Change the dashboard time zone](#change-the-dashboard-time-zone)
* [Link to an external dashboard](#link-to-an-external-dashboard)
# Metrics dashboard settings[](#metrics-dashboard-settings "Permalink")
您可以配置[监控仪表板](../integrations/prometheus.html)以显示您选择的时区以及您选择的链接.
要配置这些设置,您必须具有"管理项目操作" [权限](../../permissions.html) .
## Change the dashboard time zone[](#change-the-dashboard-time-zone "Permalink")
在 GitLab 13.1 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/214370) .
默认情况下,监视仪表板在本地时区中显示日期和时间,但是您可以 UTC 格式显示日期和时间. 更改时区:
1. 以具有"管理项目操作" [权限](../../permissions.html)的用户身份登录.
2. 导航 **设置>操作** ,然后滚动到" **指标仪表板"** .
3. 在" **仪表板时区"**选择框中,选择" *用户的本地时区"*或" *UTC"*
[![Dashboard timezone setting](img/9079254cc7f9fbc13ee5005765608b59.png)](img/dashboard_local_timezone_v13_1.png)
4. Click **保存更改**.
## Link to an external dashboard[](#link-to-an-external-dashboard "Permalink")
在 GitLab 12.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/57171) .
您可以在监视仪表板上添加一个按钮,该按钮直接链接到现有的外部仪表板:
1. 以具有"管理项目操作" [权限](../../permissions.html)的用户身份登录.
2. 导航 **设置>操作** ,然后滚动到" **指标仪表板"** .
3.**外部仪表板 URL 中** ,提供您的外部仪表板的 URL:
[![External Dashboard Setting](img/3da5d65194b00f9dc3ffde2ac5f8473b.png)](img/dashboard_external_link_v13_1.png)
4. Click **保存更改**.
GitLab 在[监视仪表板的](../../../ci/environments/index.html#monitoring-environments)右上角显示一个" **查看完整的仪表板"**按钮,该按钮可打开您提供的 URL:
[![External Dashboard Link](img/ddc1b7f5f622e5c8f6581738b42964cb.png)](img/external_dashboard_link.png)
\ No newline at end of file
# Panel types for dashboards
> 原文:[https://docs.gitlab.com/ee/operations/metrics/dashboards/panel_types.html](https://docs.gitlab.com/ee/operations/metrics/dashboards/panel_types.html)
* [Area or Line Chart](#area-or-line-chart)
* [Anomaly chart](#anomaly-chart)
* [Bar chart](#bar-chart)
* [Column chart](#column-chart)
* [Stacked column](#stacked-column)
* [Single Stat](#single-stat)
* [Percentile based results](#percentile-based-results)
* [Heatmaps](#heatmaps)
# Panel types for dashboards[](#panel-types-for-dashboards "Permalink")
监视仪表板中支持以下面板类型.
## Area or Line Chart[](#area-or-line-chart "Permalink")
要将面积图面板类型添加到仪表盘,请查看以下样本仪表盘文件:
```
dashboard: 'Dashboard Title'
panel_groups:
- group: 'Group Title'
panels:
- type: area-chart # or line-chart
title: 'Area Chart Title'
y_label: "Y-Axis"
y_axis:
format: number
precision: 0
metrics:
- id: area_http_requests_total
query_range: 'http_requests_total'
label: "Instance: {{instance}}, Method: {{method}}"
unit: "count"
```
请注意以下属性:
| Property | Type | Required | Description |
| --- | --- | --- | --- |
| type | string | no | 要渲染的面板类型. 区域面板类型的可选 |
| query_range | string | required | 对于区域面板类型,必须使用[范围查询](https://s0prometheus0io.icopy.site/docs/prometheus/latest/querying/api/) |
[![area panel chart](img/adf6de6d0c4125be4e7a25119c0193e1.png)](../../../user/project/integrations/img/prometheus_dashboard_area_panel_type_v12_8.png)
[版本 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/202696)开始,y 轴值将根据数据自动缩放. 以前,它总是从 0 开始.
## Anomaly chart[](#anomaly-chart "Permalink")
在 GitLab 12.5 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16530) .
要将异常图表面板类型添加到仪表盘,请添加*恰好具有* 3 个指标的面板.
第一个指标代表当前状态,第二个和第三个指标分别代表上限和下限:
```
dashboard: 'Dashboard Title'
panel_groups:
- group: 'Group Title'
panels:
- type: anomaly-chart
title: "Chart Title"
y_label: "Y-Axis"
metrics:
- id: anomaly_requests_normal
query_range: 'http_requests_total'
label: "# of Requests"
unit: "count"
metrics:
- id: anomaly_requests_upper_limit
query_range: 10000
label: "Max # of requests"
unit: "count"
metrics:
- id: anomaly_requests_lower_limit
query_range: 2000
label: "Min # of requests"
unit: "count"
```
请注意以下属性:
| Property | Type | Required | Description |
| --- | --- | --- | --- |
| type | string | required | 异常面板类型必须为`anomaly-chart` |
| query_range | yes | required | 对于异常面板类型,必须在每个指标中使用[范围查询](https://s0prometheus0io.icopy.site/docs/prometheus/latest/querying/api/) . |
[![anomaly panel type](img/8a4af39c416005af074623092e32d782.png)](../../../user/project/integrations/img/prometheus_dashboard_anomaly_panel_type.png)
## Bar chart[](#bar-chart "Permalink")
要将条形图添加到仪表板,请查看以下样本仪表板文件:
```
dashboard: 'Dashboard Title'
panel_groups:
- group: 'Group title'
panels:
- type: bar
title: "Http Handlers"
x_label: 'Response Size'
y_axis:
name: "Handlers"
metrics:
- id: prometheus_http_response_size_bytes_bucket
query_range: "sum(increase(prometheus_http_response_size_bytes_bucket[1d])) by (handler)"
unit: 'Bytes'
```
请注意以下属性:
| Property | Type | Required | Description |
| --- | --- | --- | --- |
| `type` | string | yes | 要渲染的面板类型. 对于条形图类型,设置为`bar` |
| `query_range` | yes | yes | 对于条形图,必须使用[范围查询](https://s0prometheus0io.icopy.site/docs/prometheus/latest/querying/api/) |
[![bar chart panel type](img/c61ac95a0fe55d92ab3c711ea814a8c8.png)](../../../user/project/integrations/img/prometheus_dashboard_bar_chart_panel_type_v12.10.png)
## Column chart[](#column-chart "Permalink")
要将列面板类型添加到仪表板,请查看以下样本仪表板文件:
```
dashboard: 'Dashboard Title'
panel_groups:
- group: 'Group title'
panels:
- title: "Column"
type: "column"
metrics:
- id: 1024_memory
query: 'avg(sum(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) by (job)) without (job) / count(avg(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) without (job)) /1024/1024'
unit: MB
label: "Memory Usage"
```
请注意以下属性:
| Property | Type | Required | Description |
| --- | --- | --- | --- |
| type | string | yes | 要渲染的面板类型. 对于列面板类型,设置为`column` |
| query_range | yes | yes | 对于列面板类型,必须使用[范围查询](https://s0prometheus0io.icopy.site/docs/prometheus/latest/querying/api/) |
[![anomaly panel type](img/468eb44e935f615292705e2fc013ddb7.png)](../../../user/project/integrations/img/prometheus_dashboard_column_panel_type.png)
## Stacked column[](#stacked-column "Permalink")
在 GitLab 12.8 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/30583) .
要将堆叠的列面板类型添加到仪表板,请查看以下样本仪表板文件:
```
dashboard: 'Dashboard title'
priority: 1
panel_groups:
- group: 'Group Title'
priority: 5
panels:
- type: 'stacked-column'
title: "Stacked column"
y_label: "y label"
x_label: 'x label'
metrics:
- id: memory_1
query_range: 'memory_query'
label: "memory query 1"
unit: "count"
series_name: 'group 1'
- id: memory_2
query_range: 'memory_query_2'
label: "memory query 2"
unit: "count"
series_name: 'group 2'
```
[![stacked column panel type](img/62313a9f27e05c60c700ec9625e27d02.png)](../../../user/project/integrations/img/prometheus_dashboard_stacked_column_panel_type_v12_8.png)
| Property | Type | Required | Description |
| --- | --- | --- | --- |
| `type` | string | yes | 要渲染的面板类型. 对于堆叠式柱面板类型,设置为" `stacked-column` |
| `query_range` | yes | yes | 对于堆叠式列面板类型,必须使用[范围查询](https://s0prometheus0io.icopy.site/docs/prometheus/latest/querying/api/) |
## Single Stat[](#single-stat "Permalink")
要将单个状态面板类型添加到仪表板,请查看以下样本仪表板文件:
```
dashboard: 'Dashboard Title'
panel_groups:
- group: 'Group Title'
panels:
- title: "Single Stat"
type: "single-stat"
metrics:
- id: 10
query: 'max(go_memstats_alloc_bytes{job="prometheus"})'
unit: MB
label: "Total"
```
请注意以下属性:
| Property | Type | Required | Description |
| --- | --- | --- | --- |
| type | string | yes | 要渲染的面板类型. 对于单一统计信息面板类型,设置为`single-stat` |
| field | string | no | 面板显示指标的值. 要使面板显示标签的值,请在该键中放置标签的名称. |
| query | string | yes | For single stat panel types, you must use an [instant query](https://s0prometheus0io.icopy.site/docs/prometheus/latest/querying/api/) |
[![single stat panel type](img/51902d01ed097ad499a4e6eb984d3e86.png)](../../../user/project/integrations/img/prometheus_dashboard_single_stat_panel_type.png)
## Percentile based results[](#percentile-based-results "Permalink")
在 GitLab 12.8 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/201946) .
有时需要将查询结果表示为 100 中的百分比值.您可以在面板定义的根部使用`max_value`属性:
```
dashboard: 'Dashboard Title'
panel_groups:
- group: 'Group Title'
panels:
- title: "Single Stat"
type: "single-stat"
max_value: 100
metrics:
- id: 10
query: 'max(go_memstats_alloc_bytes{job="prometheus"})'
unit: '%'
label: "Total"
```
例如,如果查询值为`53.6` ,则将`%`添加为单位将得出`53.6%`的单个统计值,但是如果查询的最大期望值为`120` ,则该值为`44.6%` . 添加`max_value`会导致显示正确的百分比值.
## Heatmaps[](#heatmaps "Permalink")
在 GitLab 12.5 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/30581) .
要将热图面板类型添加到仪表板,请查看以下样本仪表板文件:
```
dashboard: 'Dashboard Title'
panel_groups:
- group: 'Group Title'
panels:
- title: "Heatmap"
type: "heatmap"
metrics:
- id: 10
query: 'sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[60m])) by (status_code)'
unit: req/sec
label: "Status code"
```
请注意以下属性:
| Property | Type | Required | Description |
| --- | --- | --- | --- |
| type | string | yes | 要渲染的面板类型. 对于热图面板类型,设置为`heatmap` |
| query_range | yes | yes | 对于区域面板类型,必须使用[范围查询](https://s0prometheus0io.icopy.site/docs/prometheus/latest/querying/api/) |
[![heatmap panel type](img/10fd27d874d8e6ace6b74801909782ae.png)](../../../user/project/integrations/img/heatmap_panel_type.png)
**警告:**当查询返回太多数据点时,热图数据桶的尺寸趋于向下至 0,从而使图表的数据不可见,如下图所示. 要解决此问题,请通过更改指标仪表板 UI 上的时间范围过滤器,或将**step**属性添加到仪表板的 YAML 文件中,来限制返回的数据量.
[![heatmap chart_too_much_data](img/c89e56a24555efe89bb446cf31b5f764.png)](../../../user/project/integrations/img/heatmap_chart_too_much_data_v_13_2.png)
\ No newline at end of file
# Using Variables
> 原文:[https://docs.gitlab.com/ee/operations/metrics/dashboards/variables.html](https://docs.gitlab.com/ee/operations/metrics/dashboards/variables.html)
* [Query Variables](#query-variables)
* [Predefined variables](#predefined-variables)
* [__range](#__range)
* [User-defined variables](#user-defined-variables)
* [Query Variables from URL](#query-variables-from-url)
# Using Variables[](#using-variables "Permalink")
## Query Variables[](#query-variables "Permalink")
可以使用双花括号来指定变量,例如`"{{ci_environment_slug}}"` (在 GitLab 12.7 中已[添加](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20793) ).
在 GitLab 13.0 中[删除](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31581)了对`"%{ci_environment_slug}"`格式的支持. 继续使用旧格式的查询将不会显示任何数据.
## Predefined variables[](#predefined-variables "Permalink")
GitLab 在 Prometheus 查询中支持一组有限的[CI 变量](../../../ci/variables/README.html) . 这对于标识特定环境(例如`ci_environment_slug` )特别有用. 支持的变量是:
* `ci_environment_slug`
* `kube_namespace`
* `ci_project_name`
* `ci_project_namespace`
* `ci_project_path`
* `ci_environment_name`
* `__range`
**注意:** Prometheus 查询的变量必须小写.
### __range[](#__range "Permalink")
`__range`变量在 Prometheus [范围向量选择器中](https://s0prometheus0io.icopy.site/docs/prometheus/latest/querying/basics/)很有用. 它的值是仪表板时间范围内的总秒数. 例如,如果仪表板时间范围设置为 8 小时,则`__range`值为`28800s` .
## User-defined variables[](#user-defined-variables "Permalink")
[可以](../../../operations/metrics/dashboards/yaml.html#templating-templating-properties)在自定义仪表板 YAML 文件中[定义变量](../../../operations/metrics/dashboards/yaml.html#templating-templating-properties) .
## Query Variables from URL[](#query-variables-from-url "Permalink")
在 GitLab 13.0 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/214500) .
GitLab 支持通过 URL 参数设置自定义变量. 用双花括号( `{{example}}` )包围变量名称,以在查询中插入变量:
```
avg(sum(container_memory_usage_bytes{container_name!="{{pod}}"}) by (job)) without (job) /1024/1024/1024'
```
该查询的 URL 为:
```
http://gitlab.com/<user>/<project>/-/environments/<environment_id>/metrics?dashboard=.gitlab%2Fdashboards%2Fcustom.yml&pod=POD
```
\ No newline at end of file
# Templating variables for metrics dashboards
> 原文:[https://docs.gitlab.com/ee/operations/metrics/dashboards/templating_variables.html](https://docs.gitlab.com/ee/operations/metrics/dashboards/templating_variables.html)
* [`text` variable type](#text-variable-type)
* [Simple syntax](#simple-syntax)
* [Full syntax](#full-syntax)
* [`custom` variable type](#custom-variable-type)
* [Simple syntax](#simple-syntax-1)
* [Full syntax](#full-syntax-1)
* [`metric_label_values` variable type](#metric_label_values-variable-type)
* [Full syntax](#full-syntax-2)
# Templating variables for metrics dashboards[](#templating-variables-for-metrics-dashboards "Permalink")
在 GitLab 13.0 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/214539) .
模板变量可用于使指标仪表板更加通用.
`templating`[仪表板 YAML 中](yaml.html#dashboard-top-level-properties)的顶级键. 在`templating`下的`variables`键中定义变量. `variables`键的值应为哈希, `variables`下的每个键在仪表板上定义一个模板变量,并且可以包含字母数字和下划线字符.
可以使用[使用变量中](variables.html)所述的语法在同一仪表板的 Prometheus 查询[中使用变量](variables.html) .
## `text` variable type[](#text-variable-type "Permalink")
**警告:**此变量类型是*alpha*功能,如有更改,恕不另行通知!
对于仪表板 YAML 中定义的每个`text`变量,仪表板 UI 上都会有一个自由文本框,您可以为每个变量输入一个值.
`text`变量类型支持简单和完整的语法.
### Simple syntax[](#simple-syntax "Permalink")
本示例创建一个名为`variable1` ,其默认值为`default value`
```
templating:
variables:
variable1: 'default value' # `text` type variable with `default value` as its default.
```
### Full syntax[](#full-syntax "Permalink")
本示例创建一个名为`variable1` ,其默认值为`default` . UI 上文本框的标签将为`label`键的值:
```
templating:
variables:
variable1: # The variable name that can be used in queries.
label: 'Variable 1' # (Optional) label that will appear in the UI for this text box.
type: text
options:
default_value: 'default' # (Optional) default value.
```
## `custom` variable type[](#custom-variable-type "Permalink")
**警告:**此变量类型是*alpha*功能,如有更改,恕不另行通知!
仪表板 YAML 中定义的每个`custom`变量都会在仪表板 UI 上创建一个下拉选择器,允许您为每个变量选择一个值.
`custom`变量类型支持简单和完整的语法.
### Simple syntax[](#simple-syntax-1 "Permalink")
本示例创建一个名为`variable1` ,其默认值为`value1` . 仪表板界面将显示一个下拉列表,其中包含`value1``value2``value3`作为选择.
```
templating:
variables:
variable1: ['value1', 'value2', 'value3']
```
### Full syntax[](#full-syntax-1 "Permalink")
本示例创建一个名为`variable1` ,其默认值为`value_option_2` . UI 上文本框的标签将为`label`键的值. 仪表板界面将显示一个下拉列表,其中包含`Option 1``Option 2` .
如果从下拉列表中选择`Option 1` ,则变量将被替换为`value option 1` . 同样,如果选择`Option 2` ,则变量将替换为`value_option_2`
```
templating:
variables:
variable1: # The variable name that can be used in queries.
label: 'Variable 1' # (Optional) label that will appear in the UI for this dropdown.
type: custom
options:
values:
- value: 'value option 1' # The value that will replace the variable in queries.
text: 'Option 1' # (Optional) Text that will appear in the UI dropdown.
- value: 'value_option_2'
text: 'Option 2'
default: true # (Optional) This option should be the default value of this variable.
```
## `metric_label_values` variable type[](#metric_label_values-variable-type "Permalink")
**警告:**此变量类型是*alpha*功能,如有更改,恕不另行通知!
### Full syntax[](#full-syntax-2 "Permalink")
本示例创建一个名为`variable2` . 下拉列表的值将是`up{env="production"}`描述的 Prometheus 系列中`backend`标签的所有不同值.
```
templating:
variables:
variable2: # The variable name that can be interpolated in queries.
label: 'Variable 2' # (Optional) label that will appear in the UI for this dropdown.
type: metric_label_values
options:
series_selector: 'up{env="production"}'
label: 'backend'
```
\ No newline at end of file
# Prometheus Metrics library
> 原文:[https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/)
* [Exporters](#exporters)
* [Identifying Environments](#identifying-environments)
# Prometheus Metrics library[](#prometheus-metrics-library "Permalink")
在 GitLab 9.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8935) .
GitLab 可自动检测某些[Prometheus 出口商](https://s0prometheus0io.icopy.site/docs/instrumenting/exporters/) .
## Exporters[](#exporters "Permalink")
当前支持的出口商是:
* [Kubernetes](kubernetes.html)
* [NGINX](nginx.html)
* [NGINX Ingress Controller 0.9.0-0.15.x](nginx_ingress_vts.html)
* [NGINX Ingress Controller 0.16.0+](nginx_ingress.html)
* [HAProxy](haproxy.html)
* [Amazon Cloud Watch](cloudwatch.html)
我们已尝试为每个出口商展示最重要的指标,并将在以后的版本中继续增加对其他出口商的支持. 如果您想增加对其他官方出口商的支持,欢迎捐款.
## Identifying Environments[](#identifying-environments "Permalink")
GitLab 从已配置的 Prometheus 服务器检索性能数据,并尝试识别已知指标的存在. 一旦确定,GitLab 然后需要能够将数据映射到特定环境.
为了隔离并仅显示给定环境的相关指标,GitLab 需要一种方法来检测关联了哪些标签. 为此,GitLab 使用已定义的查询并填写特定于环境的变量. 通常,这涉及寻找[`$CI_ENVIRONMENT_SLUG`](../../../../ci/variables/README.html#predefined-environment-variables) ,但也可能包括其他信息,例如项目的 Kubernetes 命名空间. 每个搜索查询都在[导出器特定的文档中](#exporters)定义.
\ No newline at end of file
# Monitoring AWS Resources
> 原文:[https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/cloudwatch.html](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/cloudwatch.html)
* [Requirements](#requirements)
* [Metrics supported](#metrics-supported)
* [Configuring Prometheus to monitor for Cloudwatch metrics](#configuring-prometheus-to-monitor-for-cloudwatch-metrics)
* [Specifying the Environment label](#specifying-the-environment-label)
# Monitoring AWS Resources[](#monitoring-aws-resources "Permalink")
在 GitLab 9.4 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12621)
GitLab 支持从[Elastic Load Balancer](https://aws.amazon.com/elasticloadbalancing/)开始自动检测和监视 AWS 资源. 这是通过利用官方[Cloudwatch 导出程序提供的](https://github.com/prometheus/cloudwatch_exporter) ,该程序将[Cloudwatch 指标](https://aws.amazon.com/cloudwatch/)转换为 Prometheus 可读形式.
## Requirements[](#requirements "Permalink")
必须启用[Prometheus 服务](../prometheus.html) .
## Metrics supported[](#metrics-supported "Permalink")
| Name | Query |
| --- | --- |
| 吞吐量(要求/秒) | `sum(aws_elb_request_count_sum{%{environment_filter}}) / 60` |
| 延迟(毫秒) | `avg(aws_elb_latency_average{%{environment_filter}}) * 1000` |
| HTTP 错误率(%) | `sum(aws_elb_httpcode_backend_5_xx_sum{%{environment_filter}}) / sum(aws_elb_request_count_sum{%{environment_filter}})` |
## Configuring Prometheus to monitor for Cloudwatch metrics[](#configuring-prometheus-to-monitor-for-cloudwatch-metrics "Permalink")
要开始使用 Cloudwatch 监控,您应该安装和配置[Cloudwatch 导出程序](https://github.com/prometheus/cloudwatch_exporter) ,该程序可检索和解析指定的 Cloudwatch 指标并将其转换为 Prometheus 监控端点.
目前,唯一受支持的 AWS 资源是 Elastic Load Balancer,其 Cloudwatch 指标在[此处记录](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-cloudwatch-metrics.html) .
样品的 CloudWatch 导出配置文件,配置用于基本 AWS ELB 监测,是[可供下载](../samples/cloudwatch.yml) .
## Specifying the Environment label[](#specifying-the-environment-label "Permalink")
为了隔离并仅显示给定环境的相关指标,GitLab 需要一种方法来检测关联了哪些标签. 为此,GitLab 将[查找`environment`标签](index.html#identifying-environments) .
\ No newline at end of file
# Monitoring HAProxy
> 原文:[https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/haproxy.html](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/haproxy.html)
* [Requirements](#requirements)
* [Metrics supported](#metrics-supported)
* [Configuring Prometheus to monitor for HAProxy metrics](#configuring-prometheus-to-monitor-for-haproxy-metrics)
* [Specifying the Environment label](#specifying-the-environment-label)
# Monitoring HAProxy[](#monitoring-haproxy "Permalink")
在 GitLab 9.4 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12621)
GitLab 支持自动检测和监视 HAProxy. 这是通过利用[HAProxy Exporter](https://github.com/prometheus/haproxy_exporter)来提供的,后者将 HAProxy 统计信息转换为 Prometheus 可读形式.
## Requirements[](#requirements "Permalink")
必须启用[Prometheus 服务](../prometheus.html) .
## Metrics supported[](#metrics-supported "Permalink")
| Name | Query |
| --- | --- |
| 吞吐量(要求/秒) | `sum(rate(haproxy_frontend_http_requests_total{%{environment_filter}}[2m])) by (code)` |
| HTTP 错误率(%) | `sum(rate(haproxy_frontend_http_requests_total{code="5xx",%{environment_filter}}[2m])) / sum(rate(haproxy_frontend_http_requests_total{%{environment_filter}}[2m]))` |
## Configuring Prometheus to monitor for HAProxy metrics[](#configuring-prometheus-to-monitor-for-haproxy-metrics "Permalink")
要开始使用 NGINX 监视,您应该安装并配置[HAProxy 导出程序](https://github.com/prometheus/haproxy_exporter) ,该程序可以解析这些统计信息并将其转换为 Prometheus 监视端点.
## Specifying the Environment label[](#specifying-the-environment-label "Permalink")
为了隔离并仅显示给定环境的相关指标,GitLab 需要一种方法来检测关联了哪些标签. 为此,GitLab 将[查找`environment`标签](index.html#identifying-environments) .
\ No newline at end of file
# Monitoring Kubernetes
> 原文:[https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/kubernetes.html](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/kubernetes.html)
* [Requirements](#requirements)
* [Metrics supported](#metrics-supported)
* [Configuring Prometheus to monitor for Kubernetes metrics](#configuring-prometheus-to-monitor-for-kubernetes-metrics)
* [Specifying the Environment](#specifying-the-environment)
* [Displaying Canary metrics](#displaying-canary-metrics-premium)
* [Canary metrics supported](#canary-metrics-supported)
# Monitoring Kubernetes[](#monitoring-kubernetes "Permalink")
在 GitLab 9.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8935) .
GitLab 支持自动检测和监视 Kubernetes 指标.
## Requirements[](#requirements "Permalink")
必须启用[Prometheus](../prometheus.html)[Kubernetes](../kubernetes.html)集成服务.
## Metrics supported[](#metrics-supported "Permalink")
* 平均内存使用量(MB):
```
avg(sum(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) by (job)) without (job) / count(avg(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) without (job)) /1024/1024
```
* 平均 CPU 使用率(%):
```
avg(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}[15m])) by (job)) without (job) / count(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}[15m])) by (pod_name))
```
## Configuring Prometheus to monitor for Kubernetes metrics[](#configuring-prometheus-to-monitor-for-kubernetes-metrics "Permalink")
为了收集 Kubernetes 指标,需要将 Prometheus 部署到集群中并进行正确配置. GitLab 支持两种方法:
* GitLab [与 Kubernetes 集成](../../clusters/index.html) ,并且可以[将 Prometheus 部署到连接的集群中](../prometheus.html#managed-prometheus-on-kubernetes) . 它被自动配置为收集 Kubernetes 指标.
* 要配置自己的 Prometheus 服务器,可以遵循[Prometheus 文档](https://s0prometheus0io.icopy.site/docs/introduction/overview/) .
## Specifying the Environment[](#specifying-the-environment "Permalink")
为了隔离并仅显示给定环境的相关 CPU 和内存指标,GitLab 需要一种方法来检测其正在运行的容器. 由于这些指标是在容器级别跟踪的,因此传统的 Kubernetes 标签不可用.
相反, [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)[DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)名称应以[CI_ENVIRONMENT_SLUG 开头](../../../../ci/variables/README.html#predefined-environment-variables) . 如果需要,可以在其后跟一个`-`和其他内容. 例如, `review-homepage-5620p5`的部署名称将与`review/homepage`环境匹配.
## Displaying Canary metrics[](#displaying-canary-metrics-premium "Permalink")
[GitLab 10.2 中](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/15201)引入.
GitLab 还收集了针对[Canary 部署的](../../canary_deployments.html) Kubernetes 指标,从而可以轻松比较当前部署的版本和 Canary.
这些度量标准期望[Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)[DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)名称以`$CI_ENVIRONMENT_SLUG-canary`开头,以隔离 canary 度量标准.
### Canary metrics supported[](#canary-metrics-supported "Permalink")
* 平均内存使用量(MB)
```
avg(sum(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}) by (job)) without (job) / count(avg(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}) without (job)) /1024/1024
```
* 平均 CPU 使用率(%)
```
avg(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}[15m])) by (job)) without (job) / count(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}[15m])) by (pod_name))
```
\ No newline at end of file
# Monitoring NGINX
> 原文:[https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/nginx.html](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/nginx.html)
* [Requirements](#requirements)
* [Metrics supported](#metrics-supported)
* [Configuring Prometheus to monitor for NGINX metrics](#configuring-prometheus-to-monitor-for-nginx-metrics)
* [Specifying the Environment label](#specifying-the-environment-label)
# Monitoring NGINX[](#monitoring-nginx "Permalink")
在 GitLab 9.4 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12621)
GitLab 支持自动检测和监视 NGINX. 这是通过利用[NGINX VTS 导出器提供的](https://github.com/hnlq715/nginx-vts-exporter) ,该[导出](https://github.com/hnlq715/nginx-vts-exporter)器将[VTS 统计信息](https://github.com/vozlt/nginx-module-vts)转换为 Prometheus 可读形式.
## Requirements[](#requirements "Permalink")
必须启用[Prometheus 服务](../prometheus.html) .
## Metrics supported[](#metrics-supported "Permalink")
检测到 NGINX 服务器指标,该指标跟踪 NGINX 直接提供的页面和内容.
| Name | Query |
| --- | --- |
| 吞吐量(要求/秒) | `sum(rate(nginx_server_requests{server_zone!="*", server_zone!="_", %{environment_filter}}[2m])) by (code)` |
| 延迟(毫秒) | `avg(nginx_server_requestMsec{%{environment_filter}})` |
| HTTP 错误率(HTTP 错误/秒) | `sum(rate(nginx_server_requests{code="5xx", %{environment_filter}}[2m]))` |
| HTTP 错误(%) | `sum(rate(nginx_server_requests{code=~"5.*", host="*", %{environment_filter}}[2m])) / sum(rate(nginx_server_requests{code="total", host="*", %{environment_filter}}[2m])) * 100` |
## Configuring Prometheus to monitor for NGINX metrics[](#configuring-prometheus-to-monitor-for-nginx-metrics "Permalink")
要开始使用 NGINX 监视,您应该首先为 NGINX 服务器启用[VTS 统计](https://github.com/vozlt/nginx-module-vts)模块. 这将捕获并以 HTML 可读形式显示统计信息. 接下来,您应该安装并配置[NGINX VTS 导出器](https://github.com/hnlq715/nginx-vts-exporter) ,该[导出器](https://github.com/hnlq715/nginx-vts-exporter)将解析这些统计信息并将其转换为 Prometheus 监视端点.
如果您将 NGINX 用作 Kubernetes 入口,GitLab 将在 0.9.0 及更高版本中启用后[自动检测](nginx_ingress.html)指标.
## Specifying the Environment label[](#specifying-the-environment-label "Permalink")
为了隔离并仅显示给定环境的相关指标,GitLab 需要一种方法来检测关联了哪些标签. 为此,GitLab 将[查找`environment`标签](index.html#identifying-environments) .
\ No newline at end of file
# Monitoring NGINX Ingress Controller
> 原文:[https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/nginx_ingress.html](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/nginx_ingress.html)
* [Requirements](#requirements)
* [Metrics supported](#metrics-supported)
* [Configuring NGINX Ingress monitoring](#configuring-nginx-ingress-monitoring)
* [About managed NGINX Ingress deployments](#about-managed-nginx-ingress-deployments)
* [Manually setting up NGINX Ingress for Prometheus monitoring](#manually-setting-up-nginx-ingress-for-prometheus-monitoring)
* [Specifying the Environment label](#specifying-the-environment-label)
# Monitoring NGINX Ingress Controller[](#monitoring-nginx-ingress-controller "Permalink")
在 GitLab 11.7 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22133) .
**注意:** 0.16.0 之前的 NGINX Ingress 版本提供了一个随附的[VTS Prometheus 指标导出器](nginx_ingress_vts.html) ,该导出器导出的指标与内置指标不同.
GitLab 支持自动检测和监视 Kubernetes NGINX Ingress 控制器. 这是通过利用 Kubernetes NGINX Ingress 控制器[版本 0.16.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0160)及更高[版本随附](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0160)的内置 Prometheus 指标来提供的.
## Requirements[](#requirements "Permalink")
[Prometheus integration](../prometheus.html) must be active.
## Metrics supported[](#metrics-supported "Permalink")
| Name | Query |
| --- | --- |
| 吞吐量(要求/秒) | `sum(label_replace(rate(nginx_ingress_controller_requests{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m]), "status_code", "${1}xx", "status", "(.)..")) by (status_code)` |
| 延迟(毫秒) | `sum(rate(nginx_ingress_controller_ingress_upstream_latency_seconds_sum{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) / sum(rate(nginx_ingress_controller_ingress_upstream_latency_seconds_count{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) * 1000` |
| HTTP 错误率(%) | `sum(rate(nginx_ingress_controller_requests{status=~"5.*",namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) / sum(rate(nginx_ingress_controller_requests{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) * 100` |
## Configuring NGINX Ingress monitoring[](#configuring-nginx-ingress-monitoring "Permalink")
如果您已经使用 GitLab 的[Kubernetes 集群集成](../../clusters/index.html#installing-applications)部署了 NGINX Ingress,则 Prometheus 将[自动对其进行监视](#about-managed-nginx-ingress-deployments) .
对于其他部署,需要根据您的安装进行[一些配置](#manually-setting-up-nginx-ingress-for-prometheus-monitoring)
* NGINX Ingress 的版本应为 0.16.0 或更高,并启用指标.
* NGINX Ingress 应该标注为 Prometheus 监视.
* Prometheus 应该配置为监视带注释的容器.
### About managed NGINX Ingress deployments[](#about-managed-nginx-ingress-deployments "Permalink")
使用[官方 Helm 图表将](https://github.com/helm/charts/tree/master/stable/nginx-ingress) NGINX Ingress 部署到`gitlab-managed-apps`命名空间中. NGINX Ingress 将[通过 Load Balancer 的 Endpoint](../../../clusters/applications.html#ingress)[外部访问](../../../clusters/applications.html#ingress) .
通过设置以下内容,将 NGINX 配置为进行 Prometheus 监视:
* `enable-vts-status: "true"` ,以导出 Prometheus 指标.
* `prometheus.io/scrape: "true"` ,以启用自动发现.
* `prometheus.io/port: "10254"` ,以指定度量标准端口.
与 GitLab 部署的 Prometheus 服务结合使用时,将自动收集响应指标.
### Manually setting up NGINX Ingress for Prometheus monitoring[](#manually-setting-up-nginx-ingress-for-prometheus-monitoring "Permalink")
[NGINX Ingress 的](https://github.com/kubernetes/ingress-nginx) 0.9.0 及更高版本具有对导出 Prometheus 指标的内置支持. 要启用,必须传递 ConfigMap 设置: `enable-vts-status: "true"` . 启用后,Prometheus 指标端点将开始在端口 10254 上运行.
接下来,需要对 Ingress 进行注释,以进行 Prometheus 监视. 需要添加两个新的注释:
* `prometheus.io/scrape: "true"`
* `prometheus.io/port: "10254"`
管理这些设置取决于如何部署 NGINX Ingress. 如果您通过[官方 Helm 图表](https://github.com/helm/charts/tree/master/stable/nginx-ingress)进行了部署,则可以使用`controller.stats.enabled`以及所需的注释来启用指标. 另外,也可以直接在[Kubernetes 仪表板中](https://github.com/kubernetes/dashboard)编辑 NGINX Ingress YML.
## Specifying the Environment label[](#specifying-the-environment-label "Permalink")
为了隔离并仅显示给定环境的相关指标,GitLab 需要一种方法来检测关联了哪些标签. 为此,GitLab 将搜索带有适当标签的指标. 在这种情况下, `ingress`标签必须为`<CI_ENVIRONMENT_SLUG>` .
如果您使用[自动部署](../../../../topics/autodevops/stages.html#auto-deploy)来部署您的应用程序,则将自动使用此格式,并且无需您执行任何操作即可检测到指标.
\ No newline at end of file
# Monitoring NGINX Ingress Controller with VTS metrics
> 原文:[https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/nginx_ingress_vts.html](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/nginx_ingress_vts.html)
* [Requirements](#requirements)
* [Metrics supported](#metrics-supported)
* [Configuring NGINX Ingress monitoring](#configuring-nginx-ingress-monitoring)
* [About managed NGINX Ingress deployments](#about-managed-nginx-ingress-deployments)
* [Manually setting up NGINX Ingress for Prometheus monitoring](#manually-setting-up-nginx-ingress-for-prometheus-monitoring)
* [Specifying the Environment label](#specifying-the-environment-label)
# Monitoring NGINX Ingress Controller with VTS metrics[](#monitoring-nginx-ingress-controller-with-vts-metrics "Permalink")
在 GitLab 9.5 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/13438) .
**注意:** [NGINX Ingress 版本 0.16](nginx_ingress.html)及更高[版本](nginx_ingress.html)具有内置的 Prometheus 度量标准,该度量标准与基于 VTS 的度量标准不同.
GitLab 支持自动检测和监视 Kubernetes NGINX Ingress 控制器. 这是通过利用[版本 0.9.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#09-beta1)[0.15.x 中](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0150)随附的 VTS Prometheus 度量标准导出程序来[提供的](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0150) .
## Requirements[](#requirements "Permalink")
[Prometheus 集成](../prometheus.html)必须处于活动状态.
## Metrics supported[](#metrics-supported "Permalink")
| Name | Query |
| --- | --- |
| 吞吐量(要求/秒) | `sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) by (status_code)` |
| 延迟(毫秒) | `avg(nginx_upstream_response_msecs_avg{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"})` |
| HTTP 错误率(%) | `sum(rate(nginx_upstream_responses_total{status_code="5xx", upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) / sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) * 100` |
## Configuring NGINX Ingress monitoring[](#configuring-nginx-ingress-monitoring "Permalink")
如果您已经使用 GitLab 的[Kubernetes 集群集成](../../clusters/index.html#installing-applications)部署了 NGINX Ingress,则 Prometheus 将[自动对其进行监视](#about-managed-nginx-ingress-deployments) .
对于其他部署,需要根据您的安装进行[一些配置](#manually-setting-up-nginx-ingress-for-prometheus-monitoring)
* NGINX Ingress 的版本应为 0.9.0 或更高版本,并启用指标.
* NGINX Ingress 应该标注为 Prometheus 监视.
* Prometheus 应该配置为监视带注释的容器.
### About managed NGINX Ingress deployments[](#about-managed-nginx-ingress-deployments "Permalink")
NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer’s Endpoint](../../../clusters/applications.html#ingress).
通过设置以下内容,将 NGINX 配置为进行 Prometheus 监视:
* `enable-vts-status: "true"` ,以导出 Prometheus 指标.
* `prometheus.io/scrape: "true"` ,以启用自动发现.
* `prometheus.io/port: "10254"` ,以指定度量标准端口.
与 GitLab 部署的 Prometheus 服务结合使用时,将自动收集响应指标.
### Manually setting up NGINX Ingress for Prometheus monitoring[](#manually-setting-up-nginx-ingress-for-prometheus-monitoring "Permalink")
[NGINX Ingress 的](https://github.com/kubernetes/ingress-nginx) 0.9.0 及更高版本具有对导出 Prometheus 指标的内置支持. 要启用,必须传递 ConfigMap 设置: `enable-vts-status: "true"` . 启用后,Prometheus 指标端点将开始在端口 10254 上运行.
接下来,需要对 Ingress 进行注释,以进行 Prometheus 监视. 需要添加两个新的注释:
* `prometheus.io/scrape: "true"`
* `prometheus.io/port: "10254"`
管理这些设置取决于如何部署 NGINX Ingress. 如果您通过[官方 Helm 图表](https://github.com/helm/charts/tree/master/stable/nginx-ingress)进行了部署,则可以使用`controller.stats.enabled`以及所需的注释来启用指标. 或者,也可以直接在[Kubernetes 仪表板中](https://github.com/kubernetes/dashboard)编辑 NGINX Ingress YAML.
## Specifying the Environment label[](#specifying-the-environment-label "Permalink")
为了隔离并仅显示给定环境的相关指标,GitLab 需要一种方法来检测关联了哪些标签. 为此,GitLab 将搜索带有适当标签的指标. 在这种情况下, `upstream`标签的格式必须为`<KUBE_NAMESPACE>-<CI_ENVIRONMENT_SLUG>-*` .
如果您使用[自动部署](../../../../topics/autodevops/stages.html#auto-deploy)来部署您的应用程序,则将自动使用此格式,并且无需您执行任何操作即可检测到指标.
\ No newline at end of file
# Alert Management
> 原文:[https://docs.gitlab.com/ee/user/project/operations/alert_management.html](https://docs.gitlab.com/ee/user/project/operations/alert_management.html)
* [Enable Alert Management](#enable-alert-management)
* [Enable a Generic Alerts endpoint](#enable-a-generic-alerts-endpoint)
* [Enable GitLab-managed Prometheus alerts](#enable-gitlab-managed-prometheus-alerts)
* [Enable external Prometheus alerts](#enable-external-prometheus-alerts)
* [Alert Management severity](#alert-management-severity)
* [Alert Management list](#alert-management-list)
* [Alert Management list sorting](#alert-management-list-sorting)
* [Searching alerts](#searching-alerts)
* [Alert Management statuses](#alert-management-statuses)
* [Alert Management details](#alert-management-details)
* [Update an Alert’s status](#update-an-alerts-status)
* [Create an Issue from an Alert](#create-an-issue-from-an-alert)
* [Update an Alert’s assignee](#update-an-alerts-assignee)
* [Alert system notes](#alert-system-notes)
* [View an Alert’s metrics data](#view-an-alerts-metrics-data)
* [Use cases for assigning alerts](#use-cases-for-assigning-alerts)
* [Slack Notifications](#slack-notifications)
# Alert Management[](#alert-management "Permalink")
在 GitLab 13.0 中[引入](https://gitlab.com/groups/gitlab-org/-/epics/2877) .
警报管理使开发人员可以轻松发现和查看其应用程序生成的警报. 通过在开发代码的地方显示警报信息,可以提高效率和知名度.
## Enable Alert Management[](#enable-alert-management "Permalink")
**注意:**您至少需要维护者[权限](../../permissions.html)才能启用警报管理功能.
如下所述,有几种方法可以将警报接受到您的 GitLab 项目中. 启用任何这些方法将允许显示警报列表. 配置警报后,访问 您可以在项目的边栏中[查看](#alert-management-list) **操作>警报** ,以[查看](#alert-management-list)警报[列表](#alert-management-list) .
### Enable a Generic Alerts endpoint[](#enable-a-generic-alerts-endpoint "Permalink")
GitLab 提供了通用警报端点,因此您可以接受来自第三方警报服务的警报. 请参阅有关[切换常规警报](../integrations/generic_alerts.html#setting-up-generic-alerts)[说明](../integrations/generic_alerts.html#setting-up-generic-alerts)以添加此选项. 配置端点后,将启用" [警报"列表](#alert-management-list) .
要用数据填充警报,请参阅为警报端点的请求[自定义有效负载](../integrations/generic_alerts.html#customizing-the-payload) .
### Enable GitLab-managed Prometheus alerts[](#enable-gitlab-managed-prometheus-alerts "Permalink")
您可以在 Kubernetes 集群上安装 GitLab 管理的 Prometheus 应用程序. 有关更多信息,请参见[Kubernetes 上的 Managed Prometheus](../integrations/prometheus.html#managed-prometheus-on-kubernetes) . 安装了由 GitLab 管理的 Prometheus 时,也会启用[警报列表](#alert-management-list) .
要用数据填充警报,请参阅[GitLab 管理的 Prometheus 实例](../../../operations/metrics/index.html#managed-prometheus-instances) .
### Enable external Prometheus alerts[](#enable-external-prometheus-alerts "Permalink")
您可以配置外部管理的 Prometheus 实例,以将警报发送到 GitLab. 要设置此配置,请参阅[配置 Prometheus](../../../operations/metrics/index.html#external-prometheus-instances)文档. 激活外部 Prometheus 配置也会启用" [警报"列表](#alert-management-list) .
要用数据填充警报,请参阅[外部 Prometheus 实例](../../../operations/metrics/index.html#external-prometheus-instances) .
## Alert Management severity[](#alert-management-severity "Permalink")
警报的每个级别均包含一个形状和颜色编码独特的图标,以帮助您确定特定警报的严重性. 这些严重性图标可帮助您立即确定应优先调查的警报:
[![Alert Management Severity System](img/56eeecad0f9627fae21bc6b196391ba7.png)](img/alert_management_severity_v13_0.png)
警报包含以下图标之一:
| Severity | Icon | 颜色(十六进制) |
| --- | --- | --- |
| Critical | | `#8b2615` |
| High | | `#c0341d` |
| Medium | | `#fca429` |
| Low | | `#fdbc60` |
| Info | | `#418cd8` |
| Unknown | | `#bababa` |
## Alert Management list[](#alert-management-list "Permalink")
**注意:**您将至少需要具有开发人员[权限](../../permissions.html)才能查看警报管理列表.
您可以在以下位置找到警报管理列表 项目侧边栏中的**操作>警报** . 每个警报包含以下指标:
[![Alert Management List](img/c932281f198053757ebfaf5a9b99b335.png)](img/alert_list_v13_1.png)
* **严重性** -警报的当前重要性及其应受到的关注.
* **开始时间** -警报触发前多久. 此字段使用`X time ago`的标准 GitLab 模式,但细化的日期/时间工具提示支持此字段,具体取决于用户的语言环境.
* **警报说明** - The description of the alert, which attempts to capture the most meaningful data.
* **事件计数** -警报触发的次数.
* **问题** -指向为警报创建的事件问题的链接.
* **状态** -警报的[当前状态](#alert-management-statuses) .
### Alert Management list sorting[](#alert-management-list-sorting "Permalink")
在 GitLab 13.1 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/217745) .
警报管理列表显示按开始时间排序的警报,但是您可以通过单击警报管理列表中的标题来更改排序顺序.
要查看列是否可排序,请将鼠标指向标题. 可排序的列在列名旁边显示一个箭头,如以下示例所示:
[![Alert Management List Sorting](img/b46359f55df1f2affc4fe493965ebd0a.png)](img/alert_list_sort_v13_1.png)
### Searching alerts[](#searching-alerts "Permalink")
在 GitLab 13.1 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/213884) .
警报列表支持简单的自由文本搜索.
[![Alert List Search](img/cf0c5e15a3b44eb89d7513b961d6a274.png)](img/alert_list_search_v13_1.png)
此搜索过滤以下字段:
* Title
* Description
* 监控工具
* Service
### Alert Management statuses[](#alert-management-statuses "Permalink")
每个警报都包含一个状态下拉列表,以指示需要调查的警报. 标准警报状态包括已`triggered` ,已`acknowledged`和已`resolved`
* **触发** :没有人开始调查.
* **致谢** :有人正在积极调查问题.
* **解决** :不需要进一步的工作.
## Alert Management details[](#alert-management-details "Permalink")
**注意:**您至少需要具有开发人员[权限](../../permissions.html)才能查看警报管理详细信息.
通过访问[警报管理列表](#alert-management-list)并从列表中选择一个警报,导航到警报管理详细信息视图.
[![Alert Management Detail Overview](img/fd15df8f9a5a46582845610e8b5881bb.png)](img/alert_detail_overview_v13_1.png)
[![Alert Management Full Details](img/393dab24a6c8be1031a4cf469f3039e9.png)](img/alert_detail_full_v13_1.png)
### Update an Alert’s status[](#update-an-alerts-status "Permalink")
警报管理详细信息视图使您可以更新警报状态. 有关更多详细信息,请参见[警报管理状态](#alert-management-statuses) .
### Create an Issue from an Alert[](#create-an-issue-from-an-alert "Permalink")
在 GitLab 13.1 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/217745) .
警报管理详细信息视图使您可以创建问题,并使用从警报自动填充的描述来创建问题. 要创建问题,请单击**创建问题**按钮. 然后,您可以通过单击**查看问题**按钮从警报中**查看问题** .
关闭与警报相关的 GitLab 问题会将警报的状态更改为"已解决". 有关[状态](#alert-management-statuses)的更多详细信息,请参阅[警报管理](#alert-management-statuses)状态.
### Update an Alert’s assignee[](#update-an-alerts-assignee "Permalink")
在 GitLab 13.1 中[引入](https://gitlab.com/groups/gitlab-org/-/epics/3066) .
警报管理详细信息视图允许用户更新警报受让人.
在大型团队中,共享警报的所有权,可能很难跟踪谁在调查和处理警报. 警报管理详细信息视图使您可以更新警报受让人:
**注意:** manbetx 客户端打不开目前仅支持每个警报一个受让人.
1. 要显示当前警报列表,请单击 **操作>警报**
[![Alert Management List View Assignee(s)](img/2ae8145aa44498bcadafa3451ee343b1.png)](img/alert_list_assignees_v13_1.png)
2. 选择所需的警报以显示其**警报管理详细信息视图**
[![Alert Management Details View Assignee(s)](img/e80fdda43c295fbc39611b3d918d4b75.png)](img/alert_details_assignees_v13_1.png)
3. 如果右侧栏没有展开,请单击 **展开侧边栏**以展开它.
4. 在右侧栏中,找到**受让人** ,然后点击**编辑** . 从下拉菜单中,选择要分配给警报的每个用户. GitLab 为每个用户创建一个[待办事项列表项](../../todos.html) .
[![Alert Management Details View Assignee(s)](img/f7ae6b6be5d2dd02010825234555fee6.png)](img/alert_todo_assignees_v13_1.png)
要删除受让人,请单击" **受让人"**下拉菜单旁边的" **编辑"** ,然后从**受让人**列表中取消选择该用户,或单击" **未分配"** .
### Alert system notes[](#alert-system-notes "Permalink")
在 GitLab 13.1 中[引入](https://gitlab.com/groups/gitlab-org/-/epics/3066) .
当您对警报采取措施时,它会记录为系统注释,在"警报详细信息"视图中可见. 这为您提供了警报调查和分配历史的线性时间表.
以下操作将产生系统注释:
* [Updating the status of an alert](#update-an-alerts-status)
* [Creating an issue based on an alert](#create-an-issue-from-an-alert)
* [Assignment of an alert to a user](#update-an-alerts-assignee)
[![Alert Management Details View System Notes](img/b6f3d1302a444a29689905582d97eb84.png)](img/alert_detail_system_notes_v13_1.png)
### View an Alert’s metrics data[](#view-an-alerts-metrics-data "Permalink")
在 GitLab 13.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/217768) .
要查看警报的指标,请执行以下操作:
1. 以具有 Developer 或更高[权限](../../permissions.html)的用户身份登录.
2. 导航 **操作>警报** .
3. 单击您要查看的警报.
4. 在警报标题下,单击" **指标"**选项卡.
[![Alert Management Metrics View](img/ca33b4a75b3a1bc207dd2eddae8c3949.png)](img/alert_detail_metrics_v13_2.png)
For GitLab-managed Prometheus instances, metrics data is automatically available for the alert, making it easy to see surrounding behavior. See [Managed Prometheus instances](../../../operations/metrics/index.html#managed-prometheus-instances) for information on setting up alerts.
对于外部管理的 Prometheus 实例,您可以配置警报规则以在警报中显示图表. 有关如何正确配置警报规则的信息,请参阅[基于警报在事件问题中嵌入指标](../../../operations/metrics/embed.html#embedding-metrics-based-on-alerts-in-incident-issues) . 有关为自己管理的 Prometheus 实例设置警报的信息,请参阅[外部](../../../operations/metrics/index.html#external-prometheus-instances) Prometheus 实例.
## Use cases for assigning alerts[](#use-cases-for-assigning-alerts "Permalink")
考虑一个由监视的不同部分组成的团队,在单个应用程序上进行协作. 警报浮出水面之后,将警报发送给可以处理和解决警报的团队成员非常重要.
将警报分配给多个受让人可以简化协作和委派. 所有分配者都显示在团队的工作流程中,并且所有分配者都会收到通知,从而简化了警报的通信和所有权.
完成调查或修复警报的部分后,用户可以在角色完成后从警报中取消分配帐户. 可以更新[警报状态](#alert-management-statuses)以反映警报是否已解决.
### Slack Notifications[](#slack-notifications "Permalink")
在 GitLab 13.1 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/216326) .
当收到新的警报时,可以通过 Slack 消息向您发出警报.
有关如何进行设置的信息,请参阅[Slack Notifications Service 文档](../integrations/slack.html) .
\ No newline at end of file
# Error Tracking
> 原文:[https://docs.gitlab.com/ee/user/project/operations/error_tracking.html](https://docs.gitlab.com/ee/user/project/operations/error_tracking.html)
* [Sentry error tracking](#sentry-error-tracking)
* [Deploying Sentry](#deploying-sentry)
* [Enabling Sentry](#enabling-sentry)
* [Enabling GitLab issues links](#enabling-gitlab-issues-links)
* [Error Tracking List](#error-tracking-list)
* [Error Details](#error-details)
* [Taking Action on errors](#taking-action-on-errors)
* [Ignoring errors](#ignoring-errors)
* [Resolving errors](#resolving-errors)
# Error Tracking[](#error-tracking "Permalink")
在 GitLab 11.8 中[引入](https://gitlab.com/groups/gitlab-org/-/epics/169) .
错误跟踪使开发人员可以轻松发现和查看其应用程序可能产生的错误. 通过在开发代码的地方显示错误信息,可以提高效率和知名度.
## Sentry error tracking[](#sentry-error-tracking "Permalink")
[Sentry](https://sentry.io/)是一个开源错误跟踪系统. GitLab 允许管理员将 Sentry 连接到 GitLab,以允许用户查看 GitLab 中的 Sentry 错误列表.
### Deploying Sentry[](#deploying-sentry "Permalink")
您可以注册到托管在[https://sentry.io](https://sentry.io)上的云,部署自己[的本地实例](https://docs.sentry.io/server/installation/)或使用 GitLab [将 Sentry 安装到 Kubernetes 集群](../../clusters/applications.html#install-sentry-using-gitlab-cicd) .
### Enabling Sentry[](#enabling-sentry "Permalink")
**注意:**您至少需要维护者[权限](../../permissions.html)才能启用 Sentry 集成.
GitLab 提供了一种将 Sentry 连接到您的项目的简便方法:
1. 注册到 Sentry.io 或[部署您自己的](#deploying-sentry) Sentry 实例.
2. [创建](https://docs.sentry.io/guides/integrate-frontend/create-new-project/)一个新的 Sentry 项目. 对于您要集成的每个 GitLab 项目,我们建议您创建一个新的 Sentry 项目.
3. [查找或生成](https://docs.sentry.io/api/auth/)您的 Sentry 项目的 Sentry 身份验证令牌. 确保至少给令牌以下范围: `event:read``project:read` .
4. 导航到项目的**"设置">"操作"** .
5. 确保设置了**活动**复选框.
6.**Sentry API URL**字段中,输入您的 Sentry 主机名. 例如,如果这是您的 Sentry 实例可用的地址,请输入`https://sentry.example.com` . 对于 Sena 的 SaaS 版本,主机名将为`https://sentry.io` .
7. 在" **验证令牌"**字段中,输入您先前生成的令牌.
8. 单击" **连接"**按钮以测试与 Sentry 的连接并填充" **项目"**下拉列表.
9.**项目**下拉菜单中,选择一个 Sentry 项目以链接到您的 GitLab 项目.
10. 单击**保存更改**以使更改生效.
11. 现在,您可以在项目的侧栏中访问" **操作">"错误跟踪"** ,以[查看](#error-tracking-list) Sentry 错误[的列表](#error-tracking-list) .
### Enabling GitLab issues links[](#enabling-gitlab-issues-links "Permalink")
您可能还需要按照[Sentry 文档中](https://docs.sentry.io/workflow/integrations/global-integrations/#gitlab)的步骤来启用 Sentry 的 GitLab 集成.
## Error Tracking List[](#error-tracking-list "Permalink")
**注意:**您将至少需要 Reporter [权限](../../permissions.html)才能查看"错误跟踪"列表.
您可以在项目的边栏中的" **操作">"错误跟踪"**中找到"错误跟踪"列表. 在这里,您可以按标题或状态("已忽略","已解决"或"未解决"之一)过滤错误,并按"频率","首次看到"或"最后看到"的降序排列. 默认情况下,错误列表按"上次发现"排序,并过滤为"未解决的错误".
[![Error Tracking list](img/8375b8805ee35febb22389954e463cb3.png)](img/error_tracking_list_v12_6.png)
## Error Details[](#error-details "Permalink")
从错误列表中,用户可以通过单击任何错误的标题导航到错误详细信息页面.
该页面具有:
* 哨兵问题的链接.
* 如果 Sentry Issue 的第一个发行[](https://docs.sentry.io/workflow/releases/?platform=javascript#configure-sdk)的 Sentry [版本 ID /版本](https://docs.sentry.io/workflow/releases/?platform=javascript#configure-sdk)与您的 GitLab 托管项目中的提交 SHA 匹配,则指向 GitLab 提交的链接.
* 有关该问题的其他详细信息,包括完整的堆栈跟踪.
*[GitLab 12.7 及更高版本中](https://gitlab.com/gitlab-org/gitlab/-/issues/36246) ,显示语言和紧急度.
默认情况下,显示**创建问题**按钮:
[![Error Details without Issue Link](img/8d66587fae4dab1dca05f85389caa499.png)](img/error_details_v12_7.png)
如果您从错误中创建了一个 GitLab 问题,则" **创建问题"**按钮将变为" **查看问题"**按钮,并且指向 GitLab 问题的链接将出现在"错误详细信息"部分中:
[![Error Details with Issue Link](img/2fed535a429569e1ae792fb3960bcdd5.png)](img/error_details_with_issue_v12_8.png)
## Taking Action on errors[](#taking-action-on-errors "Permalink")
您可以从 GitLab UI 中对哨兵错误采取措施.
### Ignoring errors[](#ignoring-errors "Permalink")
在 GitLab 12.7 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/39665) .
在" [错误详细信息"](#error-details)页面中,只需单击页面顶部附近的" **忽略"**按钮,就可以忽略 Sentry 错误.
忽略错误将阻止它出现在" [错误跟踪列表"中](#error-tracking-list) ,并将使 Sentry 中设置的通知静音.
### Resolving errors[](#resolving-errors "Permalink")
在 GitLab 12.7 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/39825) .
在" [错误详细信息"](#error-details)页面中,您可以通过单击页面顶部附近的" **解决"**按钮来解决 Sentry 错误.
将错误标记为已解决表示错误已停止触发事件. 如果 GitLab 问题与错误相关联,则该问题将被关闭.
如果发生另一个事件,该错误将恢复为未解决.
\ No newline at end of file
# Tracing
> 原文:[https://docs.gitlab.com/ee/operations/tracing.html](https://docs.gitlab.com/ee/operations/tracing.html)
* [Jaeger tracing](#jaeger-tracing)
* [Deploying Jaeger](#deploying-jaeger)
* [Enabling Jaeger](#enabling-jaeger)
# Tracing[](#tracing-ultimate "Permalink")
在 GitLab Ultimate 11.5 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/7903) .
跟踪提供对已部署应用程序的性能和运行状况的洞察力,跟踪处理给定请求的每个功能或微服务.
不管您使用的是整体系统还是分布式系统,这都可以轻松理解请求的端到端流程.
## Jaeger tracing[](#jaeger-tracing "Permalink")
[Jaeger](https://www.jaegertracing.io/)是一个开源的,端到端的分布式跟踪系统,用于监视和调试基于微服务的分布式系统.
### Deploying Jaeger[](#deploying-jaeger "Permalink")
要了解有关部署 Jaeger 的更多信息,请阅读官方的《 [入门指南》文档](https://www.jaegertracing.io/docs/latest/getting-started/) . 有一个易于使用[的多合一 Docker 映像](https://www.jaegertracing.io/docs/latest/getting-started/#AllinoneDockerimage) ,以及[Kubernetes](https://github.com/jaegertracing/jaeger-kubernetes)[OpenShift 的](https://github.com/jaegertracing/jaeger-openshift)部署选项.
### Enabling Jaeger[](#enabling-jaeger "Permalink")
GitLab 提供了一种从项目内部打开 Jaeger UI 的简便方法:
1. 使用[客户端库](https://www.jaegertracing.io/docs/latest/client-libraries/)之一[设置 Jaeger](https://www.jaegertracing.io)并配置您的应用[程序](https://www.jaegertracing.io/docs/latest/client-libraries/) .
2. 导航到项目的**"设置">"操作",**然后提供 Jaeger URL.
3. 单击**保存更改**以使更改生效.
4. 现在,您可以在项目的侧边栏中访问" **操作">"跟踪"** ,GitLab 会将您重定向到已配置的 Jaeger URL.
\ No newline at end of file
# Incident Management
> 原文:[https://docs.gitlab.com/ee/user/incident_management/](https://docs.gitlab.com/ee/user/incident_management/)
* [Configure incidents](#configure-incidents-ultimate)
* [Notify developers of alerts](#notify-developers-of-alerts)
* [Configure PagerDuty integration](#configure-pagerduty-integration)
* [Configure Prometheus alerts](#configure-prometheus-alerts)
* [Configure external generic alerts](#configure-external-generic-alerts)
* [Embed metrics in incidents and issues](#embed-metrics-in-incidents-and-issues)
* [Context menu](#context-menu)
* [View logs from metrics panel](#view-logs-from-metrics-panel)
* [Integrate incidents with Slack](#integrate-incidents-with-slack)
* [Integrate issues with Zoom](#integrate-issues-with-zoom)
# Incident Management[](#incident-management "Permalink")
GitLab 提供了用于处理应用程序和服务中的事件的解决方案,例如设置 Prometheus 警报,显示指标和发送通知.
## Configure incidents[](#configure-incidents-ultimate "Permalink")
在 GitLab Ultimate 11.11 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/4925) .
您可以在 GitLab 用户界面中启用或禁用事件管理功能,以在触发警报时创建问题:
1. 导航 **设置>操作>事件,**然后展开**事件**
[![Incident Management Settings](img/f652f5dac5bec0bb81edc08cbfd7a01b.png)](img/incident_management_settings.png)
2. 对于 GitLab 11.11 及更高版本,您可以选中**创建问题**复选框以根据自己的[问题模板](../project/description_templates.html#creating-issue-templates)创建[问题](../project/description_templates.html#creating-issue-templates) . 有关更多信息,请参阅[从警报触发操作](../../operations/metrics/alerts.html#trigger-actions-from-alerts-ultimate) .
3. 要从警报中创建问题,请在" **问题模板"**选择框中选择**模板** .
4. 要向具有[开发者权限的](../permissions.html)用户发送[单独的电子邮件通知](#notify-developers-of-alerts) ,请选择" **向开发者发送单独的电子邮件通知"** .
5. Click **保存更改**.
适当配置的警报包括与警报相对应的查询的[嵌入式图表](../../operations/metrics/embed.html#embedding-metrics-based-on-alerts-in-incident-issues) . 您还可以将 GitLab 配置为在收到警报已解决的通知时[关闭问题](../../operations/metrics/alerts.html#trigger-actions-from-alerts-ultimate) .
### Notify developers of alerts[](#notify-developers-of-alerts "Permalink")
GitLab 可以通过创建问题并通过电子邮件提醒开发人员来应对您的应用程序和服务触发的警报. 默认情况下,GitLab 将这些电子邮件发送给项目的[所有者和维护者](../permissions.html) . 这些电子邮件包含警报的详细信息以及更多信息的链接.
要将单独的电子邮件通知发送给具有[开发者权限的](../permissions.html)用户,请参阅[配置事件](#configure-incidents-ultimate) .
## Configure PagerDuty integration[](#configure-pagerduty-integration "Permalink")
在 GitLab 13.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/119018) .
您可以使用 PagerDuty 设置一个 Webhook,以便为每个 PagerDuty 事件自动创建一个 GitLab 问题. 此配置要求您同时更改 PagerDuty 和 GitLab:
1. 以具有维护者[权限](../permissions.html)的用户身份登录.
2. 导航 **设置>操作>事件,**然后展开**事件** .
3. 选择**PagerDuty 集成**选项卡:
[![PagerDuty incidents integration](img/370ac43323901b08b905644b04f6a802.png)](img/pagerduty_incidents_integration_13_2.png)
4. 激活集成,并将更改保存在 GitLab 中.
5. 复制**Webhook URL**的值, **以**供以后使用.
6. 按照[PagerDuty 文档中](https://support.pagerduty.com/docs/webhooks)描述的步骤,将[Webhook](https://support.pagerduty.com/docs/webhooks) URL 添加到 PagerDuty Webhook 集成中.
为了确认集成成功,从 PagerDuty 触发一个测试事件以确认是否从该事件中创建了一个 GitLab 问题.
## Configure Prometheus alerts[](#configure-prometheus-alerts "Permalink")
您可以在以下位置设置 Prometheus 警报:
* [GitLab-managed Prometheus](../../operations/metrics/alerts.html) installations.
* [Self-managed Prometheus](../../operations/metrics/alerts.html#external-prometheus-instances) installations.
Prometheus 警报由特殊的警报机器人用户创建. 您无法删除此用户,但不计入您的许可限制.
## Configure external generic alerts[](#configure-external-generic-alerts "Permalink")
GitLab 可以通过通用的 Webhook 接收器接受来自任何来源的警报. 在[配置通用警报集成时](../project/integrations/generic_alerts.html) ,GitLab 会创建一个唯一的端点,该端点接收 JSON 格式的可自定义负载.
## Embed metrics in incidents and issues[](#embed-metrics-in-incidents-and-issues "Permalink")
您可以在使用[GitLab Markdown 的](../markdown.html)任何地方嵌入指标,例如描述,问题评论和合并请求. 嵌入指标可帮助您在讨论事件或性能问题时共享它们. 通过[将链接复制并粘贴到指标仪表盘](../../operations/metrics/embed.html#embedding-gitlab-managed-kubernetes-metrics) ,您可以将仪表盘直接输出到 GitLab 中的任何问题,合并请求,史诗或其他 Markdown 文本字段中.
您可以将[GitLab 托管的指标](../../operations/metrics/embed.html)[Grafana 指标](../../operations/metrics/embed_grafana.html)都嵌入事件和问题模板中.
### Context menu[](#context-menu "Permalink")
您可以从上下文菜单中查看有关嵌入式指标面板的更多详细信息. 要访问上下文菜单,请单击 面板右上角上方的**更多操作**下拉框. 选项包括:
* [View logs](#view-logs-from-metrics-panel).
* **下载 CSV-**嵌入式图表中的数据可以[CSV 格式下载](../../operations/metrics/dashboards/index.html#downloading-data-as-csv) .
#### View logs from metrics panel[](#view-logs-from-metrics-panel "Permalink")
版本历史
* 在 GitLab Ultimate 12.8 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/201846) .
* [移至](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25455) [GitLab Core](https://about.gitlab.com/pricing/) 12.9\.
如果您要对应用程序事件进行分类并需要[浏览](../../operations/metrics/dashboards/index.html#view-logs-ultimate)整个应用程序中的日志,则从指标面板查看日志可能会很有用. 这些日志可帮助您了解影响应用程序性能的因素并解决所有问题.
## Integrate incidents with Slack[](#integrate-incidents-with-slack "Permalink")
使用 Slack 斜杠命令,您可以控制 GitLab 并查看 GitLab 内容,而无需离开 Slack.
了解如何[设置 Slack 斜杠命令](../project/integrations/slack_slash_commands.html)以及如何[使用可用的斜杠命令](../../integration/slash_commands.html) .
## Integrate issues with Zoom[](#integrate-issues-with-zoom "Permalink")
通过 GitLab,您可以[将 Zoom 会议与](../project/issues/associate_zoom_meeting.html)事件[相关联,](../project/issues/associate_zoom_meeting.html)以便在事件管理期间进行同步通信. 在启动事件的 Zoom 呼叫后,您可以将电话会议与问题关联. 您的团队成员无需请求链接即可加入 Zoom 通话.
\ No newline at end of file
# GitLab Status Page
> 原文:[https://docs.gitlab.com/ee/user/project/status_page/](https://docs.gitlab.com/ee/user/project/status_page/)
* [How to set up](#how-to-set-up)
* [Cloud account set up](#cloud-account-set-up)
* [AWS Setup](#aws-setup)
* [Status Page project](#status-page-project)
* [Syncing incidents to the Status Page](#syncing-incidents-to-the-status-page)
* [Status Page UI](#status-page-ui)
* [Incident detail page](#incident-detail-page)
* [How it works](#how-it-works)
* [Publishing Incidents](#publishing-incidents)
* [Publishing updates](#publishing-updates)
* [Adding comments](#adding-comments)
* [Changing the Incident status](#changing-the-incident-status)
* [Attachment storage](#attachment-storage)
* [Limit](#limit)
# GitLab Status Page[](#gitlab-status-page-ultimate "Permalink")
[Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2479) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.10.
通过 GitLab 状态页面,您可以创建和部署静态网站,以便在事件发生时与用户进行有效沟通.
## How to set up[](#how-to-set-up "Permalink")
**注意:**仅支持将 AWS S3 作为部署目标.图 TB 子图 GitLab 实例问题(问题更新)-触发器->中间件(背景工作:JSON 生成)结束子图 Cloud Provider 中间件-保存数据-> c1(云桶存储 JSON 文件)结束子图状态页 d( CDN 上的静态站点)-获取数据-> C1 端
设置状态页面非常简单,但是您需要做一些事情.
### Cloud account set up[](#cloud-account-set-up "Permalink")
要使用 GitLab 状态页,您首先需要在操作设置页中为您的云提供商设置帐户详细信息. 今天,仅支持 AWS.
#### AWS Setup[](#aws-setup "Permalink")
1. 在您的 AWS acccout 中,创建两个新的 IAM 策略.
* [创建存储桶](https://gitlab.com/gitlab-org/status-page/-/blob/master/deploy/etc/s3_create_policy.json) .
* [更新存储桶内容](https://gitlab.com/gitlab-org/status-page/-/blob/master/deploy/etc/s3_update_bucket_policy.json) (请记住用您的存储桶名称替换`S3_BUCKET_NAME` ).
2. 使用第一步中创建的权限策略创建一个新的 AWS 访问密钥.
### Status Page project[](#status-page-project "Permalink")
要将状态页面部署到 AWS S3,您需要添加状态页面项目并配置必要的 CI 变量.
1. 分叉[状态页](https://gitlab.com/gitlab-org/status-page)项目. 这也可以通过" [存储库镜像"](https://gitlab.com/gitlab-org/status-page#repository-mirroring)来完成,这将确保您获得最新的"状态页"功能.
2.**设置> CI / CD>变量中**添加以下**变量** . (要从 Amazon 获取这些变量,请使用您的 Amazon Console):
* `S3_BUCKET_NAME` -Amazon S3 存储桶的名称(如果不存在具有提供名称的存储桶,则第一个管道运行将创建一个并为[静态网站托管](https://docs.aws.amazon.com/AmazonS3/latest/dev/HostingWebsiteOnS3Setup.html)配置它)
* `AWS_DEFAULT_REGION` -AWS 区域
* `AWS_ACCESS_KEY_ID` -AWS 访问密钥 ID
* `AWS_SECRET_ACCESS_KEY` -AWS 秘密
3. 运行管道以将状态页部署到 S3.
### Syncing incidents to the Status Page[](#syncing-incidents-to-the-status-page "Permalink")
设置 CI / CD 变量后,您需要设置要用于事件问题的项目:
1. 要查看" [操作设置"](../settings/#operations-settings)页面,请导航至 **设置>操作>状态页面** .
2. 填写您的云提供商的凭据,并确保已选中" **活动"**复选框.
3. Click **保存更改**.
## Status Page UI[](#status-page-ui "Permalink")
"状态页面"登录页面显示了最近事件的概述. 单击事件将带您到事件的详细信息页面.
[![Status Page landing page](img/d4a6279fcd73fa0a1dc68761261f4854.png)](../img/status_page_incidents_v12_10.png)
### Incident detail page[](#incident-detail-page "Permalink")
事件详细信息页面显示有关特定事件的详细信息. 例如:
* 事件的状态,包括事件的最新更新时间.
* 事件标题,包括所有表情符号.
* 事件描述,包括表情符号.
* 事件描述或注释中提供的带有有效图像扩展名的任何文件附件. 在 GitLab 13.1 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/205166) .
* 按时间顺序排列的事件更新列表.
[![Status Page detail](img/8f8d204a16e9c896b01a62220529b921.png)](../img/status_page_detail_v12_10.png)
## How it works[](#how-it-works "Permalink")
### Publishing Incidents[](#publishing-incidents "Permalink")
要发布事件,您首先需要在启用状态页设置的项目中创建一个问题.
默认情况下,问题不会发布到状态页面. 在问题中使用`/publish` [快速操作](../quick_actions.html)来发布问题. 仅[项目或小组所有者](../../permissions.html)可以发布问题.
使用快速操作后,后台工作人员将使用在安装过程中提供的凭据将问题发布到"状态页"上.
由于所有事件都是公开发布的,因此用户和组提及将由`Incident Responder`匿名,并且非公共[GitLab 参考的](../../markdown.html#special-gitlab-references)标题也将被删除.
When an Incident is published in the GitLab project, you can access the details page of the Incident by clicking the **在状态页上发布** button displayed under the Incident’s title.
[![Status Page detail link](img/3c9cb466046f19c70255f0de753a307c.png)](../img/status_page_detail_link_v13_1.png)
**注意:**机密性问题无法发布. 如果您将已发布的问题设为机密,则它将不会发布.
### Publishing updates[](#publishing-updates "Permalink")
要发布事件更新,请更新事件问题的描述.
**小心:**更改引用的问题(例如标题,机密性)时,引用的事件不会自动更新.
### Adding comments[](#adding-comments "Permalink")
要将评论添加到状态页事件中,请对事件问题创建评论.
准备发布评论时,请在评论中添加麦克风[奖表情符号](../../../user/award_emojis.html)反应( `:microphone` ). 这会将注释标记为应部署到状态页的注释.
**警告:**有权查看问题的任何人都可以在评论中添加表情符号奖,因此您可能希望将问题仅限于团队成员.
### Changing the Incident status[](#changing-the-incident-status "Permalink")
要将事件状态从`open`更改为`closed` ,请在 GitLab 中关闭事件问题. 然后将在状态页面网站上对此进行更新.
## Attachment storage[](#attachment-storage "Permalink")
在 GitLab 13.1 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/205166) .
从 GitLab 13.1 开始,作为[发布流程的](#how-it-works)一部分,附加到事件问题描述或注释的文件将被发布和未发布到状态页存储中.
### Limit[](#limit "Permalink")
每个问题仅 5000 个附件将被转移到状态页面.
\ No newline at end of file
# Feature Flags
> 原文:[https://docs.gitlab.com/ee/operations/feature_flags.html](https://docs.gitlab.com/ee/operations/feature_flags.html)
* [How it works](#how-it-works)
* [Create a feature flag](#create-a-feature-flag)
* [Rollout strategy (legacy)](#rollout-strategy-legacy)
* [Feature flag strategies](#feature-flag-strategies)
* [All users](#all-users)
* [Percent of Users](#percent-of-users)
* [User IDs](#user-ids)
* [User List](#user-list)
* [Enable or disable feature flag strategies](#enable-or-disable-feature-flag-strategies)
* [Disable a feature flag for a specific environment](#disable-a-feature-flag-for-a-specific-environment)
* [Disable a feature flag for all environments](#disable-a-feature-flag-for-all-environments)
* [Integrate feature flags with your application](#integrate-feature-flags-with-your-application)
* [Get access credentials](#get-access-credentials)
* [Choose a client library](#choose-a-client-library)
* [Feature flags API information](#feature-flags-api-information)
* [Golang application example](#golang-application-example)
* [Ruby application example](#ruby-application-example)
* [Feature Flag Related Issues](#feature-flag-related-issues)
* [Enable or disable Feature Flag Related Issues](#enable-or-disable-feature-flag-related-issues-core-only)
# Feature Flags[](#feature-flags-premium "Permalink")
在 GitLab 11.4 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/7433) .
借助功能标志,您可以将应用程序的新功能部署到较小的批量生产中. 您可以将功能打开或关闭到部分用户,以帮助您实现持续交付. 功能标记有助于降低风险,使您能够进行受控测试,并将功能交付与客户发布分开.
有关实际使用的功能标志的示例,请参阅[用于部署的 GitLab,功能标志和错误跟踪](https://www.youtube.com/embed/5tw2p6lwXxo) .
## How it works[](#how-it-works "Permalink")
GitLab 使用功能切换服务[Unleash](https://github.com/Unleash/unleash) .
通过在 GitLab 中启用或禁用标记,您的应用程序可以确定要启用或禁用的功能.
您可以在 GitLab 中创建功能标记,并使用应用程序中的 API 来获取功能标记及其状态的列表. 必须将应用程序配置为与 GitLab 进行通信,因此,开发人员可以使用兼容的客户端库并将[功能标记集成到您的应用程序中](#integrate-feature-flags-with-your-application) .
## Create a feature flag[](#create-a-feature-flag "Permalink")
要创建并启用功能标志:
1. 导航到项目的" **操作">"功能标志"** .
2. 单击**新功能标志**按钮.
3. 输入一个以字母开头的名称,该名称仅包含小写字母,数字,下划线( `_` )或破折号( `-` ),并且不以破折号( `-` )或下划线( `_` )结尾.
4. 输入描述(可选,最多 255 个字符).
5. Enter details about how the flag should be applied:
* 在 GitLab 13.0 和更早版本中,添加**Environment specs** . 对于每个环境,包括" **状态"** (默认启用)和" [**部署"策略**](#rollout-strategy-legacy) (默认为" **所有用户"** ).
* 在 GitLab 13.1 和更高版本中,添加 Feature Flag [**Strategies**](#feature-flag-strategies) . 对于每种策略,请包括" **类型"** (默认为" [**所有用户"**](#all-users) )和" **环境"** (默认为所有环境).
6. Click **创建功能标志**.
您可以通过单击 列表中任何功能标志旁边的(编辑)按钮.
## Rollout strategy (legacy)[](#rollout-strategy-legacy "Permalink")
在 GitLab 12.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/8240) .
在 GitLab 13.0 和更早版本中," **推出"策略**设置会影响哪些用户将启用该功能. 选择要启用该功能的用户百分比. 如果禁用环境规范,则推出策略将无效.
可以设置为:
* 全部用户
* [Percent of users](#percent-of-users)
* (可选)您可以单击" **包括其他用户 ID"**复选框,并添加特定用户 ID 列表以启用该功能.
* [User IDs](#user-ids)
## Feature flag strategies[](#feature-flag-strategies "Permalink")
版本历史
* 在 GitLab 13.0 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/35555) .
* 它部署在功能标记后面,默认情况下处于禁用状态.
* 在 GitLab.com 上启用了它.
* 要在 GitLab 自管实例中使用它,请让 GitLab 管理员[启用它](#enable-or-disable-feature-flag-strategies) .
您可以在多个环境中应用功能标记策略,而无需多次定义策略.
GitLab 功能标志使用[Unleash](https://unleash.github.io)作为功​​能标志引擎. 在"释放"中,有用于粒度特征标志控件的[策略](https://unleash.github.io/docs/activation_strategy) . GitLab 功能标志可以有多种策略,支持的策略有:
* [All users](#all-users)
* [Percent of Users](#percent-of-users)
* [User IDs](#user-ids)
* [User List](#user-list)
可以在[创建](#create-a-feature-flag)功能部件标记时将策略添加到功能部件标记,也可以在[创建](#create-a-feature-flag)后通过导航到" **操作">"功能部件标记"**并单击以编辑现有功能部件标记 (编辑).
### All users[](#all-users "Permalink")
为所有用户启用该功能. 它使用[`default`](https://unleash.github.io/docs/activation_strategy#default)释放激活策略.
### Percent of Users[](#percent-of-users "Permalink")
为一定百分比的已认证用户启用该功能. 它使用[`gradualRolloutUserId`](https://unleash.github.io/docs/activation_strategy#gradualrolloutuserid)释放激活策略.
例如,将值设置为 15%即可为 15%的经过身份验证的用户启用该功能.
推出百分比可以从 0%到 100%.
**注意:**对于已登录的用户,但对于匿名用户,保证了粘性(同一用户的一致应用程序行为).**警告:**如果选择此策略,则**必须**为 Unleash 客户端提供一个用户 ID,以启用该功能. 请参见下面的[Ruby 示例](#ruby-application-example) .
### User IDs[](#user-ids "Permalink")
在 GitLab 12.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/8240) . [更新](https://gitlab.com/gitlab-org/gitlab/-/issues/34363)为在 GitLab 12.6 中按环境定义.
为目标用户列表启用该功能. 它是使用 Unleash [`userWithId`](https://unleash.github.io/docs/activation_strategy#userwithid)激活策略实现的.
输入用户 ID 作为逗号分隔的值列表. 例如, `user@example.com, user2@example.com``username1,username2,username3`等.
**注意:**用户 ID 是您的应用程序用户的标识符. 他们不必是 GitLab 用户.**注意:** **必须**为 Unleash 客户端提供用户 ID,才能为目标用户启用该功能. 请参见下面的[Ruby 示例](#ruby-application-example) .
### User List[](#user-list "Permalink")
在 GitLab 13.1 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/35930) .
为使用[Feature Flag User List API](../api/feature_flag_user_lists.html)创建的[用户列表](../api/feature_flag_user_lists.html)启用功能. 与[用户 ID](#user-ids)相似,它使用 Unleash [`userWithId`](https://unleash.github.io/docs/activation_strategy#userwithid)激活策略.
### Enable or disable feature flag strategies[](#enable-or-disable-feature-flag-strategies "Permalink")
此功能正在开发中,但已准备好进行测试. 它部署在**默认情况下禁用**的功能标志的后面. [有权访问 GitLab Rails 控制台的 GitLab 管理员](../administration/feature_flags.html)可以为您的实例启用它.
要启用它:
```
Feature.enable(:feature_flags_new_version)
```
禁用它:
```
Feature.disable(:feature_flags_new_version)
```
## Disable a feature flag for a specific environment[](#disable-a-feature-flag-for-a-specific-environment "Permalink")
[GitLab 13.0 和更早版本中](https://gitlab.com/gitlab-org/gitlab/-/issues/8621) ,要为特定环境禁用功能标志:
1. 导航到项目的" **操作">"功能标志"** .
2. 对于要禁用的功能标志,请单击"铅笔"图标.
3. 禁用标志:
* 在 GitLab 13.0 和更低版本中:滑动环境的"状态"切换. 或者,要删除环境规范,请单击右侧的" **删除(X)"**图标.
* 在 GitLab 13.1 及更高版本:对于每一个战略,它适用于在**环境** ,删除环境.
4. Click **保存更改**.
## Disable a feature flag for all environments[](#disable-a-feature-flag-for-all-environments "Permalink")
禁用所有环境的功能标志:
1. 导航到项目的" **操作">"功能标志"** .
2. 对于要禁用的功能标志,请将状态切换滑动到**禁用** .
功能标志显示在" **禁用"**选项卡上.
## Integrate feature flags with your application[](#integrate-feature-flags-with-your-application "Permalink")
要在应用程序中使用功能标志,请从 GitLab 获取访问凭据. 然后使用客户端库准备您的应用程序.
### Get access credentials[](#get-access-credentials "Permalink")
要获取您的应用程序需要与 GitLab 通信的访问凭据:
1. 导航到项目的" **操作">"功能标志"** .
2. 单击**配置**按钮以查看以下内容:
* **API URL** :客户端(应用程序)连接以获取功能标志列表的 URL.
* **实例 ID** :授权检索功能标志的唯一令牌.
* **应用程序名称** :运行环境的名称. 例如,如果应用程序为生产服务器运行,则应用程序名称将为`production`或类似名称. 该值用于环境规格评估.
**注意:**这些字段的含义可能会随着时间而改变. 例如,我们不确定**实例 ID**是分配给**Environment 的**是单个令牌还是多个令牌. 另外, **应用程序名称**可以描述应用程序的版本,而不是运行环境.
### Choose a client library[](#choose-a-client-library "Permalink")
GitLab 实现与 Unleash 客户端兼容的单个后端.
使用 Unleash 客户端,开发人员可以在应用程序代码中定义标志的默认值. 如果提供的配置文件中不存在该标志,则每个功能标志评估都可以表达所需的结果.
目前,Unleash [提供了许多用于各种语言和框架的 SDK](https://github.com/Unleash/unleash#client-implementations) .
### Feature flags API information[](#feature-flags-api-information "Permalink")
有关 API 的内容,请参见:
* [Feature Flags API](../api/feature_flags.html)
* [功能标志规范 API](../api/feature_flag_specs.html) (已[在 GitLab 14.0 中](https://gitlab.com/gitlab-org/gitlab/-/issues/213369)弃用并[计划将其删除](https://gitlab.com/gitlab-org/gitlab/-/issues/213369) .)
* [Feature Flag User Lists API](../api/feature_flag_user_lists.html)
* [Legacy Feature Flags API](../api/feature_flags_legacy.html)
### Golang application example[](#golang-application-example "Permalink")
这是一个如何在 Golang 应用程序中集成特征标记的示例:
```
package main
import (
"io"
"log"
"net/http"
"github.com/Unleash/unleash-client-go"
)
type metricsInterface struct {
}
func init() {
unleash.Initialize(
unleash.WithUrl("https://gitlab.com/api/v4/feature_flags/unleash/42"),
unleash.WithInstanceId("29QmjsW6KngPR5JNPMWx"),
unleash.WithAppName("production"),
unleash.WithListener(&metricsInterface{}),
)
}
func helloServer(w http.ResponseWriter, req *http.Request) {
if unleash.IsEnabled("my_feature_name") {
io.WriteString(w, "Feature enabled\n")
} else {
io.WriteString(w, "hello, world!\n")
}
}
func main() {
http.HandleFunc("/", helloServer)
log.Fatal(http.ListenAndServe(":8080", nil))
}
```
### Ruby application example[](#ruby-application-example "Permalink")
这是一个如何在 Ruby 应用程序中集成功能标记的示例.
为 Unleash 客户端提供了一个用户 ID,以与" **百分比"卷展栏(已登录用户)卷**展策略或" **目标用户"**列表一起使用.
```
#!/usr/bin/env ruby
require 'unleash'
require 'unleash/context'
unleash = Unleash::Client.new({
url: 'http://gitlab.com/api/v4/feature_flags/unleash/42',
app_name: 'production',
instance_id: '29QmjsW6KngPR5JNPMWx'
})
unleash_context = Unleash::Context.new
# Replace "123" with the id of an authenticated user.
# Note that the context's user id must be a string:
# https://unleash.github.io/docs/unleash_context
unleash_context.user_id = "123"
if unleash.is_enabled?("my_feature_name", unleash_context)
puts "Feature enabled"
else
puts "hello, world!"
end
```
## Feature Flag Related Issues[](#feature-flag-related-issues "Permalink")
版本历史
* 在 GitLab 13.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36617) .
* 它部署在默认情况下启用的功能标志后面.
* 在 GitLab.com 上启用了它.
* 不能根据项目启用或禁用它
* 建议用于生产.
* 对于 GitLab 自我管理的实例,GitLab 管理员可以选择禁用它.
您可以将相关问题链接到功能标志. 在" **链接的问题"**部分中,单击`+`按钮,然后输入问题参考编号或问题的完整 URL.
此功能类似于[相关问题](../user/project/issues/related_issues.html)功能.
### Enable or disable Feature Flag Related Issues[](#enable-or-disable-feature-flag-related-issues-core-only "Permalink")
与功能标记相关​​的问题正在开发中,但已准备好用于生产. 它部署在**默认情况下启用**的功能标志的后面. [有权访问 GitLab Rails 控制台的 GitLab 管理员](../administration/feature_flags.html)可以选择为您的实例禁用它.
禁用它:
```
Feature.disable(:feature_flags_issue_links)
```
To enable it:
```
Feature.enable(:feature_flags_issue_links)
```
\ No newline at end of file
# GitLab CI/CD
> 原文:[https://docs.gitlab.com/ee/ci/README.html](https://docs.gitlab.com/ee/ci/README.html)
* [Overview](#overview)
* [Getting started](#getting-started)
* [Concepts](#concepts)
* [Configuration](#configuration)
* [Feature set](#feature-set)
* [Examples](#examples)
* [Administration](#administration-core-only)
* [References](#references)
* [Why GitLab CI/CD?](#why-gitlab-cicd)
* [Breaking changes](#breaking-changes)
* [13.0](#130)
* [12.0](#120)
* [11.0](#110)
* [10.0](#100)
* [9.0](#90)
# GitLab CI/CD[](#gitlab-cicd "Permalink")
GitLab CI / CD 是 GitLab 内置的工具,用于通过[连续方法](introduction/index.html#introduction-to-cicd-methodologies)进行软件开发:
* 持续集成(CI)
* 连续交付(CD)
* 持续部署(CD)
**注意:**开箱即用的管理系统可以将维护工具链所花费的时间减少 10%或更多. 观看我们的["精通持续软件开发"](https://about.gitlab.com/webcast/mastering-ci-cd/)网络广播,以了解连续方法以及 GitLab 的内置 CI 如何帮助您简化和扩展软件开发.
## Overview[](#overview "Permalink")
持续集成的工作原理是将小的代码块推送到 Git 存储库中托管的应用程序代码库中,并且每次推送时,都要运行脚本管道来构建,测试和验证代码更改,然后再将其合并到主分支中.
持续交付和部署包括进一步的 CI,可在每次推送到存储库默认分支时将应用程序部署到生产环境.
这些方法使您可以在开发周期的早期发现错误和错误,从而确保部署到生产环境的所有代码均符合为应用程序建立的代码标准.
有关这些方法和 GitLab CI / CD 的完整概述,请阅读 GitLab 的 CI / CD [简介](introduction/index.html) .
GitLab CI / CD 的视频演示: [演示:](https://www.youtube.com/watch?v=1iXFbchozdY) GitLab 的 CI / CD.
<figure class="video-container"><iframe src="https://www.youtube.com/embed/1iXFbchozdY" frameborder="0" allowfullscreen=""></iframe></figure>
## Getting started[](#getting-started "Permalink")
GitLab CI / CD 由位于存储库根目录的名为`.gitlab-ci.yml`的文件配置. 该文件创建[管道](pipelines/index.html) ,该[管道](pipelines/index.html)运行以更改存储库中的代码. 管道包含一个或多个顺序运行的阶段,每个阶段可以包含一个或多个并行运行的作业. 这些作业(或脚本)由[GitLab Runner](https://docs.gitlab.com/runner/)代理执行.
要开始使用 GitLab CI / CD,我们建议您通读以下文档:
* [How GitLab CI/CD works](introduction/index.html#how-gitlab-cicd-works).
* [Fundamental pipeline architectures](pipelines/pipeline_architectures.html).
* [GitLab CI/CD basic workflow](introduction/index.html#basic-cicd-workflow).
* [Step-by-step guide for writing `.gitlab-ci.yml` for the first time](../user/project/pages/getting_started/pages_from_scratch.html).
如果您要从其他 CI / CD 工具迁移,请查看我们方便的参考资料:
* [Migrating from CircleCI](migration/circleci.html)
* [Migrating from Jenkins](jenkins/index.html)
您也可以使用 UI 中提供的[`.gitlab-ci.yml`模板](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/lib/gitlab/ci/templates)之一来开始使用. 您可以通过创建新文件,选择适合您的应用程序的模板并根据需要进行调整来使用它们:
[![Use a `.gitlab-ci.yml` template](img/e006fccde54b694d8c0f506a675942e0.png)](img/add_file_template_11_10.png)
有关更广泛的概述,请参阅《 [CI / CD 入门](quick_start/README.html)指南》.
熟悉 GitLab CI / CD 的工作原理后,请参阅[`.gitlab-ci.yml`完整参考,](yaml/README.html)以获取可以设置和使用的所有属性.
**注意:** GitLab CI / CD 和[共享运行](runners/README.html#shared-runners)器在 GitLab.com 中启用,并且对所有用户可用,仅限于[用户的管道配额](../user/gitlab_com/index.html#shared-runners) .
## Concepts[](#concepts "Permalink")
GitLab CI / CD 使用许多概念来描述和运行您的构建和部署.
| Concept | Description |
| --- | --- |
| [Pipelines](pipelines/index.html) | Structure your CI/CD process through pipelines. |
| [Environment variables](variables/README.html) | 根据变量/值键对重用值. |
| [Environments](environments/index.html) | 将您的应用程序部署到不同的环境(例如,登台,生产). |
| [Job artifacts](pipelines/job_artifacts.html) | 输出,使用和重用作业工件. |
| [Cache dependencies](caching/index.html) | 缓存您的依赖项以加快执行速度. |
| [GitLab Runner](https://docs.gitlab.com/runner/) | 配置自己的 GitLab 运行程序以执行脚本. |
## Configuration[](#configuration "Permalink")
GitLab CI / CD 支持多种配置选项:
| Configuration | Description |
| --- | --- |
| [Schedule pipelines](pipelines/schedules.html) | 计划管道以根据需要运行. |
| [Custom path for `.gitlab-ci.yml`](pipelines/settings.html#custom-ci-configuration-path) | 为 CI / CD 配置文件定义自定义路径. |
| [Git submodules for CI/CD](git_submodules.html) | 配置作业以使用 Git 子模块. |
| [SSH keys for CI/CD](ssh_keys/README.html) | 在 CI 管道中使用 SSH 密钥. |
| [Pipeline triggers](triggers/README.html) | 通过 API 触发管道. |
| [Pipelines for Merge Requests](merge_request_pipelines/index.html) | 设计用于在合并请求中运行管道的管道结构. |
| [Integrate with Kubernetes clusters](../user/project/clusters/index.html) | 将您的项目连接到 Google Kubernetes Engine(GKE)或现有的 Kubernetes 集群. |
| [Optimize GitLab and Runner for large repositories](large_repositories/index.html) | 处理大型存储库的推荐策略. |
| [`.gitlab-ci.yml` full reference](yaml/README.html) | 您可以在 GitLab CI / CD 中使用的所有属性. |
请注意,某些操作只能根据[用户](../user/permissions.html#gitlab-cicd-permissions)[作业](../user/permissions.html#job-permissions)权限执行.
## Feature set[](#feature-set "Permalink")
使用庞大的 GitLab CI / CD 可以轻松地针对特定目的进行配置. 根据 DevOps 阶段,其功能集在下表中列出.
| Feature | Description |
| --- | --- |
| **Configure** |   |
| [Auto DevOps](../topics/autodevops/index.html) | 设置应用的整个生命周期. |
| [ChatOps](chatops/README.html) | 从聊天中触发 CI 作业,并将结果发送回通道. |
| **Verify** |   |
| [Browser Performance Testing](../user/project/merge_requests/browser_performance_testing.html) | 快速确定即将发生的代码更改对浏览器性能的影响. |
| [Load Performance Testing](../user/project/merge_requests/load_performance_testing.html) | 快速确定未决代码更改对服务器性能的影响. |
| [CI services](services/README.html) | 将 Docker 容器与您的基本映像链接起来. |
| [Code Quality](../user/project/merge_requests/code_quality.html) | 分析您的源代码质量. |
| [GitLab CI/CD for external repositories](ci_cd_for_external_repos/index.html) | 结合使用 GitHub 和 Bitbucket Cloud 中的存储库,获得 GitLab CI / CD 的优势. |
| [Interactive Web Terminals](interactive_web_terminal/index.html) | 打开一个交互式 Web 终端以调试正在运行的作业. |
| [JUnit tests](junit_test_reports.html) | 直接在合并请求中识别脚本失败. |
| [Using Docker images](docker/using_docker_images.html) | 将 GitLab 和 GitLab Runner 与 Docker 结合使用来构建和测试应用程序. |
| **Release** |   |
| [Auto Deploy](../topics/autodevops/stages.html#auto-deploy) | 将您的应用程序部署到 Kubernetes 集群中的生产环境. |
| [Building Docker images](docker/using_docker_build.html) | 使用 GitLab CI / CD 维护基于 Docker 的项目. |
| [Canary Deployments](../user/project/canary_deployments.html) | 仅将功能部件运送到一部分吊舱中,并让一定比例的用户群访问临时部署的功能部件. |
| [Deploy Boards](../user/project/deploy_boards.html) | 检查 Kubernetes 上运行的每个 CI / CD 环境的当前运行状况和状态. |
| [Feature Flags](../operations/feature_flags.html) | 在功能标记后部署功能. |
| [GitLab Pages](../user/project/pages/index.html) | 部署静态网站. |
| [GitLab Releases](../user/project/releases/index.html) | 将发行说明添加到 Git 标签. |
| [Review Apps](review_apps/index.html) | 配置 GitLab CI / CD 预览代码更改. |
| [Cloud deployment](cloud_deployment/index.html) | 将您的应用程序部署到主要的云提供商. |
| **Secure** |   |
| [Container Scanning](../user/application_security/container_scanning/index.html) | 检查您的 Docker 容器是否存在已知漏洞. |
| [Dependency Scanning](../user/application_security/dependency_scanning/index.html) | 分析您的依赖项是否存在已知漏洞. |
| [License Compliance](../user/compliance/license_compliance/index.html) | 在项目依赖项中搜索其许可证. |
| [Security Test reports](../user/application_security/index.html) | 检查应用程序漏洞. |
## Examples[](#examples "Permalink")
在" [CI 实例"](examples/README.html)页面上查找示例项目代码和教程,以将 GitLab CI / CD 与各种应用程序框架,语言和平台结合使用.
GitLab 还提供了[示例项目,这些项目已](https://gitlab.com/gitlab-examples)预先配置为使用 GitLab CI / CD.
## Administration[](#administration-core-only "Permalink")
作为 GitLab 管理员,您可以将 GitLab CI / CD 的默认行为更改为:
* An [entire GitLab instance](../user/admin_area/settings/continuous_integration.html).
* 具体项目,使用[管道设置](pipelines/settings.html) .
也可以看看:
* [How to enable or disable GitLab CI/CD](enable_or_disable_ci.html).
* Other [CI administration settings](../administration/index.html#continuous-integration-settings).
## References[](#references "Permalink")
### Why GitLab CI/CD?[](#why-gitlab-cicd "Permalink")
学习更多关于:
* [Why you might chose GitLab CI/CD](https://about.gitlab.com/blog/2016/10/17/gitlab-ci-oohlala/).
* [Reasons you might migrate from another platform](https://about.gitlab.com/blog/2016/07/22/building-our-web-app-on-gitlab-ci/).
* [5 Teams that made the switch to GitLab CI/CD](https://about.gitlab.com/blog/2019/04/25/5-teams-that-made-the-switch-to-gitlab-ci-cd/)
另请参阅[为什么选择 CI / CD?](https://docs.google.com/presentation/d/1OGgk2Tcxbpl7DJaIOzCX4Vqg3dlwfELC3u2jEeCBbDk) 介绍.
### Breaking changes[](#breaking-changes "Permalink")
随着 GitLab CI / CD 的发展,必须进行一些重大更改. 这些是:
#### 13.0[](#130 "Permalink")
* [Remove Backported `os.Expand`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4915)
* [Remove Fedora 29 package support](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/16158)
* [Remove macOS 32-bit support](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25466)
* [Removed `debug/jobs/list?v=1` endpoint](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6361)
* [Remove support for array of strings when defining services for Docker executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4922)
* [Remove `--docker-services` flag on register command](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6404)
* [Remove legacy build directory caching](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4180)
* [Remove `FF_USE_LEGACY_VOLUMES_MOUNTING_ORDER` feature flag](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6581)
* [Remove support for Windows Server 1803](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6553)
#### 12.0[](#120 "Permalink")
* [Use refspec to clone/fetch Git repository](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4069).
* [Old cache configuration](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4070).
* [Old metrics server configuration](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4072).
* [Remove `FF_K8S_USE_ENTRYPOINT_OVER_COMMAND`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4073).
* [Remove Linux distributions that reach EOL](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1130).
* [Update command line API for helper images](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4013).
* [Remove old `git clean` flow](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4175).
#### 11.0[](#110 "Permalink")
* 没有重大变化.
#### 10.0[](#100 "Permalink")
* 没有重大变化.
#### 9.0[](#90 "Permalink")
* [为 GitLab 9.0 重命名 CI 变量](variables/deprecated_variables.html#gitlab-90-renamed-variables) . 了解不建议使用的 CI 变量以及在 GitLab 9.0+中应使用的内容.
* [新的 CI 作业权限模型](../user/project/new_ci_build_permissions_model.html) . 查看 GitLab 8.12 中的更改及其对工作的影响. 有一种新方法可以访问作业中的 Git 子模块和 LFS 对象.
\ No newline at end of file
此差异已折叠。
# GitLab CI/CD include examples
> 原文:[https://docs.gitlab.com/ee/ci/yaml/includes.html](https://docs.gitlab.com/ee/ci/yaml/includes.html)
* [Single string or array of multiple values](#single-string-or-array-of-multiple-values)
* [Re-using a `before_script` template](#re-using-a-before_script-template)
* [Overriding external template values](#overriding-external-template-values)
* [Using nested includes](#using-nested-includes)
# GitLab CI/CD include examples[](#gitlab-cicd-include-examples "Permalink")
除了[GitLab CI YAML 参考中](README.html)列出的[`includes`示例](README.html#include)之外,此页面还列出了`include`用法的更多变化.
## Single string or array of multiple values[](#single-string-or-array-of-multiple-values "Permalink")
您可以将额外的 YAML 文件作为单个字符串或多个值的数组包含在内. 以下示例均有效.
`include:local`方法的单个字符串暗含:
```
include: '/templates/.after-script-template.yml'
```
Array with `include` method implied:
```
include:
- 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
- '/templates/.after-script-template.yml'
```
具有明确指定的`include`方法的单个字符串:
```
include:
remote: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
```
`include:remote`为单个项目的数组:
```
include:
- remote: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
```
具有多个显式指定的`include`方法的数组:
```
include:
- remote: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
- local: '/templates/.after-script-template.yml'
- template: Auto-DevOps.gitlab-ci.yml
```
数组混合语法:
```
include:
- 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
- '/templates/.after-script-template.yml'
- template: Auto-DevOps.gitlab-ci.yml
- project: 'my-group/my-project'
ref: master
file: '/templates/.gitlab-ci-template.yml'
```
## Re-using a `before_script` template[](#re-using-a-before_script-template "Permalink")
在以下示例中, `.before-script-template.yml`的内容将与`.gitlab-ci.yml`的内容一起自动获取和评估.
`https://gitlab.com/awesome-project/raw/master/.before-script-template.yml`内容:
```
before_script:
- apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs
- gem install bundler --no-document
- bundle install --jobs $(nproc) "${FLAGS[@]}"
```
`.gitlab-ci.yml`内容:
```
include: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
rspec:
script:
- bundle exec rspec
```
## Overriding external template values[](#overriding-external-template-values "Permalink")
以下示例显示了特定的 YAML 定义的变量以及`.gitlab-ci.yml`自定义的包含文件中`production`作业的详细信息.
`https://company.com/autodevops-template.yml`内容:
```
variables:
POSTGRES_USER: user
POSTGRES_PASSWORD: testing_password
POSTGRES_DB: $CI_ENVIRONMENT_SLUG
production:
stage: production
script:
- install_dependencies
- deploy
environment:
name: production
url: https://$CI_PROJECT_PATH_SLUG.$KUBE_INGRESS_BASE_DOMAIN
only:
- master
```
`.gitlab-ci.yml`内容:
```
include: 'https://company.com/autodevops-template.yml'
image: alpine:latest
variables:
POSTGRES_USER: root
POSTGRES_PASSWORD: secure_password
stages:
- build
- test
- production
production:
environment:
url: https://domain.com
```
在这种情况下,变量`POSTGRES_USER``POSTGRES_PASSWORD`以及`autodevops-template.yml`定义的`production`作业的环境 URL 已被`.gitlab-ci.yml`定义的新值覆盖.
合并使您可以扩展和覆盖字典映射,但是不能向包含的数组添加或修改项目. 例如,要将其他项目添加到生产作业脚本中,必须重复现有的脚本项目:
`https://company.com/autodevops-template.yml`内容:
```
production:
stage: production
script:
- install_dependencies
- deploy
```
`.gitlab-ci.yml`内容:
```
include: 'https://company.com/autodevops-template.yml'
stages:
- production
production:
script:
- install_dependencies
- deploy
- notify_owner
```
在这种情况下,如果未在`.gitlab-ci.yml`重复`install_dependencies``deploy` ,则它们将不会成为组合 CI 配置中`production`作业脚本的一部分.
## Using nested includes[](#using-nested-includes "Permalink")
以下示例显示了如何使用不同方法的组合从不同来源嵌套包含对象.
在此示例中, `.gitlab-ci.yml`本地包含文件`/.gitlab-ci/another-config.yml`
```
include:
- local: /.gitlab-ci/another-config.yml
```
`/.gitlab-ci/another-config.yml`包含一个模板和另一个项目中的`/templates/docker-workflow.yml`文件:
```
include:
- template: Bash.gitlab-ci.yml
- project: group/my-project
file: /templates/docker-workflow.yml
```
`/templates/docker-workflow.yml`出现在`group/my-project`包括的两个本地文件`group/my-project`
```
include:
- local: /templates/docker-build.yml
- local: /templates/docker-testing.yml
```
我们在`group/my-project` `/templates/docker-build.yml`添加了一个`docker-build`作业:
```
docker-build:
script: docker build -t my-image .
```
我们在`group/my-project`出现的第二个`/templates/docker-test.yml`添加了一个`docker-test`作业:
```
docker-test:
script: docker run my-image /run/tests.sh
```
\ No newline at end of file
# Introduction to CI/CD with GitLab
> 原文:[https://docs.gitlab.com/ee/ci/introduction/](https://docs.gitlab.com/ee/ci/introduction/)
* [Introduction to CI/CD methodologies](#introduction-to-cicd-methodologies)
* [Continuous Integration](#continuous-integration)
* [Continuous Delivery](#continuous-delivery)
* [Continuous Deployment](#continuous-deployment)
* [Introduction to GitLab CI/CD](#introduction-to-gitlab-cicd)
* [How GitLab CI/CD works](#how-gitlab-cicd-works)
* [Basic CI/CD workflow](#basic-cicd-workflow)
* [A deeper look into the CI/CD basic workflow](#a-deeper-look-into-the-cicd-basic-workflow)
* [Setting up GitLab CI/CD for the first time](#setting-up-gitlab-cicd-for-the-first-time)
# Introduction to CI/CD with GitLab[](#introduction-to-cicd-with-gitlab "Permalink")
在本文档中,我们将概述持续集成,持续交付和持续部署的概念,并介绍 GitLab CI / CD.
**开箱即用的管理系统可以将维护工具链所花费的时间减少 10%或更多.** 观看我们的["精通持续软件开发"](https://about.gitlab.com/webcast/mastering-ci-cd/)网络广播,以了解连续方法以及 GitLab 的内置 CI 如何帮助您简化和扩展软件开发.
## Introduction to CI/CD methodologies[](#introduction-to-cicd-methodologies "Permalink")
软件开发的连续方法基于自动执行脚本,以最大程度地减少在开发应用程序时引入错误的机会. 从开发新代码到部署新代码,他们几乎不需要人工干预,甚至根本不需要干预.
它涉及到在每次小的迭代中就不断地构建,测试和部署代码更改,从而减少了基于错误或失败的先前版本开发新代码的机会.
此方法有三种主要方法,每种方法都将根据最适合您的策略的方式进行应用.
### Continuous Integration[](#continuous-integration "Permalink")
考虑一个应用程序,其代码存储在 GitLab 的 Git 存储库中. 开发人员每天要多次推送代码更改. 对于每次向存储库的推送,您都可以创建一组脚本来自动构建和测试您的应用程序,从而减少了向应用程序引入错误的机会.
这种做法被称为[持续整合](https://en.wikipedia.org/wiki/Continuous_integration) ; 对于提交给应用程序(甚至是开发分支)的每个更改,它都会自动连续地构建和测试,以确保所引入的更改通过您为应用程序建立的所有测试,准则和代码合规性标准.
[GitLab 本身](https://gitlab.com/gitlab-org/gitlab-foss)就是使用持续集成作为软件开发方法的一个示例. 对于项目的每一次推送,都有一组检查脚本的脚本.
### Continuous Delivery[](#continuous-delivery "Permalink")
[持续交付](https://continuousdelivery.com/)是超越持续集成的一步. 您的应用程序不仅会在推送到代码库的每次代码更改时都进行构建和测试,而且作为附加步骤,尽管部署是手动触发的,但它仍会持续部署.
此方法可确保自动检查代码,但需要人工干预才能从策略上手动触发更改的部署.
### Continuous Deployment[](#continuous-deployment "Permalink")
类似于持续交付, [持续部署](https://www.airpair.com/continuous-deployment/posts/continuous-deployment-for-practical-people)也是超越持续集成的又一步. 区别在于,您无需将其手动部署,而是将其设置为自动部署. 部署您的应用程序完全不需要人工干预.
## Introduction to GitLab CI/CD[](#introduction-to-gitlab-cicd "Permalink")
GitLab CI / CD 是内置在 GitLab 中的功能强大的工具,它使您可以将所有连续方法(连续集成,交付和部署)应用于软件,而无需第三方应用程序或集成.
有关概述,请参阅最近的 GitLab 聚会中的[GitLab CI 简介](https://www.youtube.com/watch?v=l5705U8s_nQ&t=397) .
### How GitLab CI/CD works[](#how-gitlab-cicd-works "Permalink")
要使用 GitLab CI / CD,您需要做的是托管在 Git 存储库中的应用程序代码库,并在[`.gitlab-ci.yml`](../yaml/README.html)文件中指定生成,测试和部署脚本,该文件位于以下目录的根路径中:您的存储库.
在此文件中,您可以定义要运行的脚本,定义包含和缓存依赖项,选择要按顺序运行的命令和要并行运行的命令,定义要在哪里部署应用程序,以及指定是否将要自动运行脚本或手动触发任何脚本. 熟悉 GitLab CI / CD 后,您可以在配置文件中添加更多高级步骤.
要将脚本添加到该文件,您需要按照适合您的应用程序并符合您要执行的测试的顺序来组织它们. 为了可视化该过程,假设添加到配置文件中的所有脚本与在计算机的终端上运行的命令相同.
`.gitlab-ci.yml`配置文件添加到存储库后,GitLab 将检测到该文件并使用名为[GitLab Runner](https://docs.gitlab.com/runner/)的工具运行脚本,该工具的操作与终端类似.
这些脚本被分组为**作业** ,它们共同组成了一个**管道** . `.gitlab-ci.yml`文件的一个简约示例可以包含:
```
before_script:
- apt-get install rubygems ruby-dev -y
run-test:
script:
- ruby --version
```
`before_script`属性将在运行任何内容之前为您的应用程序安装依赖项,并且名为`run-test`**作业**将打印当前系统的 Ruby 版本. 它们两者都构成了在每次推送到存储库的任何分支时触发的**管道** .
GitLab CI / CD 不仅执行您已设置的作业,而且还向您显示执行期间发生的事情,就像您在终端中看到的那样:
[![job running](img/b452a194fd7fbbdd22f73a1dda9b236a.png)](img/job_running.png)
您为您的应用程序创建了策略,GitLab 根据您定义的内容为您运行管道. 您的管道状态也会由 GitLab 显示:
[![pipeline status](img/be1eaf723e0603b081c01aa4310c304c.png)](img/pipeline_status.png)
最后,如果出现任何问题,您可以轻松[回滚](../environments/index.html#retrying-and-rolling-back)所有更改:
[![rollback button](img/ce2f28e687df2b322895dbfb6c48d389.png)](img/rollback.png)
### Basic CI/CD workflow[](#basic-cicd-workflow "Permalink")
考虑以下示例,以了解 GitLab CI / CD 如何适合通用开发工作流程.
假设您已在一个问题中讨论了代码实现,并在本地进行了建议的更改. 将提交推送到 GitLab 中的远程存储库中的功能分支后,将触发项目的 CI / CD 管道集. 这样,GitLab CI / CD:
* 运行自动化脚本(顺序或并行)以:
* 构建并测试您的应用.
* 就像在`localhost`看到的那样,使用 Review Apps 预览每个合并请求的更改.
对实施感到满意后:
* 让您的代码得到审查和批准.
* 将功能分支合并到默认分支.
* GitLab CI / CD 将您的更改自动部署到生产环境.
* 最后,如果出现问题,您和您的团队可以轻松地将其回滚.
[![GitLab workflow example](img/4ab2d185d65e76a0d58ad6564dff777a.png)](img/gitlab_workflow_example_11_9.png)
GitLab CI / CD 可以做更多的事情,但是此工作流程体现了 GitLab 跟踪整个过程的能力,而无需使用外部工具来交付软件. 而且,最有用的是,您可以通过 GitLab UI 可视化所有步骤.
#### A deeper look into the CI/CD basic workflow[](#a-deeper-look-into-the-cicd-basic-workflow "Permalink")
如果我们深入研究基本工作流程,则可以在 DevOps 生命周期的每个阶段看到 GitLab 中可用的功能,如下图所示.
[![Deeper look into the basic CI/CD workflow](img/33c514aefa1ff87fe18907b27d473e03.png)](img/gitlab_workflow_example_extended_v12_3.png)
如果您从左至右查看图像,则会根据每个阶段(验证,打包,发布)看到 GitLab 中的一些可用功能.
1. **Verify**:
* 通过持续集成自动构建和测试您的应用程序.
* 使用[GitLab 代码质量](../../user/project/merge_requests/code_quality.html)分析您的源代码[质量](../../user/project/merge_requests/code_quality.html) .
* 使用[浏览器性能测试](../../user/project/merge_requests/browser_performance_testing.html)确定代码更改对性能的影响.
* 执行一系列测试,例如[容器扫描](../../user/application_security/container_scanning/index.html)[依赖扫描](../../user/application_security/dependency_scanning/index.html)[JUnit 测试](../junit_test_reports.html) .
* 使用[Review Apps](../review_apps/index.html)部署更改,以预览每个分支上的应用程序更改.
2. **Package**:
* 使用[Container Registry](../../user/packages/container_registry/index.html)存储 Docker 映像.
* 使用[NPM Registry](../../user/packages/npm_registry/index.html)存储 NPM 软件包.
*[Maven 存储库](../../user/packages/maven_repository/index.html)存储 Maven 工件.
* 将 Conan 软件包存储在[Conan 仓库中](../../user/packages/conan_repository/index.html) .
3. **Release**:
* 持续部署,自动将您的应用程序部署到生产环境.
* 连续交付,手动单击以将您的应用程序部署到生产环境.
* 使用[GitLab Pages](../../user/project/pages/index.html)部署静态网站.
* 仅将功能部件运送到您的一部分吊舱中,并让一定比例的用户群通过[Canary Deployments](../../user/project/canary_deployments.html)访问临时部署的功能部件.
*[功能标记](../../operations/feature_flags.html)后面部署[功能](../../operations/feature_flags.html) .
* 使用[GitLab Releases](../../user/project/releases/index.html)向任何 Git 标签添加发行说明.
* View of the current health and status of each CI environment running on Kubernetes with [Deploy Boards](../../user/project/deploy_boards.html).
* 使用[Auto Deploy](../../topics/autodevops/stages.html#auto-deploy)将应用程序部署到 Kubernetes 集群中的生产环境.
使用 GitLab CI / CD,您还可以:
* 通过[Auto DevOps](../../topics/autodevops/index.html)轻松设置应用程序的整个生命周期.
* 将您的应用程序部署到不同的[环境](../environments/index.html) .
* 安装自己的[GitLab Runner](https://docs.gitlab.com/runner/) .
* [Schedule pipelines](../pipelines/schedules.html).
* 使用[安全测试报告](../../user/application_security/index.html)检查应用程序漏洞.
要查看所有 CI / CD 功能,请导航回[CI / CD 索引](../README.html) .
观看视频[GitLab CI Live 演示](https://youtu.be/l5705U8s_nQ?t=369) ,深入了解 GitLab CI / CD.
### Setting up GitLab CI/CD for the first time[](#setting-up-gitlab-cicd-for-the-first-time "Permalink")
要开始使用 GitLab CI / CD,您需要熟悉[`.gitlab-ci.yml`](../yaml/README.html)配置文件的语法及其属性.
本文档[在 GitLab Pages 的范围内介绍了 GitLab CI / CD 的概念](../../user/project/pages/getting_started/pages_from_scratch.html) ,用于部署静态网站. 尽管它是为想要从头开始编写自己的 Pages 脚本的用户而设计的,但它也可以作为 GitLab CI / CD 设置过程的简介. 它涵盖了编写 CI / CD 配置文件的最初一般步骤,因此我们建议您通读它以了解 GitLab 的 CI / CD 逻辑,并学习如何为任何应用程序编写自己的脚本(或调整现有脚本).
要深入了解 GitLab 的 CI / CD 配置选项,请查看[`.gitlab-ci.yml`完整参考](../yaml/README.html) .
\ No newline at end of file
# Getting started with GitLab CI/CD
> 原文:[https://docs.gitlab.com/ee/ci/quick_start/README.html](https://docs.gitlab.com/ee/ci/quick_start/README.html)
* [Creating a `.gitlab-ci.yml` file](#creating-a-gitlab-ciyml-file)
* [What is `.gitlab-ci.yml`](#what-is-gitlab-ciyml)
* [Creating a simple `.gitlab-ci.yml` file](#creating-a-simple-gitlab-ciyml-file)
* [Push `.gitlab-ci.yml` to GitLab](#push-gitlab-ciyml-to-gitlab)
* [Configuring a Runner](#configuring-a-runner)
* [Shared Runners](#shared-runners)
* [Seeing the status of your pipeline and jobs](#seeing-the-status-of-your-pipeline-and-jobs)
* [Examples](#examples)
# Getting started with GitLab CI/CD[](#getting-started-with-gitlab-cicd "Permalink")
**注意:**从 8.0 版开始,GitLab [持续集成](https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/) (CI)已完全集成到 GitLab 本身,并且默认情况下在所有项目上都[启用](../enable_or_disable_ci.html) .**注意:**请记住,只有项目维护者和管理员用户有权访问项目的设置.**注意:**要从 Jenkins 转到 GitLab 吗? 查阅我们的[参考](../jenkins/index.html) ,将您先前存在的管道转换为我们的格式.**注意:**您可以考虑在项目中使用几种不同的[基本管道体系结构](../pipelines/pipeline_architectures.html) . 您可能需要在开始之前熟悉这些内容.
GitLab 提供[持续集成](https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/)服务. 对于每次提交或推送以触发您的 CI [管道](../pipelines/index.html) ,您必须:
* Add a [`.gitlab-ci.yml` file](#creating-a-gitlab-ciyml-file) to your repository’s root directory.
* 确保将项目配置为使用[Runner](#configuring-a-runner) .
`.gitlab-ci.yml`文件告诉 GitLab Runner 做什么. 一个简单的管道通常包括三个[阶段](../yaml/README.html#stages)
* `build`
* `test`
* `deploy`
您不需要使用所有三个阶段; 没有工作的阶段将被忽略.
管道显示在项目的**CI / CD>管道**页面下. 如果一切运行正常(没有非零返回值),您将获得与提交关联的绿色复选标记. 这样就可以轻松查看提交是否导致任何测试失败,甚至无需查看作业(测试)日志. 许多项目使用 GitLab 的 CI 服务来运行测试套件,因此如果开发人员遇到问题,他们会立即获得反馈.
通常,使用管道将经过测试的代码自动部署到登台和生产环境中.
* * *
本指南假定您具有:
* 8.0+或正在使用[GitLab.com 的](https://gitlab.com)有效 GitLab 实例.
* 您要在其中使用 CI 的 GitLab 中的项目.
* 维护者或所有者对项目的访问
让我们将其分解为 GitLab CI / CD 难题.
## Creating a `.gitlab-ci.yml` file[](#creating-a-gitlab-ciyml-file "Permalink")
在创建`.gitlab-ci.yml`之前,让我们首先简要地解释这是怎么回事.
### What is `.gitlab-ci.yml`[](#what-is-gitlab-ciyml "Permalink")
您可以在`.gitlab-ci.yml`文件中配置 CI 对项目的作用. 它位于存储库的根目录中.
在对存储库进行任何推送时,GitLab 都会查找`.gitlab-ci.yml`文件,并根据该文件的内容在*Runners*上启动作业,以进行提交.
由于`.gitlab-ci.yml`在存储库中并且受版本控制,因此旧版本仍然可以成功构建,fork 可以轻松使用 CI,分支可以具有不同的管道和作业,并且您拥有 CI 的唯一真实来源. 您可以[在我们的博客中](https://about.gitlab.com/blog/2015/05/06/why-were-replacing-gitlab-ci-jobs-with-gitlab-ci-dot-yml/)阅读更多有关为什么使用`.gitlab-ci.yml`的原因.
### Creating a simple `.gitlab-ci.yml` file[](#creating-a-simple-gitlab-ciyml-file "Permalink")
> **注意:** `.gitlab-ci.yml`是一个[YAML](https://en.wikipedia.org/wiki/YAML)文件,因此您必须特别注意缩进. 始终使用空格,不要使用制表符.
您需要在存储库的根目录中创建一个名为`.gitlab-ci.yml`的文件. 以下是 Ruby on Rails 项目的示例.
```
image: "ruby:2.5"
before_script:
- apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs
- ruby -v
- which ruby
- gem install bundler --no-document
- bundle install --jobs $(nproc) "${FLAGS[@]}"
rspec:
script:
- bundle exec rspec
rubocop:
script:
- bundle exec rubocop
```
This is the simplest possible configuration that will work for most Ruby applications:
1. 用要执行的不同命令定义两个作业`rspec``rubocop` (名称是任意的).
2. 在执行每个作业之前,将执行`before_script`定义的命令.
`.gitlab-ci.yml`文件定义了作业集,并限制了作业的运行方式和时间. 作业被定义为具有名称的顶级元素(在我们的示例中为`rspec``rubocop` ),并且始终必须包含`script`关键字. 乔布斯被用于创造就业机会,然后由挑选[运动员](../runners/README.html)和跑步者的环境中执行.
重要的是每个作业都彼此独立运行.
如果要检查项目的`.gitlab-ci.yml`是否有效,则项目名称空间的`/-/ci/lint`页下有一个 Lint 工具. 您也可以在项目的**CI / CD➔管道****管道➔作业**下找到" CI Lint"按钮以转到此页面.
有关更多信息和完整的`.gitlab-ci.yml`语法,请阅读[`.gitlab-ci.yml`上的参考文档](../yaml/README.html) .
### Push `.gitlab-ci.yml` to GitLab[](#push-gitlab-ciyml-to-gitlab "Permalink")
创建`.gitlab-ci.yml` ,应将其添加到 Git 存储库中并将其推送到 GitLab.
```
git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml"
git push origin master
```
现在,如果您转到" **管道"**页面,您将看到管道处于挂起状态.
**注意:**如果您有一个[从 GitLab 提取镜像的存储库](../../user/project/repository/repository_mirroring.html#pulling-from-a-remote-repository-starter) ,则可能需要在项目的**"设置">"存储库">"从远程存储库中提取">"触发管道以进行镜像更新"中**启用管道触发.
您也可以转到" **提交"**页面,注意提交 SHA 旁边的小暂停图标.
[![New commit pending](img/3b3e644f832753a09f245236299e74b2.png)](img/new_commit.png)
单击它,您将被定向到该特定提交的作业页面.
[![Single commit jobs page](img/f8cfebdbd362ba809375c8d9c38416ba.png)](img/single_commit_status_pending.png)
注意,有一个待处理的作业以我们在`.gitlab-ci.yml`编写的`.gitlab-ci.yml` . "卡住"表示尚未为此作业配置任何运行器.
下一步是配置运行器,以便它选择挂起的作业.
## Configuring a Runner[](#configuring-a-runner "Permalink")
在 GitLab 中,Runners 运行您在`.gitlab-ci.yml`定义的作业. Runner 可以是虚拟机,VPS,裸机,Docker 容器甚至是容器集群. GitLab 和 Runners 通过 API 进行通信,因此唯一的要求是 Runner 的计算机具有对 GitLab 服务器的网络访问权限.
Runner 可以特定于某个项目,也可以在 GitLab 中服务多个项目. 如果它服务于所有项目,则称为*Shared Runner* .
在" [跑步者"](../runners/README.html)文档中查找有关不同跑步者的更多信息.
您可以通过转到**设置➔CI / CD**来查找是否将任何跑步者分配给您的项目. 设置 Runner 既简单又直接. GitLab 支持的官方 Runner 是用 Go 编写的,其文档可以在[https://docs.gitlab.com/runner/中](https://docs.gitlab.com/runner/)找到.
为了拥有功能正常的 Runner,您需要执行以下两个步骤:
1. [Install it](https://docs.gitlab.com/runner/install/)
2. [Configure it](https://docs.gitlab.com/runner/configuration/)
请按照上面的链接设置您自己的 Runner 或使用下一节所述的 Shared Runner.
设置 Runner 之后,您应该在**设置➔CI / CD**后面的项目的 Runners 页面上看到它.
[![Activated runners](img/423e566cce1da11ef163c69219f870aa.png)](img/runners_activated.png)
### Shared Runners[](#shared-runners "Permalink")
如果使用[GitLab.com](https://gitlab.com/) ,则可以使用 GitLab Inc.提供的**共享运行程序** .
这些是在 GitLab 基础架构上运行的特殊虚拟机,可以构建任何项目.
要启用**共享运行程序,**您必须转到项目的**设置➔CI / CD** ,然后单击**启用共享运行程序** .
[Read more on Shared Runners](../runners/README.html).
## Seeing the status of your pipeline and jobs[](#seeing-the-status-of-your-pipeline-and-jobs "Permalink")
成功配置 Runner 之后,您应该看到上一次提交的状态从" *未决"*更改为" *正在* *运行"* ," *成功"*或" *失败"* .
您可以转到项目中的" **管道"**页面来查看所有管道.
[![Commit status](img/0748208b938145b0cf688cc0a3cb7b09.png)](img/pipelines_status.png)
或者,您可以转到" **管道➔作业"**页面查看所有作业.
[![Commit status](img/c0fd76908cea66a75fbd88aeb1ccec31.png)](img/builds_status.png)
通过单击作业的状态,您将能够看到该作业的日志. 这对于诊断工作为什么失败或行为与您预期的不同很重要.
[![Build log](img/f5f57e5e3d074f574a5b26d23eb0b721.png)](img/build_log.png)
您还可以在 GitLab 的各个页面中查看任何提交的状态,例如**提交****合并请求** .
## Examples[](#examples "Permalink")
请访问[示例自述文件](../examples/README.html)以查看使用各种语言的 GitLab CI 的示例列表.
\ No newline at end of file
# How to enable or disable GitLab CI/CD
> 原文:[https://docs.gitlab.com/ee/ci/enable_or_disable_ci.html](https://docs.gitlab.com/ee/ci/enable_or_disable_ci.html)
* [Per-project user setting](#per-project-user-setting)
* [Site-wide admin setting](#site-wide-admin-setting)
# How to enable or disable GitLab CI/CD[](#how-to-enable-or-disable-gitlab-cicd "Permalink")
为了有效使用 GitLab CI / CD,您需要:
* 项目根目录中存在一个有效的[`.gitlab-ci.yml`](yaml/README.html)文件.
* [跑步者](runners/README.html)正确设置.
您可以阅读我们的[快速入门指南](quick_start/README.html)以开始使用.
如果您使用的是 Jenkins 或 Drone CI 之类的外部 CI / CD 服务器,建议禁用 GitLab CI / CD,以免与提交状态 API 发生冲突.
GitLab CI/CD is exposed via the `/pipelines` and `/jobs` pages of a project. Disabling GitLab CI/CD in a project does not delete any previous jobs. In fact, the `/pipelines` and `/jobs` pages can still be accessed, although it’s hidden from the left sidebar menu.
GitLab CI / CD 在新安装中默认情况下处于启用状态,并且可以被禁用:
* 在每个项目的设置下单独进行.
* 通过修改分别用于源代码安装和 Omnibus 安装的`gitlab.yml``gitlab.rb`的设置在`gitlab.yml`站点范围内.
**注意:**这仅适用于作为 GitLab CI / CD 的一部分运行的管道. 这将不会启用或禁用通过[外部集成](../user/project/integrations/overview.html#integrations-listing)运行的管道.
## Per-project user setting[](#per-project-user-setting "Permalink")
要在项目中启用或禁用 GitLab CI / CD 管道:
1. 导航至**设置>常规>可见性,项目功能,权限** .
2. 展开**存储库**部分
3. 根据需要启用或禁用" **管道"**切换.
**项目可见性**还将影响管道可见性. 如果设置为:
* **私有** :只有项目成员才能访问管道.
* **内部****公共** :可以通过下拉框将管道设置为" **仅项目成员"**或" **具有访问权限的所有人** ".
**保存更改**以使设置生效.
## Site-wide admin setting[](#site-wide-admin-setting "Permalink")
您可以在`gitlab.yml`站点上禁用 GitLab CI / CD,方法是修改`gitlab.yml`用于源代码安装的设置,以及`gitlab.rb`用于 Omnibus 安装的设置.
有两件事要注意:
* 禁用 GitLab CI / CD,将仅影响新创建的项目. 在此修改之前启用了此功能的项目将照常工作.
* 即使您禁用了 GitLab CI / CD,用户仍然可以在项目的设置中启用它.
对于源安装, `gitlab.yml`使用编辑器打开`gitlab.yml`并将`builds`设置为`false`
```
## Default project features settings
default_projects_features:
issues: true
merge_requests: true
wiki: true
snippets: false
builds: false
```
保存文件并重新启动 GitLab:
```
sudo service gitlab restart
```
对于 Omnibus 安装,请编辑`/etc/gitlab/gitlab.rb`并添加以下行:
```
gitlab_rails['gitlab_default_projects_features_builds'] = false
```
保存文件并重新配置 GitLab:
```
sudo gitlab-ctl reconfigure
```
\ No newline at end of file
# Using SSH keys with GitLab CI/CD
> 原文:[https://docs.gitlab.com/ee/ci/ssh_keys/README.html](https://docs.gitlab.com/ee/ci/ssh_keys/README.html)
* [How it works](#how-it-works)
* [SSH keys when using the Docker executor](#ssh-keys-when-using-the-docker-executor)
* [SSH keys when using the Shell executor](#ssh-keys-when-using-the-shell-executor)
* [Verifying the SSH host keys](#verifying-the-ssh-host-keys)
* [Example project](#example-project)
# Using SSH keys with GitLab CI/CD[](#using-ssh-keys-with-gitlab-cicd "Permalink")
GitLab 当前不支持在构建环境(运行 GitLab Runner 的环境)中管理 SSH 密钥的内置支持.
SSH 密钥在以下情况下很有用:
1. 您想签出内部子模块
2. 您想使用包管理器(例如 Bundler)下载私有包
3. 您想要将应用程序部署到自己的服务器上,例如 Heroku
4. 您要执行从构建环境到远程服务器的 SSH 命令
5. 您想将文件从构建环境同步到远程服务器
如果上述任何事情都响了,那么您很可能需要 SSH 密钥.
支持最广泛的方法是通过扩展`.gitlab-ci.yml`来将 SSH 密钥注入构建环境,该解决方案可与任何类型的[执行器](https://docs.gitlab.com/runner/executors/) (Docker,shell 等)一起使用.
## How it works[](#how-it-works "Permalink")
1. 使用[`ssh-keygen`](https://linux.die.net/man/1/ssh-keygen)在本地创建新的 SSH 密钥对
2. 将私钥作为[变量](../variables/README.html)添加到您的项目中
3. 在作业期间运行[`ssh-agent`](https://linux.die.net/man/1/ssh-agent)以加载私钥.
4. 将公用密钥复制到您要访问的服务器上(通常在`~/.ssh/authorized_keys` ),如果要访问私有的 GitLab 存储库,则将其添加为[部署密钥](../../ssh/README.html#deploy-keys) .
**注意:**除非您启用[调试日志](../variables/README.html#debug-logging)记录,否则私钥将不会显示在作业日志中. 您可能还需要检查[管道](../pipelines/settings.html#visibility-of-pipelines)[可见性](../pipelines/settings.html#visibility-of-pipelines) .
## SSH keys when using the Docker executor[](#ssh-keys-when-using-the-docker-executor "Permalink")
当您的 CI / CD 作业在 Docker 容器中运行(意味着包含环境)并且您想要在私有服务器中部署代码时,您需要一种访问它的方法. 这是 SSH 密钥对派上用场的地方.
1. 您首先需要创建一个 SSH 密钥对. 有关更多信息,请按照说明[生成 SSH 密钥](../../ssh/README.html#generating-a-new-ssh-key-pair) . **不要**在 SSH 密钥中添加密码,否则`before_script`会提示您输入密码.
2. 创建一个新[变量](../variables/README.html#gitlab-cicd-environment-variables) . 在" **密钥"中**输入名称`SSH_PRIVATE_KEY`然后在" **值"**字段中粘贴先前创建的*私钥*的内容.
3. 使用`before_script`操作修改`.gitlab-ci.yml` . 在以下示例中,假定使用基于 Debian 的图像. 根据需要进行编辑:
```
before_script:
##
## Install ssh-agent if not already installed, it is required by Docker.
## (change apt-get to yum if you use an RPM-based image)
##
- 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
##
## Run ssh-agent (inside the build environment)
##
- eval $(ssh-agent -s)
##
## Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store
## We're using tr to fix line endings which makes ed25519 keys work
## without extra base64 encoding.
## https://gitlab.com/gitlab-examples/ssh-private-key/issues/1#note_48526556
##
- echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
##
## Create the SSH directory and give it the right permissions
##
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
##
## Optionally, if you will be using any Git commands, set the user name and
## and email.
##
#- git config --global user.email "user@example.com"
#- git config --global user.name "User name"
```
**注意:** [`before_script`](../yaml/README.html#before_script-and-after_script)可以全局设置或按作业设置.
4. 确保专用服务器的[SSH 主机密钥已验证](#verifying-the-ssh-host-keys) .
5. 作为最后一步,从添加您在第一步,你想拥有从构建环境中的接入服务创建一个*公共*密钥. 如果要访问私有的 GitLab 存储库,则需要将其添加为[部署密钥](../../ssh/README.html#deploy-keys) .
而已! 现在,您可以在构建环境中访问私有服务器或存储库.
## SSH keys when using the Shell executor[](#ssh-keys-when-using-the-shell-executor "Permalink")
如果您使用的是 Shell 执行程序而不是 Docker,则设置 SSH 密钥会更加容易.
您可以从安装了 GitLab Runner 的计算机生成 SSH 密钥,并将该密钥用于在该计算机上运行的所有项目.
1. 首先,登录到运行您的作业的服务器.
2. 然后,从终端以`gitlab-runner`用户身份登录:
```
sudo su - gitlab-runner
```
3. 按照说明生成 SSH 密钥对,以[生成 SSH 密钥](../../ssh/README.html#generating-a-new-ssh-key-pair) . **不要**在 SSH 密钥中添加密码,否则`before_script`会提示您输入密码.
4. 作为最后一步,加前面创建要具有从构建环境中的接入服务的一个*公共*密钥. 如果要访问私有的 GitLab 存储库,则需要将其添加为[部署密钥](../../ssh/README.html#deploy-keys) .
完成后,尝试登录到远程服务器以接受指纹:
```
ssh example.com
```
要访问 GitLab.com 上的存储库,可以使用`git@gitlab.com` .
## Verifying the SSH host keys[](#verifying-the-ssh-host-keys "Permalink")
最好检查私有服务器自己的公用密钥,以确保您不会受到中间人攻击的攻击. 万一发生任何可疑事件,您将注意到它,因为作业将失败(如果公钥不匹配,则 SSH 连接将失败).
要查找服务器的主机密钥,请从受信任的网络(最好是从私有服务器本身)运行`ssh-keyscan`命令:
```
## Use the domain name
ssh-keyscan example.com
## Or use an IP
ssh-keyscan 1.2.3.4
```
使用`SSH_KNOWN_HOSTS`作为"密钥"创建一个新[变量](../variables/README.html#gitlab-cicd-environment-variables) ,并作为"值"添加`ssh-keyscan`的输出.
**注意:**如果需要连接到多个服务器,则所有服务器主机密钥都需要收集在变量的**Value**中,每行一个密钥.**提示:**通过在`.gitlab-ci.yml`直接使用变量而不是`ssh-keyscan` ,这样做的好处是,如果主机域名由于某种原因而更改,则不必更改`.gitlab-ci.yml` . 而且,这些值是由您预定义的,这意味着如果主机密钥突然更改,CI / CD 作业将失败,并且您将知道服务器或网络出了点问题.
现在已经创建了`SSH_KNOWN_HOSTS`变量,除了上面[`.gitlab-ci.yml`](#ssh-keys-when-using-the-docker-executor)[内容](#ssh-keys-when-using-the-docker-executor)之外,还需要添加以下内容:
```
before_script:
##
## Assuming you created the SSH_KNOWN_HOSTS variable, uncomment the
## following two lines.
##
- echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
- chmod 644 ~/.ssh/known_hosts
##
## Alternatively, use ssh-keyscan to scan the keys of your private server.
## Replace example.com with your private server's domain name. Repeat that
## command if you have more than one server to connect to.
##
#- ssh-keyscan example.com >> ~/.ssh/known_hosts
#- chmod 644 ~/.ssh/known_hosts
##
## You can optionally disable host key checking. Be aware that by adding that
## you are susceptible to man-in-the-middle attacks.
## WARNING: Use this only with the Docker executor, if you use it with shell
## you will overwrite your user's SSH config.
##
#- '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" >> ~/.ssh/config'
```
## Example project[](#example-project "Permalink")
为了方便起见,我们建立了一个[示例 SSH 项目](https://gitlab.com/gitlab-examples/ssh-private-key/) ,使用我们的公共[共享](../runners/README.html)运行程序在[GitLab.com](https://gitlab.com)上运行.
想要破解吗? 只需对其进行分叉,提交并推送您的更改. 稍后,公共跑步者将选择更改并开始工作.
\ No newline at end of file
# Migrating from CircleCI
> 原文:[https://docs.gitlab.com/ee/ci/migration/circleci.html](https://docs.gitlab.com/ee/ci/migration/circleci.html)
* [`config.yml` vs `gitlab-ci.yml`](#configyml-vs-gitlab-ciyml)
* [Jobs](#jobs)
* [Docker image definition](#docker-image-definition)
* [Workflows](#workflows)
* [Parallel and sequential job execution](#parallel-and-sequential-job-execution)
* [Scheduled run](#scheduled-run)
* [Manual run](#manual-run)
* [Filter job by branch](#filter-job-by-branch)
* [Caching](#caching)
* [Contexts and variables](#contexts-and-variables)
* [Orbs](#orbs)
* [Build environments](#build-environments)
* [Machine and specific build environments](#machine-and-specific-build-environments)
# Migrating from CircleCI[](#migrating-from-circleci "Permalink")
如果您当前正在使用 CircleCI,则可以将 CI / CD 管道迁移到[GitLab CI / CD](../introduction/index.html) ,并开始使用其所有强大功能. 查看我们的[CircleCI 与 GitLab](https://about.gitlab.com/devops-tools/circle-ci-vs-gitlab.html)比较,以了解有什么不同.
在开始迁移之前,我们已经收集了一些您可能会觉得有用的资源.
[快速入门指南](../quick_start/README.html)很好地概述了 GitLab CI / CD 的工作方式. 您可能还对[Auto DevOps](../../topics/autodevops/index.html)感兴趣,可以将其用于构建,测试和部署应用程序,而几乎不需要或根本不需要进行任何配置.
对于高级 CI / CD 团队, [自定义项目模板](../../user/admin_area/custom_project_templates.html)可以启用管道配置的重用.
如果您有未在此处回答的问题, [GitLab 社区论坛](https://forum.gitlab.com/)将是一个很好的资源.
## `config.yml` vs `gitlab-ci.yml`[](#configyml-vs-gitlab-ciyml "Permalink")
CircleCI 的`config.yml`配置文件定义了脚本,作业和工作流程(在 GitLab 中称为"阶段"). 在 GitLab 中,对存储库根目录中的`.gitlab-ci.yml`文件使用类似的方法.
### Jobs[](#jobs "Permalink")
在 CircleCI 中,作业是执行特定任务的步骤的集合. 在 GitLab 中, [作业](../yaml/README.html#introduction)也是配置文件中的基本元素. 在 GitLab CI / CD 中,不需要`checkout`参数,因为系统会自动获取存储库.
CircleCI 示例作业定义:
```
jobs:
job1:
steps:
- checkout
- run: "execute-script-for-job1"
```
GitLab CI / CD 中相同作业定义的示例:
```
job1:
script: "execute-script-for-job1"
```
### Docker image definition[](#docker-image-definition "Permalink")
CircleCI 在作业级别定义图像,GitLab CI / CD 也支持该图像. 此外,GitLab CI / CD 支持全局设置此设置,以供所有未定义`image`作业使用.
CircleCI 示例图像定义:
```
jobs:
job1:
docker:
- image: ruby:2.6
```
Example of the same image definition in GitLab CI/CD:
```
job1:
image: ruby:2.6
```
### Workflows[](#workflows "Permalink")
CircleCI 确定具有`workflows`作业的运行顺序. 这也可用于确定并发,顺序,计划或手动运行. GitLab CI / CD 中的等效功能称为[stage](../yaml/README.html#stages) . 同一阶段的作业并行运行,并且仅在先前阶段完成后才运行. 默认情况下,当作业失败时,将跳过下一阶段的执行,但是即使[](../yaml/README.html#allow_failure)作业失败之后,也可以继续执行下一阶段.
有关可使用的不同类型的管道的指南,请参见["管道体系结构概述](../pipelines/pipeline_architectures.html) ". 可以定制管道来满足您的需求,例如大型复杂项目或具有独立定义组件的 monorepo.
#### Parallel and sequential job execution[](#parallel-and-sequential-job-execution "Permalink")
以下示例显示了作业如何并行或顺序运行:
1. `job1``job2`并行运行(在 GitLab CI / CD 的`build`阶段).
2. 仅在`job1``job2`成功完成之后(在`test`阶段), `job1` `job3`运行.
3. 仅在`job3`成功完成之后(在`deploy`阶段), `job3` `job4`运行.
CircleCI `workflows`示例:
```
version: 2
jobs:
job1:
steps:
- checkout
- run: make build dependencies
job2:
steps:
- run: make build artifacts
job3:
steps:
- run: make test
job4:
steps:
- run: make deploy
workflows:
version: 2
jobs:
- job1
- job2
- job3:
requires:
- job1
- job2
- job4:
requires:
- job3
```
与 GitLab CI / CD 中的`stages`相同的工作流程示例:
```
stages:
- build
- test
- deploy
job 1:
stage: build
script: make build dependencies
job 2:
stage: build
script: make build artifacts
job3:
stage: test
script: make test
job4:
stage: deploy
script: make deploy
```
#### Scheduled run[](#scheduled-run "Permalink")
GitLab CI / CD 具有易于使用的 UI 来[调度管道](../pipelines/schedules.html) . 同样,可以使用[规则](../yaml/README.html#rules)来确定是否应将作业包括在计划的管道中或从计划的管道中排除.
计划的工作流程的 CircleCI 示例:
```
commit-workflow:
jobs:
- build
scheduled-workflow:
triggers:
- schedule:
cron: "0 1 * * *"
filters:
branches:
only: try-schedule-workflow
jobs:
- build
```
使用 GitLab CI / CD 中的[`rules`](../yaml/README.html#rules)使用同一调度管道的示例:
```
job1:
script:
- make build
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule" && $CI_COMMIT_REF_NAME == "try-schedule-workflow"'
```
保存管道配置后,您可以在[GitLab UI 中](../pipelines/schedules.html#configuring-pipeline-schedules)配置 cron 计划,并且还可以在 UI 中启用或禁用计划.
#### Manual run[](#manual-run "Permalink")
手动工作流程的 CircleCI 示例:
```
release-branch-workflow:
jobs:
- build
- testing:
requires:
- build
- deploy:
type: approval
requires:
- testing
```
使用[`when: manual`](../yaml/README.html#whenmanual) GitLab CI / CD 中的[`when: manual`](../yaml/README.html#whenmanual)的相同工作流程示例:
```
deploy_prod:
stage: deploy
script:
- echo "Deploy to production server"
when: manual
```
### Filter job by branch[](#filter-job-by-branch "Permalink")
[规则](../yaml/README.html#rules)是一种机制,用于确定作业是否将针对特定分支运行.
按分支过滤的作业的 CircleCI 示例:
```
jobs:
deploy:
branches:
only:
- master
- /rc-.*/
```
在 GitLab CI / CD 中使用`rules`的相同工作流程示例:
```
deploy_prod:
stage: deploy
script:
- echo "Deploy to production server"
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
```
### Caching[](#caching "Permalink")
GitLab 提供了一种缓存机制,可通过重用以前下载的依赖项来加快作业的构建时间. 重要的是要了解[缓存和工件](../caching/index.html#cache-vs-artifacts)之间的区别,以充分利用这些功能.
使用缓存的作业的 CircleCI 示例:
```
jobs:
job1:
steps:
- restore_cache:
key: source-v1-< .Revision >
- checkout
- run: npm install
- save_cache:
key: source-v1-< .Revision >
paths:
- "node_modules"
```
在 GitLab CI / CD 中使用`cache`的同一管道的示例:
```
image: node:latest
# Cache modules in between jobs
cache:
key: $CI_COMMIT_REF_SLUG
paths:
- .npm/
before_script:
- npm ci --cache .npm --prefer-offline
test_async:
script:
- node ./specs/start.js ./specs/async.spec.js
```
## Contexts and variables[](#contexts-and-variables "Permalink")
CircleCI 提供了[上下文,](https://s0circleci0com.icopy.site/docs/2.0/contexts/)以跨项目管道安全地传递环境变量. 在 GitLab 中,可以创建一个[](../../user/group/index.html)来将相关项目组装在一起. 在组级别, [变量](../variables/README.html#group-level-environment-variables)可以存储在各个项目之外,并安全地传递到跨多个项目的管道中.
## Orbs[](#orbs "Permalink")
有两个 GitLab 问题需要解决 CircleCI Orb,以及 GitLab 如何实现类似功能.
* [https://gitlab.com/gitlab-com/Product/-/issues/1151](https://gitlab.com/gitlab-com/Product/-/issues/1151)
* [https://gitlab.com/gitlab-org/gitlab/-/issues/195173](https://gitlab.com/gitlab-org/gitlab/-/issues/195173)
## Build environments[](#build-environments "Permalink")
CircleCI 为`executors`提供`executors`特定工作的基础技术. 在 GitLab 中,这是由[Runners](https://docs.gitlab.com/runner/)完成的.
支持以下环境:
自我管理的跑步者:
* Linux
* Windows
* macOS
GitLab.com 共享跑步者:
* Linux
* Windows
* [Planned: macOS](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/5720)
### Machine and specific build environments[](#machine-and-specific-build-environments "Permalink")
通过告诉 GitLab 哪些 Runners 应该运行作业, [标签](../yaml/README.html#tags)可以用于在不同平台上运行作业.
在特定环境中运行的作业的 CircleCI 示例:
```
jobs:
ubuntuJob:
machine:
image: ubuntu-1604:201903-01
steps:
- checkout
- run: echo "Hello, $USER!"
osxJob:
macos:
xcode: 11.3.0
steps:
- checkout
- run: echo "Hello, $USER!"
```
在 GitLab CI / CD 中使用`tags`进行同一作业的示例:
```
windows job:
stage:
- build
tags:
- windows
script:
- echo Hello, %USERNAME%!
osx job:
stage:
- build
tags:
- osx
script:
- echo "Hello, $USER!"
```
\ No newline at end of file
# Migrating from Jenkins
> 原文:[https://docs.gitlab.com/ee/ci/jenkins/](https://docs.gitlab.com/ee/ci/jenkins/)
* [Managing the organizational transition](#managing-the-organizational-transition)
* [JenkinsFile Wrapper](#jenkinsfile-wrapper)
* [Important product differences](#important-product-differences)
* [Agents vs. Runners](#agents-vs-runners)
* [Groovy vs. YAML](#groovy-vs-yaml)
* [Artifact publishing](#artifact-publishing)
* [Integrated features](#integrated-features)
* [Templates](#templates)
* [Converting a declarative Jenkinsfile](#converting-a-declarative-jenkinsfile)
* [Sections](#sections)
* [`agent`](#agent)
* [`post`](#post)
* [`stages`](#stages)
* [`steps`](#steps)
* [Directives](#directives)
* [`environment`](#environment)
* [`options`](#options)
* [`parameters`](#parameters)
* [`triggers` / `cron`](#triggers--cron)
* [`tools`](#tools)
* [`input`](#input)
* [`when`](#when)
# Migrating from Jenkins[](#migrating-from-jenkins "Permalink")
许多 GitLab 用户已经从 Jenkins 成功迁移到 GitLab CI / CD. 为了使您入门时更容易,我们在这里收集了一些您可能会在使用之前可能会发现有用的资源.请将此页面视为" Jenkins 用户的 GitLab CI / CD"指南.
建议的步骤的以下列表是在观察能够快速完成此迁移的组织之后创建的:
1. 首先阅读《 GitLab CI / CD [快速入门指南》](../quick_start/README.html)[重要的产品差异](#important-product-differences) .
2. 了解[管理组织过渡](#managing-the-organizational-transition)的重要性.
3. [将 Runners 添加](../runners/README.html)到您的 GitLab 实例.
4. 教育开发人员并使他们能够在他们的项目中独立执行以下步骤:
1. 查看《 [快速入门指南](../quick_start/README.html)[管道配置参考》](../yaml/README.html) .
2. 使用[Jenkins 包装器](#jenkinsfile-wrapper)暂时维护脆弱的 Jenkins 作业.
3. 迁移构建和 CI 作业并将其配置为直接在合并请求中显示结果. 他们可以使用[Auto DevOps](../../topics/autodevops/index.html)作为起点,并[根据](../../topics/autodevops/customize.html)需要[自定义](../../topics/autodevops/customize.html)[分解](../../topics/autodevops/customize.html#using-components-of-auto-devops)配置.
4. 添加[评论应用](../review_apps/index.html) .
5. 使用[云部署模板](../cloud_deployment/index.html) ,添加[环境](../environments/index.html)[部署板](../..//user/project/deploy_boards.html)来迁移部署作业.
6. 使用 Jenkins 包装器解开仍在运行的所有作业的包装.
5. 盘点所有常见的 CI / CD 作业定义,然后为其创建和共享[模板](#templates) .
有关如何将 Jenkins 管道转换为 GitLab CI / CD 管道的示例,或如何使用 Auto DevOps 自动测试代码的示例,请观看[从 Jenkins 迁移到 GitLab 的](https://www.youtube.com/watch?v=RlEVGOpYF5Y)视频.
否则,请继续阅读以获取重要信息,这些信息将帮助您取得成功. 欢迎来到 GitLab!
如果您有未在此处回答的问题, [GitLab 社区论坛](https://forum.gitlab.com/)将是一个很好的资源.
## Managing the organizational transition[](#managing-the-organizational-transition "Permalink")
从詹金斯过渡到 GitLab 的一个重要部分是随之而来的文化和组织变革,并成功地对其进行了管理. 我们发现了一些有助于解决问题的方法:
* 为您的迁移目标设定并传达清晰的愿景有助于您的用户理解为什么值得付出努力. 当工作完成时,该值将很明显,但是在进行过程中,人们也需要意识到.
* 有关领导团队的赞助和配合有助于上述观点.
* 花时间对用户进行不同的教育,与他们共享此文档等等,将有助于确保您成功.
* 寻找顺序或延迟部分迁移的方法可能会很有帮助,但是您不想让事物长时间处于未迁移(或部分迁移)状态. 要获得 GitLab 的所有好处,仅将现有的 Jenkins 设置转移到原样上(包括任何当前问题)是不够的. 您需要利用 GitLab 提供的改进,这最终需要(最终)更新您的实现.
## JenkinsFile Wrapper[](#jenkinsfile-wrapper "Permalink")
我们正在构建一个[JenkinsFile 包装器](https://gitlab.com/gitlab-org/jfr-container-builder/) ,它将允许您在 GitLab 作业(包括插件)中运行完整的 Jenkins 实例. 通过让您将不太紧急的管道的迁移延迟一段时间,可以帮助简化过渡过程.
如果您有兴趣帮助 GitLab 测试包装器,请加入我们的[公共测试问题](https://gitlab.com/gitlab-org/gitlab/-/issues/215675)以获取说明并提供您的反馈.
## Important product differences[](#important-product-differences "Permalink")
值得一提的产品之间存在一些高级差异:
* 使用 GitLab,您不需要根`pipeline`关键字即可包装所有内容.
* 管道触发和[触发其他管道的](../yaml/README.html#trigger)方式与詹金斯不同. 可以触发 GitLab 管道:
* 在推
* on [schedule](../pipelines/schedules.html)
* 从[GitLab UI](../pipelines/index.html#run-a-pipeline-manually)
* by [API call](../triggers/README.html)
* by [webhook](../triggers/README.html#triggering-a-pipeline-from-a-webhook)
* by [ChatOps](../chatops/README.html)
* 您可以使用[`rules`语法](../yaml/README.html#rules)来控制在哪种情况下运行哪些作业,具体取决于触发方式.
* GitLab [管道调度概念](../pipelines/schedules.html)也与 Jenkins 不同.
* 您可以使用[`include`关键字](../yaml/README.html#include)[模板](#templates)重复使用管道配置. 您的模板可以保存在中央存储库中(具有不同的权限),然后任何项目都可以使用它们. 这个中央项目也可以包含脚本或其他可重用的代码.
* You can also use the [`extends` keyword](../yaml/README.html#extends) to reuse configuration within a single pipeline configuration.
* 单个阶段中的所有作业始终并行运行,并且所有阶段均按顺序运行. 我们计划通过我们的有[向无环图](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47063)功能允许某些作业根据需要中断此排序.
* [`parallel`](../yaml/README.html#parallel)关键字可以自动并行化任务,例如支持并行化的测试.
* 通常,单个阶段中的所有作业并行运行,并且所有阶段按顺序运行. 有不同的[管道体系结构](../pipelines/pipeline_architectures.html)允许您更改此行为.
* 建议使用新[`rules`语法](../yaml/README.html#rules)控制何时运行不同作业. 它比`only/except`语法更强大.
* 一个重要的区别是,作业彼此独立运行,并且每个作业都具有全新的环境. 使用[`artifacts`](../yaml/README.html#artifacts)[`dependencies`](../yaml/README.html#dependencies)关键字控制作业之间传递工件. 完成后,计划的[工作区](https://gitlab.com/gitlab-org/gitlab/-/issues/29265)功能将使您能够更轻松地在串行作业之间持久保留公共工作区.
* `.gitlab-ci.yml`文件已签入到存储库的根目录,非常类似于 Jenkinsfile,但采用 YAML 格式(请参阅[完整参考](../yaml/README.html) )而不是 Groovy DSL. 它与声明性 Jenkinsfile 格式最相似.
* 手动批准或登机口可以设置为以下[`when:manual`作业](../yaml/README.html#whenmanual) . 这些还可以利用[`protected environments`](../yaml/README.html#protecting-manual-jobs-premium)来控制谁可以批准它们.
* GitLab 带有[容器注册表](../../user/packages/container_registry/index.html) ,我们建议使用容器映像来设置您的构建环境. 例如,设置一个管道来构建您自己的构建环境,并将其发布到容器注册表. 然后,让您的管道使用此方法,而不是每个管道都使用它们自己的环境,这将变得更慢,并且一致性可能会降低. 我们有大量有关[如何使用 Container Registry 的](../../user/packages/container_registry/index.html)文档.
* 中央实用程序存储库是放置各种计划作业或其他功能类似于实用程序的手动作业的好地方. 詹金斯的装置中往往有一些.
## Agents vs. Runners[](#agents-vs-runners "Permalink")
Jenkins 代理和 GitLab Runners 都是运行作业的主机. 要转换 Jenkins 代理,只需将其卸载,然后[安装并注册 Runner](../runners/README.html) . 运行程序不需要太多的开销,因此您可以像使用的 Jenkins 代理一样调整它们的大小.
与代理相比,Runners 的工作方式存在一些重要差异:
* 跑步者可以设置为[在实例之间共享,也可以在组级别添加,也可以在项目级别设置](../runners/README.html#types-of-runners) . 他们将从您自动定义的范围中自动选择作业.
* 您还可以[使用标签](../runners/README.html#use-tags-to-limit-the-number-of-jobs-using-the-runner)进行更精细的控制,并将跑步者与特定工作相关联. 例如,您可以将标签用于需要专用,功能更强大或特定硬件的作业.
* GitLab 具有[针对](https://docs.gitlab.com/runner/configuration/autoscale.html) Runner 的[自动缩放功能](https://docs.gitlab.com/runner/configuration/autoscale.html) ,可让您将其配置为根据需要进行设置,并在不进行缩放时进行缩放. 这类似于詹金斯中的临时代理.
如果您使用的是`gitlab.com` ,则可以利用我们[共享的 Runner](../../user/gitlab_com/index.html#shared-runners) `gitlab.com`来运行作业,而无需置备自己的 Runners. 我们正在研究使它们也[可用于自我管理实例](https://gitlab.com/groups/gitlab-org/-/epics/835) .
## Groovy vs. YAML[](#groovy-vs-yaml "Permalink")
Jenkins 管道基于[Groovy](https://s0groovy-lang0org.icopy.site/) ,因此管道规范以代码形式编写. GitLab 的工作方式略有不同,我们使用结构更高级的[YAML](https://yaml.org/)格式,该格式将脚本元素放置在`script:`内部`script:`块与管道规范本身分开.
这是 GitLab 的优势,因为它有助于使学习曲线更简单地启动和运行,并且避免了一些不受限制的复杂性问题,这些问题会使您的 Jenkinsfile 难以理解和管理.
就是说,我们当然仍然重视 DRY(不要重复自己)的原则,并希望确保您的工作行为可以被一次编码并根据需要进行应用. 您可以使用`extends:`语法[在您的作业中重用配置](../yaml/README.html#extends)`include:`可用于在不同项目的管道中[重用管道配置](../yaml/README.html#include)
```
.in-docker:
tags:
- docker
image: alpine
rspec:
extends:
- .in-docker
script:
- rake rspec
```
## Artifact publishing[](#artifact-publishing "Permalink")
工件的工作方式可能与您与詹金斯一起使用时有所不同. 在 GitLab 中,任何作业都可以使用`artifacts:`关键字定义一组要保存的`artifacts:` . 可以将其配置为指向一个文件或一组文件,然后可以在每个作业之间将其持久化. 阅读更多关于我们详细的[工件文档的信息](../pipelines/job_artifacts.html)
```
pdf:
script: xelatex mycv.tex
artifacts:
paths:
- ./mycv.pdf
- ./output/
expire_in: 1 week
```
此外,我们还具有包管理功能,例如可以利用的内置容器,NPM 和 Maven 注册表. 您可以在[我们的文档](../../README.html#package)[包装部分中](../../README.html#package)查看打包功能的完整列表(包括指向文档的链接).
## Integrated features[](#integrated-features "Permalink")
在 Jenkins 中,您可能曾经使用插件来获得代码质量,单元测试,安全扫描等功能,但 GitLab 充分利用了我们连接的生态系统,将这些结果自动提取到您的合并请求,管道详细信息页面和其他位置. 您可能会发现实际上不需要配置任何内容即可显示这些内容.
如果它们无法正常工作,或者您想查看可用的[功能](../README.html#feature-set) ,则我们的[CI 功能索引](../README.html#feature-set)将提供捆绑功能的完整列表,并提供每个功能的文档链接.
### Templates[](#templates "Permalink")
对于高级 CI / CD 团队,项目模板可以启用管道配置的重用,并鼓励内部采购.
In self-managed GitLab instances, you can build an [Instance Template Repository](../../user/admin_area/settings/instance_template_repository.html). Development teams across the whole organization can select templates from a dropdown menu. A group administrator is able to set a group to use as the source for the [custom project templates](../../user/admin_area/custom_project_templates.html), which can be used by all projects in the group. An instance administrator can set a group as the source for [instance project templates](../../user/group/custom_project_templates.html), which can be used by projects in that instance.
## Converting a declarative Jenkinsfile[](#converting-a-declarative-jenkinsfile "Permalink")
声明性 Jenkinsfile 包含用于控制管道行为的" Sections"和" Directives". GitLab 中有所有这些的等效项,我们在下面对此进行了介绍.
本节基于[Jenkinsfile 语法文档](https://www.jenkins.io/doc/book/pipeline/syntax/) ,旨在将其中的概念映射到 GitLab 中的概念.
### Sections[](#sections "Permalink")
#### `agent`[](#agent "Permalink")
代理部分用于定义如何执行管道. 对于 GitLab,我们使用[GitLab Runner](../runners/README.html)来提供此功能. 您可以在 Kubernetes 或任何主机上配置自己的运行程序,也可以利用我们的共享运行程序队列(请注意,共享运行程序队列仅适用于 GitLab.com 用户.)以上链接将带您进入说明文档的文档如何快速起步和运行. 我们还支持使用[标签](../runners/README.html#use-tags-to-limit-the-number-of-jobs-using-the-runner)将不同的作业定向到不同的 Runner(执行代理).
`agent`部分还允许您定义应使用哪些 Docker 映像执行,而我们使用[`image`](../yaml/README.html#image)关键字. 该`image`可以设置在单个作业或顶层,在这种情况下,它将应用于管道中的所有作业:
```
my_job:
image: alpine
...
```
#### `post`[](#post "Permalink")
`post`部分定义了应在管道末尾执行的操作. GitLab 也通过阶段的使用来支持这一点. 您可以按以下方式定义阶段,分配给`before_pipeline``after_pipeline`阶段的所有作业都将按预期运行. 您可以根据需要将这些阶段称为:
```
stages:
- before_pipeline
- build
- test
- deploy
- after_pipeline
```
可以通过[`before_script`和`after_script`关键字](../yaml/README.html#before_script-and-after_script)设置要在任何作业之前和之后执行的步骤:
```
default:
before_script:
- echo "I run before any jobs starts in the entire pipeline, and can be responsible for setting up the environment."
```
#### `stages`[](#stages "Permalink")
GitLab CI / CD 也可以让您定义阶段,但是可以自由配置一些. GitLab [`stages`关键字](../yaml/README.html#stages)是一个顶级设置,它枚举了阶段列表,但是您不需要在" `stages`部分下嵌套单个作业. 通过使用[`stage:`关键字,](../yaml/README.html#stage)可以使`.gitlab-ci.yml`定义的任何作业成为任何阶段的一部分.
请注意,除非另有说明,否则每个管道都以`build``test``deploy`阶段实例化,并按该顺序运行. 未定义`stage`作业默认情况下放置在`test`阶段. 当然,引用阶段的每个作业都必须引用管道配置中存在的阶段.
```
stages:
- build
- test
- deploy
my_job:
stage: build
...
```
#### `steps`[](#steps "Permalink")
The `steps` section is equivalent to the [`script` section](../yaml/README.html#script) of an individual job. This is a simple YAML array with each line representing an individual command to be run:
```
my_job:
script:
- echo "hello! the current time is:"
- time
...
```
### Directives[](#directives "Permalink")
#### `environment`[](#environment "Permalink")
在 GitLab 中,我们使用[`variables`关键字](../yaml/README.html#variables)在运行时定义不同的变量. 这些也可以通过 CI / CD 设置下的 GitLab UI 进行设置. 另请参阅我们[有关变量](../variables/README.html)[一般文档](../variables/README.html) ,包括有关[受保护变量](../variables/README.html#protect-a-custom-variable)的部分,该部分可用于将对某些变量的访问限制为某些环境或运行程序:
```
variables:
POSTGRES_USER: user
POSTGRES_PASSWORD: testing_password
```
#### `options`[](#options "Permalink")
这里,存在与所讨论的对象本身相关联的用于不同事物的选项. 例如,与作业相关的选项是相对于作业本身定义的. 如果您正在寻找某个选项,则应该可以通过搜索[完整的配置参考](../yaml/README.html)页面来找到它的位置.
#### `parameters`[](#parameters "Permalink")
GitLab 不需要您定义在开始手动作业时希望可用的变量. 用户可以提供他们喜欢的任何变量.
#### `triggers` / `cron`[](#triggers--cron "Permalink")
Because GitLab is integrated tightly with Git, SCM polling options for triggers are not needed. We support an easy to use [syntax for scheduling pipelines](../pipelines/schedules.html).
#### `tools`[](#tools "Permalink")
GitLab 不支持单独的`tools`指令. 我们的最佳实践建议是使用预构建的容器映像,该映像可以缓存,并且可以构建为包含管道所需的工具. 可以设置管道以根据需要自动构建这些映像,并将它们部署到[容器注册表中](../../user/packages/container_registry/index.html) .
如果您没有在 Docker / Kubernetes 上使用容器映像,例如在 Mac 或 FreeBSD 上,则`shell`执行程序确实需要您预先设置环境或作为作业的一部分. 您可以创建一个`before_script`动作来为您处理.
#### `input`[](#input "Permalink")
`parameters`关键字类似,这是不需要的,因为始终可以为运行时变量条目提供手动作业.
#### `when`[](#when "Permalink")
GitLab 确实支持[`when`关键字](../yaml/README.html#when) ,用于指示在(或尽管发生)故障的情况下应在何时运行作业,但是大多数用于控制管道的逻辑都可以在我们功能非常强大的[`only/except`规则系统中找到](../yaml/README.html#onlyexcept-basic) (另请参见[高级语法](../yaml/README.html#onlyexcept-basic) ):
```
my_job:
only: [branches]
```
\ No newline at end of file
此差异已折叠。
此差异已折叠。
# Requirements for Auto DevOps
> 原文:[https://docs.gitlab.com/ee/topics/autodevops/requirements.html](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
* [Auto DevOps requirements for Kubernetes](#auto-devops-requirements-for-kubernetes)
* [Auto DevOps requirements for Amazon ECS](#auto-devops-requirements-for-amazon-ecs)
# Requirements for Auto DevOps[](#requirements-for-auto-devops "Permalink")
您可以为[Kubernetes](#auto-devops-requirements-for-kubernetes)[Amazon Elastic Container Service(ECS)](#auto-devops-requirements-for-amazon-ecs)设置 Auto DevOps. 有关 Auto DevOps 的更多信息,请参见[Auto DevOps 主页](index.html)[快速入门指南](quick_start_guide.html) .
## Auto DevOps requirements for Kubernetes[](#auto-devops-requirements-for-kubernetes "Permalink")
要充分利用 Auto DevOps 和 Kubernetes,您需要:
* **Kubernetes** (用于[自动审阅应用程序](stages.html#auto-review-apps)[自动部署](stages.html#auto-deploy)[自动监视](stages.html#auto-monitoring)
要启用部署,您需要:
1. 您的项目的[Kubernetes 1.12+集群](../../user/project/clusters/index.html) . 最简单的方法是[使用 GitLab UI](../../user/project/clusters/add_remove_clusters.html#create-new-cluster)创建[新集群](../../user/project/clusters/add_remove_clusters.html#create-new-cluster) . 对于 Kubernetes 1.16+群集,您必须为[Auto Deploy for Kubernetes 1.16+](stages.html#kubernetes-116)执行附加配置.
2. NGINX 入口. 在上一步中配置了 GitLab 的 Kubernetes 集成之后,可以通过安装[用于 Ingress](../../user/clusters/applications.html#ingress)的[GitLab 托管的应用程序,](../../user/clusters/applications.html#ingress)将其部署到 Kubernetes 集群中.
另外,您可以使用[`nginx-ingress`](https://github.com/helm/charts/tree/master/stable/nginx-ingress) Helm 图表手动安装 Ingress.
**注意:**如果您使用自己的 Ingress 而不是 GitLab 托管应用程序提供的 Ingress,请确保您至少运行的是 NGINX Ingress 0.9.0 版,并[启用 Prometheus](https://github.com/helm/charts/tree/master/stable/nginx-ingress#prometheus-metrics)指标以显示响应指标. 您还必须使用`prometheus.io/scrape: "true"`和`prometheus.io/port: "10254"` [注释](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)由 Prometheus 抓取的 NGINX Ingress 部署.
* **基本域** (用于[自动审阅应用程序](stages.html#auto-review-apps)[自动部署](stages.html#auto-deploy)[自动监视](stages.html#auto-monitoring)
您需要一个配置了通配符 DNS 的域,所有您的 Auto DevOps 应用程序都将使用该域. 如果您使用的是[GitLab 托管的 Ingress 应用程序](../../user/clusters/applications.html#ingress) ,则会自动为您配置 URL 端点.
您还必须[指定 Auto DevOps 基本域](index.html#auto-devops-base-domain) .
* **GitLab Runner** (所有阶段)
必须将 Runner 配置为运行 Docker,通常使用[Docker](https://docs.gitlab.com/runner/executors/docker.html)或[Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes.html)执行程序,并[启用特权模式](https://docs.gitlab.com/runner/executors/docker.html) . Runner 不需要安装在 Kubernetes 集群中,但是 Kubernetes 执行器易于使用,并且可以自动缩放. 您还可以使用[Docker Machine 将](https://docs.gitlab.com/runner/install/autoscaling.html)基于 Docker 的 Runner 配置为自动缩放.
如果您在第一步中配置了 GitLab 的 Kubernetes 集成,则可以通过[为 GitLab Runner](../../user/clusters/applications.html#gitlab-runner)安装由[GitLab 管理的应用程序](../../user/clusters/applications.html#gitlab-runner)将其部署到集群中.
运动员应注册为[共享亚军](../../ci/runners/README.html#shared-runners)整个 GitLab 实例或[特定的运动员](../../ci/runners/README.html#specific-runners)被分配到具体项目(默认值,如果你已经安装了 GitLab 亚军管理应用程序).
* **Prometheus** (for [Auto Monitoring](stages.html#auto-monitoring))
要启用自动监控,您需要在集群内部或外部安装 Prometheus,并配置为刮取 Kubernetes 集群. 如果已经配置了 GitLab 的 Kubernetes 集成,则可以通过安装[Prometheus](../../user/clusters/applications.html#prometheus)的[GitLab 托管的应用程序](../../user/clusters/applications.html#prometheus)将其部署到集群中.
必须为项目启用[Prometheus 服务](../../user/project/integrations/prometheus.html)集成,或者将其作为整个 GitLab 安装的[默认服务模板](../../user/project/integrations/services_templates.html)启用.
要获取响应指标(除了系统指标之外),您必须[配置 Prometheus 来监视 NGINX](../../user/project/integrations/prometheus_library/nginx_ingress.html#configuring-nginx-ingress-monitoring) .
* **cert-manager** (可选,用于 TLS / HTTPS)
要为您的应用程序启用 HTTPS 端点,必须安装 cert-manager,这是一个本地 Kubernetes 证书管理控制器,可帮助颁发证书. 在您的群集上安装 cert-manager 会发出[Let's Encrypt](https://letsencrypt.org/)证书,并确保证书有效和最新. 如果已经配置了 GitLab 的 Kubernetes 集成,则可以通过安装[GitLab 托管的 cert-manager 应用程序](../../user/clusters/applications.html#cert-manager)将其部署到集群中.
如果您没有安装 Kubernetes 或 Prometheus,则将跳过[Auto Review Apps](stages.html#auto-review-apps)[Auto Deploy](stages.html#auto-deploy)[Auto Monitoring](stages.html#auto-monitoring) .
满足所有要求后,您可以[启用 Auto DevOps](index.html#enablingdisabling-auto-devops) .
## Auto DevOps requirements for Amazon ECS[](#auto-devops-requirements-for-amazon-ecs "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) in GitLab 13.0.
您可以选择将[AWS ECS](../../ci/cloud_deployment/index.html)定位为部署平台,而不是使用 Kubernetes.
要开始使用针对 AWS ECS 的 Auto DevOps,您必须添加特定的环境变量. 这样做,请按照下列步骤操作:
1. 在您的项目中,转到**"设置">" CI / CD",**然后展开" **变量"**部分.
2. 通过添加具有以下值之一的`AUTO_DEVOPS_PLATFORM_TARGET`变量,指定在 Auto DevOps 部署期间要定位的 AWS 平台:
* `FARGATE`如果您的目标服务必须启动类型 FARGATE 的.
* `ECS`如果部署到 ECS,当你不执行任何启动类型检查.
触发管道时,如果启用了 Auto DevOps 且已正确[输入 AWS 凭证作为环境变量](../../ci/cloud_deployment/index.html#deploy-your-application-to-the-aws-elastic-container-service-ecs) ,则您的应用程序将部署到 AWS ECS.
**注意:**部署到 AWS ECS 时, [GitLab 托管应用程序](../../user/clusters/applications.html)不可用. 您必须在 AWS ECS 上手动配置应用程序(例如 Ingress 或 Help).**注意:**如果您同时具有有效的`AUTO_DEVOPS_PLATFORM_TARGET`变量和与项目绑定的 Kubernetes 集群,则仅运行 Kubernetes 的部署.**警告:**`AUTO_DEVOPS_PLATFORM_TARGET`变量设置为`ECS`将触发[`Jobs/Deploy/ECS.gitlab-ci.yml`模板中](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml)定义的[`Jobs/Deploy/ECS.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml) . 但是,不建议单独[包含](../../ci/yaml/README.html#includetemplate)它. 该模板仅设计用于 Auto DevOps. 如果单独包含它,它可能会发生意外更改,从而导致您的管道失败. 同样,此模板中的作业名称也可能会更改. 不要在自己的管道中覆盖这些作业的名称,因为当名称更改时,覆盖将停止工作.
\ No newline at end of file
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
# GitLab ChatOps
> 原文:[https://docs.gitlab.com/ee/ci/chatops/README.html](https://docs.gitlab.com/ee/ci/chatops/README.html)
* [How GitLab ChatOps works](#how-gitlab-chatops-works)
* [Best practices for ChatOps CI jobs](#best-practices-for-chatops-ci-jobs)
* [Controlling the ChatOps reply](#controlling-the-chatops-reply)
* [GitLab ChatOps examples](#gitlab-chatops-examples)
* [GitLab ChatOps icon](#gitlab-chatops-icon)
# GitLab ChatOps[](#gitlab-chatops "Permalink")
版本历史
*[GitLab Ultimate](https://about.gitlab.com/pricing/) 10.6 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4466) .
* 在 11.9 中[移至](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24780) [GitLab Core](https://about.gitlab.com/pricing/) .
GitLab ChatOps 提供了一种通过 Slack 等聊天服务与 CI / CD 作业进行交互的方法. 许多组织的讨论,协作和故障排除都是在聊天服务中进行的. 拥有一种方法来运行 CI / CD 作业并将输出回传到渠道,可以极大地增强团队的工作流程.
## How GitLab ChatOps works[](#how-gitlab-chatops-works "Permalink")
GitLab ChatOps 是基于[GitLab CI / CD](../README.html)[Slack Slash Commands](../../user/project/integrations/slack_slash_commands.html)构建的. ChatOps 使用以下参数为[斜杠命令](../../integration/slash_commands.html)提供`run`操作:
* 要执行的`<job name>` .
* The `<job arguments>`.
ChatOps 将以下[CI / CD 变量](../variables/README.html#predefined-environment-variables)传递给作业:
* `CHAT_INPUT`包含任何其他参数.
* `CHAT_CHANNEL`设置为触发该动作的通道的名称.
当执行时,ChatOps 查找指定的作业名称,并尝试将其与[`.gitlab-ci.yml`](../yaml/README.html)的相应作业匹配. 如果在`master`上找到匹配的作业,则计划仅包含该作业的管道. 作业完成后:
* 如果作业在*不到 30 分钟内完成* ,则 ChatOps 会将作业的输出发送到 Slack.
* 如果作业在*30 分钟内完成* ,则该作业必须使用[Slack API](https://api.slack.com/)将数据发送到通道.
要使用`run`命令,您必须具有[Developer 访问权限或更高权限](../../user/permissions.html#project-members-permissions) . 如果不能从聊天中触发某项工作,则可以将其设置为下列`except: [chat]` .
## Best practices for ChatOps CI jobs[](#best-practices-for-chatops-ci-jobs "Permalink")
由于 ChatOps 是基于 GitLab CI / CD 构建的,因此该作业具有可用的所有相同功能. 创建 ChatOps 作业时,请考虑以下最佳做法:
* GitLab 强烈建议您`only: [chat]`设置`only: [chat]`以便该作业不会作为标准 CI 管道的一部分运行.
* 如果作业设置为以下`when: manual` ,则 ChatOps 将创建管道,但是作业等待启动.
* ChatOps 为访问控制提供了有限的支持. 如果触发斜杠命令的用户在项目中具有" [开发人员"访问权限或更高权限](../../user/permissions.html#project-members-permissions) ,则作业将运行. 作业本身可以使用现有的[CI / CD 变量(](../variables/README.html#predefined-environment-variables)例如`GITLAB_USER_ID`来执行其他权限验证,但是可以[覆盖](../variables/README.html#priority-of-environment-variables)这些变量.
### Controlling the ChatOps reply[](#controlling-the-chatops-reply "Permalink")
单个命令的作业输出将作为答复发送到通道. 例如,以下任务的聊天回复是频道中的`Hello World`
```
hello-world:
stage: chatops
only: [chat]
script:
- echo "Hello World"
```
包含多个命令(或`before_script` )的作业将在聊天回复中返回其他内容. 在这些情况下,命令和它们的输出都包括在内,并且命令以 ANSI 颜色代码包装.
To selectively reply with the output of one command, its output must be bounded by the `chat_reply` section. For example, the following job lists the files in the current directory:
```
ls:
stage: chatops
only: [chat]
script:
- echo "This command will not be shown."
- echo -e "section_start:$( date +%s ):chat_reply\r\033[0K\n$( ls -la )\nsection_end:$( date +%s ):chat_reply\r\033[0K"
```
## GitLab ChatOps examples[](#gitlab-chatops-examples "Permalink")
GitLab.com 团队创建了一个[常见 ChatOps 脚本](https://gitlab.com/gitlab-com/chatops)的存储库,它们用于与我们的 GitLab 生产实例进行交互. 其他 GitLab 实例的管理员可能会发现它们很有用. 它们可以作为您可以编写以与自己的应用程序进行交互的 ChatOps 脚本的灵感.
## GitLab ChatOps icon[](#gitlab-chatops-icon "Permalink")
[官方的 GitLab ChatOps 图标](img/gitlab-chatops-icon.png)可以下载. 您可以在此处找到并下载官方的 GitLab ChatOps 图标.
[![GitLab ChatOps bot icon](img/b7658a174f8b110251a289f5276dc822.png)](img/gitlab-chatops-icon-small.png)
\ No newline at end of file
此差异已折叠。
# Docker integration
> 原文:[https://docs.gitlab.com/ee/ci/docker/README.html](https://docs.gitlab.com/ee/ci/docker/README.html)
# Docker integration[](#docker-integration "Permalink")
GitLab CI / CD 可以与[Docker](https://www.docker.com)结合使用,以实现两者之间的集成.
以下文档可用于将 GitLab CI / CD 与 Docker 结合使用:
* [Using Docker images](using_docker_images.html).
* [Building Docker images with GitLab CI/CD](using_docker_build.html).
* [Building images with kaniko and GitLab CI/CD](using_kaniko.html).
\ No newline at end of file
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
> 原文:[https://docs.gitlab.com/ee/ci/examples/browser_performance.html](https://docs.gitlab.com/ee/ci/examples/browser_performance.html)
\ No newline at end of file
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册