再現可能ビルドの簡単な紹介

クズども · 2025年4月30日 10:09:27に投稿

繰り返しビルドとは何でしょうか?

決定論的ビルドと再現可能ビルドは少し異なりますが、この記事からは同じものと理解できます。

再現可能ビルドは同じ入力とビルド環境で複数回実行しても、まったく同じ結果が得られます。この技術はソフトウェア開発、配布、セキュリティ検証において重要です。

ビルドは、いつどこで実行されてもまったく同じ出力を出す場合に再現可能と言えます。どのコンピュータを使っていても、どの時間帯で、どの外部サービスにアクセスしても、再現可能なビルドは同じバイト単位の出力を生み出します。これは開発(再現可能なビルドは複数の開発者デバイス間で簡単に共有できるため)にも、プロダクションでも(再現可能なビルドの結果が改ざんされていないか簡単に確認できるため、自分のマシンでビルドを再実行して結果が一貫しているか確認すればよい)の両方に優れています。とても役に立ちます。

繰り返し構築の三本柱

柱1:繰り返しビルド

ビルドの繰り返し性とは、ビルドマシン自体に何が起こるかを指します。もし私たちのビルド入力が利用可能で、周囲の世界に何も変化がなければ、同じ出力は繰り返されるのでしょうか?

決定論的設置計画

繰り返し可能なビルドにおける最初で最も単純かつ明白な要件は、決定論的依存関係のインストール計画です。

ほとんどの言語では、ロックされたファイルをチェックするだけで済む。現代のビルドツールでは、プロジェクトが直接的な依存要件を制約として表現し、それらの制約を解決してインストール計画(依存関係名やインストールすべきバージョンペアのリスト)を生成することが可能になることが多いです。これらのツールの多くは、シリアル化されたインストール計画用のロックファイルも生成します。開発者はこれらのロックファイルをバージョン管理に提出し、今後のビルドでも同じ依存関係名やバージョンを使用できるようにします。

依存関係ビルド自体でも決定論的(バージョン選択だけでなく)が必要であり、決定性インストールプランではそれを実現できません!

決定論的構成

何を作ればいいか分かったら、私たちのビルド自体(自分のコードや依存関係のビルドも含む)は実際に決定論的でなければなりません。

コンパイルステップがないプロジェクトでは、これは実際には問題にならないかもしれません! 例えば、すべての依存関係を持つNodeプロジェクトは純粋なJavaScriptであり、効果的な決定性を達成するために追加の作業は不要です。

コンパイルや翻訳(ソース間コンパイル)ステップを含むプロジェクトでは、決定性を確保することが再現可能なビルド構築の中で最も難しい部分です。コンパイルプロセスは、以下のようないくつかの方法で暗黙のうちに非決定性を導入することができます。

チューリングコンプリートのプログラムビルドスクリプトは、コンパイルされた出力を自由に変更できます。
実行ファイルシステムの検索やネットワーク呼び出しに依存するインストール後スクリプト。
異なるヘッダーを持つ異なるシステム上のバインディングが異なる出力を生み出すシステムインストールパッケージへのCバインディングです。
バージョン管理の外で読み取れるファイルを作成する手順。
システム時間を使ってタイムスタンプを生成するステップを構築しましょう。
ネットワークダウンロードインストール計画に明示されていない依存関係を構築する手順(例:Cバウンドのキャッシュ済みバイナリビルドのNPM依存関係をGitHubからダウンロードするなど)。
現在設定されている環境変数に基づいて動作を変更してください。ただし、環境変数の設定でビルドを提出しないでください。

これらの動作すべてが正しく設定されても必ずしも不確実性をもたらすわけではありませんが、ビルドプロセスを適切に設定することは複雑で困難な場合があります。例えば、Chromiumビルドの不確実性についてのこのブログ記事を読むことができます。これらの問題の多くは、地域の建築環境をコントロールすることで緩和でき、その点については次のセクションで説明します。

柱2:不変の環境

繰り返しビルドがあっても、ビルド入力が変わらないようにする必要があります。多くの場合、私たちは周囲の不変のスナップショットの上に構築したいと考えています。

不変の局所環境

前述の通り、ビルドの不確実性の一般的な原因の一つは、ビルドツールに反映されない「依存関係」に依存することです。 Cバウンドのシステムライブラリが最も一般的な例ですが、環境変数の設定やバージョン管理の範囲外のファイルなど、他のローカル環境要因もビルドに影響を与えることがあります。

この問題を緩和する簡単な方法は、既知の不変コンテナでビルドを実行することです。例えば、Dockerのようなコンテナランタイムは、すべての人が同じシステム依存関係、同じ環境変数、同じファイルシステム上で動作することを保証します。さらに、コンテナの内容が既知のビルドコンテナと一致しているかを簡単に検証でき、必要に応じてコンテナを完全にイメージから取り外して再作成することも容易です。

既知のコンテナや既知のコンテナ画像については、私たちは非常に明確にしています。 Dockerファイルを提出するだけでは不十分です! なぜでしょうか。なぜなら、Dockerファイル自体がDockerイメージの完全再現可能なビルドプロセスを記述していないからです。なぜなら、Dockerは不変のグローバル環境で動作しないからです。

不変の地球環境

ビルドシステムは、バージョン解決や依存関係のダウンロードなどのタスクを遂行するために外部サービスとやり取りすることが多いです。しかし、外部サービスは頻繁に変わります。

今日apt install nodejsを実行すれば昨年とは異なる結果が得られ、おそらく来年も異なる結果になるでしょう。だからこそ、Dockerfile自体は再現可能なビルドを記述できないのです。同じDockerfileを異なるタイミングで動かすと、異なるビルド出力が生まれるのです!

ここでの簡単な対策は、可能な限りビルドを設定し、正確なバージョン(理想的には正確なコンテンツハッシュも含む)を指定し、今後のビルドで現在のビルドと同じバージョンを使うようにすることです。しかし、外部サービスが予期せず挙動を変えることもあります。真に悲観的で再現可能なビルドは、できるだけ多くのネットワークリソースを使い込んだ内部イメージを実行します。

柱3:資源の利用可能性

仮に私たちのビルドが再現可能で、足元の世界が変わらなかったとしましょう。あとはビルドの入力にアクセスするだけです。簡単そうに思えますよね? まぁ。。。。。。

レジストリは時々失敗します

ほとんどのNode開発者は、NPMパッケージのキャッシュやミラーリングなしのビルドパイプラインが妨害されるという、少なくとも1回のNPM障害を経験しています。多くのNode開発者も左パッドやフェイカーの削除を経験しており、これらはNPMエコシステムに深刻なダメージを与え、事実上障害状態に等しい状況です。

このようなビルドブレイクを確実に軽減する唯一の方法は、自分でパッケージレジストリミラーを実行することです。外部サービスが利用できない場合は、画像はオンラインのままにできます。公式レジストリが古いパッケージを削除しても、ミラーはサービスを継続できます。同じ原則は他のリモートサービスにも当てはまります。自分でイメージを動かさない限り、ビルドパイプラインの利用可能性はサービスの利用可能性としか比較できません。

サービスイメージを実行する選択は常に繊細なトレードオフです。一方で、NPMのようなレジストリーには、これらのシステムをオンラインに保つ専門知識を持つ専任のエンジニアリングおよび運用チームがあります。一方で、すべてのNPMイメージを実行するよりも、小さな依存関係の小さなイメージを実行する方がはるかに簡単です。各サービスの履歴や外部サービスの信頼性、チームのビルドの可用性や人員のニーズを考慮し、各サービスの具体的な内容に基づいてミラーリングの判断を行うべきです。

サプライヤーは最大限の利用可能性を確保します

プロジェクトの依存関係を最大限に利用可能にする簡単な方法は、ベンダーに追加することです。ほとんどのパッケージマネージャーは何らかの「ベンダーリング」機能をサポートしており、これは外部サービスからのダウンロードに依存する代わりに、依存関係のソースコードをバージョン管理に保存し、ソースコードと共存させることを意味します。例えばNodeでは、これはソース管理にnode_modulesをコミットするような形かもしれません。

このソリューションは完璧ではありません(ベンダーやプロジェクトの構成によってはバージョン管理に大きな負担がかかることもあります)が、最大限の可用性を確保するために最もシンプルで簡単な解決策であることが多いです。

参考：

ハイパーリンクのログインが見えます。
ハイパーリンクのログインが見えます。

クズども · 2025年4月30日 10:10:23に投稿

C#でNuGetパッケージを構築する際の再現可能なビルドの使用について:

ハイパーリンクのログインが見えます。
ハイパーリンクのログインが見えます。

再現可能ビルドの簡単な紹介

関連記事

閲覧したセクション