コンテナベースのアプリケーションを設計するための7つの原則

昨年の終わりに、Red Hat は、コンテナ化されたアプリケーションがクラウドの世界の不可欠な部分になるために従うべき原則を概説するレポートを公開しました 。「これらの原則に従うことで、Kubernetesなどのクラウドプラットフォームでアプリケーションを自動化する準備が整います「Red Hatによると。 そして、私たちはこの文書を研究した結果、彼らの結論に同意したため、ロシア語を話すITコミュニティと共有することにしました。







この記事は、Red Hatのアーキテクトであり、いくつかのApacheプロジェクトに積極的に参加しており、Camel Design PatternsおよびKubernetes Patternsの著者であるBilgin Ibryamが作成した元の文書（ PDF ）の逐語的な翻訳ではありませんが、主なポイントを提示していることに注意してくださいかなり無料のプレゼンテーションで。



原則として、クラウドベース（クラウドネイティブ）アプリケーションでは、障害が予見され、基盤となるインフラストラクチャに問題が発生している場合でも機能とスケーリングが可能です。 これを可能にするために、そのようなアプリケーションを実行するように設計されたプラットフォームは、それらで起動されるアプリケーションに特定の義務と制限を課します。 要するに、アプリケーションはコンテナに入れて実行するだけでは十分ではありません。Kubernetesのようなプラットフォームで効率的にオーケストレーションを行うには、追加の作業が必要です。 彼らはどんな人ですか？

クラウドネイティブアプリケーションへのRed Hatアプローチ

ここで提案されているアイデアは、他のさまざまな作品に触発されています（例：

Twelve-Factor App ）、ソース管理からアプリケーションスケーラビリティモデルまで、多くの分野をカバーしています。 ただし、ここで説明する原則の範囲は、Kubernetesなどのクラウドネイティブプラットフォーム向けのマイクロサービスベースのコンテナー化アプリケーションの設計に限定されます。



すべての原則の説明では、コンテナイメージがメインプリミティブとして使用され、コンテナオーケストレーションプラットフォームが起動のターゲット環境として使用されます。 これらの原則に従うことは、コンテナが（それらに従って準備された）ほとんどのオーケストレーションエンジン、つまり スケジューラによって提供され、自動的にスケーリングおよび監視されます。 原則は、（優先順位ではなく）ランダムにリストされています。

1.単一懸念原則（SCP）

多くの点で、SCPはSOLIDの単一責任原則（SRP）に似ています。これは 、各クラスに1つの責任が必要であることを示しています。 SRPの背後にある動機-クラスの変更につながる理由は1つだけです。



「懸念」という言葉（「懸念」、「懸念」、「関心」、「タスク」と訳される）は、 懸念が責任よりも高い抽象化レベルであることを強調します。これは、コンテナのタスクの範囲をよりよく表します（クラスと比較）。 SRPの主な動機が変更の唯一の理由である場合、SCPの場合、コンテナイメージとその交換可能性を再利用できます。 1つのタスクを担当するコンテナを作成し、それを完全に解決すると、他の状況でこのイメージを再利用する可能性が高くなります。



一般に、SCPの原則は、各コンテナが単一の問題を解決し、それをうまくやらなければならないことを示しています（UNIX哲学からの古典-DOTADIW 、「1つのことをして、それをうまくやる」- 約 。 マイクロサービスが多くの問題を担当する必要がある場合、サイドカーやinitコンテナーなどのパターンを使用して、多くのコンテナーを単一のデプロイ可能なプラットフォーム（下）に結合し、各コンテナーが単一のタスクに関与し続けることができます。

2.高可観測性原理（HOP）

コンテナは、アプリケーションをパッケージ化して実行するための統一された方法であり、アプリケーションをブラックボックスに変えます。 ただし、コンテナは、実行する環境にアプリケーションプログラミングインターフェイス（API）を提供する必要があり、コンテナの状態と動作を監視できるようにします。 これは、コンテナの更新を自動化し、ライフサイクルを維持するための前提条件です。



実用的な観点から、コンテナ化されたアプリケーションは、少なくとも（少なくとも！）状態のさまざまなチェックのためのAPIを提供する必要があります： 活性 （操作性）と準備 （サービス要求に対する準備）。 さらに良いことに、アプリケーションのステータスを監視する他の方法が提供されている場合-特に、FluentdやLogstashなどのユーティリティを使用した重要なイベントをSTDERRおよびSTDOUTに記録し、メトリックを構築するためのツールとの統合：OpenTracing、Prometheusなど







結論は次のとおりです。アプリケーションをブラックボックスとして扱いますが、プラットフォームがアプリケーションを監視し、可能な限り管理するために必要なすべてのAPIを実装します。

3.ライフサイクル適合性原則（LCP）

HOPがプラットフォームが「読み取る」ことができるAPIの提供について話す場合、LCPは裏返しです。アプリケーションはプラットフォームからのイベントについて学習できるはずです。 さらに、それらについて学ぶだけでなく、それらに対応することも、この原則の名前の由来です（「適合」は「適合」、「同意」、「規則に従う」と訳されます） 。



管理プラットフォームには、コンテナのライフサイクルの管理に役立つ多くのイベントを含めることができますが、一部のイベントは他のイベントよりも重要です。 たとえば、プロセスを正しく完了するには、アプリケーションが適切なシグナル（SIGTERM）でメッセージを受信して​​、SIGKILLを介した作業の緊急終了を回避する必要があります。 他にも重要なイベントがあります。たとえば、PostStartやPreStopは、操作の開始時にアプリケーションを「ウォームアップ」するか、逆に終了時にリソースを解放するために必要です。

4.イメージ不変性の原則（IIP）

