🦆 ✋🏼 🧜🏼 Dockerを使用したルーティングサービスのトラブルシューティング 👶🏽 🎥 ✈️

Dockerを使用した方法は、サブビスのトラブルシューテング

「あなたを破るのは困難ではなく、あなたがそれらに耐える方法です」-ルー・ホルツ

Emmet O'Grady（NimbleCIとDocker Ninjaの創設者）の共著

フランツ・カフカの本「トランスフォーメーション」（「変身」）で、ある朝目覚めた人は、彼が巨大な昆虫のような生き物に変わったことを発見します。 DevOpsエンジニアとして、私たちは人生で同じ超現実的な瞬間を経験しています。エキゾチックなエラーを「敷物の下に」（最もアクセスできない場所に隠されている）見つけたり、ワームやその他の危険なエンティティに攻撃されたりします。これを十分長く行うと、遅かれ早かれ、ひどい物語、あるいは2つ（私たちと共有してください！）になります。そのような瞬間、危機が来るのを待つことはできません。迅速に行動しなければなりません。これをできるだけ早く修正するには、新しいエンティティを展開し、サービスの新しいバージョンをリリースして問題を修正する必要があります。
別の超現実的な瞬間はどうでしょうか。アプリケーションは、メディア、混雑したSlackチャンネル（チャット）、または社内掲示板で人気を博しています。ユーザーはあなたのサイトに素早く来て、あなたのサイトにはすぐに来ます、あなたのサービスはそれらでいっぱいです、ユーザーの数は制限に達し、さらにそれを超えます。エラー502を修正しようとする必死のレースでは、サーバーを見つけて新しいエンティティを起動し、ネットワークとロードバランサーを再構成する必要があります。あなたは必死にすべてのピースをまとめようとします。ナイフでスプーンで戦おうとしているように感じます。夢のようにあなたは思う：「それは自動化されるべきだ」、多分それから私はリラックスして古典を読むためにもっと時間があるでしょう。

このような感情をこれ以上経験しないでください！ Docker 1.12が役立ちます。このリリースには、次の条件を提供する多数の新機能が付属しています。

迅速な展開とロールバックサービス
自動負荷分散
サービスとそれらが動作するインフラストラクチャのスケーリングを可能にする
サービスまたは障害のあるノードを自動的に回復する

そして、Dockerが提供するものを学ぶと、使いやすくなります。

ルーティンググリッド

Docker 1.12は、新しい定義の完全なセットを提供します。その1つが「ルーティンググリッド」と呼ばれる新機能です。コンピュータネットワークのジオメトリとそのルーティングアルゴリズムは新しいものではありません。Dockerエンジニアリングチームの天才は、このアプローチを使用して、マイクロサービスアーキテクチャでのソフトウェア変更とディスカバリサービスの配信を簡素化することでした。「グリッド」は、Dockerのコンテナー1.12でトラフィックをルーティングおよびバランシングする新しい方法です。新しいルーティング戦略により、ノードにサービスがデプロイされていない場合でも、Swarmのすべてのノードの同じポートにサービスが到達できます。ルーティンググリッドは、Swarmで利用可能なすべてのサービスにリクエストを透過的に分散し、障害のあるノードを特定します。

今日のネットワークは同じように見えますか？

新しいアプローチにより、サービスの負荷分散を非常に簡単に構成できます。Swarmで実行される7つの異なるサービスを持つ3つのSwarmホストを想像してください。外部から、任意のノードにリクエストを送信して、ランダムサービスに自動的に送信（ルーティング）するか、常に1つのノードにリクエストを送信して、Dockerがサービス間のバランスを内部的に分散します。したがって、私たちは自分でサービスの負荷分散を取得します。

