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

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介:

这是我们使用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. 按照提示信息输入,参考下列示例(答案是粗体字)


root@4bd974b1c799:/# 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存储库

1
2
3
4
$ git clone https: //github.com/oskapt/rancher-gitlab-demo.git demo
$ cd demo
$ git remote set-url origin ssh: //git@git.example.com:2222/example/demo.git
$ git push -u origin master

该文件如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
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分支这样:

1
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



本文转自 RancherLabs 51CTO博客,原文链接:http://blog.51cto.com/12462495/1953181

相关实践学习
通过容器镜像仓库与容器服务快速部署spring-hello应用
本教程主要讲述如何将本地Java代码程序上传并在云端以容器化的构建、传输和运行。
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
6天前
|
Kubernetes 持续交付 Go
创建一个基于Go程序的持续集成/持续部署(CI/CD)流水线
创建一个基于Go程序的持续集成/持续部署(CI/CD)流水线
|
6天前
|
JSON API 数据格式
1api触发gitlab流水线
1api触发gitlab流水线
6-14|gitlab的runner的流水线怎么看
6-14|gitlab的runner的流水线怎么看
|
2月前
|
数据可视化 jenkins 测试技术
GitLab CI/CD 和 Jenkins对比
8月更文挑战第25天
72 5
|
2月前
|
jenkins Java 测试技术
CI/CD 流水线的设计与实施
【8月更文第30天】持续集成(Continuous Integration, CI)和持续交付(Continuous Delivery, CD)是现代软件开发中的重要组成部分。CI/CD 不仅可以加速产品的发布周期,还能提高软件的质量并减少部署过程中的风险。本文将详细介绍 CI/CD 流水线的设计与实施,并提供一些实用的工具和最佳实践。
50 2
|
2月前
|
jenkins 持续交付 API
enkins学习笔记之十一:优化Gitlab提交流水线
enkins学习笔记之十一:优化Gitlab提交流水线
enkins学习笔记之十一:优化Gitlab提交流水线
|
2月前
|
Java Spring 传感器
AI 浪潮席卷,Spring 框架配置文件管理与环境感知,为软件稳定护航,你还在等什么?
【8月更文挑战第31天】在软件开发中,配置文件管理至关重要。Spring框架提供强大支持,便于应对不同环境需求,如电商项目的开发、测试与生产环境。它支持多种格式的配置文件(如properties和YAML),并能根据环境加载不同配置,如数据库连接信息。通过`@Profile`注解可指定特定环境下的配置生效,同时支持通过命令行参数或环境变量覆盖配置值,确保应用稳定性和可靠性。
41 0
|
2月前
|
jenkins Devops Java
jenkins学习笔记之十:配置Gitlab提交流水线
jenkins学习笔记之十:配置Gitlab提交流水线
|
2月前
|
敏捷开发 测试技术 持续交付
阿里云云效产品使用合集之流水线构建出现问题,连接不到nuget,该如何处理
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
2月前
|
Devops 持续交付 开发者
.NET自动化之旅:是Azure DevOps还是GitHub Actions能够打造完美的CI/CD流水线?
【8月更文挑战第28天】在现代软件开发中,持续集成(CI)与持续部署(CD)是提升代码质量和加速交付的关键实践。对于 .NET 应用,Azure DevOps 和 GitHub Actions 等工具可高效构建 CI/CD 流水线,提升开发效率并确保软件稳定可靠。Azure DevOps 提供一站式全流程管理,支持 YAML 定义的自动化构建、测试和部署;GitHub Actions 则以简洁灵活著称,适用于 .NET 项目的自动化流程。选择合适的工具可显著提高开发效率并确保高质量标准。
15 0
下一篇
无影云桌面