用 shebang 掛起 Docker instance

週末偶而會看到一些奇怪的 side project,像是用 shebang (#!) 直接跑起一個 Docker instance 的方式:「Show HN: #!/usr/bin/env docker run (gist.github.com)」,程式碼在 gist 上:「adtac/595b5823ef73b329167b815757bbce9f」。

可以看到裡面主要的內容都是 Dockerfile,然後重點在開頭的 shebang command,把這些 Dockerfile 的指令倒進去跑 docker build:

#!/usr/bin/env -S bash -c "docker run -p 8080:8080 -it --rm \$(docker build --progress plain -f \$0 . 2>&1 | tee /dev/stderr | grep -oP 'sha256:[0-9a-f]*')"

記得這邊處理後面參數的部分有 undefined behavior,在 id=38989173 這邊也有人提到了:

Beware of portability: it relies on a non-standard behavior from some operating systems. It only works on OSs that treat all the text after the first space as argument(s) to the shebanged executable; rather than just treating the whole string as an executable path (that can happen to contain spaces).

但這主要是好玩,也就還好了...

觀察 Docker image 每一層變化的 dive,以及操作的 crane

在「Dive: A tool for exploring a Docker image, layer contents and more (github.com/wagoodman)」這邊看到的工具,官網在 GitHub 上:「wagoodman/dive」。

Docker image 是一層一層疊起來的,而 dive 可以翻出每一層的變化:

A tool for exploring a docker image, layer contents, and discovering ways to shrink the size of your Docker/OCI image.

馬上想得到的用途是拿來分析空間的使用情況,另外可以拿來確認 container 裡面的內容 (就不用 /bin/bash 進去看了)。

在留言 id=38915336 這邊另外提到了 crane 這個有趣的的東西,可以操作 Docker image。

這邊看到的說明包括了合併不同的 layer,以及類似 Gitrebase 功能 (re-apply diff):

For image and layer manipulation, crane is awesome - as is the underlying go-containerregistry library.

It lets you add new layers, or edit any metadata (env vars, labels, entrypoint, etc) in existing images. You can also "flatten" an image with multiple layers into a single layer. Additionally you can "rebase" an image (re-apply your changes onto a new/updated base image). It does all this directly in the registry, so no docker needed (though it's still useful for creating the original image).

https://github.com/google/go-containerregistry/blob/main/cmd/crane/recipes.md

(updated: better link)

兩個剛好搭在一起...

Podman Desktop 1.2 支援 Docker Compose

Hacker News 上看到 Podman Desktop 支援 Docker Compose 的消息:「Podman Desktop 1.2 Released: Compose and Kubernetes Support (podman-desktop.io)」,連結的原文是 1.2 版的 release notes:「Release Notes - Podman Desktop 1.2」。

原文提到 Compose 而不是直接講 Docker Compose,所以猜測是一個新產品,會不相容 docker compose,但看起來會是相容的東西,最後一句就說可以用 docker-compose 或是 podman-compose 跑:

In the last month we've been addind support for more Compose features. Before you were only able to control a group of containers if they were in a Pod. Now we have added the ability to control a group of Compose containers. You can now start, stop, delete and restart a group of containers launched by either docker-compose or podman-compose.

雖然沒什麼在用,但我還是有透過 Flatpak 裝 Podman Desktop,需要的時候就不用另外搞。

剛剛看了一下 Flathub 上面的版本還是 1.1.0 (Podman Desktop | Flathub),要等他更新...

Rocky Linux 提出兩個方法取得 RHEL 的 source code

在「AlmaLinux 與 Rocky Linux 看起來都暫時無解」這邊提到了檯面上目前沒有好方法穩定取得 source code 後,Rocky Linux 提出了兩個方法,在不需要同意 RHEL 的條款下取得 RHEL 的 source code:「Keeping Open Source Open」。

中間還有一些小插曲可以提一下,在社群不少抗議聲後,IBM & Red Hat 的 VP 出來直接說他們認為 RHEL rebuild 沒有任何價值,而且是故意讓 rebuilder 更難實作 RHEL rebuild:「Red Hat’s commitment to open source: A response to the git.centos.org changes」。

Ultimately, we do not find value in a RHEL rebuild and we are not under any obligation to make things easier for rebuilders; this is our call to make.

回到 Rocky Linux 的文章,他們提出來的兩個方法都是基於 GPL 的重要性質:如果你可以合法拿到 binary,那麼散佈者就有義務要提供 source code。

第一個方法是透過 RHEL 目前公開提供的 container image:

One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected.

另外一種方式是透過雲端服務的 cloud instance 跑 RHEL:

Another method that we will leverage is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata. This is the easiest for us to scale as we can do all of this through CI pipelines, spinning up cloud images to obtain the sources via DNF, and post to our Git repositories automatically.

這兩個方法都不需要同意 RHEL 目前在網站上的 TOS 與 EULA,而且短時間內應該不好防堵:前者要關掉的話,應該有一堆既有 RHEL 客戶在用會直接抱怨,真的要硬幹的話得給這些客戶時間從 public repository 轉移到要認證的 repository 上;而後者要堵的話,除非 IBM & Red Hat 決定直接不做雲端生意?

看起來 Rocky Linux 與 AlmaLinux 用這套方法可以撐一陣子,直到 IBM & Red Hat 想出新方法來搞?

在 Fly.io 上面跑 PHP

Heroku 把 free tier 拔的差不多後 (「Heroku 公佈了廢止免費方案的時間表」、「Heroku 的替代方案」),大家手上的小專案都往其他的服務跑,目前看起來做的比較有規模的就是 Fly.io 了,一個人可以建很多個 organization,而每個 organization 都有 free quota 可以用...

Fly.io 官方的文件 FLy.io Docs 裡面可以看到說明,介紹怎麼把 Laravel 站台跑起來,不過沒介紹怎麼跑純 PHP 站台,所以就看了文件研究看看,發現可以用 Docker container 跑,那就簡單了。

專案放在 GitHubgslin/fly-vanilla-php 上面。

一開始我的 Fly App 用的是 V1 的版本,是跑起來了,但後來還是換到 V2 跑,雖然兩者用起來沒有太大區別 (參考「Fly Apps」這邊的說明),但畢竟官方打算都把 V1 掛上 legacy 了,新的專案就儘量別用了...

另外一開始用 buildpacks 編 Docker image,但發現太慢了,就還是去 Docker Hub 上找個大戶人家包好的 image 來用。

首先是 fly.toml 這個檔案,這邊就直接指定用 Dockerfile 來編。

然後是 Dockerfile 這個檔案,這邊用的 image 是 richarvey/nginx-php-fpm 這包,預設會開在 port 80,所以 fly.toml 裡面就把 internal_port 指定在 80

另外就是指定了 WEBROOT,我把 root 放在 public/ 下面。

跑起來以後就可以用他提供的網址測試了,我這個專案在 https://hidden-river-325.fly.dev/ 這邊可以看到,另外我有設定自己的 domain,在 https://test-fly.gslin.com/ 也可以看到一樣的 phpinfo(); 資訊。

這邊有個小插曲,我想要掛自己的 domain 上去跑 HTTPS,但如果機器沒有掛 IPv6 address 的話,Fly.io 的系統不會認定設定已經完成,也就不會往下去申請 Let's Encrypt 的憑證,我放了一天覺得奇怪,摸了辦天才發現這個 "feature"。

跑 ArchiveTeam Warrior

Archive Team 是一個致力於保存數位資料的組織,而 ArchiveTeam Warrior 則是他們提供的軟體,可以讓你很方便直接跑 worker 加入他們的 cluster,幫忙抓資料並且保存到 Internet Archive 上。

他們提供三種方法跑 ArchiveTeam Warrior,第一種是 VM 的方式,文件裡面有介紹怎麼用 VirtualBox 或是 VMware Player 跑起來。

第二種與第三種都是 container 類的方式,DockerPodman 都能跑起來。

跑起來後可以連進 http://127.0.0.1:8001/,然後選擇想要加入的項目,或是接受指令選擇目前團隊主打的項目。

在「Projects」這頁可以看到目前主力是備份 Enjin 上的資料。

丟了兩台 VPS 的機器上去用 Docker 跑,CPU 使用率看起來很低,但網路流量看起來會因為所在的地點而差蠻多的,一台大約是 300KB/sec 到 400KB/sec,換算後大約是 1TB/mo,另外一台則只有 1/10 的量。

翻一下 Linux container 的各種 overhead

想要查一下 Linux 下跑 container 的 overhead,發現大多都是 2014~2016 左右的文章,而且基本上都是 Docker,好像沒什麼新資料,但還是整理整理...

首先是「What is the runtime performance cost of a Docker container?」這篇,裡面的答案有提到 CPU、Memory 以及 I/O 看起來 overhead 都不高,主要是網路的 latency 增加不少:

看起來大約是 40µs 的增加 (0.04ms),這個量級雖然看起來很小,但對於本來就是透過 Ethernet 溝通的的應用來說,平常可能都是 <1ms 了,0.04ms 的增加可能還是有影響 (像是 TCP 的 3-way handshake)。

另外一篇是 Percona 的「Measuring Percona Server Docker CPU/network overhead」,不過這邊是測 CPU bound 的方式,沒有碰到 heavy I/O:

可以看到網路層的變化造成 tps 的變化,也符合在 Stack Overflow 上面找到的文章。

Oracle 官方的「MySQL with Docker - Performance characteristics」這篇則是測到 I/O bound 的應用,畢竟資料庫軟體會用到很多一般 I/O 測試不會用到的 flag,像是 InnoDB 大家通常都會啟用 O_DIRECT

For these tests, we used a custom configuration file. We first deliberately set the buffer pool size to around 10% of the total database size in order to increase I/O-bound load. The database size was 2358MB, so we set our buffer pool size to 256MB. We then increased the buffer size to 16384MB to see what happens when Docker isn’t bound by I/O load.

文章後面有列出數字,可以看到 I/O bound 的應用似乎沒有什麼影響,而 network bound 的時候可以看到效能的下降。

不過得注意這些資料都是六年前的資料了,沒有什麼新資料可以看做應該是沒什麼改變,但畢竟不是 100% 確定的事情...

在 Docker 裡面跑 GUI 程式的點子

昨天的 Hacker News Daily 上看到「Running GUI apps within Docker containers」這篇文章,裡面想要把程式包到 Docker container 裡面,然後給了一些想法,另外在「Running GUI apps within Docker containers (trickster.dev)」這邊也有一些討論與想法可以看。

要注意的是,這邊主要是以 X11 類的環境為主 (所以應該還是 Linux 了),而文章是用 Firefox 當例子,不過主要應該還是會拿來跑其他的東西...

看起來 GUI 的部份主要就是先用 VNC + x11vnc 打通到 host 的 X11 環境,這邊會需要 xhost 開授權讓 container 內的程式可以控制 X11 的環境 (話說他範例裡面直接開 xhost + 也真讚)。

後面提到的 noVNC 則是把 VNC 轉到 HTML5 上面讓瀏覽器可以操作,就不是那麼感興趣。

另外在討論裡面也有人直接放大絕,把一堆權限放進去 container:

docker run -it --rm -e DISPLAY --net=host -v $XAUTHORITY:/root/.Xauthority -v /tmp/.X11-unix:/tmp/.X11-unix debian:11-slim

不過整體看起來算是提供了一些思路... 算是除了 Flatpak 外的一些方法。

使用 heredoc 語法的 Dockerfile

Simon Willison 這邊看到的,在 Dockerfile 裡面使用 heredoc 語法編 Docker image:「Introduction to heredocs in Dockerfiles」,引用的文章是「Introduction to heredocs in Dockerfiles」與「Introduction to heredocs in Dockerfiles」,七月的事情了。

heredoc 指的是可以讓開發者很方便使用多行結構,在 Dockerfile 這邊常見到的 pattern:

RUN apt-get update
RUN apt-get upgrade -y
RUN apt-get install -y ...

但這樣會產生出很多層 image,所以先前的 best practice 是:

RUN apt-get update && \
    apt-get upgrade -y && \
    apt-get install -y ...

而 heredoc 的導入簡化了不少事情,這應該有機會成為新的 best practice:

RUN <<EOF
apt-get update
apt-get upgrade -y
apt-get install -y ...
EOF

要注意的是,開頭要記得加上 #syntax 的宣告,用到 docker/dockerfile:1.3-labs 這組才能使用 heredoc:

# syntax=docker/dockerfile:1.3-labs

然後用 buildkit 去編,用新版的 Docker 已經包 buildkit v0.9.0 進去了:

DOCKER_BUILDKIT=1 docker build .

生一個 static 版本的 ffmpeg

目前有丟出來的 FFmpeg 執行包都會因為軟體授權不相容的問題,沒辦法把想要的東西都包進去 (或者無視授權丟出來 XD),但反正看一看沒看到適合的,所以弄了一天包了一包出來。另外也是因為同樣理由,這邊也只能提供步驟讓大家自己編...

我的主力放在 AV1VP9 的支援上,步驟就寫在「FFmpeg」這邊了,裡面是先開了一個 Docker container 再去裝環境,接著再把會用到的 source code 用 git clone 拉下來再固定版本,所以應該是不會有太大的意外。

另外可以看到 libfdk-aac 與 libx264 兩包我就直接拉系統的套件來包,主要是查了一下版本還算堪用,而且也不是主力要處理的東西,就不想要再自己拉下來編了。

這邊就是整理一下感想...

首先是 Rust 一直在推新功能,然後各家的軟體也幾乎就是馬上跳進去用這些新功能,所以只能用 rustup 跟到最新版的 Rustc 去編 rav1e

然後 x265 搞不定 static compile 的問題,卡在沒有 libgcc_s.a 可以用,如果還要搞 GCC 的話就太累了...

這樣在 AV1 與 VP9 的支援度就比較完整了,另外內建 libvmaf 也可以拿來分析...