Linux でのフォワーダーのインストールと構成

このドキュメントでは、Linux でフォワーダーをインストールして構成する方法について説明します。フォワーダーは、さまざまな Linux ディストリビューション（Debian、Ubuntu、Red Hat、Suse など）にインストールできます。Google Cloud は、Docker コンテナを使用してソフトウェアを提供します。Docker コンテナは、Linux を実行している物理マシンまたは仮想マシンで実行して、管理できます。

構成ファイルをカスタマイズする

Google Cloud は、ユーザーからデプロイ前に送信された情報に基づいて、フォワーダーのソフトウェアと構成ファイルを提供します。Google Cloud は、ネットワーク上のフォワーダー インスタンスに合わせて構成ファイルを調整します。構成を変更する必要がある場合は、Chronicle のサポートにお問い合わせください。

システム要件

一般的な最適化案は次のとおりです。システムに固有の最適化案については、Chronicle サポートにお問い合わせください。

  • RAM - 収集された各データ型ごとに 1.5 GB。たとえば、エンドポイントの検出とレスポンス（EDR）、DNS、DHCP はすべて別のデータ型です。3 つの型すべてのデータを収集するには、4.5 GB の RAM が必要になります。

  • CPU - 2 個の CPU は、10,000 EPS（1 秒あたりイベント数）（すべてのデータ型の合計）未満を処理するには十分です。10,000 EPS を超えるイベントを転送する予定の場合は、4～6 個の CPU をプロビジョニングします。

  • ディスク - Chronicle フォワーダーで処理するデータの量に関係なく、100 MB のディスク容量で十分です。バックログにあるメッセージをメモリではなくディスクにバッファリングする必要がある場合は、ディスク バッファリングもご覧ください。Chronicle フォワーダーは、デフォルトでメモリにバッファリングします。

ファイアウォール構成を確認する

Chronicle フォワーダー コンテナとインターネットの間にファイアウォールまたは認証済みプロキシがある場合は、次のホストへのアクセスを開くルールが必要です。

接続タイプ 宛先 ポート
TCP malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443

Docker のインストール

Docker はさまざまなホスト オペレーティング システムにインストールできます。Docker の実際のインストールは、ホスト環境に依存します。Google Cloud には、一般的な Linux ディストリビューションのいくつかに Docker をインストールする際に有用な制限付きのドキュメントが用意されています。ただし、Docker はオープンソースであり、十分なドキュメントがすでに用意されています。

システムに Docker をインストールした後は、使用している Linux ディストリビューションにかかわらず、残りの Chronicle フォワーダーのインストール プロセスは同じです。

次のコマンドを実行して、システムに Docker がインストールされていることを確認します（権限昇格）。

# docker ps

次のレスポンスは、Docker が正しくインストールされていることを示しています。

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

次のコマンドを使用して、Docker のインストールに関する追加情報を収集できます。

# docker info

Docker に問題がある場合は、Chronicle のサポートがデバッグの実施を支援するために、このコマンドの出力をリクエストする可能性があります。

フォワーダーをインストールする

このセクションでは、Docker コンテナを使用して Linux システムに Chronicle フォワーダーをインストールする方法について説明します。

ステップ 1. フォワーダー構成ファイルのダウンロード、転送、インストール

Google Cloud には、オペレーティング システム（Linux または Windows）に固有のフォワーダー構成ファイルが用意されています。Chronicle の担当者から提供されたリンクから、ノートパソコンのローカル ディレクトリ（chronicle など）にファイルをダウンロードします。以下の手順を完了したら、ノートパソコンからユーザーのホーム ディレクトリ内にあるフォワーダー ~/config ディレクトリに構成ファイルを転送します。

  1. ターミナルから Linux フォワーダーに接続します。

  2. Linux フォワーダーで新しいユーザーを作成します。

    # adduser <username>

    # passwd <username>

    # usermod -aG wheel <username>

  3. Docker コンテナを実行する新しいユーザーのホーム ディレクトリに移動します。

  4. Chronicle フォワーダーの構成ファイル # mkdir ~/config を格納するディレクトリを作成します。

  5. ディレクトリの移動

  6. ファイルが転送されたら、構成ファイルが ~/config ディレクトリにあることを確認します。

    # ls -l

