「真に再現可能なビルド」とは正確には何ですか?


9

正確には何ですか?継続的デリバリーの分野で、なぜ重要なのですか?

コンテキスト:(私はredditを推測している)のコメントの1つで、Truly Reproducibleビルドはまだ研究中の技術であり、作成するのが非常に難しいと見ました。

それで、なぜそれらを作成することがそれほど難しいのか知りたいのですか?


おそらく、それらが参照されているコンテキストへのポインタがありますか?
Dan Cornilescu 2017年

@DanCornilescuもちろん。詳細を追加しました:)
Dawny33

@ Pierre.Vriensプルオフによって、私は意味しましたmake possible:) qnも編集します!
Dawny33

1
編集のためのMerciですが、それを見ると、「作成」を意味するだけだと思います...
Pierre.Vriens

1
私の答えを改善する(または別の答えを追加する)ために、90年代初頭の自分の経験から、別の例を挙げます。 、5インチフロッピー(読み取りエラーの場合は2コピー)、(巨大な)会社でソフトウェアを配布するために...そして、私は彼らの環境(メインフレーム上)で実行可能ファイルを再構築する必要がありました。
。DevOps

回答:


8

正確には何ですか?

これがreproducible-builds.orgからの引用です:

再現可能なビルドとは、人間が読み取れるソースコードからコンピューターが使用するバイナリコードへの検証可能なパスを作成する一連のソフトウェア開発手法です。

なぜ重要なのですか?

IMOの重要性を説明する最も簡単な方法は、それらをバックアップ手順のバリエーションと見なすことです。

例として:

  • 一部のソフトウェアベンダーからライセンス供与された一部のソフトウェアパッケージを使用(依存)するビジネスを想定します。一方、ビジネスは実行可能ファイルのみを取得し、実行可能ファイルの作成に使用されたソースなどは取得しません。

  • すべてがうまくいきますが、ある時点でソフトウェアベンダーに何らかの問題が発生します。たとえば、倒産などです。

  • これはビジネスにリスクをもたらす可能性があります(長期的には)。つまり、実行可能ファイル(によって使用された)に使用された(当時)ソフトウェアベンダーからの何かに関連して、ビジネスが必要なすべてのソース、ドキュメント、ビルド手順などに(合法的な)アクセスを取得するための手順/合意がない場合ビジネスが作成されました(そしてビジネスに出荷されました)。

  • それが「ソフトウェアエスクロー」が救いに来たときです。そのような合意がある場合、サードパーティを介して、ビジネスが「使用されたもの」にアクセスして複製することがまだ可能であると考えるでしょう。実行可能ファイル。それ以降、ビジネスはそのソフトウェアを使い続ける可能性があり、適切な場合は自分で保守を開始できます(自分のビジネスを実行する場合のみ)。

  • ただし、前の箇条書きの「使用されたもの」は、この作業を行うための最も難しい部分です。サードパーティが適切な検証を事前に実行する必要があります。そして、私を信じてください。リンクの日付とは別に、それがソフトウェアベンダーがソフトウェアエージェントに提供するものと完全に一致することを証明できる実行可能ファイルを再作成するには、しばらく時間がかかります。

そして、なぜそれらを作成するのがそれほど難しいのですか?

上記のサンプルでもまだ十分に明確でない場合は、あなたが私のソフトウェアエスクローエージェントであると想像してください。私の顧客からライセンスされたソフトウェアのコピーを再作成するための入力として必要なものを教えてください。それを得る?私のコンパイラのバージョン、おそらく私のOS、コンパイル/リンクオプション、再利用可能なコンポーネント(インクルード)のバージョン、ライブラリなどについて確認することを忘れていませんか?


4

真に再現可能なビルドを作成する試みの実用的な例を提供するには、以下を検討してください-

gitリポジトリから始まるビルドパイプラインで、ユーザーは履歴を書き換えたり、マージされていないブランチを削除したりすることはできません。

ソースコードをチェックアウトした後の最初の「ビルド」ステップは、すべてのビルド時の依存関係を含むコンテナを起動することです。

実行中のビルド時コンテナの出力は、コンパイルされたバイナリを含むコンテナです。

ビルドの再現性にとってより重要なのは、次のタグが最終的なコンテナーに追加されることです。

  • 元のリポジトリのソースコードの正確なハッシュと、アーティファクトリポジトリにアップロードされるコードのgitリポジトリとtarボールスナップショットの両方のURL。
  • ビルドの実行に使用されたビルドコンテナーの正確なバージョン。
  • バイナリがロードされた元のベースイメージの正確なバージョン。
  • バイナリの作成に使用されるすべてのビルド時変数の値。
  • 3つのコンテナすべてがビルドされたdockerのバージョンと、ビルド時に実行されたバージョンのdocker。

このメタデータをすべて追加することで、将来の任意の時点でビルド依存関係の正確なセットを(ビルドコンテナー経由で)引き出し、バイナリーを正確に既知の一連のステップ(ビルドコンテナーに記載されている)でコンパイルできるようにします。 )そして、これをすべてのランタイム依存関係を持つ別の既知のベースイメージにパッケージ化し(ベースイメージタグを使用)、これはすべて、コンテナのタグに基づくソースコードの正確な正しいバージョンに基づくことができます。

理論的には、これにより、ビルドバージョンを正確に再現できるようになります。

これの重要性は、本番環境で何が実行されているかを確認できることであり、すべてが大幅にバージョンが進んでも、戻って、元々使用されていたコード、ベースイメージ、ビルドコンテナーのバージョンを引き出して、たとえば、 、以前とまったく同じように再構築する前に、そのバージョンにホットフィックスを適用します。これにより、ホットフィックスである唯一のデルタを持つアーティファクトとまったく同じであることを確認して再デプロイできます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.