如何使用GitLab和Rancher构建CI/CD流水线 – Part 2

这是我们使用GitLab和Rancher构建CI/CD流水线系列教程的第二部分。第一部分的内容介绍了如何部署、配置和确保GitLab在Rancher的运行。这一部分中,我们将介绍如何使用GitLab CI Multi-Runner构建容器,以及如何使用GitLab容器registry配置项目。除此之外,我们还将涉及如何用GitLab CI建立容器并部署到Rancher上。

使用GitLab CI Multi-Runner构建容器

GitLab CI是用于持续集成和持续交付的强大工具。它需要和Rancher配合使用,这里我们将部署一个执行作业的runner。

运行Runner

部署runner有好几种方式,不过考虑到我们的目的是要从自己的存储库中建立容器,我们将运行一个可以直接访问/var/run/docker.sock的Docker容器,来构建和自身同步的镜像。

  1. 在Rancher中,向你的Gitlab栈添加一个服务。
  2. 使用以下配置进行设置:
  • Name: runner01
  • Image: gitlab/gitlab-runner
  • Console: None
  • Volumes:
    • /var/run/docker.sock:/var/run/docker.sock
    • runner01-etc:/etc/gitlab-runner

容器运行时,它将在/etc/gitlab-runner中创建一个默认配置,该配置对应我们已经建立连接的卷。接下来,用你的Gitlab实例注册runner。

下面操作中,我设置的配置适用于基本的runner,它可以搭建任意作业。你还可以将runner限制在指定的存储库中或是使用其他的镜像。这里你可以阅读GitLab的文档来了解是最适合你的环境的选项。

配置Runner

  1. 在容器中执行shell
  2. 运行gitlab-ci-multi-runner register开始注册
  3. 按照提示信息输入,参考下列示例(答案是粗体字)

[email protected]:/# gitlab-ci-multi-runner register

Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):

https://git.example.com

Please enter the gitlab-ci token for this runner:

DGQ-J7n0tR33LXB3z_

Please enter the gitlab-ci description for this runner:

[4bd974b1c799]: runner01

Please enter the gitlab-ci tags for this runner (comma separated):

<press enter>

Whether to lock Runner to current project [true/false]:

[false]: <press enter>

Registering runner… succeeded runner=DGQ-J7dD

Please enter the executor: docker, parallels, ssh, docker-ssh+machine, kubernetes, docker-ssh, shell, virtualbox, docker+machine:

docker

Please enter the default Docker image (e.g. ruby:2.1):

docker:stable

Runner registered successfully.

放手去执行它们吧,如果runner已经运行,那么配置会自动地就重新加载。这里要着重注意的是:

  • 输入你的Gitlab实例的URL
  • 输入runner令牌(在Admin / Runners中找到)
  • 给runner起一个可被识别的名字
  • 选择runner的docker类型
  • 选择docker:stable容器镜像

在初始的注册完成后,我们需要编辑/etc/gitlab-runner/config.tom并作出调整:

  • volumes = [“/var/run/docker.sock:/var/run/docker.sock”, “/cache”]

这样在容器中装载/var/run/docker.sock,使得构建的容器保存在主机本身的镜像存储中。这是一个比Docker更好的方法。

config.toml的修改是由Runner自动执行的,因此无需重新启动。

你可以在Admin/Runners下看到你的runner并与之交互。

使用容器镜像仓库配置项目

GitLab的容器镜像仓库直接和存储库绑定,因此无法将容器转移到任何其他位置。如果你在docker组中有一个名为demo-pho的存储库,那么镜像的路径就是registry.example.com/docker/demo-php ,其中的标签是根据你如何用GitLab CI创建容器而定义的。

在本教程的余下部分,我将使用一个存储库,该存储库的内容可以在github中找到。需要执行以下内容才能在你的GitLab环境中启动它:

  1. 在GitLab中创建一个项目。在本教程中,我给它命名为example/demo(工作组是example,项目是demo)
  2. 克隆并修改rancher-gitlab-demo存储库