ステップ 2. Chronicle Container Registry の鍵のインストール

Google Cloud が提供する JSON ファイル（拡張子は .json）には、Chronicle Docker レジストリへのアクセスに必要な認証情報が含まれています。

  1. 次のコマンドテキスト（改行を含む）をテキスト エディタにコピーし、かっこ内の .json ファイル名を Chronicle Docker 認証ファイル名に変更します。

      docker login \

     -u _json_key \

     --password-stdin \

     https://gcr.io < ./chronicle-container-c2da10b71454-oneline.json

  2. 編集が完了したら、コマンドのテキスト全体をコピーし、Linux フォワーダーの ~/config ディレクトリからコマンドを実行します。

  3. 上記の Docker ログイン コマンドの出力は「Login Succeeded」になります。

問題が発生した場合は、実行中の Docker のバージョンを確認してください。

# docker version

古いバージョンの Docker（1.13.1 など）は、別のコマンドライン引数を必要とする場合があります。相違点は次のとおりです。

--password-stdin をサポートしていない古いバージョンの Docker に対するステップ 2

古いバージョンの Docker（--password-stdin を受け入れないバージョン）の場合は、JSON ファイルの内容をコピーし、パスワード プロンプトに貼り付けます。

  1. 次のコマンドを実行します。

    $ cat ./<filename>.json

  2. cat コマンドの出力をコピーします。

  3. Docker にログインします。

    docker login -u _json_key https://gcr.io

  4. Password: プロンプトで、クリップボードの内容を貼り付けます。

    パスワードの指定方法（--password-stdin またはコピーして貼り付け）に関係なく、docker login コマンドの出力は Login Succeeded になります。

ステップ 3: Docker コンテナ内でフォワーダーを実行する

次の手順を使用して最初に Chronicle フォワーダーを起動し、Chronicle コンテナの最新バージョンにアップグレードします。

--log-opt オプションは、Docker 1.13 以降で利用可能です。これらのオプションはコンテナ ログファイルのサイズを制限するため、Docker のバージョンがサポートしていれば使用する必要があります。

  1. アップグレードする場合は、まず、以前に実行した Docker をクリーンアップします。次の例では、Docker コンテナの名前は cfps であり、以下の # docker pull コマンドを使用して Google Cloud から最新の Docker イメージを取得します。

    # docker stop cfps
# docker rm cfps

  2. Google Cloud から最新の Docker イメージを取得します。

    # docker pull gcr.io/chronicle-container/cf_production_stable

  3. Docker コンテナから Chronicle フォワーダーを起動します。

    docker run \

  --detach \

  --name cfps \

  --restart=always \

  --log-opt max-size=100m \

  --log-opt max-file=10 \

  --net=host \

  -v ~/config:/opt/chronicle/external \

  gcr.io/chronicle-container/cf_production_stable

これらのコマンドは、run_docker_production_stable.sh というシェル スクリプトとしても提供されます。

Docker コンテナ（および Chronicle フォワーダー）は、システムの再起動後も維持されます。

手順 4. フォワーダーをモニタリング、管理する

以下の Docker コマンドにより、Chronicle フォワーダーのモニタリングと管理ができます。

  • Docker コンテナが実行されているかどうかを確認します。

    docker ps

  • コンテナからログを表示します。これにより、大量の出力が生成される可能性がありますが、デバッグを実施する際に有用です。

    docker logs cfps

  • コンテナ内で実行されている内容を確認するには:

    docker top cfps

  • コンテナを停止するには:

    docker stop cfps

Splunk データを収集する

Splunk のデータを Chronicle に転送するように Chronicle フォワーダーを構成できます。Google Cloud は、次の情報を使用して Splunk からデータを転送するように Chronicle フォワーダーを構成します。

  • Splunk REST API の URL（例: https://10.0.113.15:8889）。

  • 必要な各データ型（index=dns など）のデータを生成する Splunk クエリ。

Splunk アカウントの認証情報を Chronicle フォワーダーで利用できるようにする必要があります。

Splunk の認証情報のローカル ファイルを作成し、creds.txt という名前を付けます。最初の行にユーザー名を入力し、2 行目にパスワードを入力します。

  cat creds-file

  myusername
  mypassword

Chronicle フォワーダーを使用して Splunk インスタンスにアクセスするお客様の場合は、creds.txt ファイルを config ディレクトリ（構成ファイルと同じディレクトリ）にコピーします。次に例を示します。

cp creds-file ~/config/creds.txt

creds.txtem> ファイルが正しい場所にあることを確認します。

ls ~/config

syslog データを収集する

Chronicle フォワーダーは、Syslog サーバーとして動作できます。つまり、TCP 接続または UDP 接続を介した syslog データの送信をサポートする任意のアプライアンスまたはサーバーを Chronicle フォワーダーにデータを転送するように構成できます。アプライアンスまたはサーバーが Chronicle フォワーダーに送信するデータを正確に制御できます。その結果、Chronicle のフォワーダーがデータを Chronicle に転送できるようになります。

構成ファイル（Google Cloud が提供）では、転送されるデータの種類ごとにモニタリングするポートを指定します（例: ポート 10514）。デフォルトでは、Chronicle のフォワーダーは TCP 接続と UDP 接続の両方を受け入れます。

rsyslog を構成する

rsyslog を構成するには、各ポートのターゲット（たとえば各データ型）を指定する必要があります。正しい構文については、システムのドキュメントをご覧ください。rsyslog のターゲット構成の例を次に示します。

  • TCP ログ トラフィック: dns.* @192.168.0.12:10514

  • UDP ログ トラフィック: dns.* @192.168.0.12:10514

syslog 構成用の TLS の有効化

Chronicle フォワーダーへの syslog 接続用の TLS を有効にできます。Chronicle フォワーダーの構成ファイルで、次の例に示すように、証明書と証明書鍵の場所を指定します。

証明書 「/opt/chronicle/external/certs/edb3ae966a7bbe1f.pem」
certificate_key 「/opt/chronicle/external/certs/forwarder.key」

示している例に基づいて、Chronicle フォワーダーの構成は次のように変更されます。

  collectors:
- syslog:
    common:
      enabled: true
      data_type: WINDOWS_DNS
      data_hint:
      batch_n_seconds: 10
      batch_n_bytes: 1048576
  tcp_address: 0.0.0.0:10515
  connection_timeout_sec: 60
  certificate: "/opt/chronicle/external/certs/edb3ae966a7bbe1f.pem"
  certificate_key: "/opt/chronicle/external/certs/forwarder.key"

構成ディレクトリの下に証明書ディレクトリを作成し、証明書ファイルを保存できます。

パケットデータを収集する

Chronicle のフォワーダーでは、Linux の libpcap を使用してネットワーク インターフェースから直接パケットをキャプチャできます。パケットはキャプチャされ、ログエントリではなく Chronicle に送信されます。パケット キャプチャはローカル インターフェースからのみ処理されます。システムのパケット キャプチャを有効にするには、Chronicle のサポートにお問い合わせください。

Google Cloud は、パケットをキャプチャするために使用される Berkeley Packack Filter（BPF）式を使用して Chronicle フォワーダーを構成します（たとえば、localhost ではなく、ポート 53）。

データ圧縮を切り替える

ログ圧縮により、ログを Chronicle に転送する際のネットワーク帯域幅の使用量が削減されます。ただし、圧縮によって CPU 使用率が増加する場合があります。CPU 使用率と帯域幅のトレードオフは、ログデータのタイプ、データの圧縮率、フォワーダーを実行しているホスト上の CPU サイクルの可用性、ネットワーク帯域幅の使用量の削減の必要性など、さまざまな要因によって決まります。

たとえば、テキストベースのログは圧縮率が高く、低い CPU 使用率によって帯域幅を大幅に削減できます。一方、未加工のパケットの暗号化されたペイロードは圧縮率が低く、CPU 使用率が高くなります。

フォワーダーによって取り込まれるログタイプのほとんどは効率的に圧縮できるため、帯域幅の使用量を減らすために、デフォルトでログ圧縮が有効になっています。ただし、CPU 使用率の増加が帯域幅の節約によるメリットを上回る場合は、次の例に示すように、Chronicle フォワーダーの構成ファイルにある compression フィールドを false に設定することで圧縮を無効にできます。

output:
  compression: false
    url: malachiteingestion-pa.googleapis.com:443
    identity:
      identity:
      collector_id: 10479925-878c-11e7-9421-10604b7cb5c1
      customer_id: ebdc4bb9-878b-11e7-8455-10604b7cb5c1
      secret_key: |
        {
          "type": "service_account",
...

ディスク バッファリング

ディスク バッファリングを使用すると、バックログにあるメッセージをメモリではなくディスクにバッファ保存できます。バックログにあるメッセージは、フォワーダーがクラッシュした場合や基盤となるホストがクラッシュした場合に保存されます。ディスク バッファを有効にするとパフォーマンスに影響する可能性があるので注意してください。

Docker を使用してフォワーダーを実行している場合は、分離のため、構成ボリュームとは別のボリュームをマウントすることをおすすめします。また、競合を避けるために、各入力を独自のディレクトリまたはボリュームで分離する必要があります。

構成例: ディスク バッファリング

次の構成には、ディスク バッファリングを有効にする構文が含まれています。

collectors:
- syslog:
    common:
      write_to_disk_buffer_enabled: true
      # /buffers/NIX_SYSTEM is part of the external mounted volume for the forwarder
      write_to_disk_dir_path: /buffers/NIX_SYSTEM
      max_file_buffer_bytes: 1073741824
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

正規表現フィルタ

正規表現フィルタを使用すると、正規表現と未加工のログの照合に基づいてログをフィルタできます。

フィルタでは https://github.com/google/re2/wiki/Syntax で説明されている RE2 構文を使用します。

フィルタには正規表現を含める必要があります。また、必要に応じて、一致した場合の動作を定義します。一致のデフォルトの動作は「ブロック」です（ブロックとして明示的に構成できます）。

または、allow の動作をするフィルタを指定することもできます。許可フィルタを指定した場合、フォワーダーは、少なくとも 1 つの許可フィルタに一致しないログをブロックします。

任意の数のフィルタを定義できます。ブロック フィルタは、許可フィルタよりも優先されます。

フィルタを定義するときに、名前を割り当てる必要があります。アクティブなフィルタの名前は、Forwarder ヘルス指標を介して Chronicle に報告されます。構成のルートで定義されたフィルタは、コレクタレベルで定義されたフィルタと統合されます。名前が競合する場合、コレクタレベルのフィルタが優先されます。ルートレベルまたはコレクタレベルでフィルタが定義されていない場合、動作はすべて許可されます。

構成例: 正規表現フィルタ

次のフォワーダー構成では、ルートフィルタ（allow_filter）に一致しない WINEVTLOG ログがブロックされます。正規表現では、フィルタでは 0 から 99 の間の優先度を持つログのみが許可されます。ただし、「foo」や「bar」を含む NIX_SYSTEM ログは、allow_filter であるにもかかわらずブロックされます。これは、フィルタでは論理 OR が使用されているためです。フィルタがトリガーされるまで、すべてのログが処理されます。

regex_filters:
  allow_filter:
    regexp: ^<[1-9][0-9]?$>.*$
    behavior_on_match: allow
collectors:
- syslog:
    common:
      regex_filters:
        block_filter_1:
          regexp: ^.*foo.*$
          behavior_on_match: block
        block_filter_2:
          regexp: ^.*bar.*$
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

任意のラベル

ラベルは、キーと値のペアを使用してログに任意のメタデータを追加するために使用されます。ラベルは、フォワーダー全体に対して、またはフォワーダーの特定のコレクタ内で構成できます。両方が指定されている場合、ラベルには、フォワーダー キーが重複する場合にコレクタのキーが優先してマージされます。

構成例: 任意のラベル

次のフォワーダー構成では、「foo=bar」と「meow=mix」のキーと値のペアの両方が WINEVTLOG ログにアタッチされ、「foo=baz」と「meow=mix」のキーと値のペアが NIX_SYSTEM のログにアタッチされます。

metadata:
  labels:
    foo: bar
    meow: mix
collectors:
syslog:
    common:
      metadata:
        labels:
          foo: baz
          meow: mix
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Namespace

名前空間ラベルを使用して、異なるネットワーク セグメントのログを識別し、重複する IP アドレスの競合を解決します。名前空間ラベルは、フォワーダー全体に対して、またはフォワーダーの特定のコレクタ内で構成できます。両方が含まれている場合、特定のコレクタの名前空間が優先されます。

フォワーダーに構成された名前空間は、関連するアセットとともに Chronicle のユーザー インターフェースに表示されます。Chronicle の検索機能を使用して名前空間を検索することもできます。

Chronicle のユーザー インターフェースで名前空間を表示する方法については、こちらをご覧ください。

構成例: 名前空間

次のフォワーダー構成では、WINEVTLOG ログが FORWARDER 名前空間にアタッチされ、NIX_SYSTEM ログが CORPORATE 名前空間にアタッチされています。

metadata:
  namespace: FORWARDER
collectors:
- syslog:
      common:
        metadata:
          namespace: CORPORATE
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      tcp_address: 0.0.0.0:30000
      connection_timeout_sec: 60
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

Kafka 入力

Syslog の場合と同様に、Kafka トピックからデータを取り込めます。コンシューマ グループを活用することで、最大 3 つのフォワーダーをデプロイし、同じ Kafka トピックからデータを pull できます。

Kafka 消費者グループの詳細については、https://docs.confluent.io/platform/current/clients/consumer.html をご覧ください。

構成例: Kafka の入力

次のフォワーダー構成は、Kafka トピックからデータを取り込むようにフォワーダーを設定する方法を示しています。

collectors:
- kafka:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      username: user
      password: password
      topic: example-topic
      group_id: chronicle-forwarder
      timeout: 60
      brokers:
      - broker-1:9093
      - broker-2:9093
      tls:
        insecureSkipVerify: true
        certificate: "/path/to/cert.pem"
        certificate_key: "/path/to/cert.key"
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

ロード バランシングと高可用性

Chronicle Linux フォワーダーは、データソースとフォワーダー インスタンスの間にレイヤ 4 ロードバランサがインストールされている環境にデプロイできます。これにより、お客様は複数のフォワーダー間でログ収集を分散したり、フォワーダーで障害が発生した場合に別のフォワーダーにログを送信したりできます。この機能は、syslog コレクション タイプでのみサポートされています。

Linux フォワーダーには、ロードバランサからの HTTP ヘルスチェックに応答する組み込み HTTP サーバーが含まれています。また、HTTP サーバーは、フォワーダーの起動またはシャットダウン中にログが失われるのを防ぐこともできます。

フォワーダー構成ファイルの server セクションで、HTTP サーバー、負荷分散、高可用性オプションを構成します。これらのオプションは、コンテナ スケジューラとオーケストレーション ベースのデプロイで受信されるヘルスチェックや、従来のロードバランサから受信されるヘルスチェックに対して返されるタイムアウト期間とステータス コードの設定をサポートします。

ヘルスチェック、readiness チェック、liveness チェックには、次の URL パスを使用します。<host:port> 値は、フォワーダー構成で定義されます。

  • http://<host:port>/meta/available: Kubernetes などのコンテナ スケジューラ/オーケストレーターの liveness チェック。
  • http://<host:port>/meta/ready: readiness チェックと従来のロードバランサのヘルスチェック。

次のフォワーダー構成は、ロード バランシングと高可用性の例です。

collectors:
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60
server:
  graceful_timeout: 15s
  drain_timeout: 10s
  http:
    port: 8080
    host: 0.0.0.0
    read_timeout: 3s
    read_header_timeout: 3s
    write_timeout: 3s
    idle_timeout: 3s
    routes:
    - meta:
        available_status: 204
        ready_status: 204
        unready_status: 503
構成パス 説明
server : graceful_timeout フォワーダーが不適切な準備やヘルスチェックを返していながら新しい接続を引き続き受け入れている時間。これは、停止する信号を受信してから実際にサーバー自体のシャットダウンが開始されるまで、待機する時間でもあります。これにより、ロードバランサがプールからフォワーダーを削除する時間を確保できます。
server : drain_timeout アクティブな接続がサーバーによって閉じられる前に、独自に正常に終了するまでフォワーダーが待機する時間。
server : http : port HTTP サーバーがロードバランサからのヘルスチェックをリッスンするポート番号。1024 ～ 65535 の範囲に設定する必要があります。
server : http : host サーバーがリッスンする IP アドレスまたはホスト名。IP アドレスに解決できます。空の場合、デフォルト値はローカル システム（0.0.0.0）です。
server : http : read_timeout HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。ヘッダーと本文の両方でリクエスト全体を読み取るための最大時間。read_timeout と read_header_timeout の両方を設定できます。
server : http : read_header_timeout HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。リクエスト ヘッダーの読み取りが許可される最大時間。ヘッダーの読み取り後に、接続の読み取り期限がリセットされます。
server : http : write_timeout HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。レスポンスの送信に許可される最大時間。新しいリクエスト ヘッダーが読み取られるとリセットされます。
server : http : idle_timeout HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。アイドル状態の接続が有効である場合に、次のリクエストを待機する最大時間。idle_timout がゼロの場合は、read_timout の値が使用されます。両方がゼロの場合、read_header_timeout が使用されます。
routes : meta : ready_status 次のいずれかの状況でトラフィックを受け入れる準備ができた場合にフォワーダーが返すステータス コード。
  • 準備チェックは、Kubernetes などのコンテナ スケジューラまたはオーケストレーターから受信されます。
  • ヘルスチェックは、従来のロードバランサから受信されます。
routes : meta : unready_status フォワーダーがトラフィックを受け入れる準備ができていない場合に返すステータス コード。
routes : meta : available_status 実行チェックが受信され、フォワーダーが利用可能な場合に、フォワーダーが返すステータス コード。実行チェックは、多くの場合、Kubernetes などのコンテナ スケジューラやオーケストレーターによって送信されます。

よくある質問

Docker コンテナとは何か教えてください。

  • Docker コンテナは仮想マシンと同様に、セキュリティ、分離、リソースの管理を強化します。

  • 仮想マシン - 特権空間（Linux カーネル）とユーザー空間（libc、python、ls、tcpdump などのすべて）の両方があります。

  • コンテナにはユーザー空間（libc、python、ls、tcpdump などのすべて）のみあり、ホストの権限空間に依存します。

コンテナを使用して Chronicle フォワーダーが配布される理由を教えてください。

  • 分離によってセキュリティを強化します:
    • お客様の環境と要件は、Chronicle フォワーダーには影響しません。
    • Chronicle フォワーダーの環境と要件は、お客様には影響しません。
    • コンテナ配布メカニズムはすでに存在しており、非公開にして、Google Cloud とお客様向けに分けることができます: https://cloud.google.com/container-registry/

コンテナに対応しているのが Linux のみであるのはなぜですか。Windows についてどうですか？

  • コンテナは最初に Linux 用に開発され、本番環境に対応しています。

  • コンテナの Windows サポートが改善されました。コンテナは Windows Server 2016 と Windows 10 で使用できます。

高度な Docker コマンドを使用する必要はありますか？

  • Chronicle のフォワーダーは単一のコンテナを使用するため、Swarm、オーケストレーション、Kubernetes、その他の高度な Docker のコンセプトやコマンドについて学ぶ必要はありません。