Docker Swarmモード

habrで、バージョン1.12の新機能であるDocker swarmモード （ swarmのモード ）について既に書いています。 このオプションは、スタンドアロンのDocker Swarm実装に精通している人々の頭に少し混乱をもたらしました。これは、以前に配布されたもので、セットアップと使用の容易さにおいて違いはありませんでした。 ただし、Dockerを使用してSwarmをボックスに追加すると、すべてがよりシンプルになり、より明確になり、より機能的になりました。



コンテナの新しいDockerクラスターがユーザーの観点からどのように配置されているか、さらに任意のインフラストラクチャにDockerサービスを展開するための簡単で便利な方法について、さらに詳しく説明します。



まず、前の記事で約束したように、少し遅れて、DockerサービスをサポートするFabricioリリースをリリースしました。 同時に、個々のコンテナで作業することも可能です。さらに、ユーザーインターフェイスと構成の開発者は変更されないため、個々のコンテナに基づく構成からフォールトトレラントで水平方向にスケーラブルなサービスへの移行が大幅に簡素化されます。

Docker Swarmモードの有効化

swarmモードでは、すべてのノードはマネージャーとワーカーの2つのタイプに分けられます。 同時に、本格的なクラスターは、一般にノードを動作させなくても実行できます。つまり、デフォルトでマネージャーも動作しています。



マネージャの中には、常に現在クラスタのリーダーである人がいます。 他のマネージャーで実行されるすべての制御コマンドは、自動的にリダイレクトされます。











スウォームモードを有効にするには、将来のクラスターで最初のリーダーとなるホストを選択し、その上で1つのコマンドのみを実行します。

 docker swarm init
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「swarm」が初期化されると、任意の数のサービスを起動する準備が整います。 確かに、そのようなクラスターの状態は一貫性がありません（マネージャーの数が少なくとも3である場合、一貫した状態が達成されます）。 そしてもちろん、この場合でもスケーリングとフォールトトレランスについては話せません。 これを行うには、少なくとも2つの制御ノードをクラスターに接続する必要があります。 リーダーで次のコマンドを実行して、これを行う方法を学習できます。







ノードは、クラスターの存続期間中いつでも追加および削除できます。これは、深刻な方法でパフォーマンスに重大な影響を与えることはありません。

サービス作成

Dockerでサービスを作成することは、基本的にコンテナを作成することと同じです。

 docker service create --name nginx --publish 8080:80 --replicas 2 nginx:stable-alpine
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

原則として、違いは異なるオプションのセットにあります。 たとえば、サービスには--volumeオプションはありませんが、 -mountオプションがあります。これらのオプションを使用すると、ローカルノードリソースをコンテナーに接続できますが、これはさまざまな方法で行います。

サービス更新

ここから、コンテナーの作業とコンテナーのクラスター（サービス）の作業の最大の違いが始まります。 通常、単一のコンテナを更新するには、現在のコンテナを停止して新しいコンテナを開始する必要があります。 これは、重要ではありませんが、サービスの既存のダウンタイムにつながります（他のツールを使用してこのような状況を処理することに煩わされていない場合）。



少なくとも2つのレプリカの数でサービスを使用する場合、ほとんどの場合、サービスの停止は発生しません。 これは、Dockerがサービスコンテナを順番に更新することで実現されます 。 つまり、同時に、ユーザーのリクエストを処理できる少なくとも1つの作業コンテナが常に存在します。



いくつかの値（たとえば、-- publishまたは--label ）を持つことができるサービスプロパティを更新（追加および削除を含む）するには、Dockerは、接尾辞-addおよび-rmで終わる特別なオプションを使用することをお勧めします。

 #      docker service update --label-add foo=bar nginx
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、一部のオプションを削除するのは簡単ではなく、多くの場合、オプション自体に依存します。

 #     docker service update --label-rm foo nginx #       (target port) docker service update --publish-rm 80 nginx
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各オプションの詳細については、 docker service updateコマンドの説明を参照してください。

スケーリングとバランス

既存のDockerノード間でリクエストを分散するために、 イングレスロードバレーシングと呼ばれる回路が使用されます。 このメカニズムの本質は、ユーザーがどのノードを要求しても、最初に内部バランシングメカニズムを通過してから、そのような要求を現在処理できるノードにリダイレクトされることです。 つまり、どのノードでも、任意のクラスターサービスへの要求を処理できます。



Dockerサービスのスケーリングは、必要なレプリカの数を指定することにより実現されます。 クライアントからのリクエストを処理するノードの数を増やす（または減らす）必要がある時点で、必要な--replicasオプションの値でサービスプロパティを更新します。

 docker service update --replicas 3 nginx
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、使用可能なノードの数が、使用するレプリカの数より少なくないことを忘れないでください。 ノードがレプリカよりも小さくても何も悪いことは起こりませんが、一部のノードは同じサービスの複数のコンテナを起動するだけです（そうでない場合、Dockerは異なるサービスで同じサービスのレプリカを実行しようとします）。

耐障害性

サービスのフォールトトレランスはDockerによって保証されています。 これは、とりわけ、クラスター内で複数の制御ノードが同時に機能し、いつでも故障したリーダーを置き換えることができるという事実により達成されます。 より詳細には、いわゆる分散コンセンサス維持アルゴリズムであるRaftが使用されます。 興味のある方には、この素晴らしい視覚的なデモンストレーションを見ることをお勧めします。

自動展開