ルーティンググリッドを使用すると、アプリケーションが提供するコンテナの数を心配せず、クラスターがネットワーク全体を処理し、負荷分散を実行するという意味で、コンテナを真に透過的な方法で処理できます。その前に、ロードバランサーとして機能するはずのサービスの前にリバースプロキシサーバーを接続しなければならなかった場合、Dockerに負荷分散を実行させることができます。 Dockerがすべての汚い仕事をしてくれるので、1つのコンテナと100のコンテナがある状況の違いは今では些細なものになりました。スケーリングできるコンピューター（コンピューティング）リソースを増やし、スケーリングを強化するために1つのコマンドを実行するだけの理由です。 Dockerはこれをすべて行うため、スケーリングの前にアーキテクチャ分析について考える必要がなくなりました。スケーリングを開始すると、100個だけでなく1つのコンテナーに対してDockerが透過的に実行することを知っているため、リラックスできます。

「コンテナ」ではなく「サービス」という用語を使用する理由を疑問に思うかもしれません。これはDocker 1.12の新しい機能です。

サービスとタスク

Docker 1.12では、新しい抽象化「サービス」が導入されています。サービスは、クラスター内のコンテナーの望ましい状態を決定します。内部的には、カーネルはこの新しい概念を使用して、コンテナが実行されていることを確認し、エラーを処理し、トラフィックをコンテナにルーティングします。

少し深く掘り下げて、新しい概念の概念について説明しましょう。サービスは、起動されるコンテナの1つのエンティティを表すタスクで構成されます。 Swarmは、ノード間でこれらのタスクをスケジュールします。サービスの大部分は、常に実行する必要がある実行中のコンテナ（タスク）エンティティ、その動作方法（各コンテナの構成とフラグ）、および更新方法（フローティング更新など）を定義します。これらはすべてサービスの望ましい状態を表し、Dockerカーネルはクラスターの現在の状態を常に監視し、目的の状態と一致するように変更を加えます。

redisサービスの小さなプレビューを次に示します。これについては、この記事の後半で説明します。実行するには、次のようなコマンドを実行する必要があります。

$ docker service create --name redisdb --replicas=3 redis:alpine

動作中のルーティンググリッド

十分な理論、それがすべて動作しているのを見てみましょう。まず、ルーティンググリッドの内部動作を示す小さなnodejsサービスから始めます。 GitHubのコードはこちらにあります。最も重要なwebapp.jsファイルを見てみましょう。

 //  -,    ,  , IP    var http = require('http'); var os = require(“os”); var redis = require('redis'); var server = http.createServer(function (request, response) { //      “OK” response.writeHead(200, {“Content-Type”: “text/plain”}); //     log ,        var version = “2.0”; var log = {}; log.header = 'webapp'; log.name = os.hostname(); log.version = version; //        IPv4 var interfaces = os.networkInterfaces(); var addresses = []; for (var k in interfaces) { for (var k2 in interfaces[k]) { var address = interfaces[k][k2]; if (address.family === 'IPv4' && !address.internal) { addresses.push(address.address); } } } log.nics = addresses; //    redis- (redisdb)   var client = redis.createClient('6379', 'redisdb'); client.on('connect', function(err,reply) { if (err) return next(err); console.log('Connected to Redis server'); client.incr('counter', function(err, reply) { if(err) return next(err); console.log('This page has been viewed ' + reply + ' times!'); console.log(JSON.stringify(log)); response.end(“ Hello, I'm version “+ log.version +”.My hostname is “+ log.name +”, this page has been viewed “+ reply +”\n and my ip addresses are “ + log.nics + “\n” ); }); // client.incr }); // client.on }); // http.createHttpServer //   http-   8000 server.listen(8000);

このサービスは、ホスト名、それを起動したコンテナーのIPアドレス、および訪問数のカウンターのみを返します。

それがすべて私たちのアプリです。それに飛び込む前に、Docker 1.12に切り替えたことを確認する必要があります。

 $ docker version Client: Version: 1.12.0 API version: 1.24 Go version: go1.6.3 Git commit: 8eab29e Built: Thu Jul 28 21:04:48 2016 OS/Arch: darwin/amd64 Experimental: true Server: Version: 1.12.0 API version: 1.24 Go version: go1.6.3 Git commit: 8eab29e Built: Thu Jul 28 21:04:48 2016 OS/Arch: linux/amd64 Experimental: true

Dockerマシンを使用して3つのノードのクラスターを作成することから始めます。

 $ docker-machine create --driver virtualbox swarm-1 Running pre-create checks… Creating machine… … Setting Docker configuration on the remote daemon… Checking connection to Docker… Docker is up and running! … $ docker-machine create --driver virtualbox swarm-2 … Docker is up and running! $ docker-machine create --driver virtualbox swarm-3 … Docker is up and running! $ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS swarm-1 — virtualbox Running tcp://192.168.99.106:2376 v1.12.0 swarm-2 — virtualbox Running tcp://192.168.99.107:2376 v1.12.0 swarm-3 — virtualbox Running tcp://192.168.99.108:2376 v1.12.0

明確にするために、一部のコマンドの出力を減らしています。次に、Swarmを構成します。 Docker 1.12はこれを非常に簡単にします。

 $ eval $(docker-machine env swarm-1) $ docker swarm init --advertise-addr $(docker-machine ip swarm-1) Swarm initialized: current node (bihyblm2kawbzd3keonc3bz0l) is now a manager. To add a worker to this swarm, run the following command: docker swarm join \ --token SWMTKN-1–1n7gtfmvvrlwo91pv4r59vsdf73bwuwodj3saq0162vcsny89l-5zige8u81ug5adk3o4bsx32fi \ 192.168.99.106:2377 …

ここで、「worker」ノードの前のコマンドの出力であったコマンドをコピーして、他の2つのノードに貼り付けます

 $ eval $(docker-machine env swarm-2) $ docker swarm join \ --token SWMTKN-1–1n7gtfmvvrlwo91pv4r59vsdf73bwuwodj3saq0162vcsny89l-5zige8u81ug5adk3o4bsx32fi \ 192.168.99.106:2377 This node joined a swarm as a worker. $ eval $(docker-machine env swarm-3) $ docker swarm join \ --token SWMTKN-1–1n7gtfmvvrlwo91pv4r59vsdf73bwuwodj3saq0162vcsny89l-5zige8u81ug5adk3o4bsx32fi \ 192.168.99.106:2377 … This node joined a swarm as a worker.

新しいSwarmを初期化するとき、コマンドは他のノードをSwarmにアタッチするために使用できる2つの新しいコマンドを表示することに注意してください。これらのチームの「損失」を心配しないでください。「docker swarm join-token worker | manager」を実行することで、いつでも再度取得できます。

続行する前に、群れクラスターが機能していることを確認しましょう。コントロールノードにDockerクライアントを指定し、そのステータスを確認します。

 $ eval $(docker-machine env swarm-1) $ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS 5jqsuf8hsemi7bfbwzfdxfcg5 swarm-2 Ready Active 93f0ghkpsh5ru7newtqm82330 swarm-3 Ready Active b2womami9n2t8tti1acvz6v5j * swarm-1 Ready Active Leader $ docker info … Swarm: active NodeID: b2womami9n2t8tti1acvz6v5j Is Manager: true ClusterID: bimg9n2ti2tnsprkdjqg07tdm Managers: 1 Nodes: 3 Orchestration: Task History Retention Limit: 5 Raft: Snapshot interval: 10000 Heartbeat tick: 1 Election tick: 3 Dispatcher: Heartbeat period: 5 seconds CA configuration: Expiry duration: 3 months Node Address: 192.168.99.106

例に使用する新しいネットワークの作成を始めましょう。

 $ docker network create --driver overlay webnet a9j4al25hzhk2m7rdfv5bqt54

したがって、Swarmの新しいサービスを開始する準備ができました。まず、redisデータベースと「lherrera / webapp」コンテナを起動します。これにより、訪問ページがredisに保存され、コンテナのホスト名やIPアドレスなど、その他の興味深い詳細が表示されます。

Webアプリケーションをデプロイすると、Redisの「redisdb」サービスを使用してredisデータベースに接続できるようになります。 Swarmには内部DNSがあり、各サービスにDNSレコードを自動的に割り当てるため、IPアドレスを使用する必要はありません。すべてが非常に簡単です！

コントロールノードからのみサービスを展開できます。 Dockerクライアントがまだコントロールノードを指している間に、コマンドラインで「docker service create」と入力するだけです。

 $ docker service create --name webapp --replicas=3 --network webnet --publish 80:8000 lherrera/webapp:1.0 avq41soybmtw2jamdus0m3pg $ docker service create --name redisdb --network webnet --replicas 1 redis:alpine bmotumdr8bcewcfj6zqkws97x $ docker service ls ID NAME REPLICAS IMAGE COMMAND avq41soybmtw webapp 3/3 lherrera/webapp:1.0 bmotumdr8bce redisdb 1/1 redis:alpine

サービス作成チームでは、少なくとも画像（この場合はlherrera / webapp）を指定する必要があります。慣例により、webappという名前も提供しています。また、イメージの（接続）後にのみコンテナ内で起動するためのコマンドを発行する必要があります。前のコマンドでは、現在の任意の時点でコンテナーの3つのレプリカを実行することも示しています。「-replicas」フラグを使用すると、どのノードに移動するかを心配する必要がなくなります。ノードごとに1つのサービスが必要な場合は、代わりに「-mode = global」コマンドを使用できます。

前に作成した「webnet」ネットワークを使用していることがわかります。 Swarmの外部からサービスを作成できるようにするには、SwarmがWeb要求をリッスンするポートを設定する必要があります。この例では、サービス内のポート8000をすべてのノードのポート80に「設定」します。ルーティングラティスのおかげで、すべてのルーティングノードでポート80を予約し、Docker Engineはコンテナのすべてのレプリカのポート8000の間でトラフィックのバランスを取ります。

Swarmは、このサービスの説明をアプリケーションの望ましい状態として使用し、ノードにアプリケーションのデプロイを開始して、この望ましい状態を達成および維持します。サービスの追加パラメーターを指定して、リロードルール、メモリとCPUの制限、ホストコンテナーなどの説明を完了することができます。使用可能なすべてのフラグの完全なリストについては、「docker service create」コマンドを使用できます（こちらを参照）。

この段階で、ウェブアプリケーションがウェブネットネットワークに正しく接続されていることを確認できます。

 $ docker network ls NETWORK ID NAME DRIVER SCOPE df19a5c87d90 bridge bridge local 7c5762c8c6ff docker_gwbridge bridge local eb0bd5a4920b host host local bqqh4te5f5tf ingress overlay swarm 3e06a1616b7b none null local a9j4al25hzhk webnet overlay swarm $ docker service inspect webapp … “VirtualIPs”: [ { “NetworkID”: “7i9t9uhtr7x0hybsvnsheh92u”, “Addr”: “10.255.0.6/16” }, { “NetworkID”: “a9j4al25hzhk2m7rdfv5bqt54”, “Addr”: “10.0.0.4/24” } ] }, …

次に、例に戻り、サービスが稼働していることを確認します。

 $ docker service ps webapp ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR bb8n4iagxcjv4rn2oc3dj6cvy webapp.1 lherrera/webapp:1.0 swarm-1 Running Preparing about a minute ago chndeorlvglj45alr4vhy50vg webapp.2 lherrera/webapp:1.0 swarm-3 Running Preparing about a minute ago 4txay0gj6p18iuiknacdoa91x webapp.3 lherrera/webapp:1.0 swarm-2 Running Preparing about a minute ago

留意すべき質問が1つあります。Dockerサービスはidですばやく返されるコマンドを作成しますが、サービスの実際のスケーリングには、特にイメージがノード上にある必要がある場合、時間がかかる場合があります。この場合、すべてのレプリカがサービスに提供されるまで、「docker service ps webapp」コマンドを数回実行するだけです。

サービスが開始されると（これには数分かかる場合がありますが、この間コーヒーを補充します）、リクエストに応じてサービスが受け取るものを確認できます。
最初に、最初のホストのIPを取得する必要があります。

 $ NODE1=$(docker-machine ip swarm-1)

次に、Swarmのポート80でサービスを公開したため、そのIPアドレスにポート80を設定します。以下の例ではcurlを使用していますが、ブラウザーでIPを設定して同じ結果を得ることができます。

これで、新しいサービスをテストする準備ができました。

 $ curl $NODE1 Hello, I'm version 1.0.My hostname is 5a557d3ed474, this page has been viewed 1 and my ip addresses are 10.255.0.9,10.255.0.6,172.18.0.3,10.0.0.7,10.0.0.4 $ curl $NODE1 Hello, I'm version 1.0.My hostname is 4e128c8af4ae, this page has been viewed 2 and my ip addresses are 10.255.0.7,10.255.0.6,172.18.0.3,10.0.0.5,10.0.0.4 $ curl $NODE1 Hello, I'm version 1.0.My hostname is eaa73f01996c, this page has been viewed 3 and my ip addresses are 10.255.0.8,10.255.0.6,172.18.0.4,10.0.0.6,10.0.0.4

最初のリクエストがコンテナ「5a557d3ed474」に送信されたことがわかります。「更新」を数回クリックするか、コマンドラインから再度「curl」を呼び出すと、作成した3つのコンテナレプリカすべてに送信されたリクエストが表示されます。

ルーティンググリッドの他の側面を示すために、ポート80を他の2つのDockerノードのIPに「割り当て」てみてください。前と同じものが表示されます。これから、どのノードを要求したかは関係ありません。リクエストは常に3つのコンテナ間で内部的にバランスが取られます。

フローティング更新（ローリング更新）

サービスの説明の一部として、サービスを更新するための戦略を設定できます。たとえば、 — update-delayフラグを使用して、サービスタスク（コンテナ）またはタスクセットの更新間の遅延を設定できます。または、フラグ— update-parallelismを使用して、デフォルトの動作を変更できます。一度に1つのコンテナーを更新します。次の例に示すように、これらのフラグはすべて、サービス作成プロセス中または「docker service update」コマンドを使用して後で設定できます。 updateコマンドにはdocker service createコマンドとほぼ同じパラメーターが必要ですが、一部のフラグはupdateコマンドとは異なる名前を持っています。 createコマンドで設定できるものはすべて、updateコマンドで変更できるため、いつでもサービス記述の一部を自由に変更できます。

ローリング更新を手動で適用：ダウンヒュルを実際に移動し、自分が制御できないことを認識します

webappサービスを更新して、ローリング更新メカニズムの動作を確認しましょう。開発チームはwebappの改善に一生懸命取り組み、「2.0」という新しいタグをリリースしました。次に、この新しい方法で新しいサービスを更新します。

 $ docker service update --update-parallelism 1 --update-delay 5s --image lherrera/webapp:2.0 webapp

更新は一度に1つずつ行い、各更新の間隔を5秒に設定することも示していることに注意してください。このアプローチは、ダウンタイムがないことを意味します！

更新が行われている間、数秒ごとに「docker service ps webapp」を実行して、リアルタイムで更新を監視します。古い画像が1つずつオフになり、新しい画像に置き換えられます。

 $ docker service ps webapp ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR 7bdpfbbjok78zt32xd9e2mqlt webapp.1 lherrera/webapp:2.0 swarm-3 Running Running 43 seconds ago bb8n4iagxcjv4rn2oc3dj6cvy \_ webapp.1 lherrera/webapp:1.0 swarm-1 Shutdown Shutdown 44 seconds ago af2rlu0laqhrj3uz8brym0f8r webapp.2 lherrera/webapp:2.0 swarm-2 Running Running 30 seconds ago chndeorlvglj45alr4vhy50vg \_ webapp.2 lherrera/webapp:1.0 swarm-3 Shutdown Shutdown 30 seconds ago 0xjt6gib1hql10iqj6866q4pe webapp.3 lherrera/webapp:2.0 swarm-1 Running Running 57 seconds ago 4txay0gj6p18iuiknacdoa91x \_ webapp.3 lherrera/webapp:1.0 swarm-2 Shutdown Shutdown 57 seconds ago

それは信じられないほど素晴らしいものです！

アプリケーションがイメージのバージョンも印刷する場合、更新をリアルタイムで確認する別の方法は、更新中にサービスの繰り返し（エンドポイント）をクリックすることです。サービスが更新されると、更新が完了してすべてのサービスがバージョン2.0を返すまで、「バージョン2.0」を返すリクエストが徐々に増えます。

 $ curl $NODE1 Hello, I'm version 1.0.My hostname is 5a557d3ed474, this page has been viewed 4 and my ip addresses are 10.255.0.9,10.255.0.6,172.18.0.3,10.0.0.7,10.0.0.4 $ curl $NODE1 Hello, I'm version 2.0.My hostname is e0899324d9df, this page has been viewed 5 and my ip addresses are 10.255.0.10,10.255.0.6,172.18.0.4,10.0.0.8,10.0.0.4 $ curl $NODE1 ...

RedisはRedisサービスを変更せず、webappイメージのみを変更したため、継続は無効であると見なしていることに注意してください（Radisサービスのグラフは変更されていません）。

成長ソリューション

ミツバチの群れは初夏によく見られます。ミツバチは、本物のコロニーがたくさんある場合、群れで結合することにより、本能的に生存を利用します。そして、これをコンテナークラスターで行います。

群れで団結しよう...

ノードが電力の限界に達し、クラスターにノードを追加する必要があるとしましょう。とてもシンプルで、たった4つのコマンドで実行できます！わかりやすくするために、さらにいくつかを使用して、発生していることを十分に理解できるようにします。

 $ docker-machine create -d virtualbox swarm-4 … Docker is up and running! Join the node the swarm as a worker as before: $ eval $(docker-machine env swarm-4) $ docker swarm join \ --token SWMTKN-1–1n7gtfmvvrlwo91pv4r59vsdf73bwuwodj3saq0162vcsny89l-5zige8u81ug5adk3o4bsx32fi \ 192.168.99.106:2377 This node joined a swarm as a worker.

新しいノードとwebappサービスの両方が実行されていることを確認します。

 $ eval $(docker-machine env swarm-1) $ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS 93f0ghkpsh5ru7newtqm82330 swarm-3 Ready Active e9rxhj0w1ga3gz89g927qvntd swarm-4 Ready Active 5jqsuf8hsemi7bfbwzfdxfcg5 swarm-2 Ready Active b2womami9n2t8tti1acvz6v5j * swarm-1 Ready Active Leader $ docker service ps webapp ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR 7bdpfbbjok78zt32xd9e2mqlt webapp.1 lherrera/webapp:2.0 swarm-3 Running Running 5 minutes ago bb8n4iagxcjv4rn2oc3dj6cvy \_ webapp.1 lherrera/webapp:1.0 swarm-1 Shutdown Shutdown 5 minutes ago af2rlu0laqhrj3uz8brym0f8r webapp.2 lherrera/webapp:2.0 swarm-2 Running Running 5 minutes ago chndeorlvglj45alr4vhy50vg \_ webapp.2 lherrera/webapp:1.0 swarm-3 Shutdown Shutdown 5 minutes ago 0xjt6gib1hql10iqj6866q4pe webapp.3 lherrera/webapp:2.0 swarm-1 Running Running 6 minutes ago 4txay0gj6p18iuiknacdoa91x \_ webapp.3 lherrera/webapp:1.0 swarm-2 Shutdown Shutdown 6 minutes ago luis@aurelio [13:14:27] [~/webapp] [2.0]

次に、4つのレプリカに対してwebappサービスをアクティブ化します。

 $ docker service update --replicas=4 webapp

イメージが新しいノードから起動するまで数分待つ必要があります。

 $ docker service ps webapp ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR 7bdpfbbjok78zt32xd9e2mqlt webapp.1 lherrera/webapp:2.0 swarm-3 Running Running 10 minutes ago bb8n4iagxcjv4rn2oc3dj6cvy \_ webapp.1 lherrera/webapp:1.0 swarm-1 Shutdown Shutdown 10 minutes ago af2rlu0laqhrj3uz8brym0f8r webapp.2 lherrera/webapp:2.0 swarm-2 Running Running 10 minutes ago chndeorlvglj45alr4vhy50vg \_ webapp.2 lherrera/webapp:1.0 swarm-3 Shutdown Shutdown 10 minutes ago 0xjt6gib1hql10iqj6866q4pe webapp.3 lherrera/webapp:2.0 swarm-1 Running Running 10 minutes ago 4txay0gj6p18iuiknacdoa91x \_ webapp.3 lherrera/webapp:1.0 swarm-2 Shutdown Shutdown 10 minutes ago 81xbk0j61tqg76wcdi35k1bxv webapp.4 lherrera/webapp:2.0 swarm-4 Running Running 20 seconds ago

ただ？群れにいる蜂はいつも気分が良いです！

グローバルサービスの場合（例で見たように、レプリケーションとは対照的に）、Swarmは新しい利用可能なノードでサービスの新しいタスクを自動的に開始します。

ルーティングの復元力

何かが十分に起こらない場合、クラスターはこれらのサービスの状態を管理し（たとえば、レプリカの実行）、サービスを目的の状態に復元できない場合に備えます。このシナリオでは、新しいコンテナとIPアドレスが表示されたり消えたりします。幸いなことに、新しいビルトインサービスディスカバリメカニズムは、これらの状況やコンテナの障害にサービスを適応させるのに役立ち、今でも完全なノード障害は気付かれることはありません。

従来のフェルオーバー環境（HA環境）でのネトトワークルーティング

これを実際に見るために、引き続き例を見て、小さな障害が発生したクラスターのノードをシミュレートします。

クラスターでwebappがまだ実行されていることを確認しましょう：

 $ docker service ps webapp ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR 7bdpfbbjok78zt32xd9e2mqlt webapp.1 lherrera/webapp:2.0 swarm-3 Running Running 10 minutes ago bb8n4iagxcjv4rn2oc3dj6cvy \_ webapp.1 lherrera/webapp:1.0 swarm-1 Shutdown Shutdown 10 minutes ago af2rlu0laqhrj3uz8brym0f8r webapp.2 lherrera/webapp:2.0 swarm-2 Running Running 10 minutes ago chndeorlvglj45alr4vhy50vg \_ webapp.2 lherrera/webapp:1.0 swarm-3 Shutdown Shutdown 10 minutes ago 0xjt6gib1hql10iqj6866q4pe webapp.3 lherrera/webapp:2.0 swarm-1 Running Running 10 minutes ago 4txay0gj6p18iuiknacdoa91x \_ webapp.3 lherrera/webapp:1.0 swarm-2 Shutdown Shutdown 10 minutes ago 81xbk0j61tqg76wcdi35k1bxv webapp.4 lherrera/webapp:2.0 swarm-4 Running Running 20 seconds ago

ノード：

 $ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS 21z5m0vik76msi90icrf8prvf swarm-3 Ready Active 7zyckxuwsruehcfosgymwiucm swarm-4 Ready Active 9aso727d8c4vc59cxu0e8g778 swarm-2 Ready Active bihyblm2kawbzd3keonc3bz0l * swarm-1 Ready Active Leader

