让你的项目部署由五档手动升级为全自动

站长

2022年12月25日 01:05 · 阅读数 11

书接上回：《让咱们前端也能轻松搭建属于自己的博客网站！搞定域名 + HTTPS》，里面谈到了如何搭建基础网站环境，并让 HTTPS 为咱们的网站保驾护航。

在这之前，如果想把构建完的站点文件部署到服务器的话，至少得包含以下几个步骤：

打包/构建
打开 FTP 工具
连接服务器
进入服务器站点根目录
上传文件

可以看到，如果咱们每次更新网站内容都得来这么几下，还是挺繁琐的。那有没有什么办法可以简化这个操作流程呢？答案是：有。那简化后的流程到底是怎么样的呢，请看：

git push

没错，你只管提交代码，剩下的交给 CI/CD。爽否？我相信，看完本篇文章之后，你也能达到同样的境界。那就。。。开始吧！

一、前言

咱们不妨先思考一下，实现这样的效果需要什么工具？此时，小伙伴们脑海里可能涌现了各种词汇，例如：Git、Jenkins、Travis、Circle、GitLab、Github、OneDev 等等。那在这么多工具之中，怎么抉择呢，可能不同的人会有不同的理解。我先说说我的看法：

Git：这个毋庸置疑，是必选项；
Jenkins：作为一个老牌的 CI/CD 工具，在前几年可谓风靡一时，据我所知，大部分公司自研的 CI/CD 流程控制台，都是在 Jenkins 的基础上套个壳子。但是近期关于它的声音越来越少，为什么？在我看来，他拥有非常丰富的插件生态，但这也是一个缺点，导致一套组合下来非常臃肿，配置起来效率不高。
Travis、Circle：这两个类似，都可以基于开源仓库免费在线配置构建任务webhook。缺点就是，由于是国外第三方平台，对于国内的开发者来说，稳定性是个值得考虑的点。
Github：2019 年 8 月 9 日，GitHub 官方宣布了 GitHub Actions 将支持 CI/CD，并且对所有开源项目免费。GitHub Actions 对于开源项目是完全免费的，对于私有项目，也有每个月 2000 分钟的免费额度。如此看来，这对于没有服务器的小伙伴们来说，确实是个极大的诱惑。但是，如果你也恰巧有一台闲置的服务器，那就别选这个，谁让我们都有一颗爱折腾的心呢。
GitLab、OneDev：为什么这两个放一起，因为他们极度相似，都是可以私有化部署的开源 Git 仓库，同时都具有 CI/CD 功能。OneDev 是由国人开发并维护，在 Github 已拥有 10K+ star，详细介绍可查阅作者的这篇文章。我也试用了一下，成功的把 CI/CD 流程跑起来了，在体验方面确实不错。但是，据不完全统计，国内 99% 以上的公司所使用的代码仓库管理工具都是 Gitlab。所以这篇文章就以大家最熟悉的 Gitlab 为例，让咱们的博客网站部署从手动挡免费升配为自动挡。

二、开始搭建

1、GitLab 安装

1.1、安装依赖库

依次执行以下三条命令：

yum install curl openssh-server postfix cronie -y
systemctl start postfix
systemctl enable postfix.service

1.2、配置yum源

创建 repo 文件，用于指定 gitlab 安装源

vim /etc/yum.repos.d/gitlab-ce.repo

这里用的是清华大学的镜像源，输入以下内容：

[gitlab-ce]
name=Gitlab CE Repository
baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el$releasever/
gpgcheck=0
enabled=1

1.3、安装 GitLab

生成一下 yum 的缓存，并使用 yum 安装（自动安装最新版），依次执行以下两条命令：

yum makecache
yum install gitlab-ce -y

稍等 10 分钟左右，安装成功之后，会看到如下信息

让你的项目部署由五档手动升级为全自动

一些主要目录的路径

