Dockerを使用したC ++アプリの構築：動的リンクの処理方法
私は、GitHubからクローンを作成したC++プロジェクトを持っています。これは、Dockerイメージ（カスタマイズされたDebian安定版）でビルドしたいと考えています。このイメージには、C++アプリをコンパイルするための通常のツールと、プロジェクトに必要なすべての依存関係が含まれています。
私の理想的なワークフローは：
cdをプロジェクトディレクトリに追加します。- dockerを呼び出して、コンテナーにアプリの構成とビルドを許可します。
- ホストシステムで（つまり、Dockerコンテナーではなく）実行可能ファイルを実行します。
残念ながら、いくつかの共有ライブラリに対して実行可能なリンクがあり、Dockerイメージで利用可能ですが、ホストにはインストールされていません。ここには2つのオプションがあります。
- 静的ビルドを強制します-トリッキーですが、仕事を完了する必要があります。
- ホストに不足している依存関係をインストールします-簡単ですが、それは全体の目的を無効にします：システムを追加のものからクリーンに保ちます。
このハードルを克服する賢い方法は何ですか？この件に関して既知のベストプラクティスはありますか？
依存関係と動的ライブラリの管理は新しい問題ではありません。シナリオでは、Dockerを使用してビルドツールチェーン（コンパイラー）をバンドルするだけなので、Dockerの使用はその問題と無関係です。
アプリケーションが実行される環境には、すべての依存関係が必要です。ただし、ホストシステムを汚染する必要があるという意味ではありません。
たとえば、依存関係を提供するDockerコンテナ内でアプリケーションを実行できる場合があります。ただし、Dockerは不変のイメージを強く好み、不適切な量の分離を課す可能性があるため、これはしばしば適切ではありません。
もちろん、他のコンテナ化技術も存在します。これは、ソフトウェアで特別に構成されたサービス/デーモンが必要な場合に適しています。しかし、コンテナ経由でデプロイしたくない場合があります。ユーザーがコンテナー管理ソフトウェアをインストールする必要があるため、イメージに過剰なストレージが必要になる場合があるため、またはコンテナーイメージを展開すると、ソフトウェアとは無関係に依存関係にセキュリティ更新プログラムを適用することが困難になるためです。
可能であれば、静的リンクの使用は非常に便利な方法です。依存関係がライブラリだけでなく他のリソース（フォント、画像、データベース、外部サービス）も含む場合、これは機能しない可能性があることに注意してください。これは、特にLGPLに依存している場合、ソフトウェアライセンスにも影響する可能性があります。
すべての依存関係を宣言し、これらを解決するためにAPTなどの外部依存関係管理システムを使用すると便利です。これは非常にユーザーフレンドリーである可能性がありますが、制御できない依存関係を意味することもあります。依存関係が提供されていない場合は、 （/opt 。
依存関係をグローバルにインストールする必要はありません。ローカルプレフィックスの下にインストールするように依存関係を構成する場合（およびLD_LIBRARY_PATH適切に）その後、プロジェクトディレクトリ内に依存関係をインストールできます。その後、それらをアプリと一緒にデプロイできます。重要なことに、これにより、依存関係の複数のバージョンを簡単に並べることができます。依存関係を（再）インストールすると、通常のビルドプロセスの一部になります。
これらの戦略は排他的ではありませんが、必要に応じて組み合わせることができます。たとえば、適切なバージョンのlibstdc ++がホストシステムにインストールされていることを要求することは問題ありませんが、他の依存関係を静的にリンクしたい場合があります。または、依存関係をローカルにインストールできるデプロイメントスクリプトがある場合、そのスクリプトはビルドコンテナーのDockerfileでも使用できます。
結局、これらのバリアントのどれが好ましいかは、ソフトウェアのインストール方法と使用方法によって異なります。すべてをスクリプト化できる限り、何でも問題はありません。