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 方式实现的进程间通信功能,它不需要进行复杂的数据打包拆包、校验和计算验证,不需要走网络协议栈
今天的文章GitLab系列2 GitLab Workhorse分享到此就结束了,感谢您的阅读。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/61229.html