一般的なLinuxディストリビューションを新しくインストールするとします。構築してホストするWebアプリケーションのソースコードを含むtarballをダウンロードしました。このプロジェクトは少し近代的で、Node.js/npmとRuby/gem用のシステムパッケージをインストールする必要がありました。すべての前提条件が満たされたら、Webサーバーが提供できるファイルを生成するアプリケーションを構築できるように、いくつかの他のタスクを実行するnpm install -g必要があります。gem install.js.css
これでアプリをビルドしたので、これを達成するためにインストールしなければならなかったすべてを削除したいと思います。ソースソースコード、JS / CSSコンパイラ、または今コンパイルする依存関係ビルドアーティファクトは必要ありません。場合によっては、Node.js/Rubyをインストールする必要さえありません。すぐにコードを再コンパイルする予定はありません。その日が来たら、前提条件だけを再インストールします。
私は、アプリケーションを構築するためにシステムに適用する必要があるすべての変更を「解体」する簡単な方法を探しています。つまり、システムをタールボールをダウンロードする前の状態に戻しますが、最終的なビルド結果は維持します。 （共有ライブラリの問題にもかかわらず、C / C ++コンパイルのための同様のワークフローを可能にするのに十分なプロセスが一般的であれば良かったでしょう。）
私はchrootを調べて、それが声明に合うかもしれませんが、過剰に見えます。また、仮想マシンからビルドし、ビルドアーティファクトを抽出し、単にマシンを削除することも考慮しましたが、これも非効率的だと考えられます。このユースケースに適した一種のファイルシステム「スナップショット」機能はありますか？それとも、さまざまなパッケージマネージャに専用の使い捨て一時ディレクトリで特別に作業するように指示する方法はありますか？
答え1
いくつかのオプションがあります。
従来のアプローチは、ソースコードのすべてのアイテムをホームディレクトリに手動でインストールし、完了したらコンテンツを削除することです。これの利点は、すべてのディストリビューションで実行され、いくつかの依存関係がインストールされている場合にシステムライブラリを利用できることです。しかし、欠点は、何かを正しく構築することがしばしば難しいということです。
ほとんどのパッケージマネージャは通常、コマンドラインオプションまたは環境変数を介して設定された特定のパスにインストールできます。私はEmergency、pacman、DNFがこれをサポートすると確信しており、Zypperもそれをサポートすると確信しています。 dpkgベースのシステムを扱うときにdebootstrapプログラムを使用してchrootを生成することもできます（このプログラムを使用して初期化してからchrootし、そこにインストールされているパッケージマネージャを使用して必要なパッケージを追加できます）。
ディストリビューションオプションもいくつかあります。
- BTRFS<にインストールすると、SUSEはパッケージマネージャトランザクションの前後にシステムのスナップショットを撮ることができます。私はSUSEを頻繁に使用しないので、正確に説明することはできませんが、少し努力すればあなたが望むことを達成することができます。
- NixOSで使用されるNixパッケージマネージャは、デフォルトでカスタマイズ可能なインストール済みパッケージセットであるユーザー固有の「プロファイル」を受け入れます。これは、接続されたユーザーが自由に作成、変更、切り替え、および削除することができ（使用するためにroot権限を必要としない）、これを行うための別のクイックオプションを提供します。
答え2
単純なchroot、コンテナ、仮想マシンは「過剰」ではありません。これらの作業はその用途の1つです。実際にシステムに戻すことができない変更が発生するのを防ぐために必要です。最近、コンテナと仮想マシンは使いやすく、使用しない理由はありません。つまり、システムの残りの部分から完全に隔離されたビルド環境を提供します。
実際、ファイルシステムのスナップショットを使用してメインシステムのアイテムをアップグレード/インストールし、ソフトウェアを構築してから古いスナップショットに戻すことは重複します。また、あまりにも粗雑であり、作業に潜在的に危険である可能性があります。メールをダウンロードしてpop / imapサーバーから削除した場合、またはこのプログラムの構築とまったく関係のないファイルを作成/編集した場合） -みんな以前のスナップショットに戻すと、その内容が復元されます。 Fileystemスナップショットは良いアイデアで便利なツールですが、異なるオペレーティング環境を動的に切り替えるのではなく、良いバックアップおよび/または簡単なリカバリ戦略の一部として使用することをお勧めします。
ほとんどのコンテナおよび仮想マシン管理システム（たとえばdocker、、、、、lxcなどvirsh）virt-managerは、新しい状態で各実行を簡単に再開できるため、毎回まったく同じ元のビルド環境で起動できます。 VMディスクイメージは通常、スナップショットを作成して複製できる形式で保存されます（例：qcow2ZFS zvol。元のディスクイメージファイルもコピーしてオプションで圧縮できます）。 chrootで同じことを行うことはできますが、chrootを削除して直接再作成する必要があります（例：chrootの.tar.gzアーカイブを使用）。
かなり基本的な設定とビルドプロセスは、chroot、コンテナ、または仮想マシンを起動します。これは、各ビルドジョブの要件に応じて構成する一般的なビルド環境でも、1つの特定のプログラムのみをビルドするように事前構成された環境でもかまいません。次に、それを使用してソフトウェアを構築し、最後に実行される場所にコピーします（および/または配布用のパッケージを構築します。タスクが多すぎると思われる場合は試してください。）インストールの確認）。
docker特に、完全なビルドコンテナを自動的に作成したり、共通コンテナに基づいて特定のビルドコンテナをカスタマイズしたりするための優れたツールがいくつかあります。
また、仮想マシンまたはコンテナを起動し、ここにタスクを送信してコンパイルし、再び解体するプロセス全体を自動化することもできます。このアイデアを実装した既存の実装がたくさんあります。ロボットを作る（人気のあるGPL Pythonプログラムがあります。buildbotしかし、その名前、アイデア、およびタスクの実装は、2003年に最初に書かれたずっと前から存在していました。ボットの構築が重要な部分です継続的統合（CI）。しかし、CIと言えばオープンソースGitLab自動化されたビルド、テスト、デプロイなどのさまざまなCI関連タスクと組み合わせて、独自のGithubなどのソースコードリポジトリや問題トラッカーを実行するのに最適なツールです。
要約するとcreate a completely discardable build environmentそして、あなたの質問に答えてください。好きなことをする方法はとてもたくさんあります。それらの多くは、さまざまなLinuxディストリビューション用に事前にパッケージ化されています（ただし、それがどのように機能し、構成されているかを理解する必要があります）。難しい部分は、何を意味するのか、必要な機能が何であるか、自動化する機能の程度を正確に把握することです。
もちろん、もう一つの重要な要素は、ここにどれだけの時間/努力を投資する価値があるかです。たとえば、ホームソフトウェアラボ、小規模企業、またはスタートアップの場合、このツールは仕事をするのに役立ちますが、雇用者はそうではありません。必要だと思いますか？それとも、開発チーム全体が必要だと思いますか？それとも会社全体のための大規模なプロジェクトですか？
PS：私が提供したすべてのリンクが特定のソフトウェアプロジェクトや会社のページに直接リンクされていないこと、そしてWikipediaへのリンクである理由が気になる場合は、この回答が特定のソフトウェアの推奨事項ではなく概念的な概要に近いためです。ウィキペディアページには直接リンクがあり、さらに重要なのは、同様のソフトウェア、ソフトウェア比較ページ、および相互に関連する多くの概念へのリンクがあることです。これは、学習しやすい答えが1つしかない簡単なトピックではありません。より分かるほど、特定の要件に合った正しい決定を下すことが容易になります。