GitLab 11.6登场！开始支持无服务器应用、进一步整合Kubernetes

如GitLab先前预告，推出GitLab Serverless服务。而在近日登场的GitLab 116版，新版本强调的亮点，就是要整合无服务器管理平台Knative，在自家服务原生支持企业用户，开发无服务器应用，并且加速拥抱多云架构。除了无服务器架构应用，Kubernetes应用也是个大重点，在116版内，GitLab开始支持使用者根据开发需求，建置不同Kubernetes丛集群组，让容器原生专案开发工作能切分的更细致。
首先是免费版、银版、黄金版用户皆支持的无服务器功能，该功能源自于GitLab 115版时，开始整合Knative。在使用前，得预先在储存库内定义函式执行档，接着系统会协助使用者，将这些函式部署至云端丛集。而Knative的工作，则是负责根据使用者流量，进行水平扩充的任务。目前，无服务器功能还是处于Alpha阶段。

再者是针对Kubernetes应用加强的功能。第一是按照团队需求，开设不同Kubernetes丛集功能，让企业用户可在直接单一群组内，开设子群组，减少使用者设定基础架构组态的成本、时间。第二，则是锁定Kubernetes环境的安全性，GitLab开始支持Kubernetes原生的凭证管理工具Cert-manager，结合Let's Encrypt，系统可以自动核发、更新SSL凭证。

而在GitLab 115版时释出的安全仪表板（security dashboard），在116版也有了更新。GitLab表示，现在安全仪表板推出了漏洞图表功能。该图表以折线图呈现，让安全管理员可以观察当前漏洞数量的成长走势，根据漏洞严重性，GitLab分别列出严重、高风险、中风险、低风险这四等级。

再者，GitLab平台现在的Web整合开发环境，现在加入了网页终端机功能，目前还是Beta阶段。就如使用者在本地开发环境的终端机功能，可用于检查API回应、程序语法正确性等。
无服务器应用是GitLab 116版最主打的新功能，整合了无服务器管理平台Knative，让开发者可透过GitLab在Kubernetes丛集部署Knative，借此在Kubernetes环境执行无服务器应用。
今年4月初释出的GitLab IDE功能，这次116版也有了加强，进一步推出开发者本地环境惯用的终端机功能，方便开发者执行测试、代码编译等工作。
Kubernetes是不少云端原生应用都会搭配使用的技术，而GitLab在此版本，改善Kubernetes丛集的划分功能，基础架构管理员可以根据内部各工作群组需求，直接于单一群组内，开设子群组，减少使用者设定基础架构组态的时间。
在安全仪表板内，GitLab新加入了漏洞图表，以折线图呈现。上图横轴为时间，纵轴为漏洞数量，方便安全管理员评估当前系统漏洞的风险。

GitLab是由Ruby语言开发的基于Linux的Git服务器，是我见过的最强大的Git服务器。发现它之后，立即决定将Git服务器换成GitLab。
但安装好GitLab之后面临一个问题，如何将服务器上的git项目直接导入到GitLab，之前的Git服务器是由是git+apache搭建的（详见在Linux上用Apache搭建Git服务器）。
在网上发现了这篇文档——Import bare repositories into your GitLab instance，并按之进行了 *** 作。
1）设置存放代码库的主目录
vi /etc/gitlab/gitlabrb
比如这里设置为：git_data_dir "/gitlab/repos"
2）访问刚搭建的GitLab站点，创建一个group，比如cnblogs。
这时会在 /gitlab/repos 下创建 /gitlab/repos/repositories/cnblogs 文件夹。
然后在/gitlab/repos/repositories/创建一个文件夹，比如cnblogs
3）将现有的所有git项目文件复制到这个文件夹
cp -r /data/git/ /gitlab/repos/repositories/cnblogs
4）修改一下复制过来的文件夹的所有者：
chown -R git:git /gitlab/repos/repositories/cnblogs
5）运行GitLab导入命令
cd /var/opt/gitlab
gitlab-rake gitlab:import:repos
等了一段时间之后，显示done，却一个项目也没导入进来。
经研究发现，在导入时，GitLab只认文件夹名以git结尾的项目。于是，将要导入的项目文件夹名称加上git后缀，再次进行导入。
结果显示导入成功，比如：
Processing cnblogs/CNBlogsJobgit
Created CNBlogsJob (cnblogs/CNBlogsJobgit)
Done!
可以是GitLab站点上却看不到已导入的项目。多次努力，也没能解决这个问题。
后来，实在没办法，改为手动导入，导入方法如下：
1）在GitLab站点上创建与要导入的项目同名的项目。
2）进入刚创建的项目文件夹
cd /gitlab/repos/repositories/cnblogs/项目名称git
3）删除该文件下的所有文件
rm -rf
4）将要导入的项目文件夹下的所有文件复制过来
cp -r /data/git/CNBlogsJob/ /gitlab/repos/repositories/cnblogs/CNBlogsJobgit
就这样将项目一个一个地导入进来。
5）导入完成后，修改一下导入的所有项目的文件所有者
chown -R git:git /gitlab/repos/repositories/cnblogs
如果不修改所有者，客户端无法进行git push。
就这样手动地完成了现有Git项目的导入。
备注： *** 作系统是CentOS 62，GitLab版本是784。

