一日の良い時間！

この投稿では、 Bash 、 Outthentic 、およびSparrowツールを使用してインフラストラクチャのステータスを確認するためのさまざまなスクリプトを迅速かつ簡単に記述する方法について説明します...

タスク-アプリケーションをインストールし、構成設定を行うサーバーがあります。 サーバーですべてが正常であり、アプリケーションが正しく構成されて動作しているという答えをすばやく提供するスクリプトを作成したいと思います。 問題を探しているときや、次の展開で何も壊れていないことを確認するときに役立つ、一種の煙テスト。 可能性のある質問を予想して、似たようなこと（ inspec ）を行うツールがすでにあることは知っていますが、代替アプローチについてお話したいと思います。 （比較するのは面白いでしょう）。

ツール選択

なぜbashなのか？ 使い方は非常に簡単で、あらゆる種類のスクリプトを迅速かつ効率的に記述できるため、より複雑なタスクにはBashを使用しませんが、この種の問題には非常に適しています。

それでは、Outthenticとは何であり、ここでどのように役立つのでしょうか？ Outthenticはスクリプトフレームワークであり、スクリプト（この場合はBashで記述されていますが、他の言語も使用できます）をすばやく記述、構成、実行できます。同様に重要なことは、Outthenticには、自動化されたテストのスタイル。これは、監視スクリプトを作成するときに便利です。

そして最後の-なぜ（またはそのようなもの） Sparrowとそれがどのように役立つのでしょうか？ Sparrowは、カスタムスクリプト用のプラットフォームおよびランタイムであり、いわゆる既製のスクリプトを配布および構成できます。 スズメのプラグイン。 主な使い道は、スクリプトを作成してテストするときに、プラグインの形式でそれをパックし、リポジトリをSparrowにアップロードして、それを運用部門やスクリプトを使用する他の同僚に転送できることです。

実用例

この例は、実際の実践に一部基づいており、不必要な詳細で記事を読み過ぎないように、部分的に意図的に簡略化されています。 この種類のチェックを常に多かれ少なかれ行う必要があるため、自動化スクリプトを記述することにしたので、ターゲットサーバーがターゲットサーバー上にあることを確認しtarget-server



。

• tomcatが実行されている、つまりプロセスのリストに表示されている

  
  
  
  
  
  
  

• 一部のアプリケーションリソースに対するHTTPリクエスト（サーバーにデプロイ）
  
  成功したhttpコード（ 200
  
  
  
  ）を返すGET 127.0.0.1:8080/healthcheck
  
  
  
  

  
  
  
  
  
  
  
• データベースサーバーは、tcpポートアクセスレベルでターゲットサーバー（ 192.168.0.2
  
  
  
  ）から使用できます（多くの場合、セキュリティポリシーが正しく構成されていないため、これは当てはまらない可能性があり、アプリケーションが動作しなくなります）

はい。すべてのチェックがターゲットサーバーで直接実行されることに注意することが重要です。

 $ ssh target-server $ bash /path/to/check/script.bash
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Bashスクリプト

この場合、スクリプトは簡単です。

 $ cat script.bash #!/bin/bash ps uax | grep tomcat | grep -v grep echo; echo timeout 5 curl -sL 127.0.0.1:8080/healthcheck -w "GET /healhcheck --- %{http_code}\n" -o /dev/null echo; echo timeout 5 bash -c "echo OK | telnet 192.168.0.2 3306"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ターゲットサーバーでスクリプトを実行すると、出力で次のような結果が得られます（この段階では、まだチェックは行われていません。スクリプトが機能することを確認してください）。

 $ bash script.bash GET /healhcheck --- 200 tomcat 8264 0.0 32.1 2222884 326452 ? Sl Sep14 4:04 /usr/lib/jvm/java-1.8.0/bin/java -Djava.util.logging.config.file=/usr/share/tomcat8/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xmx128M -Djava.awt.headless=true -Djava.endorsed.dirs=/usr/share/tomcat8/endorsed -classpath /usr/share/tomcat8/bin/bootstrap.jar:/usr/share/tomcat8/bin/tomcat-juli.jar -Dcatalina.base=/usr/share/tomcat8 -Dcatalina.home=/usr/share/tomcat8 -Djava.io.tmpdir=/usr/share/tomcat8/temp org.apache.catalina.startup.Bootstrap start Trying 192.168.0.2 ... Connected to 192.168.0.2. Escape character is '^]'. Connection closed by foreign host.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリプト出力検証

