GitLab Workhorse 简史 已翻译 100%

Zoker 投递于 2017/03/10 13:14 (共 14 段, 翻译完成于 03-23)
阅读 3596
收藏 2
1
加载中

Gitlab-workhorse 是一个以 Go 而不是以 Ruby 编写的'周末项目',在过去 8 个月,它从一个提供 git-clone 超时通知的组件小程序,成长为几乎涉及所有对 GitLab 的 HTTP 请求的部件。 在这篇博文中,我简单回顾了这一过程。

技术和个人动机

GitLab 是一个使用 Unicorn Ruby Web 服务器的 Ruby on Rails Web 应用程序。我是 Unicorn 的粉丝,因为它使应用程序资源泄漏变得可管理,还因为它很好地服务了 GitLab,修补了我们发现但难以“合理”解决的问题。

Tocy
翻译于 2017/03/13 10:54
0

同时,Unicorn 的设计与 Gitlab 的主函数之一不兼容,即通过 HTTP(S) 的 Git 存储库访问(git clone,git push 等)。不兼容的原因是 Unicorn 严重依赖于(相对)短的请求超时。你不会希望配置 Unicorn 时的超时变慢而不是变快。另外,如果获得一个大型 Git 库,git clone 将花费很长时间。我以前 GitLab 服务工程师的时候,经常向客户解释这一问题。而我们提供的唯一的解决途径就是使用 ssh 代替 git。

BigEcho
翻译于 2017/03/13 11:49
0

另一个创建 gitlab-workhorse 的动机是我对 Go 编程语言的无限好奇心。有时 Go 被认为(或被怀疑)在背后有强有力的市场推动。市场就对我产生了影响:我有一个毛绒的 Go 吉祥物,它在我的桌子待了差不多三年。

Gopher

Tocy
翻译于 2017/03/13 21:49
0

将周末项目合并到主分支

在去年的七月的一个周末,我突然想用 Go 来构建一些东西,我想:我能否使用 Go 语言写一个 gitlab-grack 呢?这个 GitLab 组件是用于相应 Git 的 HTTP 客户端请求。我花了好几个月的时间开发这个项目。

几个月后,一个叫做 gitlab-git-http-server 的 Go 程序就上线了,但在通过 Unicorn 进行 clone 时并没有产生超时问题。把它合并到 GitLab 时使用了一个讨巧的方法,即让 NGINX 把 Git 的 HTTP 请求从 Unicorn 转移到 gitlab-git-http-server。GitLab Rails 要求的更改很小,我可以轻松将它们隐藏在功能标志后面。为给该项目画上圆满的句号,我向团队公布了 gitlab-git-http-server 的存在。

被盗用户
翻译于 2017/03/14 09:50
0

我的团队让我设法检验下 gitlab-git-http-server 程序(方法:把这个程序 merge 到 master 里面,然后配置在我们的开发服务器上),然后就开始测试了。不到一个月后,GitLab 7.14 里面就有了 gitlab-git-http-server 的功能标签。于是我们需要花一个月时间在 GitLab.com 上面测试这个程序。在我们的开发环境和 GitLab.com 之间,我们找出了最糟的 bug。在 GitLab 8.0(在 7.14 之后一个月发布的)中,我们使得 gitlab-git-http-server 成为了 GitLab 的官方组件(被 GitLab 官方要求的!)。

团队对于 gitlab-git-http-server 程序的接受可能是因为 GitLab 的 Git-over-HTTP 解决方案没有完全解决问题,并且我们已经在 gitlab-ci-multi-runner 上使用了 Go 语言。而在此之前,我们并没有预留解决 Git-over-HTTP 出现的问题的方法。

m
翻译于 2017/03/15 16:50
0

功能进化