$ git clone https://github.com/oskapt/rancher-gitlab-demo.git demo
$ cd demo
$ git remote set-url origin ssh://[email protected]:2222/example/demo.git
$ git push -u origin master

该文件如下所示:

variables:
 REGISTRY_HOST: registry.example.com
 TEST_IMAGE: $REGISTRY_HOST/$CI_PROJECT_PATH:$CI_BUILD_REF_NAME
 RELEASE_IMAGE: $REGISTRY_HOST/$CI_PROJECT_PATH:latest
stages:
 - build
 - release
before_script:
 - docker info
 - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $REGISTRY_HOST
build:
 stage: build
 script:
   - docker build --pull -t $TEST_IMAGE .
   - docker push $TEST_IMAGE
release:
 stage: release
 script:
   - docker pull $TEST_IMAGE
   - docker tag $TEST_IMAGE $RELEASE_IMAGE
   - docker push $RELEASE_IMAGE
 only:
   - master
push_to_docker_hub:
 # in order for this to work you will need to set
 # `HUB_USERNAME` and `HUB_PASSWORD` as CI variables
 # in the Gitlab project
 stage: release
 variables:
   DOCKER_IMAGE: $HUB_USERNAME/$CI_PROJECT_NAME:latest
 script:
   - docker login -u $HUB_USERNAME -p $HUB_PASSWORD
   - docker tag $RELEASE_IMAGE $DOCKER_IMAGE
   - docker push $DOCKER_IMAGE
 only:
   - master
 when: manual

我设计的这个CI文件可以在多个基本的Docker项目中使用而无需任何修改。在将变量部分的项目设置为你想要的数值后,文件的其余部分就能适用于任何项目。

这里有两个阶段——构建和发布。GitLab有自己的token,可令自己登录到自己的镜像仓库,该操作在before_script部分执行。接下来它在构建阶段执行脚本命令,构建容器并使用TEST_IMAGE变量中指定的格式标记容器。这样获得一个有分支名称的容器,就像我们的develop分支这样:

registry.example.com/example/demo:develop

接下来会推送容器信息进镜像仓库中。

如果是master分支,它会执行所有这些步骤,并且在发布阶段,它在加进镜像仓库前会继续使用latest标记镜像。这样你会得到一个同时标记了master和lastest的容器。其中lastest是默认的标签名,你可以在不指定标签名的情况下获取它。

最后,master分支有一个可供使用的手动选项,可将容器推送至Docker Hub。若要实现这一步,首先需要在GitLab项目中的Settings | CI/CD Pipelines | Secret Variables下设置HUB_USERNAME和HUB_PASSWORD。GitLab CI将根据DOCKER_IMAGE的值重新标记master镜像,接着将其推送至Docker Hub。因为我们已经指定了when下的manual,GitLab不会自动执行,那么就必须从GitLab手动执行此阶段。

通过GitLab CI搭建容器

在develop分支,你可以提交这些更改并将其推送到你的GitLab项目。如果一切都正常运行,你就可以在项目的pipelines标签下看到pipeline启动。你可以选择status图标来查看该阶段下的详细进度日志。

如果出现了任何错误,GitLab CI将报告pipeline失败,你可以查看日志了解原因。当解决了问题并推送新的提交时,GitLab CI将启动新的pipeline。如果错误是暂时的(如无法连接到Docker Hub),你可以再次运行该阶段的pipeline。

如果只想从现有的代码运行pipeline,你可以单击Run Pipeline并选择要构建的分支。

当一切都完成之后,管道会显示Passed,你可以在GitLab项目的Registry标签下看到你的容器。

创建部署用户

在使用镜像仓库之前,你需要将部署用户添加到Rancher。我建议你在你想要部署的项目上创建一个具有Reporter权限的deploy用户,而不要使用你的管理员账户。

  1. 单击右上角的扳手图标进入管理区域
  2. 单击中间列下端的New User按钮
  3. 创建一个名为deploy的用户
  4. 在Access下则说明该用户是External的。这将给用户提供GitLab中的限制访问。
  5. 单击Create User,进入汇总界面

