我们做了个简单的docsify帮助网页,因为多人协作,加上源文件都是md格式的,于是把它放在了自己的gitlab上。但是这样一来问题就是如果要发布文件,必须每次更新完都让服务器管理员去到服务器上执行一下拉取,显然不合理,看到gitlab的ci/cd功能,正好研究下,记录下来。

ci/cd介绍

什么是ci/cd?红帽是这么说的:

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案,CI/CD 主要针对在集成新代码时所引发的问题(亦称:“集成地狱”)。
ref: https://www.redhat.com/zh/topics/devops/what-is-ci-cd

那么在我的场景里,就是当有人commit并且push到gitlab之后,能自动在服务器上下载这些文件。

使用方法

0.基本环境

我们的环境很简单,也没有测试服务器,一台Windows作为发布服务器,使用docsify作为源文件,由于docsify支持服务器刷新,所以只要能覆盖文件就行了,连重启服务器都不需要。

1.安装Runner

首先需要在发布服务器上安装Gitlab Runner,把它理解为一个Agent可能更好一点,他负责处理各种任务下达,文件拉取等工作。

在这里下载Gitlab Runner :https://docs.gitlab.com/runner/install/index.html
下载完将他放到某个目录下。

2.配置Runner

Runner的权限可以针对管理员、某个仓库、某个组。我们这里针对组来设置。
我们来到gitlab仓库。找到设置,CI/CD,找到Runner并展开,这里可以看到你的Runner配置,将Token复制下来。

在发布服务器上,打开cmd,运行gitlab-runner.exe register就可以了。下面会分别让你输入tokengitlab地址等等。
另外下面的操作方式选择了shell,我们看到还有docker等方式。我们暂时用不到。

然后在运行gitlab-runner.exe install,将他注册为服务并启动即可。

此时在仓库里已经可以看到Runner为绿色了。

另外,不知道是不是bug,windows如果选择shell的话,默认在runner文件夹下的config.toml文件,runner下的shell参数是pwsh,而这个pwsh是无法执行的,会报错。需要手工改成powershell才行。

配置.gitlab-ci.yml文件

.gitlab-ci.yml文件其实就是告诉runner,什么时候做什么事情。我的示例如下:

pages:
  #部署服务器(仅下载即可)
  stage: deploy
  variables:
    targetPath_working: D:\help
  #将文件cp到d:\help目录,即上述变量。
  script:
    - echo $CI_PROJECT_DIR
    - echo $targetPath_working
    - echo $CI_PROJECT_DIR\*---------to---------$targetPath_working
    - rm -r $targetPath_working\*
    - cp -r $CI_PROJECT_DIR\* $targetPath_working
# 只针对master分支生效
  only:
  - master

其实就可以看到具体的操作模式了。

测试

我们可以尝试着commit一个修改到git仓库,观察gitlab,可以看到流水线已经开始执行了。同时到Windows发布服务器上,我们可以看到服务器在下载gitlab上的文件,并拷贝到目录,也就是我们在.gitlab-ci.yml文件里告诉他要做的事情。

总结

我们这个还很简单,但是效果已经达到了,如果后期还有测试服务器等的发布需求,完全可以通过编辑gitlab-ci.yml来实现。

从netdevops,到云原生,真的感觉纯网管的日子会原来越不好过。。。(程序员制造的)自动化在不停的抢网管的工作,不会代码的网管真的迟早要被淘汰出主流了。。。

Logo

为开发者提供学习成长、分享交流、生态实践、资源工具等服务,帮助开发者快速成长。

更多推荐