51

GitLab Auto DevOps功能与Kubernetes集成教程

 4 years ago
source link: https://segmentfault.com/a/1190000018961978?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

介 绍

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

aqiamqu.png!web

背 景

什么是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/ranc...

目前,授权集群端点功能暂时仅适用于使用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/to...

  • 运行版本v2.2.0或更高版本的Rancher实例:您可以以单节点模式启动Rancher( https://rancher.com/quick-start/ ),也可以创建HA安装( https://rancher.com/docs/ranc... )。
  • Rancher管理的Kubernetes集群:您还需要一个通过RKE配置的、Rancher上管理的集群。此外,集群中需要有一个管理员用户,如果您使用的是GitLab.com,则需要通过公共网络访问控制平面节点。

设置Rancher和Kubernetes

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

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

登录Rancher并导航到要集成的下游集群。在本演示中,我们将在EC2实例上创建一个名为testing的集群,该集群在Amazon中运行:

iMvUjmr.png!web

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

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

nmABN3A.png!web

在我的示例中,此集群的名称是testing-testing-2,并且端点server是AWS提供的公共IP。

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

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

zEVZVjy.png!web

复制token字段(不包括引号)并保存。

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

MbYZV3b.png!web

设置GitLab项目

通过我们从Rancher收集的信息,我们现在可以配置GitLab了。我们将首先在GitLab中创建一个新项目,该项目将使用Auto DevOps功能与我们的Kubernetes集群集成。

首先,登录GitLab,然后选择New Project。

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

NnMfeiF.png!web

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

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

在项目页面左侧的菜单窗格中,选择“设置”>“CI / CD”。展开“ 环境变量”部分,并设置以下变量: V3qMzu3.png!web

我们这次会禁用下图这些功能,因为我们的简单示例暂时不需要它们,并且它们会延长部署所需的时间。在实际项目中,您可以根据您的实际需求启用其中一些选项:

ayIFjaU.png!web

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

连接GitLab和Rancher

现在,我们已准备好将我们的GitLab项目与Rancher管理的Kubernetes集群集成。

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

按以下信息填写相应字段:

FBZbIrF.png!web

YzMf6zU.png!web

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

GitLab连接到集群时所做的第一件事就是为项目创建一个命名空间。如果您在一段时间后没有看到创建名称空间,则说明可能出现了一些问题。

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

接下来,安装Ingress,它将允许GitLab将流量路由到您的应用程序:

6jmi6rB.png!web

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

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

3IjA32B.png!web

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

BFJbamF.png!web

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

BFJbamF.png!web

验证Rancher中的部署

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

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

GitLab代表您创建了两个命名空间:一个是gitlab-managed-apps,另一个是唯一的应用程序命名空间。gitlab-managed-apps命名空间包含资源,如用于部署应用程序的nginx 和Helm tiller实例。那个应用程序的唯一命名空间,包含着应用程序的部署。

为了将这些进一步可视化,我们可以将这些命名空间移动到我们的Default项目中。您也可以使用任何其他项目。单击“移动”按钮,然后选择所需的项目:

J7ZFreV.png!web

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

VBrIve6.png!web

请注意部署名称下的443 / https链接。单击该链接,您就可以跳转至您的部署的通配符域的ingress。如果一切顺利,你将可以看到这个象征着成功的页面:

ZVRn6zZ.png!web

结 语

恭喜!您刚刚成功地使用授权集群端点将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 预约此次课程,周三晚使用同一链接即可观看直播!


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK