高可用性を実現するためのDockerSwarm

Docker Swarmに関するこのブログでは、高可用性を実現するために、構成済みのDockerSwarmを介してDockerエンジンのクラスターをセットアップする能力について説明しています。

Webベースのアプリケーションの最も重要な機能は何ですか?たくさんありますが、私にとっては 高可用性 最も重要です。それがDockerSwarmが私たちの達成に役立つことです!これは、アプリケーションの可用性を高めるのに役立ちます。

私の中で 前のブログ 、DockerComposeがどのように機能するかを説明しました。 Docker Swarmに関するこのブログは前者の続きであり、ここでは、マルチコンテナーアプリケーションをコンテナー化するためにDockerSwarmを使用する利点について説明しました。





このブログの場合、DockerSwarmが使用されるのはAngularアプリケーションのみです。
注意 :MEANStackアプリをコンテナ化する方法は同じです。

では、Docker Swarmとは何ですか?

DockerSwarm のクラスターを作成および維持するための手法です Dockerエンジン Dockerエンジンはさまざまなノードでホストでき、リモートロケーションにあるこれらのノードは 集まる スウォームモードで接続した場合。



DockerSwarmを使用する理由

すでに述べた理由で!達成 高可用性 ダウンタイムがないことは、そこにあるすべてのサービスプロバイダーにとって優先事項です。高可用性はクライアントに印象を与えますか?ええと、彼らがダウンタイムに直面しても、彼らは感銘を受けません。それは簡単です。

DockerSwarmのその他の利点

他の多くのサービスと同様に、DockerSwarmは自動で実行します 負荷分散 私たちのために。したがって、DevOpsエンジニアは、ノードが失敗したときに処理要求を他のノードにルーティングする必要はありません。クラスタのマネージャが自動的に負荷分散を実行します。

分散型アクセス もう1つの利点です。どういう意味ですか?これは、マネージャーからすべてのノードに簡単にアクセスできることを意味します。また、マネージャーは定期的にノードにプロンプ​​トを表示し、ダウンタイムに対処するためにノードのヘルス/ステータスを追跡します。ただし、ノードは他のノード/マネージャーで実行されているサービスにアクセスしたり追跡したりすることはできません。



番号を確認できます。ノードで実行されているコンテナの数、 拡大する いいえ。コンテナのまたは スケールダウン いいえ。要件に基づいて、1つのコマンドを実行するだけです。

アプリケーションがデプロイされた後でも、発行できます ローリングアップデート CI(継続的インテグレーション)が達成されていることを確認します。ローリング更新は次々にノードに発行されるため、ダウンタイムが発生せず、クラスター内の他のノード間で負荷が分散されます。

それで、次は何ですか?明らかなことをする。すでにDockerに取り組んでいる場合、または組織が信頼性の高いWebサービスをコンテナー化することを希望している場合は、DockerSwarmを使い始めてください。

注意 :Dockerエンジンは、独立したホスト/サーバーまたはホスト内の複数のVMにインストールされます。

スウォームモード入門

Docker Swarmはマネージャーによって開始されます。つまり、このように言えば、Swarmクラスターを開始するインスタンスがマネージャーになります。クラスターを開始するコマンドは次のとおりです。

$ docker swarm init --advertise-addr ip-address

ここで、「– advertise-addr」フラグは、クラスターに参加したい他のノードに自分自身をアドバタイズするために使用されます。マネージャのIPアドレスは、フラグとともに指定する必要があります。以下はサンプルのスクリーンショットです。

dockerinitコマンド-dockerswarm-edureka

Swarmクラスターが開始されると、マネージャーの側でトークンが生成されます。このトークンは、群れクラスターに参加するために他のノードによって使用される必要があります。

正確にはどうですか?マネージャーのDockerエンジンで生成されたトークン全体をコピーし、ノードのDockerエンジンに貼り付けて実行します。上のスクリーンショットで強調表示されている部分はトークンです。トークンがワーカーノードで実行されると、次のスクリーンショットのようになります。

DevOpsのPuppetとは

クラスターに参加するノードは、後でマネージャーに昇格できます。 Dockerエンジンをマネージャーとして参加させる場合は、マネージャーの最後で次のコマンドを実行します。

$ docker swarmjoin-tokenmanager

その後、ノードのトークンをクラスターに参加させたい場合は、以下のコマンドを実行します。

$ docker swarmjoin-tokenノード

先に進み、必要なすべてのノードでトークンを実行して、クラスターに参加します。すべてが完了したら、docker node listコマンドを実行して、クラスターに参加しているノードの数とそのステータスを確認できます。コマンドは次のとおりです。

$ docker node ls

スクリーンショットは以下のとおりです。

AngularアプリのDockerイメージの作成

すべてが順調であれば、Docker Imageがビルドされていれば、Swarmサービスを開始できます。 DockerイメージはDockerfileから構築できます。アプリケーションのビルドに使用されるDockerfileは次のとおりです。

