Arch Linux、bit-for-bitで再現可能なDockerイメージの提供を開始

 (antiz.fr)
4 ポイント 投稿者 GN⁺ 5 일 전 | 1件のコメント | WhatsAppで共有
  • bit-for-bitの再現可能性を備えたArch LinuxのDockerイメージが提供され、数か月前にWSLイメージで達成した同じマイルストーンがDockerにも拡張された
  • イメージは専用のreproタグで配布され、再現性を保証するためにpacmanキーが削除されているため、初期状態ではpacmanをそのまま使うことはできない
  • コンテナ内でパッケージをインストールまたは更新するには、keyringの再生成が必要であり、pacman-key --init && pacman-key --populate archlinuxで初期化できる
  • 再現性はビルド間のdigest一致とdiffociによる比較で検証され、rootFSの決定論的ビルド、タイムスタンプ正規化、ldconfig補助キャッシュの削除といった調整もあわせて適用されている
  • 再現手順はREPRO.mdで確認でき、今後はrebuilderサーバーによる自動再ビルドと検証、ビルドログおよび結果の公開へと発展する可能性がある

主要ポイント

  • Arch LinuxのDockerイメージが、bit-for-bitで再現可能な形で提供されるようになり、数か月前にWSLイメージで達成した同じマイルストーンをDocker側へ拡張した
  • このイメージは専用のreproタグで配布され、再現性を保証するにはイメージからpacmanキーを削除する必要があるため、pacmanをそのまま使用できない
    • 適切な解決策が用意されるまでは、この制約のため別タグとしてひとまず提供される
  • コンテナ内でパッケージのインストールや更新を行うには、まずpacman-key --init && pacman-key --populate archlinuxを実行してkeyringを再生成する必要がある
    • 初回実行時に対話的に進めるか、このイメージをベースにしたDockerfileのRUN文で実行できる
    • Distroboxではdistrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux"のようにpre-init hookで処理できる
  • イメージのbit-for-bit再現性は、ビルド間のdigest一致によって確認され、podman inspect --format '{{.Digest}}' <image>とdiffociによる比較で検証される
  • このDockerイメージを再現する方法はREPRO.mdで確認できる

実装と調整事項

  • Dockerイメージ用のbase rootFSを決定論的にビルドする作業が最大の課題であり、rootFSビルドシステムを共有するWSLイメージと同じプロセスを再利用した
    • 関連するWSLコミットはこちらで確認できる
  • Docker固有の調整のひとつとしてSOURCE_DATE_EPOCHを設定し、Dockerfileのorg.opencontainers.image.created LABELもこれに従うように合わせた
  • ビルド済みイメージで非決定性を引き起こすldconfig補助キャッシュファイルvar/cache/ldconfig/aux-cacheをDockerfile段階で削除した
  • docker buildまたはpodman build時に--source-date-epoch=$SOURCE_DATE_EPOCHと--rewrite-timestampオプションを使用し、タイムスタンプ正規化を適用した
    • 例として、etc/、etc/ld.so.cache、etc/os-release、sys/、var/cache/、var/cache/ldconfig/、proc/、dev/の時刻がそれぞれ異なって記録されていた問題が示されている
  • 関連変更の全体像は、archlinux-dockerリポジトリのmerge request diffでより詳しく確認できる
  • 次の段階として、DockerイメージとWSLイメージ、そして今後の再現可能なイメージを対象に、rebuilderをサーバー上に構築して定期的な自動再ビルド、再現性検証、ビルドログと結果の公開まで検討している

関連記事