サーバーと戦うためにアプリケーションの新しいバージョンを展開すると、常に何かがうまくいかないというリスクが伴います。 そのため、週末や休日の前にアプリケーションの新しいバージョンを公開するのは悪い兆候と見なされます。 さらに、年末年始などの長期休暇の前に、軍事インフラの変更は、開始する前に1〜2週間停止します。



Dockerサービスはアプリケーションを起動および更新するための完全に信頼できる方法を提供するという事実にもかかわらず、多くの場合、以前のバージョンへの迅速なロールバックは何らかの理由で困難であり、これによりユーザーが何時間もアクセスできなくなる可能性があります。



アプリケーションの更新時に問題を回避する最も信頼できる方法は、 自動化とテストです。 このために、自動展開システムが開発されています。 このようなシステムの重要な部分は、原則として、選択したインフラストラクチャで以前のバージョンに迅速にアップグレードしてロールバックできることです。

ファブリシオ

ほとんどの展開自動化ツールは、XMLやYAMLなどの一般的なマークアップ言語を使用して構成の説明を提供します。 いくつかはさらに進んで、そのような構成を記述するための独自の言語を開発します（例： HCLまたはPuppet言語 ）。 次の理由により、これらのパスを使用する必要はありません。

• XML / YAMLは、拡張や使用に関して本格的なプログラミング言語と比較することはできません。また、単純化されたマークアップを使用して構成を簡素化するという要望はしばしば反対であり、すべてが複雑になりますプラスプログラミングの特別な場合。
• 独自のプログラミング言語の開発は非常に複雑で退屈なプロセスであり、ほとんどの場合、それに費やした労力の価値はありません。

そのため、Fabricioは、通常のPythonを使用して、構成と信頼性が高く実績のあるライブラリ（悪名高いFabric ）を記述します。



もちろん、多くの人はこれに反対するかもしれません。すべての開発者とDevOpsがPythonを知っているわけではないと言っています。 まあ、まず、Python（およびBash）は、すべての自尊心のあるDevOpsが知っているべきである（まあ、またはほぼ全員）紳士的なスクリプト言語のセットに含まれています。 そして第二に、逆説的に、Pythonを知ることはほとんどオプションです。 私の言葉を支持して、Django for Fabricioに基づいたサービスの構成例を示します。





この例は、YAMLの同様の説明ほど複雑ではないことに同意します。 少なくとも1つのプログラミング言語を知っている人は、この構成を問題なく理解できます。



しかし、きれいな歌詞。

展開プロセス

概略的に、Fabricioを使用してサービスをデプロイするプロセスは、下の図に示すようになります（上記の構成に対してfab djangoコマンドを実行した後）。











各項目を順番に検討してください。 まず最初に、並列実行モードがオンになっている場合（指定されたオプション--parallelを指定した場合）、提示されたスキームが関連していることにすぐに注意します。 シーケンシャルモードの違いは、モード内のすべてのアクションが厳密にシーケンシャルに実行されることだけです。



展開コマンドを起動するとすぐに、次の手順が順番に開始されます。

• pullと同時に、新しいDockerイメージをダウンロードするプロセスがすべてのノードで開始されます。 構成では、制御ノード（マネージャー）のアドレスのみを指定するだけで十分であることに注意してください。使用可能なマネージャーをすべてリストする必要はありません。指定されていないノードはDockerによって自動的に更新されます。 ワーカーを含む構成での指定を妨げるものは何もありませんが（ SSHトンネルを使用する場合など、場合によってはこれが必要です）
• migrate 、次のステップは移行の適用です。 このステップは一度に1つの現在のノードでのみ実行されることが重要です。この場合、Fabricioは特別なメカニズムを使用して、移行プロセスが1つのノードでのみ実行され、一度だけ実行されるようにします。
• updateは 、すべてのサービスコンテナを更新するために、updateコマンドを1回実行するだけで十分なため、このステップでFabricioが2回実行されないようにします。

必要に応じて、各コマンド（プル、移行、更新）を個別に実行できます。 この以前のFabricioレビュー記事で説明されているように、展開プロセスに追加の手順（準備、プッシュ、バックアップ）を含めることもできます 。



Fabricioのすべてのコマンド（バックアップと復元を除く）はi等です。つまり、同じパラメーターで再実行しても安全です。

前のバージョンへのロールバック

前のバージョンへのロールバック（前述の構成のfab django.rollbackコマンド ）は、展開プロセスとほぼ同じです。









移行のロールバックとサービス自体の以前の状態へのロールバックの両方が、マネージャーノードの1つで厳密に1回実行されます。

おわりに

コンテナ化は、サーバー開発の未来です。 まだこれに気付いていない人はすぐに既成事実に直面するでしょう。 コンテナは、開発者とDevOpsの手にとって便利でシンプルで強力な武器です。



Docker 1.12のリリースでは、Kubernetesの支持者は後者を使用することについてほとんど議論をしていません。 DockerサービスはKubernetesサービスと同じ機能をすべて提供するだけでなく、OS（Linux、macOS、Windows）での構成が容易であり、追加のコンポーネント（コンテナー）をインストールして実行する必要がないため、多くの利点さえあります。



Fabricio-Dockerを使用してサーバーと戦い、テストするアプリケーションの新しいバージョンの開発、テスト、および展開を支援するツール-スケーラブルでフォールトトレラントなサービスの展開をサポートするようになりました。 ページ上のFabricioのさまざまな使用法について、 例とレシピを使用して理解することができます （すべての例は詳細に説明され、Vagrantを使用して自動化されています）。