Gitlab是套功能完善的源码管理系统，平时用于公司内部各研发组的源码同步、问题跟踪、开发协同。Gitlab自带的CI/CD功能与Gitlab更简单、灵活的协同工作，也减小了日常维护的压力，因此，本文针对Gitlab的CI/CD功能做的要点分享。

基于GitLab的CI/CD系统由Gitlab与Gitlab-runner两个主要部分构成。

Gitlab源码库管理系统，提供基于Git的源码库管理、协作、权限等丰富的功能。

在Gitlab源码库的根目录中如果创建有`gitlab-ciyml`文件，相当于为当前源码库启用了CI/CD功能。

该文件用于控制CI/CD流程与行为，每次源码的提交、合并动作都会触发Gitlab执行当前 *** 作分支上的该文件。

该文件中通过gitlab提供的关键字、预定义变量、脚本代码等等来规划pipeline和定义Job，实现依据条件控制不同Gitlab-Runner中的执行器进行需要动作，共同完成代码的编译、打包、发布等 *** 作。

Gitlab-Runner运行在本地或远程目标机上的一个程序，作用是接收执行Gitlab的指令，比如编译、打包部署等等。

一个Gitlab可接入多个Gitlab-Runner，每个Runner可以注册多种相同或不同形式的“执行器”。

Runner与Gitlab联接需要通过Gitlab生成的Token，每个Runner对应且仅对应到一个唯一的Token。

Gitlab-Runner基于Go语言开发，可运行在多种系统平台。Gitlab-runner在Gitlab中有三种使用权限范围，第一种是全局共享，第二种是群组共享，第三种是项目特定。

Gitlab-Runner的作用是接收Gitlab指令，并控制与管理“执行器”的程序。具体动作执行则是由Runner派生出的“执行器”这个逻辑模块来完成，Runner支持多种“执行器”形式，有Shell，有Docker等等。

Gitlab-Runner的安装有两种方式，一种是直接安装到原生系统，另一种是以Docker容器方式进行安装。Runner安装完成后，需要执行Runner中的注册命令，建立与Gitlab的关联。

在注册过程中需要填入Gitlab服务器地址、Gitlab提供的Token、执行器形式，以及不同执行器的配置等等。

将Runner以原生系统方式进行安装（也可以以Docker形式安装），并在Runner注册时选择Docker执行器形式。

在注册过程中会要求指定一个Docker Image，该Docker Image是默认用于执行指令的实体（即在`gitlab-ciyml`中未指定Image时默认使用，也可以在Job中明确指定其它的Docker Image）。Runner注册完成后会在`/etc/gitlab-runner`中生成一个`configtoml`文件，如要修改Runner配置，可重新注册（重新注册原配置不会删除，原注册的执行器还保持有效，需要在Gitlab端删除）或修改该文件。另外，一个Runner实例可以配置多个同类型或不同类型的执行器。

执行器是用于Job执行不同的指令，因此执行器的环境需要依据Job的具体要求进行配置，比如用于Java构建，则执行器环境中需要支持jdk、maven等指令。由于本篇用的是Docker形式的执行器，因此在指定的DockerImage中要安装好JDK与MAVEN包（注：为了更好的利用自建的DockerImage，需要创建一个Docker私服，可以用Harbor或Nexus3来实现自定义的Docker Image的管理）。

每个Job都会重新启动一个新的容器，并且会自动完成源码库的下载（放在启动容器的`/build`目录中），并且这个不要求执行器镜像支持Git（原理不清楚，有清楚的欢迎评论区指教！），如何在Job中禁止下载原码还需要再学习（有清楚的欢迎评论区指教！）。

以下是`configtoml`文件及主要字段说明:

`gitlab-ciyml`文件必须在源码库的根目录中，该文件用于控制源码何时、何地、如何加工处理代码的配置脚本，并且需要符合`YAML`的格式与语法。

在该脚本中，通过`stages`关键字定义代码处理阶段，定义的上下顺序则是阶段执行次序。

然后就是各种各样的JOB定义，在Job中需要指明哪个阶段执行，在哪个执行器运行，什么条件下执行，以及执行的具体动作。多个不同的JOB可以关联到同一个阶段，实现并发处理不同的事务。

Gitlab为CI/CD提供了平台与机制，在微服务、异构系统开发时代CI/CD已成为必不可少的效率工具，也可以说是软件自动化生产线，但要用好和维护好一套CI/CD，需要有丰富的研发经验与广泛的系统知识。

问题发生的起源：

每次重启了服务器。clone时发现IP地址是一堆乱码。不是域名地址。见截图

解决方案

（注）gitlab部署在docker中，则需要执行第2步：“进入gitlab容器”的 *** 作。反之，直接从第3步：“进入config目录”开始执行即可

1、登陆搭建gitlab的服务器

2、进入gitlab容器

dockerexec-it gitlab bash

3、进入config目录。编辑gitlabyml文件

cd  /opt/gitlab/embedded/service/gitlab-rails/config

vim gitlabyml

 4、重启gitlab。必须重启

gitlab-ctl restart

---