container

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 想出新方法來搞？

跑 ArchiveTeam Warrior

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

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

第二種與第三種都是 container 類的方式，Docker 與 Podman 都能跑起來。

跑起來後可以連進 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 外的一些方法。

生一個 static 版本的 ffmpeg

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

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

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

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

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

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

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

在 AWS Summit Taiwan 2021 上講的 HashiCorp Vault

今年的 AWS Summit Taiwan 2021 是線上的形式，早在前一個月前就先預錄好，但開始的時候就忘記要宣傳一下了... 結果是在找資料的時候發現其他人有提到：「AWS實作紀錄 #2：高可用性保管服務 (2021 AWS Summit Taiwan)」。

投影片與影片如果有興趣的人可以去 AWS 活動頁面上看，或者上面提到的那篇。

這次講的主題是想要在雲端上面搭建 Vault，但又不希望自己搞一堆 High Availability 的架構，最好是雲端服務本身就有提供... 而既然是在 AWS 的場子，主要都還是以 AWS 的服務來搭建。

在這次的設計裡，Vault 的資料是放在 DynamoDB 上，然後透過 KMS 管理加密用的，這兩個服務本身都有 High Availability，所以直接用就可以了。

接下來是跑 Vault 程式的部份，這部份得自己處理 High Availability 的架構，我是用兩台很小台的 EC2 instance (t4g.nano) 在跑，這邊也可以換成 ECS 或是 EKS 的 container。

接下來把這兩台 EC2 instance 掛起來的也都是 High Availability 服務：在 EC2 instance 前面用 ELB 擋住提供 HTTP API 服務，另外這邊即使是內部用，也可以上 HTTPS (透過 ACM 掛上 HTTPS 的憑證)。

在 ELB 上看到只有一台機器活著是正常的，因為兩台機器之間是 active-standby 架構，同時間只會有一台機器在運作，而 lock 的機制是 Vault 透過 DynamoDB 實做的，不需要另外處理。

其實裡面大多數的元件都可以抽換，像是 DynamoDB 也可以用其他的服務來當儲存層，馬上可以想到的是 RDS 的 MySQL 或是 PostgreSQL。

概念上不算困難，所以投影片上主要就是給設定檔，這樣方便大家抄，不用在自己摸指令摸半天...

用 Podman 替代 Docker？

也是因為最近 Docker Desktop 改變授權的關係 (參考先前寫的「Docker Desktop 要開始對商用收費了，以及 Open Source 版本的設法」這篇)，有不少人在講怎麼用 Podman 替代 Docker，不過要注意這邊的替代不是 drop-in replacement，而是功能上的替代。轉移的過程還是得花一些時間處理...

在 Mac 上面的範例大多都是用 Homebrew，我在 MacPorts 上也有看到套件：「podman」，看起來好像得多裝 qemu，但即使把 qemu 裝起來，也還是不會動... 後續因為沒有需求，加上先前已經把 Docker CLI 的版本弄好了，暫時就沒再多研究要怎麼跑起來。

另外有人寫了「Migrating from Docker to Podman」這篇，在「GUI Replacement」的部份還介紹了對應的 GUI 方案，也可以參考看看。

跟以前的養套殺類似，都會推動一些 open source 替代方案的成熟度，以這次的情況看起來這些能量有很大一部份都會進到 Podman 裡面，對於個人用戶也可以再放幾個月看看是不是要跳槽過去。

Amazon ECS Anywhere

在去年年底 AWS 的公佈的「re:Invent 2020 – Preannouncements for Tuesday, December 1」裡面提到兩個有趣的產品，一個是 Amazon ECS Anywhere，另外一個是 Amazon EKS Anywhere，現在 Amazon ECS Anywhere 開放了：「Getting Started with Amazon ECS Anywhere – Now Generally Available」。

這兩個服務都是把自家的機器 container 化然後讓 AWS 的服務直接管理，只是一個是 ECS (AWS 自家的規格)，另外一個是 EKS (基於 Kubernetes)，這次丟出來當然很重要，不過還是會等 EKS Anywhere 出來後一起比較看看。

價錢的部份就是照機器數量算，一台機器大約 USD$7.38/month，以 bare metal 等級的機器來說倒是沒什麼問題：

You pay $0.01025 per hour for each managed ECS Anywhere on-premises instance. An on-premises instance is a customer-managed instance that has been registered with an Amazon ECS cluster and runs the Amazon ECS container agent.

這樣讓地端的機器更容易上雲，不過離台灣本地沒有 region 在網路的 latency 上就有點討厭了，另外一種搞法是找 dedicated hosting 或是自己塞機器進 colocation hosting，然後掛上這類服務？

AWS 推出 CloudShell

AWS 推出了 CloudShell，讓使用者可以繼承 IAM 的權限，在瀏覽器裡面用 command line 操作 AWS 資源：「AWS CloudShell – Command-Line Access to AWS Resources」。

使用方式很簡單，在 web console 上方的 icon 點下去就可以用了，只是第一次使用的時候會看到需要建立環境的訊息，會等比較久：

連進去後測了一下，看起來是跑一個 30GB Disk 與 4GB RAM 的 container 起來，/proc/cpuinfo 裡面可以看到是 Intel E5-2676 v3 的機器，以這個資訊來查，看起來可能是 m4 系列的機器。

網路的部份基本上對 internet 的 TCP 與 UDP 都可以通，但需要操作 raw socket 丟 ICMP 的 ping 與 mtr 就不會通了。

目前支援的區域只有這些，之後應該會陸陸續續再開放：

Regions – CloudShell is available today in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo) Regions, with the remaining regions on the near-term roadmap.

費用的部份，官方是說不需要另外的費用，只需要付出用到的 AWS 資源，但這邊沒給範例啊，到底是怎麼算的... 看了一圈 EC2、ECS、EKS 都沒有機器，應該是不會算到這邊？

Pricing – You can use up to 10 concurrent shells in each region at no charge. You only pay for other AWS resources you use with CloudShell to create and run your applications.

刷了一下的感覺是，對於已經習慣跳板機的人來說好像還好，尤其是 command line 已經用熟了，太習慣用 Ctrl-W 刪字串，而在瀏覽器裡面按下去就會直接出事的情況，還是有點難用...

比較明顯的好處應該是整合了 IAM 的權限，所以在 awscli 下的權限是一樣的，另外對於有些 web console 沒支援的操作可以用這個方法補強，而不需要自己弄機器出來跑。

AWS 推出 Amazon Elastic Container Registry Public (公開版的 ECR)

算是延伸產品線，把 Amazon ECR 變成可以公開使用：「Amazon Elastic Container Registry Public: A New Public Container Registry」。

這篇稍微有趣的地方是，文章裡面的上面這張圖有把 path 模糊化，但下面那張沒有遮，後面的文字也直接有提到 path (這是要給使用者玩的...)：

ECR Public 會自動同步到兩個 region，但設定的頁面上好像沒寫會怎麼挑... 另外前面會放 CloudFront 加速。

ECR Public automatically replicates container images across two AWS Regions to reduce download times and improve availability. Therefore, using public images directly from ECR Public may simplify your build process if you were previously creating and managing local copies. ECR Public caches image layers in Amazon CloudFront, to improve pull performance for a global audience, especially for popular images.

費用的部份，意外的有提供一些免費的空間與頻寬可以用，算是在推廣嗎？