Docker：マスタースレーブPostgreSQL構成を展開する

前回の記事では、Dockerコンテナーの展開を自動化するプロジェクトについて説明しましたが 、その開発は今年の初めに始まりました。 数か月が経ち、Fabricioは大幅に改善および改善されました。今日は、最新の技術革新の1つである、PostgreSQLのマスタースレーブ構成の自動展開についてお話したいと思います。



コンテナでPostgreSQLを実行することは最も一般的なアイデアではありません。これには合理的な説明があります。すでにかなり忙しいサービスにネットワーク遅延を追加することです 。 しかし、そのような解決策をまだ適用できる場合がいくつかあります。 たとえば、 Dockerを完全に信頼している場合、データベースに大きな負荷はかかりませんが、保存されたデータを複数のサーバーに複製/複製する機能は重要です。 または、バトルサーバーに設定を適用する前に、設定をテストおよびデバッグするためだけに使用します。



多くのテキスト情報で読者（およびユーザー） を飽きさせないために 、実際に動作するコンテナーでFabricioを使用する 「ライブ」の例を挙げるといいと思いました-同意する必要があります-それを一度見た方が良いです。



PostgreSQLのマスタースレーブ構成の例は、Dockerがインストールされている3つの仮想マシンに実装されています。 これらの仮想マシンの作成と初期構成はVagrantを使用して完全に自動化されているため、サンプルの実行に問題はありません。

実装されたシナリオ

マスター/スレーブ構成の場合の最も重要なシナリオは、間違いなくマスター（マスター）サーバーの障害後のデータベースの復元です。 原則として、戦闘システムでは、これは既存のサーバーの継続的な監視システムと、失敗したホストの自動切り替え/除外-フェールオーバーを使用して構成されます。 たとえば、今日人気のあるpgpool-IIツールは、これらの目的に使用できます。 ただし、このようなシステムの構成は簡単なタスクではないため（自動化のためにすべてを完全に信頼できるわけではありません）、多くの場合、障害後の自動回復を行わない構成を見つけることができます。 そのようなシステムで依然として障害が発生する場合、通常は、手動または半自動モードで、バックアップコピーからデータベースを復元するか、アプリケーション構成を新しいデータベースマスターのアドレスに切り替えることで解消されます。



Fabricioは、ウィザードの失敗から回復する半自動の方法を提供します。 これを行うには、障害が発生したサーバーが新しいサーバーに置き換えられたか、展開構成設定から削除されたことを確認した後、1つのコマンドのみを実行する必要があります。

fab --parallel db
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しいスレーブサーバーを構成に追加するスクリプトは、上記のオプションと大差ありません。このため、このサーバーのアドレスをFabricioホストリストに登録し、展開コマンドを再実行するだけで十分です。 データベースの初期状態は、現在のマスターサーバーからコピーされます。





Fabricioは、テストのニーズに合わせて、利用可能なホストのリストからウィザードをランダムに選択することにより、構成を最初からデプロイすることもサポートしています。

実装機能

自動ウィザード検出では、Fabricioをパラレル実行モードで実行する必要がありますが、これはデフォルトでは無効になっています。 そのため、展開コマンドで--parallelオプションが使用されます。



少なくとも1つのスレーブが独自の空でないデータフォルダー（PG_VERSIONファイルの存在によって決定される）を持っている場合、新しいマスターの自動選択（プロモーション）はデフォルトでは実行されません（スクリプトは対応するエラーで終了します）。 この手順は完全に安全ですが、このオプションを有効にする前に、新しいウィザードを選択するためのアルゴリズムに慣れることをお勧めします。 この場合、少なくともいくつかのデータを持つホストからマスターがランダムに選択され、データは新しいマスターから「空の」ホストに（つまり、独自のデータベースなしで）コピーされます。



また、前の状態へのロールバックは、特別な指示なしでは機能しません。これは、マスタースレーブ構成ではこのようなシナリオがまったく提供されないためです。結局、マスターは自動的に修復されず、何らかのエラーが発生した場合は、手動で修復するよりも、自動化に依存しています。 ロールバックオプションがまだ有効な場合、親クラス（単一のPostgreSQL構成）から継承されたロールバックロジックが使用されます-前回の成功した展開中に更新された内容に応じて、以前の構成および/または以前のコンテナー（またはコンテナー）が返されます。

今後の計画

近い将来、おそらく年末まで、Dockerバージョン1.12以降のSwarmモードのサポートが実装される予定です。 これにより、Fabricioは個々のコンテナーだけでなく、自動スケーリングとフォールトトレランスを備えたサービス全体をすぐに展開できます。



Swarmのソリューションを実装した後、Kubernetesおよび/またはMesosのサポートを利用することは論理的です。 ただし、これに対する個別のタスクはまだなく、すべてが実装の複雑さに依存します。