コンテナ化されたアプリケーションでは、不変性が定められています。それらは一度収集された後、異なる環境で変更なしに起動されます。 これは、作業で使用されるデータを保存するための外部ツールの使用、および異なる環境用のさまざまな構成の作成/適用を意味します。 コンテナ化されたアプリケーションの変更は、すべての環境で使用される新しいコンテナイメージのアセンブリにつながるはずです。 不変インフラストラクチャと呼ばれる同じ原則が、サーバーインフラストラクチャの管理に使用されます。

5.プロセスの使い捨ての原則（PDP）

コンテナ化されたアプリケーションに切り替える主な理由の1つは、コンテナの寿命をできるだけ短くし、いつでも別のコンテナと交換できるようにすることです。 コンテナを置き換える多くの理由があります：状態の確認、アプリケーションのスケールダウン、別のホストへの移行、リソースの不足...



したがって、コンテナ化されたアプリケーションは、状態を分散および冗長に保つ必要があります。 さらに、アプリケーションは迅速に開始および停止する必要があり、突然の（そして完全な）ハードウェア障害に備えてさえ準備する必要があります。 この原則を実装するもう1つの優れた方法は、次のように小さなコンテナを作成することです コンテナは異なるホストで自動的に起動され、サイズが小さいと起動時間が短縮されます（最初にホストシステムに物理的にコピーする必要があるため）。

6.自己抑制原則（S-CP）

コンテナには、Linuxカーネルの存在のみに依存して、アセンブリ時に必要なものがすべて含まれている必要があります（すべての追加ライブラリは、アセンブリ時に「表示」されます）。 これは、ライブラリに加えて、実行可能なプログラミング言語環境、アプリケーションプラットフォーム（使用する場合）、およびコンテナ化されたアプリケーションを実行するためのその他の依存関係を含める必要があることも意味します。 唯一の例外は、環境によって異なる設定であり、起動時に提供する必要があります（たとえば、KubernetesのConfigMap



）。







一部のアプリケーションは、多くのコンテナ化されたコンポーネントで構成されています。 たとえば、コンテナ化されたWebアプリケーションでは、データベースを含むコンテナが必要になる場合があります。 この原則は、コンテナを結合することを提供していません。データベースを備えたコンテナだけがその操作に必要なすべてを備え、Webアプリケーションを備えたコンテナはWebアプリケーション（Webサーバーなど）のすべてを備えている必要があります。

7.ランタイム制限の原則（RCP）

S-CPの原則では、アセンブリ時間と結果のバイナリの内容の観点からコンテナを考慮しますが、コンテナはディスク上にある1次元のブラックボックスではありません。 コンテナのその他の「測定値」は、起動時に表示されます-これらは、メモリ、プロセッサ、その他のリソースの消費量の「測定値」です。







コンテナはリソース要件を宣言し、この情報をプラットフォームに送信する必要があります。これは、CPU、メモリ、ネットワーク、ディスクに対するリクエストがプラットフォームの計画、自動スケーリング、リソース管理の実行に影響し、コンテナの一般的なSLAレベルを提供するためです。 さらに、アプリケーションがそれに割り当てられたリソースに適合することが重要です。 リソースが不足している場合、プラットフォームはそのようなコンテナを停止または移行する可能性が低くなります。

その他の推奨事項

これらの原則に加えて、コンテナに関連する基本的ではないが、それでも有用なことが多いプラクティスが提案されています。

• 小さい画像を探します。 一時ファイルを削除し、不要なパッケージをインストールしないでください。 これにより、コンテナーのサイズだけでなく、ビルド時間、およびイメージをコピーするときにネットワーク経由でデータを転送するのにかかる時間も削減されます。
• UIDをサポートします。 sudoコマンドを使用したり、特定のユーザー/ UIDを使用してコンテナーを起動したりすることは避けてください。
• 重要なポートをマークします。 EXPOSE
  
  
  
  コマンドでラベルを付けると、人とソフトウェアの両方でイメージを簡単に使用できます。
• 永続的なデータにボリュームを使用します（コンテナの破棄後も保持する必要がある）。
• タグ、ラベル、注釈を使用して、画像のメタデータを定義します。 これにより、開発者による今後の使用が簡素化されます。
• ホストとイメージを同期します。 コンテナ化されたアプリケーションの中には、特定の属性（時間やマシンIDなど）のためにホストと同期する必要がある場合があります。

トピックに関するパターンとベストプラクティスに関する追加リソースへのリンク：

• コンテナパターン （マティアスリュープケン） ;
• Dockerfiles （Docker） を作成するためのベストプラクティス
• コンテナのベストプラクティス （プロジェクトアトミック） ;
• OpenShift Enterprise 3.0イメージ作成ガイドライン （Red Hat） ;
• コンテナベースの分散システムの設計パターン （Brendan Burns、David Oppenheimer） ;
• Kubernetes Patterns （Bilgin Ibryam、RolandHuß） ;
• 12因子アプリ （Adam Wiggins）

翻訳者からのPS

これらの原則の一部-特に、「すべてを支配する1つのイメージ」と呼ばれる画像不変性原則（IIP）、および自己抑制原則（S-CP）は、レポート「 ベストCI / KubernetesとGitLabを収録したCD 」 （リンクテキストスクイーズとフルビデオ） 。



ブログもご覧ください。

• 「 2018年のマイクロサービスマッドネスの死 」
• 「 クラウドネイティブ向けのオープンソースソリューション（およびその他）のCNCFガイド 」;
• 「 何人の開発者が継続的インテグレーションは必要ないと考えていますか？ ";
• 「 小規模プロジェクトでのKubernetesでの経験 」 （ビデオレポート、Kubernetes技術デバイスの紹介を含む）。