8年前、コンテナは既知のテクノロジーでしたが、一般に採用されることはほとんどありませんでした。次に、Solomon Hykesは、コンテナーテクノロジーであるDockerを作成し、コンテナーをはるかに使いやすくしました。今日、コンテナはITの世界を支配しています。ガートナーは、組織の70％が2023年までにコンテナ化されたアプリケーションを実行すると予測しています。
なんで？組織は、構成が簡単で、展開が速く、コンテナ化されたアプリケーションを使用して同じハードウェアでより多くのワークロードを実行できるという利点を認識しています。
コンテナーを最大限に活用するには、Dockerコンテナーを監視する必要があります。コンテナの監視がなければ、暗闇の中で旅行していることになります。文字通り、コンテナがどれだけうまく機能しているか、何をしているか、またはコンテナがどれだけうまく機能しているかを確認することはできません。
また、Dockerコンテナの監視がないと、コンテナ上に構築されたマイクロサービスとアプリケーションがどのように機能しているかを知ることができません。コンテナの監視により、コンテナ自体、およびより大規模なユーザー向けプログラムで何が起こっているかを知ることができます。
Docker Container Monitoring：基本
コンテナーが人気がある主な理由は、コンテナーが継続的統合/継続的デプロイメント（CI / CD）に適しているためです。これは、プログラマーがコードを共有リポジトリに早期かつ頻繁に統合できるように設計されたaDevOps方法論です。そこに到達すると、コンテナ化されたプログラムが迅速かつ効率的に展開されます。
Dockerを使用すると、開発者はあらゆるアプリケーションを軽量でポータブルな自給自足のコンテナーとしてパック、出荷、実行でき、事実上どこでも実行できます。コンテナを使用すると、アプリケーションをすぐに移植できます。
コンテナーは、開発者がコードを単一のコンテナーに分離できるようにすることでこれを実現し、プログラムの変更と更新をより効率的にします。これにより、企業はCI / CDパイプラインを使用して、複数の小規模なアジャイルチーム間で大規模な開発プロジェクトを分割し、コンテナーを介した新しいコード配信と更新されたコード配信を自動化できます。
最後に、おそらくビジネスにとって最も重要なポイントであるコンテナにより、企業はハードウェアとクラウドのリソースを最大化できます。以前はParallelsのサーバー仮想化のCTOであり、主要なLinuxカーネル開発者であるJames Bottomleyが説明したように、「Hyper-V、KVM、XenなどのVMハイパーバイザーはすべて仮想ハードウェアのエミュレートに基づいています。つまり、システム要件の点で彼らは太っています。」
ただし、コンテナは共有オペレーティングシステムを使用するため、システムリソースの観点からはハイパーバイザーよりもはるかにスリムです。ハードウェアを仮想化する代わりに、コンテナは単一のLinuxインスタンス上にあります。これは、Bottomleyが述べたように、「無駄な99.9パーセントのVMジャンクを残して、アプリケーションを含む小さくてきれいなカプセルを残す」ことができることを意味します。つまり、適切に調整されたコンテナシステムを使用すると、以前は1つのインスタンスしか実行できなかった4〜6個のコンテナをシステムで実行できます。
今日、多くの種類のコンテナプラットフォームがあります。 Dockerは最もよく知られていますが、LXC、runC、containerd、podmanもあります。これらはすべて同様の機能を実行し、ほとんど同じツールで管理できます。
Dockerとは何ですか？
では、Dockerとは具体的に何ですか？ DockerはLXCの上に構築されています。他のコンテナと同様に、Dockerで実行されているプログラムに関する限り、Dockerには独自のファイルシステム、ストレージ、CPU、およびRAMがあります。コンテナーとVMの主な違いは、ハイパーバイザーがデバイス全体を抽象化するのに対し、コンテナーはオペレーティングシステムカーネルを抽象化するだけであるということです。 Dockerのすべての利点は、その単純なメカニズムだけからもたらされます。
FreeBSD Jails、Oracle Solaris Zones、OpenVZなどの前任者がコンテナを適切かつ安全に機能させることができたが、市場での成功はほとんどなかったのに、なぜ成功したのでしょうか。ある程度、コンテナは成功しましたが、見えませんでした。たとえば、Googleは10年以上にわたって独自のオープンソースのコンテナprogramlmctfy（Let Me Contain That For You）を使用していました。検索、Gmail、GoogleドキュメントなどのGoogle機能を使用するときはいつでも、非表示のコンテナで実行されていました。
Dockerがもたらすのは、以前のアプローチよりもコンテナーのデプロイと使用がより安全で効率的になることです。さらに、DockerとCanonical、Google、Red Hat、Parallelsなどの他のコンテナパワーとのパートナーシップにより、キーオープンソースコンポーネントのlibcontainerで、コンテナに待望の標準化がもたらされます。
Dockerは、libcontainersコンテナー形式とそのランタイム、および関連する仕様をLinuxFoundationのOpenContainerProjectに提供します。具体的には、これにはnsinitを含むlibcontainerプロジェクトのコンテンツ全体と、Dockerから独立して実行するために必要なすべての変更が含まれます。
Dockerは、他のコンテナ標準化の取り組みに引き続き取り組んでいます。たとえば、DockerはオープンソースのコンテナーランタイムであるcontainerdをCloud Native Computing Foundation（CNCF）に寄付しました。 Dockerを成功させるには、標準化が大きな役割を果たします。
他のコンテナテクノロジーとは異なり、Dockerはソフトウェア定義ネットワーク（SDN）もサポートしています。これにより、DevOpsチームは、ハードウェアスイッチを気にすることなく、コンテナーのネットワークを定義できます。代わりに、複雑なネットワークトポロジを設定し、構成ファイルを介してネットワークを定義します。
同時に、SDNとDockerはマイクロサービスの活用を可能にします。これらを組み合わせることで、HTTPやTCPなどのよく知られたプロトコルを介して相互に連携する疎結合サービスからアプリケーションをより効率的に構築できます。
最後に、Dockerの成功は、ユーザーがクラウドコンピューティングの革命を利用できるように、適切なタイミングで適切なオープンテクノロジーであることに大きな負債を負っています。
コンテナモニタリングとは何ですか？
企業の一般的なシナリオは、Dockerを使用し、会社に不可欠なアプリケーションを実行する数十万から数十万のコンテナーを持っていることです。それらを調整するために、おそらく彼らはKubernetesを使用しています。 CNCFCTOのChrisAniszczykが言うように、Kubernetesとコンテナは本質的にパッケージ取引であるという理解にはますます空白があります。他にもコンテナオーケストレーションプログラムがありますが、Kubernetesは圧倒的なマーケットリーダーです。このうち、Datadogは、Kubernetesユーザーの90％近くがクラウドマネージドサービスを活用していると報告しています。2020年の70％近くから増加しています。
それは素晴らしいことです。ただし、Kubernetesはコンテナを制御、デプロイ、スケーリングします。それらを監視しません。
監視は複雑です。コンテナは一時的なものです。それらはほんの数分で上下に回転します。平均的なKubernetesコンテナは1日続きます。仮想サーバーまたはベアメタルサーバーで実行されている従来のアプリケーションを監視するために使用するツールは、機能しません。監視プログラムがレポートを要求するまでに、コンテナは見えなくなって、その中のログを持っている可能性があります。
コンテナ監視の利点
複雑ですが、コンテナの監視は不可欠です。システム管理者のGaryWilliamsが言うように、「監視しすぎることはできません」。ゲイリーは正しいです。
コンテナ監視の利点は次のとおりです。
- システムの停止を回避するために問題を事前に特定します。
- 時系列データを監視して、アプリケーションの実行を改善します。
- リソース割り当てを最適化します。
- 問題をできるだけ早くキャッチして、問題を迅速に解決します。
コンテナベースのアプリケーションはランサムウェアや暗号通貨の攻撃から絶えず攻撃を受けているため、コンテナの監視も重要です。つまり、セキュリティとパフォーマンスの両方のために、コンテナを監視する必要があります。これらは、すべてのシステムを監視するのと同じ理由であり、コンテナも同じです。
監視プログラムは、コンテナから可観測性データを収集するための他の課題に直面しています。いくつかのデータ収集方法があります。それらには以下が含まれます：
- 専用の監視エージェントをホストアプリケーションまたはコンテナとして導入します。
- ログルーターを導入して、コンテナーによって生成されたログを自動的に収集します。
- Dockerロギングドライバーを使用してコンテナーログをホストに保存します。
- Docker統計、Kubernetesメトリックパイプライン、または同様のAPIを介してメトリックを収集します。
コンテナの監視には、メモリ使用率、CPU使用率、CPU制限、メモリ制限などの基本的な指標が含まれます。監視プログラムは、リアルタイムのストリーミングログ、トレース、および可観測性も提供する必要があります。
より高いレベルでは、コンテナとそのホストから監視データを収集して一元化するだけでなく、個々のコンテナではなく、アプリケーション全体のデータを収集して分析する必要があります。
LogDNAのMinhDaoが述べているように、「3層のWebアプリケーションがあり、各層が個別のコンテナーとして実行されていると想像してください。ここで、バックエンド層が突然エラーを生成し始め、その結果、コンテナーがクラッシュしていると想像してください。個々のコンテナからログとメトリックを取得することは根本原因の分析に役立ちますが、アプリケーション全体のコンテキストでエラーを確認するのには役立ちません。問題はコンテナ固有の問題である場合もあれば、より広範なアプリケーション全体の問題を示している場合もあります。」
すべてをまとめれば、疑問の余地はありません。コンテナを監視する必要があります。
5つの最高のコンテナ監視ツール
最高のコンテナ監視プログラムの多くは、オープンソースプログラムです。 Linodeは、FilebeatとMetricbeatをKibanaで使用し、時系列分析をGraphiteとGrafana Dashboardで使用して、Elasticsearch、Logstash、およびKibana（ELK）スタックを開始するための基本を提供します。少し努力すれば、独自のコンテナ監視システムを構築できます。
以下のリストのプログラムはアルファベット順であり、最良から最悪の順序ではありません。公平にランク付けできないからです。それらはすべて独自の長所と短所があり、多くの場合、さまざまなメトリックを測定します。したがって、コンテナを注意深く監視することを真剣に考えている場合は、これらのプログラムのいくつかを使用する必要がある可能性があります。
Container Advisor（cAdvisor）
GoogleのContainerAdvisor（cAdvisor）は、オープンソースの監視プログラムです。これは、対象のコンテナーのリソース使用量とパフォーマンスデータを収集、集約、およびエクスポートするデーモンとして実行されます。各コンテナのリソース分離パラメータ、履歴リソース使用量、完全な履歴リソース使用量のヒストグラム、およびネットワーク統計を追跡します。このデータは、コンテナごとおよびマシン全体にエクスポートされます。
このプログラムにはネイティブのDockerコンテナーサポートが付属しており、他のほとんどすべてのコンテナータイプをすぐにサポートするように設計されています。また、Prometheusメトリックを公開します。つまり、cAdvisorはデータを収集し、Prometheusはデータを取得します。 CAdvisorのコンテナの抽象化は、lmctfyに基づいているため、コンテナは本質的に階層的にネストされています。
cAdvisorビルドをイメージとしてDockerホストにインストールできます。このプログラムは、Webユーザーインターフェイス（UI）とRESTアプリケーションプログラミングインターフェイス（API）の両方も提供します。これにより、Dockerコンテナを直接監視することも、Webサービスエンドポイントを介してメトリックを外部アプリケーションに統合することもできます。
データドッグ
Datadogは正当な理由でDockerによって推奨されています。コンテナ、インフラストラクチャ、およびアプリケーション関連のメトリックを追跡する多数の監視ツールを提供します。
そのUIとダッシュボードも非常に便利です。リアルタイムデータを使用すると、時系列、クエリ値、トップリスト、テーブル、ヒートマップ、ツリーマップ、円グラフ、ホストマップ、ログストリーム、リスト、アラート値、サービスマップなど、さまざまな視覚化を設定できます。 。データを自動的に関連付け、異常な動作を視覚化します。
Datadogの心臓部は独自のものですが、Datadogエージェントと、マシンおよびクラウドで実行される他のすべてのプログラムはオープンソースです。
監視は、グラフィカルな視覚化とアラートを提供するトレース要求を介して利用できます。このプログラムは、詳細なログデータを介して、サービス、アプリケーション、およびプラットフォームに関するデータを収集します。
このプログラムは監視エコシステムです。コンテナ以外にも、ほとんどすべてを監視します。これは、StatsD、OpenMetrics、OpenTelemetryなどのほとんどのテレメトリプログラムとプロトコルをサポートすることで部分的に行われます。
主にサービスとしてのソフトウェア（SaaS）として販売されていますが、オンプレミスで展開することもできます。
ElasticsearchとKibana
Elasticsearchは、ApacheLuceneライブラリから派生したオープンソースのJavaベースの検索エンジンです。分散型のマルチテナント対応の全文検索エンジンに、HTTPWebインターフェイスとスキーマフリーのJSONドキュメントを提供します。これがELKスタックの心臓部です。
そのパートナープログラムであるKibanaは、Elasticsearchデータを視覚化し、ELKスタックをナビゲートするための無料のオープンユーザーUIです。クエリの読み込みを追跡して、リクエストがアプリをどのように通過するかを確認できます。 Kibanaには、ヒストグラム、線グラフ、円グラフ、サンバーストなど、通常のUIダッシュボードクラシックが付属しています。もちろん、すべてのドキュメントを検索できます。
コンテナの監視目的で、FilebeatとMetricbeatを使用してコンテナデータを自動的にキャプチャします。 Filebeatは自動的にコンテナを見つけ、そのログをElasticsearchに保存します。 Metricbeatをコンテナに自動的にデプロイします。そこで、システムレベルのCPU使用率、メモリ、ファイルシステム、ディスクIO、およびネットワークIOの統計を収集します。 Goで記述されたそのモジュールは、Apache、NGINX、MongoDB、MySQL、PostgreSQL、Prometheusなどのコンテナー内のプログラムも監視できます。その後、Kibanaを使用してこのすべてのデータにアクセスできます。
非常に柔軟性があります。構成と使用方法を学ぶのにかなりの時間を費やす必要がありますが、時間の価値があります。
プロメテウスとグラファナ
ElasticsearchやKibanaと同様に、PrometheusとGrafanaは、独自の監視システムを構築するために使用できるオープンソースプログラムです。複雑ですが、その価値はあります。
Prometheusは、データを時系列として保存します。時系列では、データは同じメトリックと同じラベル付きディメンションのセットのタイムスタンプ値のストリームとして保持されます。
CNCFプロジェクトであるPrometheusは、コンテナーから直接、またはプッシュゲートウェイを使用してメトリックをスクレイプします。削り取られたサンプルはローカルに保存され、ルールがそのデータに適用されて、新しい時系列を集約して生成したり、ユーザー定義のアラートを生成したりします。
Prometheusの主な焦点は、正確さではなく信頼性です。プログラムは、リモートサービスへの依存を回避するために、各Prometheusサーバーをローカル時系列データベースストレージでスタンドアロンにすることでこれを行います。この設計により、Prometheusは、問題を迅速に特定し、リアルタイムのフィードバックを取得するために信頼できる理想的なツールになります。したがって、通常、クラウド上で実行されるコンテナベースのマイクロサービスなどの非常に動的なシステムで使用されます。
Prometheusには独自のWebダッシュボードがあります。または、APIを使用してPrometheusからデータを抽出できます。 Grafanaがデフォルトのインターフェースとして使用されます。
Sysdig
Sysdigは、Prometheusと連携して動作する商用クラウド監視プラットフォームです。これにより、独自のPrometheus監視システムを構築しなくても、時系列データにアクセスできます。
Sysdigは、コンテナーメタデータからDockerデータを直接追跡して、セキュリティと監視を可能にします。 Dockerは、コンテナー化されたアプリケーションの監視ソリューションとしてSysdigを推奨しています。
Sysdigはまた、Linux監視プログラムを単一の一貫したインターフェースに統合します。プログラムは、Linuxカーネルと統合することにより、オペレーティングシステムレベルでこれを実行します。システムコールやその他のオペレーティングシステムのイベントをキャプチャします。
Prometheusと低レベルのオペレーティングシステムの洞察の独自の組み合わせにより、強力な監視ツールになっています。
結論
コンテナの監視は必須であり、便利ではありません。監視なしでコンテナを運転することは、ヘッドライトなしで暗く曲がりくねった高速道路を運転するようなものです。
選択する監視プログラムは、ユースケース、予算、および組織で利用可能なITリソースによって異なります。利用可能な多くのオープンソースプログラムを使用して独自のコンテナ監視システムを作成することも、商用パッケージを使用することもできます。使用する監視プログラムに関係なく、コンテナ化されたWebアプリケーションの正常性と安定性に不可欠なコンポーネントです。