至此 gitlab-git-http-server 能处理的还不多:只处理 Git 的 HTTP 客户端请求。但这就像你有了一个锤子,于是什么东西都想钉一下。在 GitLab 8.1 中,我们让 gitlab-git-http-server 也能够处理网页端 'download zip'  的访问接口。在整个过程中,这一阶段的发生似乎是理所当然,但在当时却是摆在我们面前的鸿沟:我们认为 gitlab-git-http-server 只是一个守护进程,能够理解(无状态) HTTP 基本认证,但并不会作为会话 cookies 识别不同的用户。但会话 cookie 只是一个 HTTP 头,因此在整个过程中,没有什么能够阻止 gitlab-git-http-server '扮演'登录用户,也无法阻止它临时产生 zip 文件。

被盗用户
翻译于 2017/03/14 10:12
0

新名称时刻

在 GitLab 8.2 中我们想要发布两个新的特性,用于解决过去我们认为困扰 Git-over-HTTP 的 Unicorn 超时问题: Git LFS 支持 (由 Marin 开发)和 CI build artifacts (由 Kamil 开发)。这两个特性同时依赖于用户上传和下载任意的大文件。

此次开发为 gitlab-git-http-server 带来了很多新的改进。首先,越来越多的人需要说或写 'gitlab-git-http-server' 这一词,用的人多,这个名字叫起来就显得过于拗口。并且增加了一些新的特性,这个名字就不再合适了,因为程序已经不仅仅只处理 Git-over-HTTP。我们要谢谢 Marin 起的 'gitlab-workhorse'这个名字,我非常喜欢它,因为它点出了 Unicorn 的缺陷。

被盗用户
翻译于 2017/03/16 10:07
0

Kamil 是 Go 领域的常驻专家,自 gitlab-workhorse 得到他的关注后,取得了很大的进步。我们有信心让 gitlab-workhorse 发挥效用。

有段时间 Marin 和我试图在 gitlab-workhorse 中实现文件上传/下载,而 Kamil 则使用 NGINX 插件为 CI 工件实现了同样的功能。后来我们发现是重复劳动后,决定在代码发布之前,在 gitlab-workhorse 和 GitLab 8.2 中同时实现该功能。

Tocy
翻译于 2017/03/19 09:45
0

我们最终得到了一个在 gitlab-workhorse 上下载文件的优秀解决方案,灵感来自 Kamil 打算在 NGINX 中使用的机制:X-Sendfile 文件头。大多数时候,当你想使用 gitlab-workhorse 在 GitLab 中做出更快或更健壮的功能时,你必须同时编写 Ruby 版本和 Go 版本。但因为 Ruby on Rails 已经支持 X-Sendfile,GitLab 开发人员可以在无需编写任何 Go 代码的情况下获得 gitlab-workhorse 对文件下载的优化支持!

Tocy
翻译于 2017/03/15 17:44
0

孤注一掷

此时,通过在 gitlab-workhorse 中完成部分工作我们可以构建新的 GitLab 特性了,取得成功的同时相应的也会产生问题。每次我们向 gitlab-workhorse 添加新功能,都意味着在 NGINX配置 中将更多的 HTTP 请求转移到 gitlab-workhorse 上。 这个复杂性被隐藏在那些使用 Omnibus 包安装 GitLab 的人身上,但我可以从 gitlab-workhorse 问题跟踪器中看出来,使用源代码安装是问题的主要来源。

在 gitlab-workhorse 之前,NGINX 提供静态文件或将请求转发到 Unicorn 上:

+----------+      +-------------+
|          |      |             |
|  NGINX   +----> |   Unicorn   |
|          |      |             |
+------+---+      +-------------+
       |
       |
       |          +------------+
       |          |            |
       +--------> |   static   |
                  |   files    |
                  |            |
                  +------------+
Tocy
翻译于 2017/03/15 17:54
0
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(2)

BigEcho
BigEcho

引用来自“lidashuang”的评论

回复@BigEcho : 主函数之一不兼容 主要功能吧
回复@lidashuang : Unicorn 的设计与 Gitlab 的主函数dou不兼容
lidashuang
lidashuang
回复@BigEcho : 主函数之一不兼容 主要功能吧
返回顶部
顶部