代码仓库保存位置：/var/opt/gitlab/git-data/repositories/
代码仓库备份位置：/var/opt/gitlab/backups/
postgresql 数据及配置目录：/var/opt/gitlab/postgresql/data/
redis 默认配置目录：/var/opt/gitlab/redis
gitlab 配置文件：/etc/gitlab/gitlab.rb

1.4、配置gitlab访问地址

编辑配置文件

vim /etc/gitlab/gitlab.rb

找到 external_url 这个配置项，把值设置为你自己的域名，这里以 gitlab.hxkj.vip 为例。然后修改默认端口为：8088。否则的话他默认的 80 端口会跟咱们博客网站的端口冲突。

external_url 'http://gitlab.hxkj.vip'
nginx['listen_port'] = 8088

让你的项目部署由五档手动升级为全自动

接下来去域名解析控制台，将 gitlab.hxkj.vip 解析至这台服务器。可以按这篇文章操作：域名解析。用文章中提到的 A 记录的方式解析即可。

解析完成之后，再配置一下 Nginx，让 gitlab.hxkj.vip 域名能正确的访问到 GitLab：

vim /etc/nginx/nginx.conf

参考配置如下：

server {
    listen       80;
    server_name  gitlab.hxkj.vip;
    rewrite ^(.*)$ https://$host$1 permanent;
}

server {
    listen       443;
    server_name  gitlab.hxkj.vip;
    ssl on;
    client_max_body_size 500m;

    ssl_certificate     /etc/nginx/cert/hxkj.vip/fullchain.cer;
    ssl_certificate_key /etc/nginx/cert/hxkj.vip/hxkj.vip.key;
    include             /etc/nginx/ssl-options.conf;

    location / {
           proxy_pass http://127.0.0.1:8088;
    }

}

1.5、重载配置并启用服务

执行以下命令即可：

gitlab-ctl reconfigure

控制台一顿输出之后，你会看到如下信息：

让你的项目部署由五档手动升级为全自动

注意这句话，意思是初始密码在这个文件里面。可用于 gitlab 的第一次登录。在浏览器输入 gitlab.hxkj.vip 即可打开登录页面。

让你的项目部署由五档手动升级为全自动

上面的登录密码可以通过 cat /etc/gitlab/initial_root_password 命令获取：

让你的项目部署由五档手动升级为全自动

登录之后记得到用户中心修改密码，或者新增一个用户。

2、Runner 安装

2.1、添加 GitLab 的官方 rpm 源

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash

2.2、安装 gitlab-runner

使用 yum 一键搞定

yum install gitlab-runner -y

输出如下信息，代表安装成功了

让你的项目部署由五档手动升级为全自动

2.3、注册 Runner

依旧一条命令搞定

gitlab-runner register

注册过程中，会让输入一些信息，这里先去gitlab站点的配置拿到两个配置信息，分别是 URL 和 token，获取路径：Gitlab项目首页 -> setting -> CI/CD -> Runners -> Specific Runners，如下图所示：

让你的项目部署由五档手动升级为全自动

按下图中的标注进行操作即可

让你的项目部署由五档手动升级为全自动

2.4、激活 Runner

一般来说，注册成功之后，默认就是激活状态，像这样：

让你的项目部署由五档手动升级为全自动

假设你看到的 Runner 前面没有小绿点，或者是灰色的图标，则需要手动执行下面那条命令：

gitlab-runner verify

3、gitlab-ci.yml 配置

3.1、初识 .gitlab-ci.yml

首先，咱们明确一下 gitlab-ci.yml 是啥，以及配置 gitlab-ci.yml 需要具备的前置知识。

.gitlab-ci.yml 文件决定着 GitLab CI 的流程是怎样运行的，一般来说我们把它放到项目根目录下，当把它 push 到仓库后，GitLab 会自动识别。所以，我们还需要掌握 YML 的基本语法规则。

YML 是一种编写配置文件的语言，比 JSON 更为简洁和方便，因此，我们首先要掌握的就是 YML 文件的编写语法。

一份简单的 YML 文件长下面这个样子：

# 注释
xxx-job: 
  stage: build
  script:
    - yarn build

