2020年の docker-satysfi 振り返り

この記事は SATySFi Advent Calendar 2020 の13日目の記事です。

SATySFi ユーザのみなさま今年も amutake/satysfi (以降 docker-satysfi) をご利用いただきありがとうございました (docker-satysfi は SATySFi と Satyrographos (SATySFi のパッケージマネージャ) が入った Docker イメージです。詳しくは satysfi-docker を使って SATySFi をお手軽に試す - amutake's blog をご覧ください。なお最近リポジトリの名前を satysfi-docker から docker-satysfi に変えた (理由は後述) ので、これまでは satysfi-docker と呼んでいましたがこれからは docker-satysfi と呼ぶことにします)。

Docker Hub を見ると Pull された回数が 10K+ とのことで、(もしかしたらほとんどが CI からなのかもしれませんが、) たくさんの方に使っていただいているみたいです。ありがとうございます。

さて、今年の docker-satysfi の振り返りをしていきます。

新しいバージョンがリリースされたときに粛々と更新できた

SATySFi は今年1月にバージョン 0.0.4 が出て、現在は 0.0.5 (satyrographos-repo は 0.0.5+dev2020.09.05) になっています。

今年も昨年同様、SATySFi の新しいバージョンが出たときは docker-satysfi の方も更新することができました。 0.0.5+dev2020.09.05 だけは気がつくのがひと月ほど遅れてしまいましたが、それ以外はわりと早く追従できたのではないかなと思います。

docker-satysfi みたいなものは粛々と更新していくのが重要だと思っていますので、とりあえず今年はそれを達成できました。

まあ、新しいバージョンが出たときにやることと言っても各 Dockerfile に書かれているバージョンを書き換えて GitHub でリリースを作るだけなので、5分かからないくらいで済みます。

nightly ビルドによって SATySFi のビルドエラーにいくつか気づけた & 直せた

今年は docker-satysfi のおかげで SATySFi と Satyrographos のビルドエラーにいち早く気がつくことができ、そのうちのいくつかはパッチを送ることができました。

docker-satysfi では nightly ビルドとして毎日 SATySFi と Satyrographos の最新版のビルドをしているのですが、 SATySFi もしくは Satyrographos がビルドできなくなると nightly ビルドも失敗して、毎日しつこくビルドエラーがメールで届くようになってしまうので、できるだけ早く直さないといけないという圧を受けることができました。実際、ものによってはビルドできなくなっても当日には直せていた気がします (レビュー・マージも素早く行っていただいたおかげ)。

docker-satysfi の利用者ではなくても、nightly ビルドの定義を見れば SATySFi をビルドできる方法がわかるので、ビルドできなくなったときは見てみてください。

パッケージの CI で使ってくれる方が増えてきた

そのままですがパッケージの CI で docker-satysfi を使っていただいている方をちょくちょく見かけるようになってきました。嬉しいです。

昨年の Advent Calendar で書いた記事 GitHub Actions で SATySFi の文書やパッケージの CI - amutake's blog のおかげかもしれません。

この昨年の記事ですが、いまは opam (opam ファイル) と satyrographos を使って依存パッケージをインストールする流れができているのでそれでやるとよりシンプルにできそうです。更新したほうがいいですがまだできていないです。また、後述する opam-slim タグを使うと CI も1分くらい速くなります。

opam が使えてサイズが小さいイメージを作ることができた (opam-slim タグ)

まだ experimental ですが、opam-slim というタグができました。ので軽く紹介をします。

利点と欠点

docker-satysfi にはいくつかのタグがあります。全部入りのタグ (latest, 無印)、SATySFi と Satyrographos のバイナリだけのタグ (slim)、日々の最新版を含むタグ (nightly) です。今回 opam-slim というタグが増えたのですが、他のタグに比べて opam-slim の利点はいくつかあります。

opam を使って satyrographos-repo にある SATySFi のパッケージをインストールできる
- opam-slim という名前の通り、opam が使えるようになっています。
- なお slim というタグもありますが、そちらは opam なしになります。
サイズが小さい
- 同じく opam が使える latest タグは圧縮後で 800 MB 以上ありますが、opam-slim は圧縮後で 100 MB 程度です。
opam update が速い
- latest に比べて opam update がかなり速いです。
- latest はデフォルトのリポジトリ (opam-repository) が入っていてその更新もあるので遅いのですが、opam-slim は opam-repository が入っていないので、その分速いです。opam-repository は基本的には OCaml 用のリポジトリで、opam-slim タグは OCaml を切り捨てて SATySFi 専用としているので、opam-repository も入れていません。

以上が利点になります。欠点は以下です。

experimental である
- experimental な理由はいろいろあるのですが、詳細は satysfi-docker の opam-slim タグ - amutake's blog をご覧いただければと思います (自分用に書いたので雑です)。
- experimental ではありますが、satyrographos-repo にある OCaml を直接の依存に持たないパッケージだけ使う分には普通に使えると思います。
opam-slim 自体のビルドが遅い
- GitHub Actions でだいたい30分くらいかかります。
opam-slim 自体のデバッグがつらい
- サイズを小さくするために Docker のレイヤーキャッシュを効かせられず、デバッグがものすごく面倒です。30分後に間違いを発見してまた直して30分…という感じになります。つらい。

使い分け

現在の docker-satysfi には、latest (無印), slim, nightly, opam-slim という4つのタグがあります。

タグたくさんあるけどじゃあどれを使えばいいんだという方は、以下のように使い分けてみてください。なんでもいいですという方は latest (無印) を使えば OK な気がします。

satysfi と satyrographos のバイナリだけあればよくて、まだリリースされていない最新版を使いたい → nightly
satysfi と satyrographos のバイナリだけあればよくて、バージョンは固定したい → slim
OCaml コンパイラはいらないが、opam を使って satyrographos-repo にある SATySFi のパッケージをインストールして使いたい。多少トラブルが起こる可能性があってもできるだけ小さいイメージがいい → opam-slim
上記いずれも合致しない → latest (無印)

毎日の最新版を使いたいけど opam も使いたいという方に対してはいまのところ方法がないです。すみません。 nightly で opam を使いたい人がいるのか不明なので後回しになっています。nightly で opam を使いたい人は issue かなにかに書いていただけると対応するかもしれません。

(WIP) arm64 サポート

M1 Mac が出て、arm64 で docker-satysfi を使いたいユーザが今後増えそうです。まだ M1 Mac 用の Docker は正式リリースされていないようですが、来年には正式リリースされるようなので、docker-satysfi も arm64 をサポートしなければいけません。

ということでこちらの PR で作業をしていて、とりあえず arm64 のイメージはビルドできるようになったのですが、ビルドがとっっっても遅く、3,4時間ほどかかってしまうのでマージを躊躇っています。

CI でいちいち3,4時間も待たされるのは辛いのと、じゃあ CI は amd64 だけにしてリリースだけ arm64 イメージをビルドするようにするとしても、latest や slim は数ヶ月に1度なのでいいのですが、nightly は毎日やるので毎日4時間かーとなってしまいます。まあビルドは勝手に行われるのでいいっちゃいいのですが、計算リソースもったいない感が…。

GitHub Actions で arm64 の環境を使えるようになればたぶんビルドも速くできるのですが、少なくともいまはありません。ロードマップに Actions: Multiple hosted runner sizes, custom networking, and custom images · Issue #95 · github/roadmap · GitHub というのは見つけたのですが GitHub AE / GitHub Cloud / GitHub Server というのがなんなのかわからなかったです (Enterprise 系のやつなんですかね)。でも all ラベル (Available to all users, including a free tier. という意味らしい) がついているのでいつかは普通の人間にも使えるようになりそうです。自分で環境を用意する (Self-hosted runner を使う) といますぐ arm64 で走らせられるらしいですがわざわざお金を出して用意するのもなあという…。

なお arm64 対応自体は、docker が公式で作っている Action (setup-buildx-action, setup-qemu-acton, build-push-action) を使えば簡単にできました。

(2020-12-20 追記) 一旦 latest, slim, opam-slim だけ arm64 サポートを入れました。0.0.5-59-g32f2525 から使えます。CI と nightly で arm64 をサポートするのは GitHub Actions に arm64 が出てからにします。

リポジトリ名を変えた

最近まで (2020/12/08 まで) は satysfi-docker というリポジトリ名だったのですが、docker-satysfi に変えました。

理由は、いろいろなリポジトリを見た感じ docker- 始まりのほうが一般的っぽいのと、satysfi-docker だと docker 関連の何かをする SATySFi パッケージのように見えるためです。

まあこれだけっちゃこれだけなので別に変えなくてもいいのですが、うーんと思いつつ半年くらいそのままでずっともやもやしていて、で変えるなら早いほうがいいので思い切って変えました。

リポジトリ名を変えた影響ですが、イメージの名前は変更していないので普通に使っている人には影響ないと思います。自分でイメージをビルドする人はもしかしたら影響があるかもしれませんがしばらくはリダイレクトされるはず？

2021年も docker-satysfi をよろしくお願いします

以上、docker-satysfi の2020年の振り返りでした。来年もよろしくお願いします。

一応、来年やりたいことも少し書いておきます。

継続してメンテを続ける
- 一番大事な気がします
arm64 サポートを入れる
- マージボタンポチでいいのですが勇気が…
- (2020-12-20 追記) マージしました
satyrographos のバージョンが上がったときも更新したい
- 別のタグにするかイメージの上書きで対応？ (トレードオフがあって迷い)
タグの整理
- タグ多すぎ感あるので整理したいです
nightly ビルドのエラーを他の人も気づけるようにしたい
- slack に投げるとか…

最後に、これは余談ですが、SATySFi には安心して後方互換性を壊していってほしいと思っています。すでに計画されているようなので改めて言う必要もないかもですが…。

Satyrographos (特に lockdown) や satyrographos-repo (特に snapshot) もありますし docker-satysfi もあるので、文書がビルドできなくなるといったことはほとんどないと思います。 docker-satysfi の最初のモチベーションも SATySFi のバージョンを固定して使いたいというものだったので、後方互換性がなくなったときに古いバージョンの SATySFi が簡単に使えるようになっていないと docker-satysfi の存在価値がなくなってしまうというか。

互換性の破壊に各種パッケージがついていくのが大変になるという懸念はありますが、いま satyrographos-repo にあるパッケージにはきちんと satysfi < 0.0.6 がついているので既存分は問題ないのと、何かあってもほとんどのパッケージが GitHub で管理されていて気軽に Issue や Pull Request を作れますし、そんなに問題にはならない気がします。そもそも SATySFi はまだバージョン 0.0.x ということもありますし、パッケージ作成者のみなさんもそれをわかって作っているはず…。

あとは SATySFi に関する記事の内容が古くなってしまうかもしれないですが、それはしょうがないというか、CHANGELOG もありますし影響は最小限に抑えられる気がします。

まあそんな感じで、こちらの準備は整っているので安心して壊してくれ、という気持ちです。