GitLab系列2 GitLab Workhorse

GitLab Workhorse

上一回介绍了 GitLab 的基础功能和架构，但还没具体讲解用户的请求是怎么被处理的，只是将各个组件的功能职责介绍了一遍，本节将简单介绍 gitlab-workhorse 的功能

首先回顾一下：GitLab 利用 Nginx 将前端的 http/https 请求代理至 gitlab-workhorse，gitlab-workhorse 再将请求转发至 Unicorn Web 服务器。默认情况下 gitlab-workhorse 与前端之间的通信是使用 unix domain socket 进行的，但也支持 TCP 转发请求；GitLab 使用 Unicorn Web 服务器提供动态网页和 API 接口

1. Nginx 入口

从架构图可以看出，HTTP/HTTPS 请求进入 GitLab 的第一站是 nginx

下载 GitLab-ce 官方源码后，进入 ${gitlab-ce根目录}/lib/support/nginx，打开 gitlab-ssl 可以看到 nginx 的配置

GitLab 默认将 http 请求重定向至 https 请求

## Redirects all HTTP traffic to the HTTPS host
server {
  listen 0.0.0.0:80;
  listen [::]:80 ipv6only=on default_server;
  server_name YOUR_SERVER_FQDN;
  server_tokens off;
  return 301 https://$http_host$request_uri;
  access_log  /var/log/nginx/gitlab_access.log gitlab_ssl_access;
  error_log   /var/log/nginx/gitlab_error.log;
}
复制代码

https 的设置相对比较复杂，这里仅提一个亮点：location: / 下面的 proxy_pass http://gitlab-workhorse; ，说明了 除了某些静态页面，nginx 几乎将所有的 http/https 请求传递给了 gitlab-workhorse 组件处理(使用 unix socket 通信)

Unix Socket 是一种 socket 方式实现的进程间通信功能，它不需要进行复杂的数据打包拆包、校验和计算验证，不需要走网络协议栈