3年前、Dockerはコンテナ化と呼ばれる難解なLinuxカーネルテクノロジーをシンプルで誰もが利用できるようにしました。今日、私たちはコンテナオーケストレーションについても同じことを行っています。
コンテナー オーケストレーションは、コンテナーを 1 つのホストに個別にデプロイすることから、複雑なマルチコンテナー アプリを多数のマシンにデプロイすることに移行するために必要なものです。 これには、インフラストラクチャから独立した分散プラットフォームが必要であり、アプリケーションの存続期間全体を通じてオンラインを維持し、ハードウェア障害やソフトウェアの更新に耐えます。 オーケストレーションは、3年前のコンテナ化と同じ段階にあります。2つのオプションがあります:複雑なアドホックシステムをまとめるために技術専門家の軍隊を必要とするか、すべてのハードウェア、サービス、サポート、ソフトウェアを購入する限り、多くの専門家がいる会社に頼ってすべてを世話する必要があります彼らから。そのための言葉があります、それはロックインと呼ばれます。
Dockerユーザーは、どちらのオプションも受け入れられないことを私たちと共有しています。 代わりに、ロックインすることなく、誰もがオーケストレーションを使用できるようにするプラットフォームが必要です。 コンテナオーケストレーションは、プラットフォームに組み込まれていれば、実装が容易で、移植性が高く、安全で、回復力があり、高速になります。
Docker 1.12 以降、コア Docker エンジンに機能が追加され、マルチホストおよびマルチコンテナーのオーケストレーションが簡単になりました。 サービスやノードなどの新しい API オブジェクトが追加され、Docker API を使用して、スウォームと呼ばれる Docker エンジンのグループにアプリをデプロイおよび管理できるようになりました。 Docker 1.12 では、Docker をオーケストレーションする最良の方法は Docker です。
Docker 1.12 の設計は、次の 4 つの原則に基づいています。
- 簡単 それでも強力 – オーケストレーションは、最新の分散アプリケーションの中心的な部分です。それは非常に中心的であるため、コアDockerエンジンにシームレスに組み込まれています。 オーケストレーションに対する Microsoft のアプローチは、コンテナーに関する Microsoft の哲学に従っており、セットアップが不要で、少数の簡単な概念を学ぶだけで済み、ユーザー エクスペリエンスが "うまくいく" というものです。
- 回復力 – マシンは常に故障します。 最新のシステムでは、これらの障害が定期的に発生することを想定し、アプリケーションのダウンタイムなしで適応する必要があるため、単一障害点ゼロの設計が必須です。
- セキュア – セキュリティをデフォルトにする必要があります。強力なセキュリティに対する障壁 (証明書の生成、PKI を理解する必要がある) は取り除く必要があります。 ただし、上級ユーザーは、証明書の署名と発行のあらゆる側面を制御および監査できる必要があります。
- オプション機能と下位互換性 –何百万人ものユーザーがいるため、Docker Engineでは下位互換性を維持する必要があります。すべての新機能はオプションであり、使用しない場合、オーバーヘッド (メモリ、CPU) は発生しません。 Docker Engine のオーケストレーションは、プラットフォームのバッテリーが含まれていますが、交換可能なアプローチにより、ユーザーは Docker Engine 上に構築されたサードパーティのオーケストレーターを引き続き使用できます。
Docker 1.12の新機能がどのように機能するかを見てみましょう。
1つの分散型ビルディングブロックでスウォームを作成する
すべては、スウォーム(自己修復エンジンのグループ)を作成することから始まりますが、ブートストラップノードでは次のように簡単です。
ドッカースウォーム初期化
内部的には、これにより1つのノードの Raft コンセンサスグループが作成されます。 この最初のノードにはマネージャーの役割があり、コマンドを受け入れてタスクをスケジュールします。 より多くのノードをスウォームに参加させると、それらはデフォルトでワーカーになり、マネージャーによってディスパッチされたコンテナを実行するだけです。 オプションで、マネージャー ノードを追加できます。マネージャーノードはRaftコンセンサスグループの一部になります。 最適化されたRaftストアを使用して、読み取りがメモリから直接処理されるため、スケジューリングのパフォーマンスが高速になります。
サービスの作成とスケーリング
docker run を使用して 1 つのコンテナーを実行するのと同様に、docker サービスを使用してエンジンの群れでレプリケート、分散、負荷分散プロセスを開始できるようになりました。
ドッカーサービス作成–名前フロントエンド–レプリカ5 -p 80:80/tcp nginx:最新
このコマンドは、5つのnginxコンテナの群れで望ましい状態を宣言し、群れ内の任意のノードのポート80で単一の内部負荷分散サービスとして到達可能です。 内部的には、Linux カーネルに 15 年以上使用されているカーネル内レイヤー 4 マルチプロトコル ロード バランサーである Linux IPvs を使用して、この作業を行います。 カーネル内でIPVSルーティングパケットを使用すると、swarmのルーティングメッシュは高性能のコンテナ対応ロードバランシングを提供します。
サービスを作成するときに、必要に応じて、レプリケートされたサービスまたはグローバル サービスを作成できます。 レプリケートされたサービスとは、定義した任意の数のコンテナーが使用可能なホストに分散されることを意味します。対照的に、グローバルサービスは、スウォーム内のすべてのホストで1つのインスタンスに同じコンテナをスケジュールします。
Docker が回復性を提供する方法を見てみましょう。スウォームモード対応エンジンは自己修復機能があり、定義したアプリケーションを認識し、問題が発生したときに環境を継続的にチェックして調整します。たとえば、nginxインスタンスを実行しているマシンの1つを取り外すと、新しいコンテナが別のノードに表示されます。群れの中の半分のマシンのネットワークスイッチを抜くと、残りの半分が引き継ぎ、コンテナを再配布します。 更新については、変更を加えた後のサービスの再デプロイ方法を柔軟に行えるようになりました。 群れのコンテナのローリング更新または並列更新を設定できます。
100 インスタンスまでスケールアップしたいですか? それは次のように簡単です:
ドッカーサービススケールフロントエンド= 100
典型的な 2 層 (web+db) アプリケーションは、次のように作成されます。
ドッカーネットワーク作成-Dオーバーレイマイネット
ドッカーサービス作成–名前フロントエンド–レプリカ5 -p 80:80 / tcp \
–ネットワークマイネットマイウェブアプリ
Docker Service create –name redis –network mynet redis:latest
これは、このアプリケーションの基本的なアーキテクチャです。
セキュリティ
Docker 1.12 のコア原則は、Docker プラットフォーム用の既定のエクスペリエンスでセキュリティ保護された、ゼロ構成を作成することです。 管理者がアプリケーションを本番環境にデプロイする際によく直面する主なハードルの1つは、アプリケーションを安全に実行することですが、Docker 1.12を使用すると、管理者は安全な本番クラスターをセットアップするのとまったく同じ手順に従ってデモクラスターを設定できます。
セキュリティは、事後にボルトオンできるものではありません。 そのため、Docker 1.12には相互に認証されたTLSが付属しており、群れに参加しているすべてのノードの通信に認証、承認、暗号化をすぐに提供します。
最初のマネージャーを起動すると、Docker Engine によって新しい認証局 (CA) と一連の初期証明書が生成されます。 この最初のステップの後、スウォームに参加するすべてのノードには、ランダムに生成されたIDと、スウォームでの現在の役割(マネージャーまたはワーカー)を持つ新しい証明書が自動的に発行されます。 これらの証明書は、この群れに参加している間、暗号的に安全なノードIDとして使用され、タスクやその他の更新の安全な配布を確実にするためにマネージャーによって使用されます。
TLSの採用における最大の障壁の1つは、必要な公開鍵基盤(PKI)の作成、構成、および保守の難しさでした。 Docker 1.12 では、すべてが安全なデフォルトでセットアップおよび構成されるだけでなく、TLS 証明書の処理で最も面倒な部分の 1 つである証明書のローテーションも自動化されました。
内部的には、スウォームに参加しているすべてのノードが常に証明書を更新し、漏洩または侵害された可能性のある証明書が有効でなくなるようにします。 証明書をローテーションする頻度はユーザーが構成でき、30 分ごとに設定できます。
独自の認証局を使用する場合は、スウォーム内のマネージャがクラスタをリモート URL に参加させようとするノードの証明書署名要求を中継する外部 CA モードもサポートしています。
バンドル
Docker 1.12 では、 分散アプリケーション バンドル (実験的ビルドのみ) と呼ばれる新しいファイル形式が導入されています。バンドルは、フルスタックアプリケーションに焦点を当てたサービス上の新しい抽象化です。
Docker バンドル ファイルは、以下を義務付ける一連のサービスの宣言型仕様です。
- 実行する特定のイメージリビジョン
- 作成するネットワーク
- これらのサービス内のコンテナーを実行するためにネットワーク化する方法
バンドル ファイルは完全に移植可能であり、完全に仕様およびバージョン管理されたマルチコンテナー Docker アプリを出荷できるため、ソフトウェア配信パイプラインのデプロイ成果物として最適です。
バンドルファイルの仕様はシンプルでオープンであり、バンドルを好きなように作成できます。 作業を開始するために、Docker Compose にはバンドルファイルを作成するための実験的なサポートがあり、Docker 1.12 とスウォームモードを有効にすると、バンドルファイルをデプロイできます。
バンドルは、マルチサービス アプリを開発者のラップトップから CI 経由で運用環境に移動するための効率的なメカニズムです。 これは実験的なものであり、コミュニティからのフィードバックを求めています。
ドッカー1.12の内部
内部を見ると、Docker 1.12は他にも多くの興味深いテクノロジーを使用しています。ノード間通信は gRPCを使用して行われるため、接続の多重化やヘッダー圧縮などのHTTP/2の利点があります。 私たちのデータ構造は 、protobufsのおかげで効率的に送信されます。
Docker 1.12 に関する次の追加リソースを確認してください。
- ダウンロード Docker 1.12 for Docker for Mac または Windows
- チュートリアルをご覧ください: docs.docker.com/engine/swarm/swarm-tutorial/
- スウォームの詳細: docs.docker.com/engine/swarm/
- バンドルを試す: github.com/docker/docker/blob/master/experimental/docker-stacks-and-bundles.md
ドッカーについてもっと知る
- ドッカーは初めてですか? 10分間の オンラインチュートリアルをお試しください
- 無料の Docker Hub アカウントでイメージを共有し、ビルドを自動化します
- Docker 1.12 リリースノートを読む
- ドッカーウィークリーを購読する
- 今後の Dockerオンラインミートアップにサインアップする
- 今後の Docker ミートアップに参加する
- DockerCon EU 2015 のビデオを見る
フィードバック
0についての考え "Docker 1.12:組み込みのオーケストレーションが登場しました!"