アイデアは、ハードウェアに拘束されないいくつかの項目を構成し、それをRaspberry Piや通常のx64サーバーなどの物理デバイスに展開するDockerイメージなどを持つことです。
私はこれが不可能だと仮定しています。これ単にdockerにターゲットと一致しないいくつかの仮想化ハードウェアがあるからですか？新しくインストールされたLinuxのコンテナでdocker-imageを実行したくありません。すべてをローカルで実行する必要があります。
誰かがこれを実装する方法、どのような正しい方向を教えてもらえますか？開発および運用ソフトウェア最初からそんな考えをしなければならなかったのに。一部を作成してinstall-scriptsコピーすることを除いてconfigs（基本的には本当です）。
私が得たいのは、できるだけ仮想マシンで設定し、（ほぼ）すべてのハードウェアにインストールして起動するrestore-image開始点を持つことです。image
それとも、Linuxがハードウェアの変更を処理する方法を誤解していますか？ （GPU交換で悪い経験をしました）
（周りを見ればそんなようだ。ドッカー最高で最大賢いこれに対する解決策はを使用することですdocker export。しかし、より簡単な解決策があるかどうか疑問に思います。怠惰ではなく、不自然な誤りで手動でスクリプトを作成するのではなく、私が指定した特定のアプリケーション/構成をエクスポートできるプログラムかもしれません。 )
答え1
インストールされているシステム（アプリケーション、構成などを含む）のイメージを別のマシン（仮想マシンではなく実際のベアメタルハードウェア）に「複製」する方法を探しているとします。
したがって、仮想マシンやDockerコンテナではなく、物理ハードウェアをソースとして起動する必要があります。そのコンピュータに必要なものはすべてインストールしますが、デバイスごとにサードパーティ製のドライバをインストールしないでください。カーネルが自動的に提供するドライバを引き続き使用できる場合は、イメージが他のシステムで実行される可能性が高くなります。もちろん同じアーキテクチャでなければならないので、x86用のイメージをビルドするにはx86マシンが必要で、Pi用のイメージをビルドするにはPiが必要です。
その後利用できますクローン属ディスクイメージを作成し、別のコンピュータにイメージを復元します。しかし、ClonezillaはPiではなくx86システムでのみ動作します。
もう1つの方法は、ddディスク全体（rawデバイス）を外部ドライブ/ USBスティックのファイルにコピーし、イメージファイルを別のコンピュータに復元することです（rawディスクデバイスに書き込む）。同じイメージファイルが必要です。 2台のコンピュータのディスクサイズ - そうでなければ、複製されたシステムがまったく起動しないことを望まない。もちろん、マシン（ソースまたはターゲット）がライブメディアから起動した後にこれを実行する必要がありますが、オペレーティングシステムはディスク上でアクティブになりません（ターゲットマシンがまったく存在しない場合、唯一の方法はブートはライブメディアから行われます）。
大量の作業を必要とするほとんどの「ハードコア」方法（ただし、この方法を使用してより大きなディスクを持つシステムにシステムを複製できます）は、ファイルシステム全体をtarディスクにインポートすることです（ライブメディアから起動した後でも同様です）。そして、ターゲットマシンの適切なパーティションに解凍します（もちろん、手動でパーティションを作成した後）。その後、/etc/fstabファイルを調整し（パーティションUUIDは通常異なるため）、ターゲットシステムにブートローダをインストールする必要があります。私はサーバーをより強力なハードウェアに交換するときに作業システムを「複製」するためにこの方法を複数回使用しました。
警告：コンピュータに静的に設定されたIPアドレスがある場合、「複製」ターゲットコンピュータも同じアドレスを持ちます。これを手動で変更する必要があります。一部のシステムでは、/etc/udev/rules.dudevが前のシステムのデバイスを「忘れて」、次回の起動時に再検出するようにするには、一部のファイル（名前に「永続」を含むファイル）を削除する必要があります。そうしないと、問題が発生する可能性があります。たとえば、ネットワークインターフェイスが存在しません（例：これ例）