GitLab 想要支援 ActivityPub

看到「Support ActivityPub for merge requests」這則消息,這個 epic 的作者 Derek Ferguson 可以看到是 GitLab 家的「Group Manager, Product」,看起來是產品團隊的主管職 (不是很確定)。

這張 epic 想建立跨 GitLab 服務之間的 ecosystem:

There already has been several very popular discussions around this (see here, here and the epic here). The gist of it is: what people really want is to have one global "Gitlab network" to be able to interact between various projects without having to register on each of their hosts.

不過目前像是在討論階段?但既然是由內部提出來的,目前的討論看起來也還算... 正面?應該是有機會看到後續的更新...

GitHub 的 Markdown 透過 Mermaid 支援各種流程圖

前幾天 GitHub 宣佈他們站上的 Markdown 透過 Mermaid 支援流程圖:「Include diagrams in your Markdown files with Mermaid」。

翻了一下 GitLab 也有 Mermaid 支援:「GitLab Flavored Markdown」,所以這個部份兩邊的系統可以通了...

寫 API 文件時也蠻常用到的東西,之前是在 GitLab 上面弄了 PlantUML 的支援,找時間來分析...

用 Kroki 搞定 GitLab 上的 UML 圖

在「在自架 GitLab 使用 Kroki 來繪圖」這邊看到 Kroki,先把自己的 GitLab 接上去,整個流程還蠻簡單的...

Kroki uses a simple algorithm (deflate + base64) to encode your diagram in the URL:

GET /plantuml/svg/SyfFKj2rKt3CoKnELR1Io4ZDoSa70000

我跟 Heresy 用的方法不太一樣,是透過「Manual Install」這邊的方式裝,只要先把 .jar 檔抓下來放到對應的位置 (我是丟到 /usr/share/kroki/ 這邊),然後自己寫個 systemd 的 service 檔案放到 /lib/systemd/system/kroki.service 裡面:

#
[Unit]
Description=Kroki daemon
After=remote-fs.target

[Service]
ExecStart=/usr/bin/java -jar /usr/share/kroki/kroki-server-v0.13.0.jar
Restart=always
RestartSec=60
Type=simple

[Install]
WantedBy=multi-user.target

預設是 SECURE 模式 (參考「Configuration」這邊的說明),我就不加什麼特別的參數了,另外預設會跑在 port 8000,這邊會需要自己設定 nginx

然後讓 systemd 重讀設定再跑起來:

sudo systemctl daemon-reload
sudo systemctl enable kroki
sudo service kroki restart

目前跑的兩台機器都是 Ubuntu 18.04,內建的 JDK 都是 Java 8 的版本,不確定 Java 11 的環境如何。

關閉 GitLab 的 nginx,使用自己裝的 nginx

我自己架設的 GitLab 是透過「Install self-managed GitLab」這邊的方法裝進 Ubuntu 系統內的 (我在自己的 wiki 上也有整理:「GitLab」),他會自己下載所有對應的套件,包括了 nginx

但這樣就直接把 TCP port 80/443 都吃掉了,同一台機器要放其他的 virtual host 就比較麻煩,所以找了些方法讓 GitLab 不要佔用 TCP port 80/443。

首先是找到這篇,資料有點舊,但裡面關掉 nginx 的方法還算是有用:「How to setup gitlab without embedded nginx」。

現在只要把 /etc/gitlab/gitlab.rb 裡面的:

  • nginx['enable'] 改成 false
  • web_server['external_users'] 改成 ['www-data']

然後跑 gitlab-ctl reconfigure 讓他更新設定檔,接下來停掉整個 GitLab 再打開 (或是重開機) 讓 nginx 完全失效就可以了。

接下來弄好自己的 nginx 以及 HTTPS 設定,這個部份我自己偏好用 dehydrated,其他人會有不同的偏好設法。

在弄完 nginx 後再來是 proxy_pass 類的資訊要帶進去,這個部份可以參考本來 GitLab 的 nginx 設定檔 (在 /var/opt/gitlab/nginx/conf/ 這下面),其中最重要的就是 GitLab 本身,我們會在 /etc/nginx/conf.d/upstream.conf 裡面寫入對應的 upstream 資訊 (沒這個檔案就自己生一個):

upstream gitlab-workhorse {
    server unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket;
}

接下來是在對應的 virtual host 下設定 proxy_pass

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://gitlab-workhorse;
    }

另外我有啟用 GitLab 提供的 Mattermost,所以也要翻設定導進去:

#
upstream gitlab_mattermost {
    server 127.0.0.1:8065;
}

與:

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://gitlab_mattermost;
    }

都弄好後叫 nginx 重讀設定,接下來應該就會動了... 然後 TCP port 80/443 也算自由了,要掛其他的網域上去應該都 OK。

維基基金會的 Git Server 從 Gerrit 換到 GitLab

這兩天受到注意的消息,維基基金會決定把 Git Server 從本來的 Gerrit 轉換到自建的 GitLab 上:「GitLab consultation」,在 Hacker News 上也有不少討論 (i.e. 戰文):「Wikimedia is moving to Gitlab (mediawiki.org)」。

先從官方的說法開始看,主要是 Gerrit 的運作方式與目前業界與社群的常用方式不同,也導致了 usability 不怎麼好,這使得社群與基金會的員工的學習成本偏高:

While Gerrit’s workflow is in many respects best-in-class, its interface suffers from usability deficits, and its workflow differs from mainstream industry practices. This creates barriers to entry for the community and slows onboarding for WMF technical staff.