これが楽しい部分の始まりです-誰が作業ノードをオフにして何が起こるかを知りたくないのですか？

 $ docker-machine stop swarm-2

サービスがどのように応答したかを見てみましょう。

 $ docker service ps webapp ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR 7bdpfbbjok78zt32xd9e2mqlt webapp.1 lherrera/webapp:2.0 swarm-3 Running Running 11 minutes ago bb8n4iagxcjv4rn2oc3dj6cvy \_ webapp.1 lherrera/webapp:1.0 swarm-1 Shutdown Shutdown 11 minutes ago af2rlu0laqhrj3uz8brym0f8r webapp.2 lherrera/webapp:2.0 swarm-4 Running Running 11 minutes ago chndeorlvglj45alr4vhy50vg \_ webapp.2 lherrera/webapp:1.0 swarm-3 Shutdown Shutdown 11 minutes ago 0xjt6gib1hql10iqj6866q4pe webapp.3 lherrera/webapp:2.0 swarm-1 Running Running 11 minutes ago 4txay0gj6p18iuiknacdoa91x \_ webapp.3 lherrera/webapp:1.0 swarm-4 Shutdown Shutdown 11 minutes ago 15pxa5ccp9fqfbhdh76q78aza webapp.4 lherrera/webapp:2.0 swarm-3 Running Running 4 seconds ago 81xbk0j61tqg76wcdi35k1bxv \_ webapp.4 lherrera/webapp:2.0 swarm-2 Shutdown Running about a minute ago

わあ！ Dockerは、swarm-2ノードを「殺した」後、swarm-3ノードに新しいコンテナをデプロイしました。ご覧のとおり、3つのレプリカが実行されています（「swarm-3」ノードに2つ）...

 $ curl $NODE1 Hello, I'm version 2.0.My hostname is 0d49c828b675, this page has been viewed 7 and my ip addresses are 10.0.0.7,10.0.0.4,172.18.0.4,10.255.0.10,10.255.0.6 $ curl $NODE1 Hello, I'm version 2.0.My hostname is d60e1881ac86, this page has been viewed 8 and my ip addresses are 10.0.0.7,10.0.0.4,172.18.0.4,10.255.0.10,10.255.0.6

そして、トラフィックは新しく作成されたコンテナに自動的にリダイレクトされます！

Swarmの成長と開発

ソフトウェアは急速に変化しています。失敗は起こります。そして、あなたがそれを最も期待しないとき、それらは必然的に起こります。「サービス」の新しい抽象化がDocker 1.12で導入され、更新が簡素化され、ダウンタイムとサービス障害が防止されました。さらに、この新しいアプローチにより、Webサーバーなどの長時間実行されるサービスの計画と保守がはるかに簡単になります。少数のコマンドを使用して、Docker EngineのSwarmに複製、分散、負荷分散されたサービスをデプロイできるようになりました。クラスターは、サービスの状態を管理し、ノードまたはコンテナーに障害が発生した場合にサービスを目的の状態にすることもできます。

ソロモン・ハイクスは、開発者の生活を楽にすることをどのように望んでいるかをよく説明しています。基盤となるインフラストラクチャに関係なく」

Docker 1.12のリリースにより、確かに約束どおりに機能すると思います。 Dockerによって物事がより簡単になります。これが、冒頭で述べたこれらの超現実的な瞬間が消え始めた瞬間です。 DevOpsで他の超現実的な瞬間はありますか？共有してください！

詳細とDocker 1.12へのリンク

https://www.youtube.com/watch?v=dooPhkXT9yI-Swarmノードがどのように機能し、相互に情報を交換するかの詳細を詳細に調べます。
https://www.youtube.com/watch?v=_F6PSP-qhdA-詳細なレビューのパート2では、組織化されたサービスの処理方法と障害の処理方法に焦点を当てています。

Dockerを使用したルーティングサービスのトラブルシューティング