監視の全体的なポイントは、複数のチームを順番に実行し、一連の単純なルールを使用して出力を分析する機能です。ここでは、Outthenticが登場します。

まず、パッケージをCPANモジュールとしてインストールします。

 $ cpanm Outthentic
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、Outthenticで実行できるようにスクリプトをわずかに変更します。

• スクリプトの名前をstrory.bash
  
  
  
  変更します。これは、Outthenticフレームワークにスクリプトを含めるための合意です。

 $ mv script.bash story.bash
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• Outthenticフレームワークに付属し、実際にスクリプトを実行するコンソールクライアントstrun
  
  
  
  を介してスクリプトを実行します。

 $ strun
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリプトを直接実行した場合と同様に、出力を取得します。 これまでのところ、Outthenticの利点は明らかではありません。 DSLを使用します。 スクリプト出力を検証するためのいくつかの簡単なテストルールを作成し、そのルールをstory.check



ファイルに入れましょう。

 $ cat story.check GET /healhcheck --- 200 tomcat8 Connected to 192.168.0.2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

strun



再度実行します。

 $ strun 2017-09-18 17:39:55 : [path] / GET /healhcheck --- 200 tomcat 8264 0.0 32.1 2222884 326452 ? Sl Sep14 4:04 /usr/lib/jvm/java-1.8.0/bin/java -Djava.util.logging.config.file=/usr/share/tomcat8/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xmx128M -Djava.awt.headless=true -Djava.endorsed.dirs=/usr/share/tomcat8/endorsed -classpath /usr/share/tomcat8/bin/bootstrap.jar:/usr/share/tomcat8/bin/tomcat-juli.jar -Dcatalina.base=/usr/share/tomcat8 -Dcatalina.home=/usr/share/tomcat8 -Djava.io.tmpdir=/usr/share/tomcat8/temp org.apache.catalina.startup.Bootstrap start Trying 192.168.0.2 ... Connected to 192.168.0.2. Escape character is '^]'. Connection closed by foreign host. ok scenario succeeded ok text has 'GET /healhcheck --- 200' ok text has 'tomcat8' ok text has 'Connected to 192.168.0.2' STATUS SUCCEED
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

検証ルールが機能し、スクリプトからの出力がすべてのチェックに正常に合格したことがわかります。これは、監視から必要なものすべてです。 strun



レポートstrun



カスタマイズ可能であり、いくつかのオプションがあります。たとえば、エラーの場合にのみ 、すべての詳細を表示するより簡潔な出力を選択できます。

 $ strun --format production
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

何らかの理由でTomcatサーバーが実行されていない場合、レポートは次のようになります。

 $ strun --format production 2017-09-18 17:44:43 : [path] / not ok text has 'tomcat8' GET /healhcheck --- 200 Trying 192.168.0.2 ... Connected to 192.168.0.2. Escape character is '^]'. Connection closed by foreign host. STATUS FAILED (2)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

監視スクリプトのパラメーター化

Outthenticは、スクリプトの入力パラメーターを簡単に追加および構成できるという点でも便利です。 純粋に理論的には、データベースサーバーのホストとポートを設定するとします。

outthenticの用語でデフォルト設定を保存するファイルであるsuite.yamlを使用して、入力パラメーターのデフォルト値を追加します。

 $ cat suite.yaml --- db_server: ip_address: "192.168.0.2" port: 3306
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、構成ファイルの階層は任意です。Outthenticを使用して階層データ構造として記述された入力パラメーターを転送し、Bashスクリプト内でも （追加の解析なしで）使用することがいかに簡単で単純かを示したいだけです。

監視スクリプトを少し変更して、 外部から入力パラメーターを取得するようにします。

 $ cat script.bash #!/bin/bash db_server_address=$(config db_server.ip_address) db_server_port=$(config db_server.port) # ...      # ... timeout 5 bash -c "echo OK | telnet $db_server_address $db_server_port $db_server_port"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、既定のパラメーターを使用してスクリプトを実行できます。

 #       ip address 192.168.0.2   3306 $ strun
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、コマンドラインからパラメーターをオーバーライドします。

 $ strun --param db_server.ip_address=192.168.0.3 --param db_server.port=3307
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに進むと、私たちがやるべきことは、すべての関係者のスクリプトを操作に移すことだけです。そのためには、Sparrowが必要です。

