ソリューションとテクノロジーで成功への道筋をつけることができます。Cloudお客様のビジネス全体に役立つ、わかりやすい料金体系です。安全でインテリジェントなプラットフォームを使って今すぐ始めましょう。プロダクトをお試しいただけます。マネジメントパートナーを探すパートナーになるその他のご利用方法ホームソリューションアーキテクチャコンテナ運用のおすすめの方法この記事では、コンテナを操作しやすくするための一連のおすすめの方法について説明します。これらのプラクティスは、セキュリティからモニタリング、ロギングまで、幅広いトピックをカバーしています。コンテナ全般でアプリケーションを実行しやすくすることです。方法論から発想を得たものです。アプリケーションを構築する際は、この方法論が非常に役立つリソースとなります。ここで説明するおすすめの方法は、すべてが同じく重要であるというわけではありません。本番環境ワークロードを正常に実行するために、必要のない方法もあれば、不可欠な方法もあります。セキュリティに関連する方法の重要度は主観的なものです。実装するかどうかは、個々の環境と制約によって異なります。関する知識が必要です。コンテナで作業していることが前提となります。コンテナの構築に関するアドバイスについては、コンテナ構築のおすすめの方法をご覧ください。高アプリケーションの管理に不可欠な部分として、ログにはアプリケーションで発生したイベントに関する貴重な情報が含まれています。ログ管理を容易にすることを目指しています。ローテーションを処理しなければなりません。サーバーに転送して一元管理することもあります。書き込むことができるため、簡単かつ標準化された方法でログを処理できます。コマンドを使用してアクセスできます。メカニズムを実装する必要はありません。メカニズムを使用してください。オペレーターは、ログを一元管理して検索可能にするためのシステムを用意する必要があります。よってこのサービスが提供されます。Kibana)スタックがあります。ログほとんどのログ管理システムは、実際には時系列データベースであり、時刻でインデックス付けされたドキュメントを格納します。つのドキュメントとして格納されます。形式でログを記録します。このようにすれば、これらのフィールドに基づいて、より効率的にログを検索できます。形式に変換するとします。wrong.変換後のログは次のようになります。ログをすべて、ログの中から簡単に検索できます。行で書き込んで、正しく解析されるようにする必要があります。実際には、次のようになります。wrong."}ご覧のように、通常のログ行よりもかなり読みにくくなります。この方法を使用する場合は、チームが手動によるログ検査に大きく依存することがないようにしてください。ログを書き出すよう構成するのは簡単ではありません。パターンを使用するのが最善の方法となります。サイドカーとは、アプリケーションと同じポッドで動作する小さなコンテナのことです。ドキュメントをご覧ください。エージェントがログを読み取って転送するように構成します。ローテーションに対処しなければなりません。コンテナによってローテーションを処理できます。コンテナを試している場合、従来のサーバーのようにコンテナを扱わないでください。実行中のコンテナ内でアプリケーションを更新したり、脆弱性が発生したときに実行中のコンテナにパッチを適用したりしたくなるかもしれません。コンテナは基本的に、このような処理に対応するように設計されていません。コンテナは、ステートレスかつ不変になるように設計されています。「ステートレス」とは、すべての状態(任意の種類の永続データ)がコンテナの外部に格納されることを意味します。この外部ストレージは、必要に応じてさまざまな形をとることができます。ストアを使用することをおすすめします。Memcached)を使用することをおすすめします。ブロックレベルのストレージ(データベース用など)が必要な場合は、コンテナに接続された外部ディスクを使用できます。場合は、永続ディスクの使用をおすすめします。上記の方法をとることで、コンテナそのものからデータを取り除きます。データの損失を心配せずに、いつでもコンテナを正常にシャットダウンしたり破棄したりできます。コンテナがその存続期間を通して変更されないことを意味します。更新されることも、パッチを適用されることも、構成が変更されることもありません。コードを更新したり、パッチを適用したりする必要がある場合は、新しいイメージを作成して再デプロイします。不変性は、デプロイをより安全で、より繰り返しやすいものにします。ロールバックする必要がある場合は、単に古いイメージを再デプロイすればよいだけです。イメージをデプロイして、可能な限り同一のデプロイにできます。オプションなど)を外部化することをおすすめします。通常、コンテナを構成するには、環境変数または特定のパスにマウントされた構成ファイルを使用します。構成を更新する必要がある場合は、更新した構成を使用して、(同じイメージに基づく)新しいコンテナをデプロイします。この組み合わせにより、デプロイを自動化して、デプロイを繰り返しやすくするとともに信頼性を向上させることができます。ユーザーとしてアプリケーションを実行しないでください。その理由は単純で、アプリケーションが不正侵入された場合、攻撃者がサーバーに対する完全アクセス権を入手することになるためです。同様の理由から、特権付きコンテナを使用することは避けてください。特権付きコンテナとは、ホストマシンのすべてのデバイスに対するアクセス権を持ち、コンテナのほぼすべてのセキュリティ機能をバイパスするコンテナのことです。特権付きコンテナを使用する必要があると思われる場合は、次の代替手段を検討してください。フラグを使用して、コンテナに固有の機能を与えます。ドキュメントに、デフォルトで有効になっている機能と、明示的に有効にする必要がある機能の両方がリストされています。コンテナまたは初期コンテナ内で、ホストの設定を変更します。アプリケーションとは異なり、これらのコンテナは内部トラフィックにも外部トラフィックにも公開する必要がないため、分離を強化できます。変更する必要がある場合は、専用のアノテーションを使用します。使用して特権付きコンテナを禁止できます。これにより、ポッドに対して特定の要件を適用できます。クラスタで、これらの要件に違反するポッドを作成することはできません。高ロギングと同様に、モニタリングもアプリケーションの管理に不可欠な部分です。多くの点で、コンテナ化アプリケーションのモニタリングは、コンテナ化されていないアプリケーションをモニタリングする場合と同じ原則に従います。システムを再構成する余裕はありません。モニタリングとは、エンドユーザーであるかのように外部からアプリケーションを調べることを意味します。モニタリングが役立つのは、最終的に提供しようとしているサービスが利用可能で、機能している場合です。モニタリングはインフラストラクチャの外部から行うため、従来型のインフラストラクチャとコンテナ化されたインフラストラクチャを区別しません。モニタリングとは、ある種の特権アクセスを使用してアプリケーションを調べ、エンドユーザーには見えないアプリケーションの動作に関する指標を収集することを意味します。モニタリングでは、インフラストラクチャの最も深くにあるレイヤを調べる必要があるため、従来型のインフラストラクチャとコンテナ化されたインフラストラクチャを明確に区別します。ポッドで収集する指標は、特定の形式でなければなりません。モニタリングできます。有効にする方法をご覧ください。示します(画像をクリックすると、大きいバージョンの画像を表示できます)。形式の指標を公開する必要があります。つの方法について説明します。エンドポイントは、後述のアプリケーションの状態を公開するで取り上げるエンドポイントと同じように機能します。次のようなレスポンスが返されます。ラベル、右端の数値がこれらのラベルに対応する指標の値です。エンドポイントを簡単に生成できます。(他の多くの機能と併せ)この形式を使用した指標を公開できます。このエンドポイントは、公共のインターネットには公開しないでください。ドキュメントで詳しく説明しています。エンドポイントでインストゥルメントできるわけではありません。パターンを使用することをおすすめします。コンテナを使用してアプリケーションのログを管理する方法を説明しました。それと同じパターンをモニタリングにも使用できます。システムで認識できる形式とプロトコルに指標を変換するという仕組みです。Extensions(JMX)について見ていきましょう。使用して指標を公開します。エンドポイントを介して公開します。エンドポイントの公開が制限されるという利点もあります。本番環境でのアプリケーションの管理を容易にするためには、アプリケーションがその状態をシステム全体に伝える必要があります。アプリケーションが実行されているのか、正常な状態なのか、トラフィックを受信できる状態なのか、どのように動作しているのかといった情報です。つのタイプのヘルスチェックを使用できます。このセクションで説明するように、それぞれに特定の用途があります。ポートをチェックするなど)。エンドポイントを使用することです。ドキュメントをご覧ください。このセクションに記載されたパスは、慣例的なものです。エンドポイントの実際のパスは、アプリケーションによって異なります。エンドポイントを公開することです。OK」レスポンスを送信すれば、アプリケーションは正常です。おける「正常」の意味は、コンテナを強制終了したり再起動したりする必要がないということです。正常と見なされるための要素はアプリケーションによって異なりますが、通常は次のことを意味します。エンドポイントを公開することです。OK」レスポンスを送信すれば、アプリケーションはトラフィックを受信できる状態です。トラフィックを受信できる状態とは、次のことを意味します。準備完了プローブを使用してアプリケーションのデプロイをオーケストレートします。そのデプロイに属するポッドのローリング更新を行います。は新しいポッドの準備ができるまで待ってから(準備ができると準備完了プローブで示されます)、次のポッドの更新を行います。エンドポイントに結合されます。これは、正常な状態と準備完了状態の間に実質的な違いがないためです。中コンテナは分離を確保します。コンテナ内のプロセスは、ホストマシンや他の連結コンテナからの情報にアクセスできません。コンテナはホストマシンのカーネルを共有するため、このブログで説明しているように、仮想マシンでの分離ほど完全な分離ではありません。カーネル自体で)脆弱性を見つけて、その脆弱性を悪用してコンテナからエスケープすることはできます。してアクセスする恐れがあります。してプロセスを実行しないことです。ユーザーを指定します。命令をオーバーライドします。実際には、いくつかの課題があります。して実行しないようにするには、不明の非特権ユーザーで実行できるようにコンテナを設計します。多くの場合、さまざまなフォルダに対する権限を調整する必要が生じます。与えることができます。コンテナがこのおすすめの方法に準拠しているかどうかを確認する簡単な方法は、次のように、ランダムなユーザーを使用してローカルでコンテナを実行し、コンテナが正常に動作するかどうかをテストすることです。使用しているコンテナ名で置き換えてください。グループに与えることができます。この構成により、外部ファイルの所有権の問題が解決されます。未満のポートにバインドすることはできません。通常、これが問題になることはありません。サービスを構成できるためです。リダイレクトするように構成できます。デプロイされるイメージとして使用する場合も、使用するイメージのタグを選択する必要があります。公開イメージと非公開イメージのほとんどは、コンテナ構築のおすすめの方法で説明しているようなタグ付けシステムに従います。バージョニングに近いシステムを使用している場合、考慮しなければならないタグ付けの詳細がいくつかあります。重要な点として、「latest」タグはイメージの間で頻繁に移し替えられることがあります。そのため、このタグに頼って予測可能または再生可能なビルドを行うことはできません。生成される可能性があります。代わりに、次のように改訂したバージョンを明記することを検討してください。基づくイメージがビルドされるようになります。バージョンも同梱されているため、ビルドされるイメージをより詳細に制御できます。この結果は、ビルド時だけではなく、実行時にも当てはまります。使用するバージョンが保証されません。する可能性があります。されるまでの間に更新されていると、ノードが実行するイメージが異なる可能性があります(これらすべてのイメージには、ある時点でいずれも「latest」タグが付けられます)。行では常に不変のタグを使用してください。不変のタグを使用すれば、常に再現可能なビルドになります。これにはセキュリティに関するトレードオフが伴います。パッチの適用を自動化しにくくなるという点です。バージョン(つまり、「X.Y.Z」の「Z」)では下位互換性が維持された形で変更が行われるはずです。「X.Y」タグを使用して、自動的にバグ修正を行うことができます。内のタグは、完全に不変であるわけではありません。イメージの所有者がタグを変更しようと思えば変更できます。実際のところ、「X.Y.Z」タグはほとんど常に不変です。「SuperSoft」という名前のソフトウェアがあるとします。バージョンによって脆弱性が修正されます。ファイルを作成するとします。リリースしたとします。更新する必要があります。最終的には、使用する外部イメージごとのタグ付けシステムを慎重に調べ、これらのイメージの作成者をどれだけ信頼するか、そしてどのタグを使用するかを決定しなければなりません。次のステップコンテナ構築のおすすめの方法について学習する。最初のコンテナを作成する。クラスタをスピンアップする。環境の準備について学習する。社独自のおすすめの方法について学習する。その一部はこのドキュメントで取り上げていますが、取り上げていないものもあります。チュートリアルをご覧ください。