持续集成和持续部署

持续集成指的是,频繁地(一天多次)将代码集成到主干,主要是为了快速发现错误和防止大幅度偏离主干分支。 持续部署指的是,频繁地将软件的新版本,交付给质量团队或者用户,代码通过评审以后,自动部署到生产环境。

# 持续集成

持续集成指的是,频繁地(一天多次)将代码集成到主干,主要是为了快速发现错误和防止大幅度偏离主干分支。

持续部署指的是,频繁地将软件的新版本,交付给质量团队或者用户,代码通过评审以后,自动部署到生产环境。

真正良性的运维能力是——人管代码,代码管机器,而不是人管机器。你敲了什么命令没人知道,但是你写个工具做变更线上系统,这个工具干了什么事,看看工具的源码就知道了。

总之,接下来的工作要尽可能的自动化。

持续集成系统演变过程

  • 最初阶段:提交代码-自动部署;
  • 一般进阶:提交代码-代码静态分析-自动部署;
  • 高级进阶:提交代码-代码静态分析-自动化测试集(单元、验收、性能)-自动部署;

接下来,我们使用 Gitlab CI 实现最初阶段,提交代码之后自动部署

# Gitlab CI

# 1. 安装 Gitlab Runner

Gitlab Runner 部署在产品服务器上,是 .gitlab-ci.yml 的 script 部分的真正执行者,用来完成部署、测试等任务。

## 添加 Gitlab 的官方仓库
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

sudo apt-get install gitlab-runner

# 2. 修改 Gitlab Runner 的执行用户

默认 gitlab runner 会添加一个新用户 gitlab-runner 来执行任务,现在修改为原来的用户。

使用 ps aux | grep gitlab 来查看 gitlab runner 的执行用户,获得这样的结果:

/usr/bin/gitlab-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runner

现在执行:

sudo gitlab-runner uninstall
sudo gitlab-runner install --working-directory /home/ubuntu --user ubuntu
sudo gitlab-runner restart

检验,可以看到 --user—working-directory 已经修改成功:

/usr/bin/gitlab-runner run --working-directory /home/ubuntu --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user ubuntu

# 3. Gitlab 仓库注册 Runner

可以在 /settings/ci_cdRunners settings 板块下获取需要的 url 和 token,以及管理当前仓库注册的 runner。

sudo gitlab-runner register

引导会让你输入 gitlab 服务器的 url、仓库的 token。

引导会让你输入 tag,一个项目可能有多个 runner,是根据 tag 来区别 runner 的。

引导会让你输入 executor,这个是要用什么方式来执行脚本,图方便输入 shell 就好了。

# 4. 编写脚本

出于方便的考虑,我们可以在服务器上编写一些脚本,之后在配置文件 .gitlab-ci.yml 那里就可以调用。

比如,pullRepo 脚本用来拉取仓库的最新内容:

sudo nano /usr/local/bin/pullRepo
sudo chmod +x /usr/local/bin/pullRepo
##!/bin/bash
if [ $# -ne 2 ]
then
  echo "arguments error!"
  exit 1
else
  deploy_path="$HOME/repos/$1/$2"
  mkdir -p $deploy_path
  if [ ! -d "$deploy_path" ]
  then
    project_path="[email protected]:"$1/$2".git"
    git clone $project_path $deploy_path
  else
    cd $deploy_path
    git pull
  fi
fi

tgmsg 脚本用来使用 telegram 发送通知

##!/bin/bash
curl -H "Content-Type: application/json" \
  -d "{\"chat_id\":00000001,\"text\":\"$1\"}" \
  https://api.telegram.org/bot{{botToken}}/sendMessage

# 5. Gitlab CI 配置文件

项目根目录添加一个 .gitlab-ci.yml 配置文件,记录一系列的阶段和规则。Gitlab-CI 会在 push 之后解析它来调用相应的 runner 来执行脚本。

stages: # 定义一批 stage
  - deploy
pull repo: # 定义一个任务
  stage: deploy # 相同 stage 的任务并发执行
  script: # runner 执行的叫脚本
    - pullRepo keng42 ci-demo
    - tgmsg "depoly keng42/ci-demo success"
  only:
    - master # 限制只有 master 分支的更新才会触发
  tags:
    - production # 对应 runner 配置的标签

至此,向仓库的 master 分支 push 更新,就可以在 /pipelines 看到一个新的任务,点进去还可以实时查看执行反馈。

# 持续更新

TO BE CONTINUED

# 参考

配置 Gitlab CI 自动发布代码到生产环境

[后端]gitlab之gitlab-ci自动部署

fir.im 持续集成技术实践

从 GITLAB 误删除数据库想到的