先日、個人開発のOSS - Submarine.jsのv1.0をリリースしました記事はこちら

Ansibleの冪等性に関する Tweet が、結構な反応をいただけたこともあり、今回は、私がSubmarine.jsで克服したかった「冪等性の限界」と、それを、どのような哲学で解決しようとしているかについて、説明しようと思います

冪等性の理想と現実

そもそも冪等性とは? という話は、各所で説明されていることなので簡単に

冪等性とは
- 同じ操作を何回実行しても、同じ結果が得られること
- インフラの構成管理の世界では、何回同じコードを実行しても、同じサーバの状態が得られるという意味で使われる
- Webの世界ではHTTPのGETやPUTメソッドは冪等だけど、POSTは冪等ではないなどと言われる

Ansibleでは、この冪等性を簡単に実現するために、目的に応じて膨大な数のモジュールが提供されています

Ansibleのモジュール一覧
https://docs.ansible.com/ansible/latest/modules/list_of_all_modules.html

Ansibleを使って構成管理をしているプロジェクトでは、これら膨大なモジュール群の中から、自分のやりたいことに合ったモジュールを探して、組み合わせて利用します

ところが、意外と自分のほしい機能がない(あるいは見つからない)ことがあり、そういうときにはshellモジュールなどを使って、冪等なコードを自前で書く必要があります

この「冪等なコード」というのが、結構複雑になりがちで、レビューやメンテナンスがしづらかったり、バグの温床になったりします

冪等なコードを書くために必要なこと

前述のように冪等性というのは、構成管理をする上で理想的な考えではあるけれども、実装上の困難が多いのも事実です

そもそも冪等なコードを実現するためには、以下のような3つの要件を、1度に実現する複雑な処理が必要です

冪等なコードの要件 (引用 : https://twitter.com/tmiki74306808/status/1175631407516807175)
1. 在るべき状態の定義
2. 現在の状態の確認手段
3. 状態を移行するための手段

多くのことを1度にやろうとすると、大体うまくいかないものです

Submarine.jsのアプローチ

Submarine.jsでは、まず上記の冪等なコードに必要な処理を、1度に実行するのではなく明確に分割しようと考え、現在の状態の確認手段を query、あるべき状態の定義(と確認)を test、状態を移行するための手段を command、として1つのクラスのメソッドとして定義できるようにしました

Correct-server-state-with-ssh.js

const Submarine=require('Submarine');

const CorrectServerState=class extends Submarine {
  query(){
    return {
      file_content: String.raw`
        test -r /tmp/submarine/hogehoge \
          && cat /tmp/submarine/hogehoge \
          || echo 'File not readable' \
            >&2
      `,
    };
  }

  test(stats){
    return {
      file_content_is_hogehoge: stats.file_content === 'hogehoge',
    };
  }

  command(){
    return String.raw`
      mkdir -p /tmp/submarine \
        && echo 'hogehoge' \
          > /tmp/submarine/hogehoge
    `;
  }


}


const state=new CorrectServerState({
  conn: 'ssh',
  host: 'server1',
});



state.correct()
  .then(console.log);

上記のコードで query は、キーと値のセットを返します。値はサーバの状態を確認するShellScriptの文字列で、キーは単なる名前です
test は query で定義したShellScript群の実行結果が引数として与えられ、それらが、あるべき状態か否かの複数の判定項目を判定して、判定結果をキーと値で返します
そして command では、判定結果に応じて実行したいShellScriptを文字列として返します

こうして定義されたclassをnewするときに接続先のホストを指定して correct 関数を実行すると query を実行し、その結果を test し、あるべき状態でないときだけ command で定義したShellScriptが実行されるようになっています

また command を実行せず query だけ、あるいは query と test だけを実行する関数も用意されています ( current と check という関数です)

当然、これらの処理を複数のサーバで実行する方法や、複数classの処理を順番に実行するような機構もあります(ここでの説明は割愛しますが)

こうすることで、冪等なコードに一定の秩序が生まれます。Shellの中に書くif文もかなり減らせます。しかもサーバの状態を確認する処理と、サーバに変更を加える処理が分離されたことで、変更の処理が実行されるかどうかを安全に確認でき、メンテナンス性も向上しています。

また command を実装せず、テストのためだけに利用するなど、応用範囲も広がります

その他、開発の経緯など

このSubmarine.jsのアイディアは、オブジェクト指向の世界で、CQS(コマンドとクエリの分離)や、その発展形であるCQRS(コマンド・クエリ責務分離)と呼ばれている考え方に触発されたものです

またJavaScriptを使って状態を管理するのはReact.jsやVue.jsに影響を受けています

HTTPの世界でGETやPUTとPOSTが明確に分けられていたり、データベースの世界ではCRUDのような概念があるように、インフラの世界でも「状態」を扱うのに適したフレームワークがあっても良いかなと思って開発してみました