让你的项目部署由五档手动升级为全自动
书接上回:《让咱们前端也能轻松搭建属于自己的博客网站!搞定域名 + 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
别忘了点赞、关注支持一下哦~
欢迎评论区提问交流。
转载自:https://juejin.cn/post/7178668238744584250