GitLab默认会为用户发送登录电子邮件,因此我们需要编辑用户并设置密码。

  1. 在汇总界面上,单击右上角的Edit
  2. 为用户设置密码,接着单击Save Changes
  3. 在GitLab导航到你的项目,单击Settings后点击Members
  4. 在搜索栏键入deploy并选择deploy用户
  5. 给用户Reporter权限
  6. 点击Add to project保存更改

现在,deploy用户有权从你的项目的容器注册表访问容器。

部署容器到Rancher

我们到目前为止的所有步骤都是为了这一步——从你的私有镜像仓库中获取容器并将它部署到Rancher上。我们需要做的最后一件事是添加镜像仓库,然后做一个新的栈和服务。

  1. 在Rancher中,单击Infrastructure并选择Registries
  2. 单击Add Registry
  3. 选择Custom
  4. 输入你的注册表URl(例如example.com)
  5. 输入你的部署用户的用户名和密码
  6. 单机Create

把镜像仓库添加到Rancher之后,你已经可以从这些镜像中创建服务了。

  1. 创建一个名为demo的栈
  2. 添加一个服务,名字由你决定。让镜像使用你新的容器镜像中的develop标签
  • example.com/example/demo:develop

点击Create

恭喜你!你刚刚已经用私有容器镜像仓库部署了项目的开发版本!

从这里开始可以做什么

这是一个漫长的教程,但当所有的重要步骤完成后,你可以使用已经安装好的工具开始工作了。从现在开始你可以做这些事情:

  • 为你其他的项目设置工作组。对于将要包含的项目,可以使用逻辑集合,像docker或者websites一样。
  • 将其他项目导入GitLab
  • 设置GitLab CI来构建容器
  • 修改master分支,融合develop分支,引入.gitlab-ci.yml,然后将其推送至GitLab。更新Rancher以获取lastest镜像标签。
  • 将HUB_USERNAME和HUB_PASSWORD添加到项目中,然后手动将你的镜像推送至Docker Hub

原文来源:Rancher Labs

时间: 2024-10-06 23:49:13

如何使用GitLab和Rancher构建CI/CD流水线 – Part 2的相关文章

如何使用GitLab和Rancher构建CI/CD流水线–Part 1

介绍 GitLab核心是集成管理Git存储库的工具.比如你希望创建一个提供服务的平台,那么GitLab将提供强大的身份验证和授权机制.工作组.问题跟踪.wiki和片段,除此之外还有公有.内部和私有存储库. GitLab强大之处在于,它包含强大的持续集成(CI)引擎和Docker容器镜像仓库,让使用者从开发到发布都使用相同的实用工具.它还有两个更强大的开源软件实用工具:Prometheus负责监控,Mattermost负责和团队沟通.该平台有着坚实的API并能和多个现有第三方系统集成,如:JIRA

Rancher 构建 CI/CD 自动化流程 - 动态配置 Jenkins-slave(二)

一.说明 1.1 说明 前面介绍采用 Jenkinsfile + KubernetesPod.yaml 方式进行部署项目(Rancher 构建 CI/CD 自动化流程 - 动态配置 Jenkins-slave(一)),maven.kubectl 等容器工具需要在 KubernetesPod.yaml 中定义,存放在代码中,比较繁琐. 这里采用 Jenkinsfile + docker in docker 方式进行部署,把 maven 等工具都运行在 docker 容器中,这样减少了 yaml 文

5步实现规模化的Kubernetes CI/CD 流水线

一.背景在近几年,Kubernetes迅速成为了容器编排的事实上的开源标准.与虚拟机不同,Kubernetes在抽象化基础架构的同时可靠地大规模编排容器,这可以帮助开发人员将工作负载与基础架构的复杂性质分开.Kubernetes是CI/CD自动化的理想选择,因为它提供了许多内置功能,这些功能使应用程序部署实现标准化和可重用,提高了开发人员的生产力,并加快了云原生应用程序的采用.Platform9是成立于2013年的云服务提供商,能够提供业界唯一由SaaS管理的混合云解决方案,使用户能够快速采用云

