Docker コンテナーでのソフトウェアの検出

9.2.5 から使用可能です。 Docker と Podman は、ソフトウェア・コンテナー内のアプリケーション・デプロイメントを自動化できるプラットフォームです。BigFix InventoryBigFix Inventory は、Docker コンテナー内にインストールされているソフトウェアをディスカバーします。また、ディスカバーされた BigFix 製品のライセンス・メトリック使用状況の測定も行います。

要件

BigFix Inventory は、以下の条件で、Docker および Podman コンテナー内にインストールされているソフトウェアをディスカバーします。
  • ホスト・コンピューターにデプロイされている Docker または Podman エンジンが 1 つのみである。
  • コンテナーが実行中である。
  • 結果のスキャンおよびアップロードがホスト・コンピューターで有効になっている。
  • コンテナー内にインストールされているソフトウェアが、ソフトウェア ID タグを配信している。
  • コンテナーでソフトウェアが適切にディスカバーされるようにするために、コンテナーのコンテンツはそのライフサイクル全体を通して変更できません。
  • BigFix クライアントまたは接続切断スキャナーが、ホスト・コンピューターにインストールされている必要があります。
  • Docker コンテナーが以下のいずれかのプラットフォームに適用されている。
    • Red Hat Enterprise Linux 7 for x86
    • Red Hat Enterprise Linux 7 for BigFix (64 ビット)
    • SUSE Linux 12 for x86
    • 9.2.10 Red Hat OpenShift コンテナー・アプリケーション・プラットフォーム
  • Podman コンテナーが以下のいずれかのプラットフォームにデプロイされている。
    • Red Hat Enterprise Linux 8 for x86
    • Red Hat Enterprise Linux 9 for x86
  • Podman コンテナーにインストールされているソフトウェアのディスカバリーは、podman コマンド引数と docker コマンド引数の構文との互換性に依存します。
  • docker コマンドは、次のいずれかの方法で podman コマンドにリダイレクトする必要があります。
    • podman-docker Red Hat パッケージをインストールします。
    • コンピューター設定を使用して、Podman エンジンのインストール・パスを構成します。詳しくは、以下を参照してください。
注: docker コマンドを Podman コマンドの別名として使用すると、動作しない場合があります。

コンテナーでのソフトウェア・ディスカバリーの有効化

コンテナーにインストールされているソフトウェアのディスカバリーは、デフォルトで有効になっています。一部の Docker または Podman 環境では、非デフォルト・インストール・パスを指定したり、ディレクトリーをスキャンから除外したりするための追加手順を実行する必要が生じることがあります。詳しくは、「Docker コンテナーでのスキャンの構成」を参照してください。コンテナー内のソフトウェア・ディスカバリーを無効にする方法について詳しくは、「Docker コンテナーでのスキャンの無効化」を参照してください。

接続切断スキャナー

コンテナーにインストールされているソフトウェア・ディスカバリーを有効にするには、DOCKER_SCAN_ENABLED パラメーター値を true に設定します。詳しくは、こちらを参照してください: 接続切断スキャナーの構成パラメーター (切断シナリオ)。

ソフトウェアの表示

Docker コンテナー内にインストールされているソフトウェアは、「Software Installations」レポートに表示できます。これは、ホスト・コンピューターの下に表示されます。ソフトウェアが検出された理由を確認するには、「詳細」をクリックします。


Docker コンテナーにインストールされているソフトウェアの詳細
詳細には、特に、以下に関する情報が含まれています。
  • 1 ソフトウェアが検出されたコンテナー。
  • 2 検出の原因となったソフトウェア ID タグ。

ライセンス・メトリック使用状況の測定

Docker コンテナーにインストールされているソフトウェアのディスカバリーとは別に、BigFix Inventory はディスカバーされた BigFix 製品のライセンス・メトリック使用状況も報告します。Docker または Podman が物理ホスト上にデプロイされている場合は、そのホストのレベルでライセンス・メトリック使用状況が計算されます。仮想マシン上にデプロイされている場合は、その仮想マシンのレベルで使用状況が計算されます。詳しくは、以下の各シナリオを参照してください。
重要: Docker または Podman は、サブキャパシティーが適格な仮想化ではありませんが、サブキャパシティーが適格な仮想化と組み合わせて使用できます。以下の各シナリオでは、PVU と RVU MAPC の使用状況の計算方法を説明します。レポートされるその他のメトリックの使用状況についても、同じような方法で計算されます。

シナリオ 1: 物理サーバー上にデプロイされた Docker または Podman エンジン

Docker または Podman エンジンが物理サーバー上に直接デプロイされている場合、PVU および RVU MAPC の使用状況は、ホスト・コンピューターのレベルで測定されます。

例: 4 つの Intel Xeon 3400 プロセッサー (それぞれ 6 コア) を搭載している物理サーバーに 3 つのコンテナーがデプロイされているものとします。合計で 24 コアになります。IBM MQ が、3 つのコンテナーのうち 2 つのコンテナーにインストールされているものとします。BigFix Inventory は、ホスト・コンピューターのレベルで PVU と RVU MAPC の使用状況をカウントします。


物理サーバー上にデプロイされた Docker

この場合、IBM MQ は、24 コアにアクセスできます。PVU テーブルによると、サーバーに 4 つのソケットがある場合、このプロセッサー・モデルには、1 コアにつき 100 PVU が割り当てられます。したがって、IBM MQ の PVU 使用状況は 2400 PVU になります。IBM MQ の別のインスタンスが 3 つ目のコンテナーにインストールされていたとしても、この値は同じになります。

シナリオ 2: 仮想マシンにデプロイされた Docker または Podman エンジン

Docker または Podman エンジンが仮想マシンにデプロイされている場合、PVU および RVU MAPC 使用状況は、仮想マシンで使用可能な PVU の最大数としてカウントされます。

例: 4 つの Intel Xeon 3400 プロセッサー (それぞれ 6 コア) を搭載している物理サーバーに 2 つの仮想マシンがインストールされているものとします。合計で 24 コアになります。各仮想マシンには 8 コアが割り当てられ、2 つのコンテナーが適用されています。IBM MQ が以下の場所にインストールされています。
  • 最初の仮想マシン上の 1 つのコンテナー
  • 2 つ目の仮想マシン上の 2 つのコンテナー

仮想マシンにデプロイされた Docker

この場合、各仮想マシンにインストールされている IBM MQ は 8 コアにアクセスできます。合計で、物理コンピューターで使用可能な 24 コアのうち 16 コアにアクセスできます。PVU テーブルによると、サーバーに 4 つのソケットがある場合、このプロセッサー・モデルには、1 コアにつき 100 PVU が割り当てられます。したがって、IBM MQ の PVU 使用状況は 1600 PVU になります。Docker または Podman エンジンが物理サーバー上に直接デプロイされていた場合、IBM MQ は 24 コアにアクセスできるため、PVU 使用状況は 2400 PVU になります。

ログ

Docker または Podman コンテナーにインストールされているソフトウェアのディスカバリーでの問題をトラブルシューティングするには、docker_scan.log ログを参照してください。このログは、BigFix クライアント・インストール・ディレクトリー内に保管されています。デフォルトでは、これは以下のとおりです。
  • Linux var/opt/BesClient/LMT/CIT/docker_scan.log
  • Windows C:\Program Files (x86)\BigFix Enterprise\BESClient\LMT\CIT\docker_scan.log