Sparrowプラグインとしてのスクリプトの配布

Sparrowには、 SparrowHubパブリックリポジトリとリモートGitリポジトリ上に構築されたプライベートリポジトリの2つの主要なスクリプト配布オプションがあります。

ほとんどの場合、純粋に内部スクリプトを記述する場合、2番目の方法の方が適しています。 また、スクリプトソースがリモートGitリポジトリにあることのみを必要とするため、より簡単です。

 $ git init . $ git add . $ git commit -a -m "outthentic monitoring script"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メインのプロジェクトファイル（story.bashとstory.check）を追加して、 メタデータでファイルを構成する必要があります（実際、これは単なるスクリプトではなく、Sparrowプラグインであることを明確にしています）。

 $ cat sparrow.json { "name" : "server-check" "description" : "check server health" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、メタデータファイルには非常に多くのパラメーターが含まれている場合がありますが、簡単にするために、最小限のセットに制限します。

さて、実際に最初のSparrowプラグインを作成しました。ファイルをgit remoteに送信します。

 git add sparrow.json git commit -a -m "add sparrow meta file" git remote add origin $remote-git-repository git push -u origin master
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

既製の監視スクリプトを Sparrowプラグインとして使用する

これは、Sparrowを使用してスクリプトを簡単にインストールし、サードパーティのコマンドと統合する方法を示しているという意味で最も興味深い部分です。

まず、ターゲットサーバーで作成したプラグインを使用するには、このSparrowサーバーにクライアントをインストールする必要があります。

 $ cpanm Sparrow
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、すべてがシンプルです。 プラグインはプライベートであり、一般的なリポジトリからダウンロードされません、これについてSparrowに通知します：

 $ echo "server-check $remote-git-repository" >> ~/sparrow.list
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ローカルインデックスファイル~/sparrow.list



入れる値のペアは、プラグインの名前です（前の部分で使用したものと、プラグインのソースコードがあるリモートリポジトリのURLと一致する必要はありません）

ここで、追加したプラグインが利用可能になるように、雀のインデックスを更新します。

 $ sparrow index update
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プラグイン自体をインストールします。

 $ sparrow plg install server-check
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これでプラグインをそのまま実行できます：

 $ sparrow plg install server-check
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、パラメータを渡すことにより：

 $ sparrow plg install server-check --param db_server.ip_address=192.168.0.3 --param db_server.port=3307
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後に、Sparrow タスクの形式で同じことを開始できます 。

 $ sparrow project create monitoring $ sparrow task add monitoring app1 server-check $ sparrow task ini monitoring/app1 --- db_server: ip_address: "192.168.0.2" port: 3306 --- $ sparrow task run monitoring/app1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後の起動オプションは、同じプラグインを実行する複数のタスク（異なる構成）を作成できるという点で便利です。 基本的に、タスクはSparrowプラグインを起動するための名前付き設定であり、プロジェクトはタスクのグループです。

PS

以上です。 誰かが興味を持っているなら、ここに私が言っていないことがあります：

• プライベートSparrowリポジトリは、ローカルの~/sparrow.list
  
  
  
  ファイルインデックス（多数のプラグインには不便です）だけでなく、 Sparrow :: ~/sparrow.list
  
  
  
  プライベートSparrowリポジトリを管理するためのAPIを通じても構成できます。

  
  
  
  
  
  
  

• Sparrowプラグインは、Sparrowクライアントが自動的にプリインストールされた状態で（sshを介して）サーバー上でリモートで実行できます。Sparrowdoプロジェクトへようこそ。 Sparrow用のPerl6 APIなどもあります（- ：！

  
  
  
  
  
  
  
• Outthentic DSLを使用すると、単なるサブストリングマッチングよりもはるかに複雑で興味深い検証ルールを作成できます。 その中には、Perl5正規表現の検証、範囲とシーケンスの検証、および汎用プログラミング言語を使用した動的ルール生成があります。

いつものように-質問、コメント、提案、建設的な批判-歓迎します。

よろしく

アレクセイ