从这里我们就可以看出：

YML 通过缩进组织层级
YML 里允许通过 # 符号编写注释

在基本结构上，YML 和 JSON 也类似

JSON 是由对象，数组，以及对象和数组的嵌套结构组成的
YML 也是由对象，数组，以及对象和数组的嵌套结构组成的。

如下所示：

YML 中的数组写法

colors
  - red
  - blue
  - yellow

相当于 JSON 中的

{ "colors": ["red","blue","yellow"] }

YML 中的对象写法：

people:
  name: zhangsan
  age: 14

相当于 JSON 中的

{
  "people": {
     "name": "zhangsan"
     "age": 14
  } 
}

当然也可以是数组和对象之间形成的嵌套结构

a:
  b:
    - d
  c: e

相当于

{
  "a": {
    "b": [ "d" ],
    "c": "e"
   }
}

了解了这些，对于编写一个常用的 .gitlab-ci.yml 已经没有任何问题了。

3.2、配置 .gitlab-ci.yml

接下来，咱们尝试着写一个 .gitlab-ci.yml。下面这个文件所展示的内容，就是咱们这次会用上的全部配置信息，每条配置都有详细的注释：

#本次流程包含几个步骤，有多少个就写多少个，这边简单部署的话，用一个就够了
stages:
  - deploy

# 任务名称
deploy_job:
  # 当前执行哪个步骤
  stage: deploy
  only:
    # 指定当且仅当master分支有变动时，触发构建任务
    - master
  script:
    # 安装依赖
    - yarn
    # 运行项目打包命令
    - yarn build
    # 进入打包输出目录
    - cd ./dist
    # 压缩所有文件
    - tar -zcvf hxkj.tar.gz *
    # 将压缩文件移动到 nginx 站点根目录
    - mv hxkj.tar.gz /usr/share/nginx/html/
    # 进入 nginx 站点根目录
    - cd /usr/share/nginx/html
    # 解压并覆盖原有文件
    - tar -zxvf hxkj.tar.gz
    # 移除压缩包
    - rm -f hxkj.tar.gz

上面唯一需要注意的就是 # 任务名称 这一行，本质上是可以按个人喜好任意取名，但是需要避开以下几个系统内置的关键词

image
services
stages
types
before_script
after_script
variables
cache
include
true
false
nil
deploy

加上之后，项目的目录结构大致长这样，也可以去我的 GitHub 仓库查看

让你的项目部署由五档手动升级为全自动

3.3、提交项目代码

OK！终于到最后一步了，commit 然后 push。

可以看到运行如下：

让你的项目部署由五档手动升级为全自动

运行成功后：

让你的项目部署由五档手动升级为全自动

至此，你已经掌握如何跟 GitLab 一起愉快的玩 CI/CD 了。但是，它也有个致命的缺点，那就是内存消耗大了，一般人真的扛不住。我这边计划后续替换成 OneDev，它对内存优化做得挺不错，感兴趣的同学可以蹲一波后续。

三、结语

说个题外话，在写这篇文章时候，本来有打算结合 Docker 一起讲，用 Docker + CI/CD 的方式实现来实现整个流程，这也是目前最流行的 CI/CD 方式，复杂一点的系统还会加个 K8S。这样加在一起写，文章的内容会丰富很多，但是，写着写着，转念一想，我们真的需要 Docker 吗？真的有必要为了用 Docker 而用吗？事实上，就这个案例而言，完全可以抛弃它。

同样的，在做架构设计的时候，有些人为了实现某些需求，使劲的在系统中加各种组件、各种中间件，导致系统异常的臃肿复杂。为了炫技？为了吹牛？为了 KPI？还是为了在简历上加些技能点？我认为，最成功的架构设计就应该以最小的复杂度完成实际的业务需求，难的是做减法而不是做加法。切忌用大炮打蚊子。共勉。

作者：HashTang

个人空间：hxkj.vip

别忘了点赞、关注支持一下哦~

欢迎评论区提问交流。