AWS CodeBuild 宣佈支援 GitLab Runner?

看到 AWS CodeBuild 宣佈支援 GitLab Runner 的公告:「AWS CodeBuild now supports managed GitLab runners」。

第一眼看到有點問號,看了公告說明後的確就是把工作丟進 GitLab Runner 跑:

AWS CodeBuild now supports managed GitLab self-hosted runners. Customers can configure their CodeBuild projects to receive GitLab CI/CD job events and run them on CodeBuild ephemeral hosts.

但沒看懂支援 GitLab Runner 這個的用途... 會用 AWS CodeBuild 的人會需要這個嗎?有自己架 GitLab Runner 的人不是都應該用 GitLab 了嗎?

我再多想看看到底會有什麼情境會這樣架...

CI 服務的 IP 清單

目前的 CI 大多數都是跑在 cloud 上面,而且會 scaling,所以我一直以為沒有固定的 IP address (算是我的刻板印象),不過實際查了一下,發現商用 CI 服務是有考慮到的...

Travis CI 的說明是在「ip-addresses.md」這邊,可以透過 nat.travisci.net 這個 DNS record 取得他們的 NAT 會用到的 IP address。

另外他們會在使用前 24 小時前先公佈這組資料,所以如果你設計 cron job 更新的話可以考慮進去:

We will announce changes to this set of IP addresses with a 24 hour notice period.

CircleCI 則是再「IP ranges」這邊提供類似的方式,jobs.knownips.circleci.comcore.knownips.circleci.com 以及 all.knownips.circleci.com,另外新增的提前通知會有 30 天:

30 days notice will be given before changes are made to the existing set of IP address ranges.

GitHub Actions 則是可以在「About GitHub's IP addresses」以及「REST API endpoints for meta data」這邊拿到,在 actions 這個 key 下面有 IP address 的列表,測了一下不需要帶 token 就可以取得,不過這邊好像沒看到預先通知的時間...

其實因為這些服務還是共用 IP pool,攻擊者也可以租用這些 CI 服務在上面跑程式... 所以主要的需求還是 compliance,倒不是真的會因此變得有多安全。

Gitea 推出 Actions

Hacker News 上看到 Gitea 出 1.19 的消息:「Gitea 1.19 (gitea.io)」,在討論裡面就有人提到 Gitea Actions,從名字就知道是抄自 GitHub Actions,算是 Gitea 開始建立自己的 DevOps 生態系的一個重要功能。

目前這個功能還被掛在 EXPERIMENTAL 上,預設是關閉的,而且我自己試了一下也的確試跑不太起來,出現這樣的錯誤訊息,暫時也沒空去細追:

time="2023-03-28T17:36:37Z" level=info msg="poller: request stage from remote server" func=pollTask
time="2023-03-28T17:36:37Z" level=error msg="cannot accept task" error="unknown: rpc error: code = Internal desc = pick task: CreateTaskForRunner: Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1" func=pollTask
time="2023-03-28T17:36:37Z" level=error msg="can't find the task: unknown: rpc error: code = Internal desc = pick task: CreateTaskForRunner: Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1" func=Poll

接下來會有更多人跳進去試,之後再來看看成熟度如何...

在本機用 pip 直接安裝 PostgreSQL server

看到 PostgreSQL 官方站台上的介紹,可以直接用 Pythonpip 指令安裝 PostgreSQL server:「Install a local, non-root PostgreSQL Server with Python "pip"」,專案在「postgresql-wheel」這邊。

GitHub 上面的說明跑了一下,還真的可以惡搞... 這樣如果真的要在 CI 裡面跑的話也簡單很多了?只要能 pip 裝軟體就能跟你拼 XDDD

也省掉需要設定一些權限跑 Docker-in-Docker...

cURL 與 Travis CI 的事件

前幾天 Daniel Stenberg (cURL 的發明人與現在的維護者) 發表一篇從 Travis CI 搬出來的文章,換到 Zuul CICircle CI 上:「Bye bye Travis CI」,對應的 Hacker News 的討論可以在「Bye Bye Travis CI (haxx.se)」這邊翻到。

文章裡提到主要的兩個點是,Travis CI 當初有承諾會提供免費服務給 open source project:

今年的時候整個 Travis CI 的商業收費的機制改了,另外也嚴格增加了對 open source project 的限制,包括了你不能收到任何商業公司或是任何組織的贊助:

Project must not be sponsored by a commercial company or organization (monetary or with employees paid to work on the project)

另外 Daniel Stenberg 在文章裡也表明目前不打算付錢,要找市場上便宜可用的方案 (而目前看起來還有,至少 Zuul CI 與 Circle CI 都在選項內),所以就從 Travis CI 搬離了:

Lots of people have commented and think I’m “whining” about Travis CI charging for something that is useful and that I should rather just pay up. I could probably have gone with that but I dislike their broken promise and that they don’t consider us Open source anymore and I feel I have a responsibility to use the funds we get from gracious donors as wisely and economically as possible, and that includes using no-cost or cheap services rather than services charging thousands of dollars per year.

If there really were no other available and viable options, then paying could’ve been an alternative. Now, moving on to something else was the right choice for us.

然後 Travis CI 過了兩天丟出「Open Source Terms at Travis CI – An Update and Clarification」,雖然沒有表明是在講 cURL,但放在一起看其實也都大概知道發生什麼事情。

