GitLab Auto DevOps功能与Kubernetes集成教程

介 绍

在这篇文章中，咱们将介绍如何将GitLab的Auto DevOps功能与Rancher管理的Kubernetes集群链接起来，利用Rancher v2.2.0中引入的受权集群端点的功能。经过本文，你将能全面了解GitLab如何与Kubernetes集成，以及Rancher如何使用受权集群端点简化这一集成工做的流程。本文很是适合Kubernetes管理员、DevOps工程师，或任何想将其开发工做流与Kubernetes进行集成的人。

背 景

什么是GitLab Auto DevOps？

Auto DevOps是在GitLab 10.0中引入的功能，它让用户能够设置自动检测、构建、测试和部署项目的DevOps管道。将GitLab Auto DevOps与Kubernetes集群配合使用，这意味着用户能够无需配置CI / CD资源和其余工具，便可以部署应用程序。

什么是Rancher的受权集群端点？

从v2.2.0开始，Rancher引入了一项名为Authorized Cluster Endpoint的新功能，用户能够直接访问Kubernetes而无需经过Rancher进行代理。在v2.2.0以前，若是要直接与下游Kubernetes集群通讯，用户必须从各个节点手动检索kubeconfig文件以及API服务器地址。这不只增长了操做的复杂度，并且尚未提供一种机制来控制经过Rancher管理集群时可用的细化权限。

从Rancher v2.2.0开始，部署Rancher管理的集群时，默认状况下会启用受权群集端点（ACE）功能。ACE将部分Rancher身份验证和受权机制推送到下游Kubernetes集群，容许Rancher用户直接链接到这些集群，同时仍遵照安全策略。

若是您已为某些项目中的某个用户明确授予了权限，则当该用户使用受权集群端点进行链接时，这些权限能自动生效应用。如今，不管用户是经过Rancher仍是直接链接到Kubernetes集群，安全性都能获得保障。

受权集群端点功能的相关文档对此有更详细的说明：

https://rancher.com/docs/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#authorized-cluster-endpoint

注意

目前，受权集群端点功能暂时仅适用于使用Rancher Kubernetes Engine（RKE）启动的下游Kubernetes进群。

前期准备

要将GitLab Auto DevOps与Rancher管理的Kubernetes集群进行对接，您须要实现准备好：

• 一个GitLab.com账户，或一个自托管GitLab实例上的账户（需已启用Auto DevOps）：GitLab.com账户须要已经配置好了Auto DevOps。若是您使用的是自托管GitLab实例，则能够参考这一GitLab文档了解如何启用Auto DevOps：https://docs.gitlab.com/ee/topics/autodevops/

• 运行版本v2.2.0或更高版本的Rancher实例：您能够以单节点模式启动Rancher（https://rancher.com/quick-start/），也能够建立HA安装（https://rancher.com/docs/rancher/v2.x/en/installation/ha/）。

• Rancher管理的Kubernetes集群：您还须要一个经过RKE配置的、Rancher上管理的集群。此外，集群中须要有一个管理员用户，若是您使用的是GitLab.com，则须要经过公共网络访问控制平面节点。

设置Rancher和Kubernetes

首先，咱们须要先将Rancher和Kubernetes设置好。该过程的第一部分主要涉及收集信息。

注意

为简单起见，这些步骤使用的是Rancher中默认的admin账户。最佳实践要求您使用独立用户执行此类过程，并限制该用户对正在集成GitLab的集群的权限。

登陆Rancher并导航到要集成的下游集群。在本演示中，咱们将在EC2实例上建立一个名为testing的集群，该集群在Amazon中运行：

在集群的仪表板上，单击顶部的Kubeconfig File按钮。这将打开kubeconfig集群的文件，其中包括受权集群端点的信息。

kubeconfig文件中的第一个条目是经过Rancher服务器的集群端点。向下滚动以标识此集群的受权群集端点，该集群列为单独的集群条目：

在个人示例中，此集群的名称是testing-testing-2，而且端点server是AWS提供的公共IP。

复制server和certificate-authority-data字段的值，不包括引号，并保存它们。

在kubeconfig文件中进一步向下滚动并找到您的用户名和token：

复制token字段（不包括引号）并保存。

接下来解码证书受权机构数据的base64版本，将其转换回原始版本并保存。根据您的工具，一些可行的选项包括：

设置GitLab项目

经过咱们从Rancher收集的信息，咱们如今能够配置GitLab了。咱们将首先在GitLab中建立一个新项目，该项目将使用Auto DevOps功能与咱们的Kubernetes集群集成。

首先，登陆GitLab，而后选择New Project。

在“新建项目”页面上，选择“从模板建立”选项卡。这将为您提供要使用的模板项目列表。选择NodeJS Express，而后单击“Use template”：

为项目命名，并将“可见性级别”设置为“ 公共”。完成后单击“ 建立项目”。

注意

在我撰写本文时，可见性级别能够设为“私密”，不过这是GitLab的Auto DevOps实验性功能。