另外也發現內部很多人會直接用外部的 Git 服務,了解後主要列出三個原因:

  • lower friction to create new repositories
  • easier setup and self-service of Continuous Integration configuration
  • more familiarity with pull-request style workflows

再來就是尋找與選擇的過程了,但其實市場上也沒什麼可以選的,從說明的 FAQ 部份可以看到 GitHub 與 GitLab,另外因為基金會的特性有強烈偏好 open source self-hosting 方案,基本上就是 GitLab 了...

不過如果是因為 code review 而決定換過去的話,我猜不完全是工具的問題,內部應該有不少政治上的問題,只是外面這次看不出來而已。

在 Hacker News 上的討論還蠻有趣的,有些前員工的發言點出了在 code review 時遇到的問題看起來不是這次換成 GitLab 可以解的。

GitLab.com 將不支援免費使用者的 2FA reset

好像是在 Hacker News 的首頁上看到的,GitLab 宣佈他們的服務將不提供免費使用者 2FA reset:「GitLab Support is no longer processing MFA resets for free users」,對應的討論串在「Gitlab Support is no longer processing MFA resets for free users (gitlab.com)」這邊可以看到。

官方的公告,從今年的 8/15 開始就不再提供 reset:

As of Aug. 15th, 2020, GitLab Support will no longer process MFA resets for free accounts.

這反而是鼓勵使用者不要開啟 2FA,在討論裡面有人就講到這件事情,這個方法讓設定 2FA 的人受到處罰:

Think about the psychology of what you are telling people: "You have two choices - one is normal security, which you use on 80%+ of the rest of the internet, and one is 2fa which you only use on the annoying services that badger you into it. On the first one, if you lose your password you can do a password reset. On the second one, if your laptop and phone get fried in a rainstorm / car crash / act of children, you lose access to everything forever, no recourse and no recovery. And by the way, we totally encourage you to choose the second one... "

主因是,不是每個用 2FA 的人都知道要怎麼保護自己的帳號:像是同時有多把硬體的 U2F 放在不同地方,並且還有手機的 TOTP,另外還會把 backup code 放到安全的地方。

這次可以看出來 GitLab 的安全概念其實又出包了...

OpenVZ 裡的 Docker

前幾天在公司弄 GitLabGitLab CI,前者光跑起來都還沒動他就先吃 1.5GB 左右的記憶體,動兩下就 2.5GB 了。後者的 CI 隨著使用的情況而改變,不過最少丟個 1GB 差不多...

公司用的機器當然是還好,先簡單弄一台 t3a.medium (4GB) 跑 GitLab 主體,然後另外一台 t3a.small (2GB) 跑 CI 的 Runner,真的有需要的時候可以再往上拉...

不過自己也要弄的時候就會考慮到成本問題,畢竟也只有自己一個人用,如果在 Vultr 上面租類似的機器就要 USD$30/month,其他的 KVM VPS 也都差不多價錢。

OpenVZ 的 VPS 主機一向都比 KVM 的 VPS 便宜不少,但有不少限制。其中一個限制就是沒辦法跑 Docker,這樣就沒辦法把 GitLab CI 的 Runner 跑上去了 (有其他模式可以跑,但我這邊偏好用 Docker)。

查了一下資料 (因為記得 OpenVZ 有計畫要支援 Docker),發現 OpenVZ 7 已經支援 Docker 了,而且在官方文件上面也都已經有說明了:「10.3. Setting Up Docker in Virtuozzo Containers」、「Docker inside CT vz7」。

然後順著找一下,發現市場上也已經有 OpenVZ 7 的 VPS,而且會宣傳支援 Docker,試著租一個月也確認可以跑,這樣代表之後又有更多選項啦...

GitLab 12.1 之後放棄支援 MySQL

GitLab 打算在 12.1 之後放掉 MySQL 的支援:「Why we're ending support for MySQL in 12.1」。

GitLab 在說明裡給了不少原因,但看了看以後還是覺得 GitLab 每次在做技術決策時給出來的理由都很... 有趣?XD

每次看這三家提供的技術工具或是技術決策都很有趣... (另外兩家是 UberYahoo!)

GitHub 推出 Package Registry

GitHub 推出了「GitHub Package Registry」,可以代管自己開發的軟體。

目前支援 npm (Node.js)、DockerMaven (Java)、NuGet (.NET)、RubyGems (Ruby) 五個平台,

隔壁 GitLab 說我們早就有了而氣噗噗中:「Packaging now standard, dependency proxy next?」。

Anyway,省下一些事情,以前會透過 CI/CD 丟到像是 packagecloud.io 這樣的服務上讓內部使用,現在看起來 GitHub 上面可以解決一些簡單的情境...

走不同方向的 Git Hosting:sr.ht

看到「sr.ht, the hacker's forge, now open for public alpha」這篇,講 sr.ht 這個 Git Hosting。

文章裡面有提到,目前大多數的 Git Hosting 都很像,不管是 BitbucketGitLab、其實大家都是抄 GitHub 的界面與功能抄得很開心...

sr.ht 則是從不同的角度來設計 Git Hosting,避免了大量 js 的界面,但還是提供了很豐富的功能 (支援 markdown 文件、CI、透過 mailing list 討論、有一個 ticket system 可以放各種事項、wiki、...)。

其實還是支援了現在 Git Hosting 常見的功能,只是功能與界面上不太相同而已 XD