FROMノード:6RUN mkdir -p / usr / src / app WORKDIR / usr / src / app COPY package.json / usr / src / app RUN npm cache clean RUN npm installCOPY。 / usr / src / app EXPOSE 4200 CMD ['npm'、 'start']

Dockerfileは、ベースイメージからカスタムDockerイメージを構築するための一連のコマンドを一緒に実行するために使用されます。ご覧のとおり、私が使用したベースイメージは「Node:6」です。 NodeJSは、バージョン6でタグ付けされたDockerHubのイメージIです。

次に、コンテナ内に新しいDockerディレクトリを作成し、それをコンテナ内の作業ディレクトリにします。

「package.json」ファイルをローカルマシンからコンテナの作業ディレクトリにコピーしています。次に、「RUN npmcacheclean」コマンドと「RUNnpminstall」コマンドを指定しています。 npmインストール コマンドは、package.jsonファイルに記載されている依存関係のバージョンをダウンロードします。

次に、すべてのプロジェクトコードをローカルマシンからコンテナーにコピーし、ブラウザーでAngularアプリケーションにアクセスするためのポート番号4200を公開し、最後に、アプリケーションをコンテナー化するnpmstartコマンドを指定します。

ここで、このDockerfileに基づいてDockerイメージを作成するには、次のコマンドを実行します。

$ docker build -tangular-image。

注意: Dockerイメージは、クラスター内のすべてのノードに組み込む必要があります。これがないと、他のDockerエンジンでコンテナーをスピンできません。

Rプログラミング言語を使用している企業

DockerSwarmサービスの開始

Dockerイメージが構築されているとすると、このイメージからコンテナーをスピンアウトできます。しかし、もっと良いことをします。それからDockerSwarmサービスを作成します。スウォームサービスを作成するコマンドは次のとおりです。

$ docker service create --name'Angular-App-Container '-p 4200:4200angular-image

ここで、「name」フラグはサービスに名前を付けるために使用され、「p」フラグはコンテナポートをホストポートに公開するために使用されます。 package.jsonファイルで、Angularアプリをホストするコンテナーポートを指定しました。また、このコマンドの4200は、コンテナのポート4200をホストのポート4200にマップするのに役立ちます。「angular-image」は、以前に作成したイメージの名前です。

覚えておいてください :サービスを作成すると、クラスター内の任意のDockerエンジンでホストできます。群れのマネージャーは、それがホストされる場所を決定します。ただし、ホストされているノードに関係なく、クラスターに接続されている任意のノードからlocalhost:4200でアプリケーションにアクセスできます。

そんなことがあるものか? Swarmは、クラスター内の他のすべてのノードがアクセスできるようにポート番号を内部的に公開しているためです。つまり、ポート番号です。クラスター内の任意のノード/マネージャー上の4200は、Angularアプリケーションをレンダリングします。

それで?コンテナはアクティブですか?

docker service listコマンドを実行すると、サービスがコンテナ化されているかどうかを確認できます。ただし、コンテナがデプロイされるまでに1分かかる場合があります。以下はコマンドです:

$ docker service ls

このコマンドは、Swarmクラスターによって管理されているすべてのサービスを一覧表示します。この場合、1つのアクティブなコンテナが表示されます。以下のスクリーンショットを参照してください。

ここで、「REPLICAS = 1/1」は、クラスター内にそのコンテナーの単一の「サービス」があることを示します。また、「MODE = Replicated」は、サービスがクラスター内のすべてのノードに複製されることを示します。

ここで、アプリがホストされているノード/マネージャーを特定するために、コマンドdocker servicepsコマンドを実行してからコンテナー名を実行できます。コマンドは次のとおりです。

$ docker service ps Angular-App-Container

同じもののスクリーンショットは以下のとおりです。

これは、アプリケーションがホストされているノードの詳細と、サービスの開始に使用されるコマンドについて説明しています。

「dockerps」コマンドは、アクティブなコンテナに関する詳細に光を当てます。コマンドは次のとおりです。

$ docker ps

以下のスクリーンショットを参照してください。

ただし、このコマンドは、クラスターマネージャーとサービスが実際にホストされているノードでのみ機能します。

実行中のノードの数を確認するには、nodelistコマンドを実行します。コマンドは次のとおりです。

$ docker node ls

特定のホストで実行されているコンテナーを確認するには、nodepsコマンドを実行します。コマンドは次のとおりです。

$ docker node ps

覚えているかと思いますが、サービスは現在レプリケートモードで実行されていると前述しました。これは、サービスがクラスター内のすべてのノードに複製されることを意味します。代替案があると思いますか?

絶対に!グローバルモードと呼ばれるものがあります。このモードでは、クラスター内のすべてのシングル/マネージャーで実行されているこのコンテナーのサービスがあります。別のコンテナセットをスピンする前に、現在のサービス/コンテナを停止することを忘れないでください。