在项目页面左侧的菜单窗格中，选择“设置”>“CI / CD”。展开“ 环境变量”部分，并设置如下变量：

咱们此次会禁用下图这些功能，由于咱们的简单示例暂时不须要它们，而且它们会延长部署所需的时间。在实际项目中，您能够根据您的实际需求启用其中一些选项：

单击“ 保存变量”以完成GitLab项目配置。

链接GitLab和Rancher

如今，咱们已准备好将咱们的GitLab项目与Rancher管理的Kubernetes集群集成。

在GitLab中，选择新克隆的项目。在左侧菜单中，选择“ 操做”>“Kubernetes”。单击绿色“添加Kubernetes集群”按钮。在下一页上，选择“添加现有集群”选项卡。

按如下信息填写相应字段：

单击“ 添加Kubernetes集群”。GitLab将添加集群，并在其中建立新的命名空间。您能够查看Rancher接口，确认新建立的命名空间已经建立成功。

注意

GitLab链接到集群时所作的第一件事就是为项目建立一个命名空间。若是您在一段时间后没有看到建立名称空间，则说明可能出现了一些问题。

将集群添加到GitLab后，将显示要安装到集群中的应用程序列表。第一个是Helm Tiller。继续，单击“ 安装”将其添加到集群。

接下来，安装Ingress，它将容许GitLab将流量路由到您的应用程序：

根据您配置进群的方式，您的入口端点可能会自动填充，也可能不会。在本教程中，我将使用xip.io主机名来指向单个节点的流量。至于您的用例，您可能须要设置通配符域并将其指向此ingress（或指向您的节点IP等）。

部署好ingress后，滚动到页面顶部并找到“基本域”字段。输入其中一个节点的公共IP地址，而后输入.xip.io。这将建立一个解析为该IP地址的通配符域，这对于咱们的示例就足够了：

接下来，在导航栏中，选择“设置”>“CI / CD”。展开“ 自动DevOps”部分，而后选中“默认为自动DevOps管道”框。这不只意味着Auto DevOps已被设为默认值，还可以触发构建。将“部署策略”设置为“ 继续部署到生产”：

检查Auto DevOps框后，管道运行将开始。导航到GitLab中的CI / CD>管道。您应该看到相似于下图的内容，这代表GitLab正在部署您的应用程序：

验证Rancher中的部署

下面让咱们回到Rancher，查看一下咱们的部署的状况，看看资源是如何转换为Rancher界面中的Kubernetes对象的。

在Rancher中，导航到您的进群，而后单击顶部导航菜单中的Projects / Namespaces。

GitLab表明您建立了两个命名空间：一个是gitlab-managed-apps，另外一个是惟一的应用程序命名空间。gitlab-managed-apps命名空间包含资源，如用于部署应用程序的nginx 和Helm tiller实例。那个应用程序的惟一命名空间，包含着应用程序的部署。

为了将这些进一步可视化，咱们能够将这些命名空间移动到咱们的Default项目中。您也可使用任何其余项目。单击“移动”按钮，而后选择所需的项目：

移动命名空间后，导航到他们所属的项目，而后导航到Workloads页面。该页面将在其特定于应用程序的命名空间中显示您的新部署：

请注意部署名称下的443 / https连接。单击该连接，您就能够跳转至您的部署的通配符域的ingress。若是一切顺利，你将能够看到这个象征着成功的页面：

结 语

恭喜！您刚刚成功地使用受权集群端点将GitLab的Auto DevOps与Rancher管理的Kubernetes集群链接，以实现更安全、直接的链接了！

当探索Rancher的其余区域时，你可能会注意到GitLab以你的名义为你建立的其余对象。例如，“负载均衡”选项卡显示已部署的L7 ingress以及建立的主机名。您还能够在“服务发现”选项卡下查看部署的应用程序的内部服务。

GitLab的Auto DevOps功能不只易于使用，并且可定制且功能强大。在本文的演示中，咱们禁用了一些高级功能，如自动测试、依赖项扫描和许可管理。这些功能在后期也能够从新启用，并经过配置GitLab，为您的开发环境提供更多意想不到的便利与价值。除了Auto DevOps以外，GitLab还为CI / CD提供了.gitlab-ci.yml文件，用户能够借此进行更多的扩展定制。在GitLab的文档中您能够了解到更多信息：

https://docs.gitlab.com

在Kubernetes和Rancher上构建CI / CD流水线

Kubernetes的一大价值，就是为企业优化开发操做流程，而CI工做流与Kubernetes的集成，是大多团队极关注的重要部分。

本周三（4月24日）晚20:30，Rancher将举办免费的在线培训《企业如何构建CI/CD流水线》，本次直播中，咱们将分享：

• 如何对接GitLab

• 构建镜像

• 发布镜像到内置的镜像仓库

• 发布镜像到远端仓库

• 经过流水线部署应用

• 经过应用商店发布本身的应用

• 如何设置流水线通知

您能够点击连接：http://live.vhall.com/729465809 预定这次课程，周三晚使用同一连接便可观看直播！