1件のコメント

 
GN⁺ 5 일 전
Hacker Newsのコメント

  • こういう自信は見ていて気持ちがいい
    ほぼ1年間 WSL 2 で Arch Linux を動かしていたがとても良く、その後は約5か月間ネイティブの Arch を使っていて、やはり満足していた
    今もネイティブの Arch を使い続けていて、dotfiles はArch Docker imageでクリーンなファイルシステム上でテストしている
    完全なデスクトップ環境までセットアップするエンドツーエンドテストが必要なときは、VM で Arch を動かしている
    自分にも問題は多いが、少なくとも Arch 自体はその1つではない

    • dotfiles の変更にもstaged rolloutやロールバックがあるのか気になる
      Prometheus メトリクスや health probe までサポートするエンタープライズ級の dotfiles セットアップを探していたので、まさにそんな感じに聞こえる
    • 他の distro もサポートしてくれてありがとう、共有してくれたことにも感謝する
      今まで必要だと思ったことすらなかったのに、見た瞬間に必要になった
    • NixOS や flakes も試したことがあるのか気になる
      もし使ったことがあるなら、どんな感想だったのかも聞いてみたい

  • すべての Docker コンテナは本来こうあるべきだったと思う
    docker build の段階で apt-get update を回すのは、ほとんどアンチパターンに近い

    • ただし https://github.com/reproducible-containers/repro-sources-lis... を使うなら例外になる
      実際に使ってみたが、かなりうまく動いた
    • どちらにしても完全に楽というわけではない
      更新しなければコンテナに既知のセキュリティ問題が積み上がり、更新すれば再現可能性が壊れる
      再現性はたしかにクールでセキュリティ上の利点もあるが、コンテナが1か月を超えると目的から外れているようにも感じられるし、最大寿命は1日単位のほうが適切かもしれない
    • アンチパターンなのは分かるが、ソフトウェアをインストールする必要があるときの代替案が分からない
      タグ付きのソースコードを取ってきて、全部 gcc で自前コンパイルしろという意味なのだろうか
    • それを絶対的なルールのように見ることには同意しない
      再現可能なコンテナが良いのは確かだが、常に必要なわけではないし、コンテナ内で apt-get を実行しつつ再現性を気にしなくてよいケースも十分多い
    • distro が新バージョンの公開と同時に repo から旧バージョンを消してしまうことが多いので、さらに難しくなる
      もちろん archive から取る方法はあるにはある

  • 再現可能なイメージは普段は感情的な満足感しか与えない機能のように感じられがちだが、本当に必要になる日が来る
    こちらでも、同一であるべき2つのイメージが別々のマシンでタイムスタンプの3バイト差を出し、そのせいで見当違いの方向を bisect して午後を丸ごと無駄にしたことがある
    派手ではないが、間違いなく価値のある勝利だった

    • そもそもタイムスタンプの差がどうやって障害につながったのか気になる

  • たぶんCI/CD パイプラインに Arch を使っていることをみんなに知らせる何かを差し込めるだろう
    CrossFit をやっていることも一緒に知らせるだろうけど

    • こんな koan を思い出す
      ヴィーガンの CrossFitter で、しかも Arch ユーザーに会ったら、その人は最初に何を話してくるだろう
    • なぜ誰かがSlackware を使っていないことを誇らしげに語るのか、一度も理解できたことがない

  • Reproducible Builds についての情報はここで見られる
    https://reproducible-builds.org/
    密接に関連するBootstrappable Buildsコミュニティはこちら
    https://bootstrappable.org/

  • Arch や Alpine のような、よく設計されたmutable オペレーティングシステムが長期的には NixOS のようなシステムに勝つのか少し気になる
    インストールスクリプトは宣言的な設定言語より表現力が高く、たいていはそれほど冗長でもないからだ

    • それならむしろGuixを使えばよさそうだ
      宣言的な設定言語もあるし、同時にチューリング完全で書きやすいプログラミング言語も手に入る
    • strictly more powerful が正確にはどういう意味なのか気になる

  • 記事は読んだし、かなりクールに見えるのだが、Dockerfile と docker image を混同して話しているように感じる
    Dockerfile の代わりに nix のようなものでイメージの tar ファイルを直接ビルドしていたらもっと簡単だったかもしれないし、もちろんややマニアックではあるが、そのほうがよりクリーンだったはずだ

  • 細かい指摘だが、OCI Imageという用語を使うほうがより正確だと思う
    podman でもまったく問題なく動く

    • このコメント欄では自分はかなり初心者で文脈を全部追えてはいないが、この指摘はかなり目が開かれるポイントだった

  • これを実際に可能にした人たちには本当に大きな敬意を払いたい
    こういう見出し1つを生み出すためにかかる時間と労力は、想像以上だ

  • まったく別の話だが、そのページにはアニメーションが1つあって、1秒のあいだページ上のほとんどすべての要素が下に約20ピクセルずつ動く
    目の前でレイアウトが揺れるので、当然CLSを壊滅させると思ったが、実際の CLS は 0 だった
    だとすると、CLS は誤解を招く指標なのではないかと思えてくる

    • それは意図的なアニメーションによって起きていることだ
      CLS は初期レンダリング時点の変化を扱うため、レイアウト移動のように見えても CLS として記録される種類のものではない
    • それはレイアウトシフトではない
      CSS transition による動きなので予測可能な変化であり、そのため layout shift には計算されない