そのためのコマンドは次のとおりです。

$ docker service rm Angular-App-Container

グローバルモードでコンテナを回転させるコマンドは次のとおりです。

$ docker service create --name'Angular-App-Container '-p 4200:4200 --mode global angle-image

これにより、クラスター内の3つのノードに3つのサービスが作成されます。 docker servicelistコマンドを実行して確認できます。このスクリーンショットは以下のとおりです。

docker service psコマンドを実行すると、次のように表示されます。

ご覧のとおり、モードが複製され、このコンテナーのレプリカは3であると表示されます。これで、このブログの最良の部分が表示されます。

3つのコンテナー間でサービスの2つのレプリカを実行するには、レプリカフラグを使用できます。以下のコマンドを見てください。

$ docker service create --name'Angular-App-Container '-p 4200:4200 --replicas = 2angular-image

これらの2つのサービスは、クラスター内の3つのノード間で負荷分散されていることがわかります。 docker service processコマンドを実行して、コンテナーがアクティブになっているノードを確認します。以下のスクリーンショットを参照してください。コンテナーは、1つのマネージャーノードと1つのワーカーノードでアクティブになります。

例を挙げたJavaの抽象化とは

ワーカーノードから、「docker ps」コマンドを実行して、コンテナが実行されていることを確認できます。

高可用性のためのDockerSwarm

ここで、クラスターに高可用性があることを実際に確認するには、ノードの1つがダウンし、クラスター内の他のノードがそれを補うシナリオを体験する必要があります。次のコマンドを使用して、ノードの1つからコンテナを手動で停止することにより、このシナリオを実現できます。

$ docker stop Angular-App-Container

コンテナが実行されているノードWorker-1で上記のコマンドを実行します。マネージャから、次のコマンドを実行します。

$ docker service ps Angular-App-Container

これで、コンテナーがノードWorker-2とManagerで実行されていることがわかります。ただし、ノードWorker-1からシャットダウンされています。以下のスクリーンショットからも同じことがわかります。

こうやって Dockerの高可用性 が達成された。私nワーカー1でコンテナーが非アクティブであるにもかかわらず、アプリケーションはそのワーカーノードのポート番号4200でレンダリングできます。これは、クラスター内の他のノードに内部的に接続されており、ブラウザーでアプリケーションをレンダリングできるためです。

サービスをスケールアップした後の高可用性

レプリケートモードでもグローバルモードでも、クラスターで実行されているサービスの数を増やすことができます。また、スケールアップした後でも、高可用性を維持することができます。すごいですね。

しかし、ポイントに戻って、クラスター内のサービスの数をスケールアップすることがいかに簡単であるかを見てみましょう。クラスターに2つまたは3つのレプリカがあると仮定して、1つのコマンドを実行するだけでサービスを5つにスケールアップしましょう。コマンドは次のとおりです。

$ docker service scale Angular-App-Container = 5

このスクリーンショットは以下のとおりです。

docker service listコマンドを実行すると、レプリカの数が5になっていることがわかります。また、サービス名と一緒にdocker service psコマンドを実行すると、5つのサービスが3つのノードでどのように負荷分散および分散されているかを確認できます。 。コマンドは次のとおりです。

$ docker service ls $ docker service psAngular-App-Container

そして最後に、Docker Swarmのセットアップで、マネージャーが手続きに参加せず、プロセスの管理のみに専念させたくない場合は、マネージャーがアプリケーションをホストするのをやめることができます。これが世界での仕組みだからですよね?マネージャーは他の労働者を管理するためだけのものです。とにかく、それを行うためのコマンドは次のとおりです。

$ docker node update --availabilitydrain Manager-1

docker nodelistコマンドとdockerservice psコマンドを実行して、マネージャーがクラスターに参加しているかどうかを確認できます。

$ docker node ls $ docker service psAngular-App-Container

これで、コンテナーサービスがワーカーノード間で分割され、マネージャーノードが実際にサービスのコンテナー化から排出されていることがわかります。スクリーンショットは以下のとおりです。

これで、DockerSwarmに関するこのブログは終了です。このブログで、高可用性を実現するためにSwarmモードを実装することがいかに重要であるかが説明されていることを願っています。このDockerチュートリアルシリーズのその他のブログにご期待ください。

または、以下のビデオを見て、DockerSwarmがどのように機能するかを理解することもできます。上で説明したすべての概念がビデオでカバーされています。

高可用性のためのDockerSwarm | Dockerチュートリアル| DevOpsチュートリアル

Dockerについて学習したので、 25万人以上の満足した学習者のネットワークを持つ信頼できるオンライン学習会社であるEdurekaが世界中に広がっています。このEdurekaDocker認定トレーニングコースは、学習者がDockerの実装と習得に関する専門知識を習得するのに役立ちます。

質問がありますか?コメント欄にご記入ください。折り返しご連絡いたします。