GitLab Architecture(架构)

南风 2018年07月06日 44次浏览

一、GitLab是什么?

GitLab是由GitLab Inc.开发,使用MIT许可证的基于网络的Git仓库管理工具,且具有wiki和issue跟踪功能。

GitLab 是一个用于仓库管理系统的开源项目。 使用Git作为代码管理工具,并在此基础上搭建起来的web服务。Github是公共的git仓库,而Gitlab适合于搭建企业内部私有git仓库。

二、GitLiab架构如何?

官网上将组件架构类比成一个物理的办公室,下面是一些组件的描述:
  • repository:这个仓库用户操作处理一些货物,它们都可以存在在这些仓库中,这个仓库是硬盘或者一些复杂的东西,例如NFS文件系统;

  • Nginx:Nginx扮演一个前台的工作,用户首先来到前台并请求办公室员工做一些事情,实际上就是一个GitLab Web的代理工具;

  • Database: Database就是办公室的一个文件储物柜;

    • 可以存储仓库中货物的一些操作处理(如:元数据,issue,合并请求 merge request 等)
    • 可以存储用户校验、权限记录
  • Redis:Redis是一个包含办公室员工的交流板,作缓存,分发任务用;

  • Sidekiq:Sidekiq是一个主要负责发送邮件的办公室员工,他的任务都是来自于Redis交流板中;

  • Unicorn:Unicorn是一个主要负责处理快速/普通任务的办公室员工,他与Redis交流板协同处理任务,他的一些具体任务描述;

    • 从Redis储物柜中拿出用户的session检查用户的权限;
    • 给Sidekiq创建任务;
    • 从仓库中取货物或者移动仓库中的货物;
  • GitLab-shell:GitLab-shell是第三种办公室员工,他使用一部传真机(SSH)代替前台(HTTP)传递命令,他通过Redis和Sidekiq进行通信,并直接或通过 TCP 间接访问 Unicorn;

  • Gitaly:后台服务,专门负责访问磁盘以高效处理 git 操作,并缓存耗时操作。所有的 git 操作都通过 Gitaly 处理;

  • GitLab-workhorse:反向代理服务器,可以处理与 Rails 无关的请求(磁盘上的 CSS、JS 文件等),处理 Git Push/Pull 请求,处理到 Rails 的连接(修改由 Rails 发送的响应或发送给 Rails 的请求,管理 Rails 的长期 WebSocket 连接等)

  • GitLab持续集成组件

    • GitLab-CI:GitLab-CI就是一套配合GitLab使用的持续集成系统(当然,还有其它的持续集成系统,同样可以配合GitLab使用,比如Jenkins)。而且GitLab8.0以后的版本是默认集成了GitLab-CI并且默认启用的。
    • GitLab-Runner:GitLab-Runner是配合GitLab-CI进行使用的。一般地,GitLab里面的每一个工程都会定义一个属于这个工程的软件集成脚本,用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时,比如有人push了代码,GitLab就会将这个变动通知GitLab-CI。这时GitLab-CI会找出与这个工程相关联的Runner,并通知这些Runner把代码更新到本地并执行预定义好的执行脚本。
    • GitLab-Runner可以分类两种类型:Shared Runner(共享型)和Specific Runner(指定型):
      • Shared Runner:这种Runner(工人)是所有工程都能够用的。只有系统管理员能够创建Shared Runner。
      • Specific Runner:这种Runner(工人)只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。

参考文献:
https://docs.gitlab.com/ce/development/architecture.html
https://blog.csdn.net/kikajack/article/details/80354774
https://www.tuicool.com/articles/bYbi2mJ
https://docs.gitlab.com/ee/ci/README.html#doc-nav
https://www.cnblogs.com/cnundefined/p/7095368.html
https://docs.gitlab.com/runner/