看了一下自己的小專案 (更新頻率不高,test case 也不多),丟 Circle CI 還算是夠用,另外自己也有弄個 GitLab,需要的時候也可以在上面跑 CI。

這邊另外看到 cURL 這種大型專案,因為 test case 數量很多,丟到不同的 CI vendor 上跑,看起來是個還不錯的架構...

Travis CI 停止提供服務給 Open Source 專案

Hacker News Daily 上看到這個,在講 Travis CI 終止對 open source 專案的服務:「Travis CI is no longer providing CI minutes for open source projects」。

有不少專案已經改用其他 CI 服務的 free tier 做,像是 GitHub ActionsCircleCI 都有提供。

看了一下 Hacker News 上的討論,不少人是可以理解不會有永遠免費的午餐,只是這次 Travis CI 的處理讓大家覺得比較討厭的是,一方面官方一直跟 open source community 說我們很願意支援 open source community (前幾個禮拜官方 blog 還有發文重申這件事情),另外一方面是一直在朝著關閉服務走:從限制 10K credits 開始,到現在不會再提供 credit 給 open source 專案。

有人整理了對應的時間軸:

? 2018: Travis CI announces they are starting the process of merging travis-ci.org, which provided free builds for OSS projects, into travis-ci.com, which until then was only for paying customers. They promise OSS builds will continue to be free.

? 2020: Travis CI announces they are shutting down travis-ci.org at the end of the year and all projects have to move to travis-ci.com. They promise OSS builds will continue to be free.

Early November 2020: travis-ci.com switches from providing unlimited builds for OSS to only providing 10k one-time credits by default. Projects that meet certain guidelines (e.g. no one paid to work on them) can apply for recurring credits.

Later in November 2020: CI for many OSS projects that had migrated to travis-ci.com starts to fail, as they've exhausted their 10K credits.

Dec 2020: If what is reported here is accurate, Travis CI stop providing any recurring OSS credits. CI breaks for the remaining OSS projects on travis-ci.com.

Jan 2021: travis-ci.org shuts down. CI will be broken for all projects using it. They'll have the option of migrating to travis-ci.com, but will soon break again as they exhaust their 10k credits.

這種服務非常吃 CPU resource,大型專案如果每個 push 或是每個 pull request 都跑一輪完整的測試,成本應該不低,大概可以理解為什麼 Travis CI 會這樣決定,不過態度就...

其他家有提供 free tier 的 CI 最近應該會湧入不少人,這幾個月可以看看其他家會不會也跟進,另外一方面應該也會有人開始自架?

HashiCorp 推出 Boundary 與 Waypoint

HashiCorp 推出了兩個新的產品。

第一個是 Boundary,這個產品看起來還很早期,但看起來想要實做 BeyondCorp 的一些想法 (可以參考之前寫的「Google 推的 BeyondCorp」):「Announcing HashiCorp Boundary」,這在 Hacker News 上有討論串,而且 HashiCorp 的老大 Mitchell Hashimoto 也有出來回答一些問題:「HashiCorp Boundary (hashicorp.com)」。

這個產品讓他慢慢發展起來應該會是不錯的 open-source implementation,不過傳統的 castle 在小一點的場合也還算夠用...

另外一個是 Waypoint,看起來是個 CI/CD 類的產品:「Announcing HashiCorp Waypoint」,在 Hacker News 上也有討論串,而且同樣的 Mitchell Hashimoto 也有在裡面回覆一些東西:「Waypoint: Build, deploy, and release applications across any platform (hashicorp.com)」。

我自己看了一下設定的方式以及一些畫面,然後再回頭看 Hacker News 上的討論,以目前得到的資訊來看,這個產品似乎沒有很明顯解決到痛點,也許就是補產品線...

Travis CI 支援 Arm64 平台的編譯與測試了

剛剛看到 Travis CI 宣佈支援 Arm64 的編譯與測試環境了:「Announcing General Availability of Graviton2 CPU Support!」。

架構上是利用 AWS 推出的機器來做,其中支援的 OS image 目前看起來是以 Ubuntu 為主,其中 16.04 (xenial) 與 18.04 (bionic) 只有 LXD container 的環境,而 20.04 (focal) 則除了 LXD container 環境外,也有完整的 VM 環境可以跑:

Following Arm64 distributions of Ubuntu are available for you as LXD containers:

Xenial (16.04)
Bionic (18.04)
Focal (20.04)

Following Arm64 distribution of Ubuntu is available for you as a full VM option:

Focal (20.04)

看起來底層是用 Ubuntu 20.04 為主力,然後提供 container 跑其他版本。

Travis CI 推出 20.04 的環境了

看到 Travis CI 推出 Ubuntu 20.04 的測試環境公告,嚇了一跳:「Ubuntu 20.04 (Focal Fossa) build environment is available!」。

要知道當年是在 2017 年七月才支援 Ubuntu 14.04 (參考「Travis CI 總算要把 Trusty 當作預設環境了...」這篇),在 2018 年十一月才支援 Ubuntu 16.04 (參考「Travis CI 居然記得要支援 16.04 了...」這篇),然後 18.04 上線乾脆不公告了 (翻了一下社群的討論「Ubuntu 18.04.1 LTS (Bionic Beaver)」,是在 2019 年的七月左右支援的)...

這次 20.04 出來還不到半年居然支援了!

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,試著租一個月也確認可以跑,這樣代表之後又有更多選項啦...