rancher+gitlab+appveyor 实现 CI/CD 流水线(汇总)

rancher+gitlab+appveyor 实现 CI/CD 流水线 本文主要是做一些汇总,将近期接触并弄好的一些工具整合起来,弄一套流水线,减轻一定工作压力 工具介绍 所有的组件都是使用 docker 跑的,所以一款好用的 docker 的 ui 管理工具很重要,那就是rancher.这里只是用来管理一些工具,有点屈才了 项目代码托管使用 gitlab,其内置了 CI/CD,成套使用,非常方便 appveyor 也是一个 CI/CD 解决方案,基于asp.net core开发.其内置 nu

Jenkins与Docker的自动化CI/CD流水线实战

Jenkins与Docker的自动化CI/CD流水线实战 标签(空格分隔): docker的部分 一:什么是CI/CD 二: 发布流程设计 三:部署Git仓库并上传测试代码 一:什么是CI/CD 持续集成(Continuous Integration,CI):代码合并.构建.部署.测试都在一起,不断地执行这个过程,并对结果反馈. 持续部署(Continuous Deployment,CD):部署到测试环境.预生产环境.生产环境. 持续交付(Continuous Delivery,CD):将最终产

容器平台自动化CI/CD流水线实操

CI/CD----(实操说明) CI/CD 持续集成(Continuous Integration, CI):  代码合并,构建,部署,测试都在一起,不断地执行这个过程,并对结果反馈. 持续部署(Continuous Deployment, CD): 部署到测试环境.预生产环境.生成环境. 持续部署(Continuous Delivery, CD):  将最终产品发布到生成环境.给用户使用. Jenkins与容器技术CI/CD实战 说明:这张图稍微更形象一点,上线之前先把代码git到版本仓库,然

docker与jenkins的自动化CI/CD流水线实战

docker与jenkins的自动化CI/CD流水线实战 在互联网时代,对于每一家公司,软件开发和发布的重要性不言而喻,目前已经形成一套标准的流程,最重要的组成部分就是持续集成(CI)及持续部署.交付(CD).本文基于Jenkins+Docker+Git实现一套CI自动化发布流程. 高效的CI/CD环境可以获得: ? 及时发现问题 ? 大幅度减少故障率 ? 加快迭代速度 ? 减少时间成本 一.发布流程设计 总结:开发===>提交代码到Git/Svn===>推送到Jenkins====>通

Jenkins与Docker/Kubernetes的自动化CI/CD流水线实践--免费直播课等你来约

直播老师简介: 李振良·奇虎360-高级运维工程师,主要负责360浏览器业务运维.7年互联网运维工作经验,具备丰富的运维实战经验,曾主导容器云平台建设并将业务容器化部署 老师博客专栏地址:基于Kubernetes企业级容器云平台落地与实践 直播课内容大纲: 1.什么是CI/CD?2.Jenkins Pipeline2.Jenkins与Docker发布JAVA项目3.Jenkins与Kubernetes发布JAVA项目 直播时间: 2018年7月26日(本周四)晚8点30分--9点30分 QQ群直

通过Jenkins与Docker构建CI/CD基础架构

###前言 提到容器平台,最早接触的便是LXC(Linux Container),是2010年刚刚接触虚拟化平台的时候,当时开源解决方案是xen的天下(后来KVM才后来者居上),且性能各方面都不弱,价值当时还不是移动互联网时代,业务量远远没有那么大,大部分公司都是物理机部署应用,用虚拟化平台的公司也是寥寥无几,可想而知,没有业务,没有场景,那就没有技术的用武之地了,所以,LXC生而伟大而用不逢时,Docker之所以能够青出于蓝而胜于蓝,取得如此大的成功的原因还是归咎于移动互联网带来的流量大爆炸,