クラウドネイティブを語る上で「コンテナ化」は避けて通れない

[[381346]]

この記事はWeChatの公開アカウント「Full-Stack Coder Portrait」から転載したもので、著者はXiaomajiaです。この記事を転載する場合は、Full-Stack Coder Portrait の公開アカウントにご連絡ください。

コンテナ

クラウドネイティブについて語るとき、「コンテナ」を避けることはできません。

『Cloud Native Patterns』という本の中で、著者の Cornelia Davis は次のように指摘しています。「コンテナーはクラウドネイティブアプリケーションの基礎です。」

Cloud Native Foundation は、クラウドネイティブへの第一歩としてマイクロサービスのコンテナ化を推進しています。

マイクロサービスをコンテナ化することは考えやすく、プロセスもシンプルです。

コード、依存関係、ランタイムは、コンテナイメージと呼ばれる単一のバイナリファイルにパッケージ化されます。画像はイメージリポジトリに保存されます。 Docker は Docker Hub イメージリポジトリを公式に管理しています。

必要に応じて、イメージを、コンテナランタイムエンジンがインストールされている任意のコンピューターで実行できる実行可能なコンテナインスタンスに変換し、オンデマンドで任意の数のコンテナインスタンスをデプロイできます。

次の図は、単一のホスト上のコンテナで実行されている 3 つのマイクロサービスを示しています。

各コンテナは独自の依存関係とランタイムを維持しますが、それらは異なる場合があります。上の図では、同じホスト上で実行されている Product マイクロサービスの異なるバージョンがわかります。各コンテナは、基盤となるホストオペレーティングシステム、メモリ、プロセッサの一部を共有しますが、互いに分離されています。

コンテナモデルは、「12 要素アプリ」の依存関係の原則に準拠しています。

要素 2 では、「各マイクロサービスは独自の依存関係を分離してパッケージ化し、それらを変更する (システム全体に影響を与えずに)」と規定されています。

コンテナーは Linux と Windows の両方のワークロードをサポートします。

コンテナベンダーは複数存在しますが、Dockerはクラウドネイティブアプリケーションのパッケージ化、展開、実行における事実上の標準となり、最大の市場シェアを誇り、ソフトウェアコンテナの開発を推進してきました。

コンテナの理由

コンテナは移植性を提供し、環境間で一貫した出力を保証します。すべてを 1 つのパッケージにカプセル化することで、マイクロサービスと依存関係をインフラストラクチャから分離できます。
Docker ランタイムエンジンがインストールされている任意の環境に同じコンテナーをデプロイできます。コンテナ化により、環境 (フレームワーク、ライブラリファイル、ランタイム) を事前に構成するための時間のオーバーヘッドが排除されます。
基盤となるオペレーティングシステムとホストリソースを共有することにより、コンテナーは完全な仮想マシンよりもはるかに少ないスペースを占め、サイズが小さく高密度になり、単一のホスト上で複数のマイクロサービスを実行できます。

コンテナオーケストレーション

Docker API/ツールはイメージとコンテナを作成しますが、コンテナを管理するためのツールも必要です。

コンテナを管理するソフトウェアは「コンテナオーケストレーター」と呼ばれ、大規模にコンテナを使用する場合に重要です。

コンテナオーケストレーターは何をするのですか?

タスク	説明する
スケジュール	コンテナインスタンスを自動的に構成およびスケジュールする
親和性/反親和性	コンテナを近くまたは遠くの場所にデプロイして可用性とパフォーマンスを向上させる
健康モニタリング	障害を自動的に検出して修復する
フェイルオーバー	障害が発生したインスタンスを正常なマシンに自動的に転送する
スケーリング	予想される状態に合わせてコンテナを自動的に増減します
ネットワーキング	コンテナにオーバーレイネットワークを提供する
サービス検出	コンテナはお互いを発見する
ローリングアップグレード	ゼロダウンタイムの増分アップグレードとゼロダウンタイムの自動ロールバック