GitLab+Docker搭建CI/CD自动化部署

简介:

1.使用场景
CICD,顾名思义就是持续集成(Continuous Integration)和持续部署(Continuous Deployment)简称,指在开发过程中自动执行一系列脚本来减低开发引入 bug 的概率,在新代码从开发到部署的过程中,尽量减少人工的介入。
以前的老技术,比如git/svn+jenkins这种,jenkins的配置多数还是依赖于负责维护CI的人,很多人不熟悉jenkins怎么配置,每一个步骤应该怎么编译和测试,一般都由CI的人来定义。
而CICD,其实可以使用jenkinsfile,就象gitlab的 .gitlab-ci.yaml文件,把CICD的流程控制和步骤也作为开发的一部分,由开发去维护。并且可以很快的部署到多个环境。
持续集成
持续集成指在和向远程仓库 push 代码后,在这次提交合并入主分支前进行一系列测试,构建等流程。假设现在有个应用的代码存储在 gitlab 上,每天开发者都 push 很多次提交,针对每次 push,你可以创建一系列脚本进行自动测试,降低往应用里引入错误的概率。这就是持续集成,它可应用在包括开发分支在内的多个分支上。
持续部署
持续部署在持续集成的基础上更进一步,指将推送指仓库默认分支的部署至产品环境。如果这部分需要手动触发,这就是一个持续交付(Continuous Delivery)环节。

  1. 安装环境
    Gitlab 内置了 CICD 工具,不需要使用第三方工具。使用gitlab的CICD流程,使用物联管理平台项目为例子。搭建一个pipe。一旦提交代码,自动将物联管理平台部署到docker(k8s集群)中。

使用到的技术有: docker,gitlab-runner,linux shell,(k8s,helm)
环境:
IP 安装软件
172.26.67.109 docker、gitlab
172.26.67.108 docker、gitlab-runner

2.1 安装docker和docker-compose
在两台服务器上安装docker,百度或参考以前写的《Centos7下安装Docker.docx》、《通过 docker-compose 快速构建部署.docx》
2.2 安装gitlab
在172.26.67.109上使用docker安装gitlab
在172.26.67.109上编写一个docker-compose.yml文件
version: '3'
services:

gitlab:
  image: twang2218/gitlab-ce-zh 
  restart: always
  container_name: "gitlab"      
  privileged: true
  hostname: "172.26.67.109"
  environment:        
    GITLAB_OMNIBUS_CONFIG: |
      external_url 'http://172.26.67.109'
      gitlab_rails["time_zone"] = "Asia/Shanghai"
      gitlab_rails["gitlab_shell_ssh_port"] = 1222
      nginx["listen_port"] = 80
  
  ports:
    - "80:80"
    - "8443:443"
    - "1222:22"
  
  volumes:
    - ./gitlab/config:/etc/gitlab
    - ./gitlab/data:/var/opt/gitlab
    - ./gitlab/logs:/var/log/gitlab
    - "/etc/localtime:/etc/localtime:ro"

然后docker-compose up -d运行𧘖安装gitlab,𧘖安装后浏览器打开http://172.26.67.109

创建组、用户、项目等
2.3 安装gitlab-runner
在172.26.67.108上使用docker安装gitlab-runner
在172.26.67.108上编写一个docker-compose.yml文件
version: '3'
services:
gitlab-runner:

  container_name: gitlab-runner
  restart: always  
  privileged: true
  image: gitlab/gitlab-runner      
  volumes:
    - "/var/run/docker.sock:/var/run/docker.sock"
    - "./gitlab-runner/config:/etc/gitlab-runner"
    - "/etc/localtime:/etc/localtime:ro"

然后docker-compose up -d运行𧘖安装gitlab-runner,然后注册gitlab-runner到gitlab上
1、从gitlab上获取注册令牌

2、注册gitlab-runner
docker exec -it gitlab-runner gitlab-ci-multi-runner register -n \
--url http://172.26.67.109/ \
--registration-token XXXXXXXXXXXS5UDqw \
--tag-list=dev,uat,prod \
--description "project_build_runner" \
--docker-privileged=false \
--docker-pull-policy="if-not-present" \
--docker-image "livingobjects/jre8" \
--docker-volumes /var/run/docker.sock:/var/run/docker.sock \
--docker-volumes /opt/data/gitlab-runner/.m2:/root/.m2 \
--executor docker

在gitab上可以看到己注册的gitlab-runner

  1. 持续集成、部署
    使用 Gitlab 的 CICD ,只需要在 Gitlab 的仓库的根目录中添加 .gitlab-ci.yml 文件。

这个文件中,可以定义CICD 的各个环节,配置每个环节执行的命令,触发方式等。这个配置文件其实就是按照 YAML 规定了一些结构的 shell 脚本,里面的命令会在符合条件时逐一执行。一旦在仓库中添加这个文件,Gitlab 会检测到它并用名为 Gitlab Runner 工具执行它。每次触发的 CICD 会把配置中的脚划分为不同的 job,多个 job 组成一个 pipeline。
最简单的 .gitlab-ci.yml 文件可以包含:
before_script:

  • apt-get install rubygems ruby-dev -y
    run-test:

script:

- ruby --version

其中 before_scripts 属性会在执行任一脚本前预装一些需要的依赖(类似 unittest 的 setUp 方法),此后名为 run-test 的脚本会显示当前系统的 ruby 版本。这两个步骤组成了一个 pipeline 会在这个仓库的每次push后执行。这行任务的执行情况也可以在 Gitlab 的对应页面上查看,就像在 Terminal 中看日志一样。

而每个 pipeline 的 job 的执行情况也可以在页面上查看

如果中途报错了,可以一键回滚

CICD 工作流
假设你在本地修改了一些代码以增加一些特性,当你把这些改动 push 到远程仓库的特性分支后,项目里设定的 CICD pipeline 就被触发了,一般流程如下:
运行自动脚本(串行或并行):
 构建并测试应用
 在合并前 review 改动
上述流程如果没有问题就可以把改动合并入主分支,CD 会自动把它部署到产品中,如果发现了任何问题,还能一键回滚。
工作流程图如下:

该图简要显示了基本的工作流,想要了解 Gitlab CICD 的更多特请,请参阅CICD 索引表
.gitlab-ci.yml 文件结构
.gitlab-ci.yml 是指定了 CICD 相关配置的 YAML 文件。(YAML 是专门用来写配置文件的语言,简洁强大,和 python 一样用缩进代表层级,表达能力和 JSON 基本一致,但格式更方便。
一般而言,CICD 过程会包含如下最外层的 key:
stages: 定义整个 CICD pipeline 的 job 数量和名称
variables: 定义 CICD 流程中的一些环境变量
before_scripts: 在每个 job 的 scripts 执行前进行的命令集,一般是创建目录,打印 context 目录等操作,可类比 unittest 的 setUp 方法
stage: 定义了一个 job 的具体流程,可以在前面加上名称
下面通过一个例子进行一些讲解
stages:

  • test
  • build
  • deploy
    variables:

GIT_STRATEGY: none
PROJECT_REPO_NAMESPACE: test
PROJECT_REPO_NAME: cicd_learn
DEPLOYMENT_REPO_NAMESPACE: test
DEPLOYMENT_REPO_NAME: deploy_test
before_script:

  • export ROOT_PATH=$(pwd)
  • echo 'root path:' $ROOT_PATH
  • mkdir $PROJECT_REPO_NAME
  • cd $PROJECT_REPO_NAME
  • echo 'date:' $DATE
    test_stage:

stage: test
script:

- <test related command here>

artifacts:

paths:
  - xxxx.html
when: always

allow_failure: false
build_stage:
stage: build
script:

 - <build related command here>

when: manual
allow_failure: false
only:

- master

deploy:
stage: deploy
script:

- <deploy related command here>

allow_failure: false
only:

- master

stages
例子中 stages 值为一个数组(p.s. 用 - 代表数组和 markdown 类似)。包含了三个 job,test, build, deploy分别实现自动测试,打包项目和部署。下方的 stage 必须在全局定义的 stages 内。
variables
值为键值对象,为了后续的流程,此处定义了开发项目和部署项目的 namespace 和 repo_name。同 shell 类似,后续使用其值需要加上 $ 符号。定义的变量也有对应的作用域,定义在顶层就可以作为全局变量供所有 job 使用,如果是一些 job 特有的变量,就定义在 job 内部。
before_script
值为数组,每一个元素其实就是一个 linux 命令,写的时候装作自己在写 shell 就好。该部分主要生成了后续构建需要的镜像标签,切换当前目录等。为了 debug 方便,这些变量最好打印。类似的,如果在 job 完成后有一些时候操作,可以定义 after_script。需要注意的是如果定义在顶层,内部的命令会在每个 job 运行之前执行,如果某些 job 需要特别的预操作,可以在 job 内部再配置一个 before_script 对象,它会复写外部的全局预操作。
test_stage
名为 test 的 job 的具体配置,一般是个复合对象。
stage
job 对应的 stage,如果有多个 job 对应同一个 stage,在执行时会并行执行这些 job。
script
这个 job 执行的命令,此处是进入的项目仓库目录,并且执行了一个 shell 脚本,这个脚本定义了执行项目的所有单元测试。一般建议如果要执行的命令过多,就把这些命令写成脚本放在项目内。CICD 流程直接执行这个脚本。
artifacts
这个对象用来定义 job 的产出,比如我们让 test_stage 产出一个 html 格式的报告,显示每个单元测试的执行情况(报告生成相关代码写在项目内)。 数组内 paths 和 when 分别定义报告的路径和产出场景。此处表示报告放置于根目录下,任何时候都要提供报告。设定正确后,就可以 Gitlab 的 pipline 页面上可以下载相关文件。
allow_failure
见名知意,如果值为 true,那么即使没通过测试,也可以执行后续的 job.
build_stage
该步骤在测试通过的基础上,把项目编译打包,方便后续部署。
when
此处的 when 定义在 job 内的顶层,值为 manual 表示其需要在 Gitlab 上手动触发(页面上点击按钮即可)。
only
only 指明了 job 的执行场景,可以是分支名,表明只有 master 分支可以执行 build,如果要用排除法反向指定,可以用 except。
deploy_stage
所有的 key 现在你应该都了解了,这里不再赘述。这一步骤主要是将部署产品的服务器上的内容更新。

目录
相关文章
|
11天前
|
Docker 容器
docker 部署gitlab
docker 部署gitlab
|
18天前
|
运维 Kubernetes 监控
构建高效自动化运维体系:基于Docker和Kubernetes的实践指南
【5月更文挑战第29天】 在现代云计算环境中,自动化运维已成为提升服务效率、确保系统稳定性的关键因素。本文深入探讨了如何利用Docker容器化技术和Kubernetes集群管理工具来构建一个高效且灵活的自动化运维体系。通过分析具体实施步骤和策略,我们旨在为读者提供一个清晰的指导框架,以支持他们在不断变化的技术需求中快速部署和扩展应用程序。本指南不仅涉及技术的基础知识,还涵盖了持续集成/持续部署(CI/CD)流程的集成,以及监控和日志管理的优化实践。
|
19天前
|
运维 Kubernetes 监控
构建高效自动化运维系统:基于Docker和Kubernetes的实践
【5月更文挑战第28天】在现代云计算环境中,自动化运维已成为提升服务效率、减少人为错误和应对快速变化需求的关键。本文以实际案例为依托,详细探讨了如何利用Docker容器化技术和Kubernetes集群管理系统搭建一套高效的自动化运维平台。通过深入分析Docker的轻量级虚拟化特性及Kubernetes的编排能力,本文展示了从基础设施搭建到持续集成、部署和监控的全自动化流程,旨在为运维工程师提供一种提高生产力、降低运营成本的可行解决方案。
|
1月前
|
存储 测试技术 持续交付
【Docker 专栏】Docker 与 CI/CD 的集成策略
【5月更文挑战第8天】本文探讨了Docker在CI/CD流程中的作用,强调了环境一致性、快速部署和资源隔离等优势。通过在构建、测试和部署阶段集成Docker,可以提升软件开发效率和质量。具体集成策略包括使用Dockerfile构建镜像、整合CI/CD工具如Jenkins和GitLab。集成带来的好处包括提高效率、增强可靠性、加速交付和简化管理。然而,也需应对镜像管理、网络配置和安全等问题。通过案例分析,证明了Docker与CI/CD集成的有效性和必要性。
【Docker 专栏】Docker 与 CI/CD 的集成策略
|
1月前
|
数据库 Docker 容器
【Docker 专栏】使用 Dockerfile 自动化构建 Docker 镜像
【5月更文挑战第8天】Dockerfile是构建Docker镜像的关键,它包含一系列指令,用于描述应用运行环境及所需软件包。通过自动化构建,能提高效率、保证可重复性并提升灵活性。确定基础镜像、安装依赖、设置环境后,执行Dockerfile生成镜像,用于应用程序部署。虽然需要熟悉Docker技术和应用细节,但其带来的益处使其成为现代软件开发和部署的重要工具。
【Docker 专栏】使用 Dockerfile 自动化构建 Docker 镜像
|
1月前
|
运维 Kubernetes 负载均衡
构建高效自动化运维体系:基于Docker和Kubernetes的实践指南
【4月更文挑战第28天】随着云计算和微服务架构的普及,自动化运维已成为提升系统稳定性、效率及快速响应市场变化的关键。本文将探讨如何利用容器化技术Docker和容器编排工具Kubernetes来构建一个高效、可扩展的自动化运维体系。我们将分析该技术栈的优势,并通过一系列实践案例,展示如何优化现有的运维流程,实现资源的最大化利用和风险的有效控制。
|
1月前
|
jenkins 持续交付 开发工具
Jenkins 快速入门 (含Jenkins + Docker + Git 简单的自动化实操)(下)
Jenkins 快速入门 (含Jenkins + Docker + Git 简单的自动化实操)
|
1月前
|
jenkins Java 持续交付
Jenkins 快速入门 (含Jenkins + Docker + Git 简单的自动化实操)(上)
Jenkins 快速入门 (含Jenkins + Docker + Git 简单的自动化实操)
|
1月前
|
jenkins Java 持续交付
Jenkins与Docker的自动化CI/CD实战
Jenkins与Docker的自动化CI/CD实战
|
1月前
无缝构建与部署:GitLab CI/CD首秀的实战攻略
无缝构建与部署:GitLab CI/CD首秀的实战攻略
82 0
无缝构建与部署:GitLab CI/CD首秀的实战攻略