大学院でやってよかったこと

これは何

　ついに大学院情報工学専攻（修士）を修了してしまうため，何かポエムが書きたくなりました．ネットには研究室への怨嗟が溢れていて*1，大学院が楽しいとか（当たり前の人にとっては当たり前過ぎて）あんまり書いてないので，じゃあ自分で書いてみようという感じです． 実験系（ウェット）な人たちには「は？」と言われることが多々ありそうです．気をつけてお読みください．

　また，僕自身は大学院から専攻を変えたため，あまり一般的な大学院生とは言いがたい可能性があります．専攻を変えた経緯は以下の過去記事を参照のこと．

poyo.hatenablog.jp

完走した感想

ゴールした人のイラスト

　大学院の2年間はあまりにも早く終わってしまい，あまり実感がありませんが，おおよそ楽しく充実した時間でした．「大学院進学やめとけばよかった」と考えたことは，おそらく一度も無いと思います．残念ながら（今のところ）目に見える実績が無く，研究活動として見たときには大失敗だった可能性もありますが，様々な面で成長を感じた2年間でした．特に修士論文は自分でテーマを決め執筆まで行ったことで，大きな自信となりました．就活も特に危なげなく終わり，4月からは東京で働きます．頑張っていくのでよろしくお願いします．

　特にWeb系の一部では「大学院に行くよりさっさと働いた方がいい」という風潮があるように感じますが，コンピュータサイエンスの修士を修めることにはそれなりの意義があると思います．修士の価値は自分で決める，そういうことだと考えています．自分が修士に価値を感じることが出来たのは，ひとえに研究室のメンバー及び先生方のおかげです．ありがとうございました．研究室の今後のますますの発展を祈っています．

大学院の良かったところ

　結局，どういう研究室に入るかによってこの辺りは大きく変わってくると思います．そういう意味では，「大学院の」というよりも「研究室の」良かったところですね．

• （卒業できれば）修士号が手に入る
• 研究室という空間を2年間フルに使える
• 研究について技術的なものからメンタル的なところまで相談できる相手が居る
• レベルが近いまたは上の相手が多い
• 純粋な興味ドリブンで好きなだけやっていい

興味があるからというだけの理由でこれだけ時間を好きに使って没頭できる機会はそう無いと思います．4回生ではあまりにも時間が短すぎ，できることが限られてしまう上，どうしても先生や先輩の言うことをはいはい聞くだけの存在になりがちです．自分主導で研究を進めることは，基本的には修士以降で初めて出来るような印象が強いです．とりあえずで進んできて良い場所では無いと思いますが，ちゃんと覚悟をしてきている人にとって少なくとも悪い場所にはなり得ないはずです．皆様，進学の方，いかがでしょうか．

やって良かったこと

　この2年間，授業・自身の研究を除いて，やってみて良かったことを6つ取り上げたいと思います．そんなに奇抜なことはしていません．また，就活についても特に言及していません．分野によってあまりにも大きな差があり，参考にならないと考えたためです．

1. とにかく物を捨てる

故人のコレクションの処分に困る人のイラスト

　この作業で僕の大学院生活はスタートしました．研究室というのは，よっぽど新興のところで無い限り，最低でも数年から数十年という年月が積もり積もった場所です．しかも大抵研究者は整理整頓が苦手です*2．そのため，学生の生活空間がどうでもいいもので溢れていることが多いです．先生の了解を得つつ，どんどん捨てていきました．

　2~3年しかいない環境を整備するモチベーションが湧かない人の気持ちも理解出来ますが，綺麗にすると単純に周りから感謝されて気分が良いのでお得です．

2. とにかく掃除する

清掃業者のイラスト

• 明確に掃除する時間が無い
• ゴミは限界まで溜める
• 水回りを誰も掃除したことがなく，臭い
• 掃除する気がない

など，特に男ばかりの研究室ではありがちな気がしています．率先してゴミを捨て，部屋を掃除しました． 他に，複雑なゴミの分別ルールについての周知や，なくなってきた消耗品の購入リクエストなども行っていました．これも単純に周りから感謝されて気分が良いのでお得です．

　特に部屋の匂いはため込んだゴミの他に水回りなどが原因のことがあり，キッチンハイターで三角コーナーと排水溝を漂白・殺菌するだけで多少マシになります．

3. 細かい不満を設備投資で潰す

貢ぐ人のイラスト

　買って良かったものリストです．研究室で使って良かった物は以下の通りです．

• 短焦点プロジェクタ
  • 10万円くらいだった
  • 上から吊らなくても十分有用
  • 空間を広く使えるようになる他，常にスクリーンの目の前に置いておくことでカジュアルに使えるように
• メタルラック
  • サーバにしているマシンの置き場
  • 高さを自由に変えられるので収納したいものを最適な形で仕舞える
• 多少マシなモニタ
  • 43インチ4Kや，フルHDだがUSB-C1本で出力と給電ができるもの*3など
• 椅子
  • 古い物を捨てて新しいものにリプレース
  • 座り心地が悪い/キャスターの滑りが悪いなどは地味にストレスなため
• 荷物置き用バスケット*4
  • 明確に各自のカバンを置く場所が出来ると，なんとなく部屋が片付いて見える
• スタイルハンガー*5
  • コートなどを椅子にかけている研究室におすすめ
  • いつの間にかずり落ちて床に…とかならなくて良い感じ
• 大判のウェットティッシュ
  • 机を拭いたりするのに雑巾はどんどん汚れてあまり衛生的ではない
  • 使い捨てることが出来るウェットティッシュは掃除のハードルを下げる
• キッチンペーパー
  • 食器用布巾は使い込まないと水を吸わない
  • 研究室では洗濯もしづらいので不衛生……
  • よく水を吸ってくれて使い捨てれるので便利

プロジェクタや4Kモニタ以外は比較的安価なものを並べたつもりです．ちなみに個人で買って良かったものは以下です．

• iPad Pro + Apple Pencil
  • 圧倒的に捗る
  • これ一台で論文を読んで校正もできる
  • 論文を紙で読む時代は終わった
• Air Pods
  • 研究室ではカジュアルに研究の話を振られたり，来客があったりするため，周囲の音が聞こえるイヤホンが便利だった
  • 最初はAmbie Wirelessを使っていたが少し耳が痛いのが気になり売却
• USB-Cの給電アダプタ
  • 移動する場所全てに置いておいた
  • 充電器の持ち運びを減らせるのは楽
• 大乱闘スマッシュブラザーズSPECIAL
  • ストレス解消や学生の交流に大変良い
  • ちなみに負けるとストレスが溜まるので勝つことがストレス解消の秘訣*6

金は正義です．

4. コミュニケーションのハードルを下げる

会話をするカラスのイラスト

　そもそも弊研究室ではSlackを導入しており，メールなどよりはハードルが低かったです．未だにメーリングリストというところも多いようですが，正直メールは今の学生に馴染まないと思います．特に全体連絡に対して返事するべきかどうかとか，後から会話に参加する人がこれまでのやりとりを見れないとか……返事せずともリアクションで態度を表明でき，話題ごとに話す場所を分割できるSlackやDiscord，Microsoft Teamsなどの導入がおすすめです．そういったツールが導入されていても，DMやプライベートチャンネルがメインとなってしまうと効果は半減です．僕は積極的に研究のネタになりそうな内容や，アドバイス・質問等をSlackの公開チャンネルに投げることで，情報をオープンにし共有する文化の醸成を目指しました．完全に上手くいったとは言いがたいですが，まぁやらないよりは良かったかなと思っています．

　オフラインでのコミュニケーションでも，後輩に積極的に話しかけたり，先生とカジュアルに話すところを周囲に見せたりなど，より話しかけやすい雰囲気を作ることを意識していました．積極的に各自が今の状況を（フォーマルな形ではなくカジュアルに）共有する雰囲気を作ることで，自分だけでなく周囲の人のガス抜きもできていたのではないかと考えています．楽しかったとは言っても研究がつらいことは多数あったため，気軽に愚痴を言えたり，どうするべきか相談できるというのは重要だったと感じました．

5. 研究相談に積極的に応じる

カウンセリングを受ける男性のイラスト

　まず前提として弊ラボは学生数に対して先生が少なく，かつ教授が様々な事情で多忙であり，何もかもを教授に見てもらうという体制を取ることが難しいという実情がありました．そのため，以前から論文は一旦同期や先輩の校正を通してから先生に見せるというスキームがありました*7．研究の方針についても全て教授にお伺いを立てるのではなく，先輩と相談するなど学生間で方針を決め，ある程度進めながら詰まったら教授と話し合うといった進め方をしていました．とはいえ，自分のものでない研究に付き合う義務は特にないため，相談に乗る行為や校正は完全にボランティアです．今年はM2 7人+B4 4人という大人数が修論/卒論を執筆する関係上，容易にパンクすることが予想されたため，さっさと論文を書いて校正に回ることを決めていました．

　結果として，研究方針の相談までは深く関われませんでしたが，考察に対する批評や，論文自体の書き方など多数の面で後輩/同期の執筆に関わりました．いくら専攻する分野（ソフトウェア工学）が同じとは言え各自の研究内容は大きく違うため，研究の内容理解からしっかりとする必要があり，様々な発見がありました．単純に複数本の論文を書いたようなものなので（？），お得です．一度で二度，三度美味しいみたいな感じです．ただし，余裕が無いと死んでしまうので計画的に早く終わらせましょう！！！

　加えてドクターの先輩の研究相談に関わったりしたこともありました*8．これもドクターまで行く人が

• 日頃からどれくらい研究しているのか
• どのように見通しを立てて研究をしているのか
• うまく行っていないときにどうメンタルを保っているのか*9

など，身近で見て感じることが出来たのは大きかったです．自分にD進は向いていないなと分かったのも良かったですね．

6. 負債の返却

便利屋・なんでも屋のイラスト

　果たしてこれは返却できたのか新しい負債を増やしたのかまだ判断できませんが，とにかくこういうことをやっていました．

poyo.hatenablog.jp

中でも，Wikiをesa.ioへ移行できたのが最も大きな進歩だったと思っています．それまでほとんど誰も書いてくれなかったWikiが1年間で数百記事以上に成長し，大きく貢献できたと感じています．もちろん他のメンバーの執筆を促進するために自分もたくさん書いたという面もあり，そのモチベーションは以下の記事にまとめています．

poyo.hatenablog.jp

これから

運動会の徒競走でスターターピストルを鳴らす先生と、スタートラインに並ぶ生徒たちのイラスト

　さて，冒頭にも書いた通り，僕はこれから社会人として労働をやっていくことになります．修士卒という意味では，多くの人が自分と同じスタートラインに立っていると言えるかと思います．普通に研究したあの子も，死ぬほど研究して賞も取りまくった彼も，2年間遊んでいて卒論から進歩があんまり無かったあいつも，僕も，みんな同じ修士号です．単なる修士卒として埋没しないよう，自身の強みをさらに伸ばし，弱点を補っていきます．よろしくお願いします．

---

*1:主観です

*2:これも主観ですが今のところほとんどの人には当てはまっていると感じています

*3:DELL P2419HC．2万円前半で安いのでオススメ

*4:カフェとかの足下にあるようなやつ www.askul.co.jp

*5:こういうの www.askul.co.jp

*6:別に強くないので負けまくった

*7:周囲の話を聞いていると，意外と多くのラボではこれをやっていないっぽい？誤字脱字の指摘だけでもやれば良いのにと思います

*8:単に「いやそれは無理でしょ〜〜〜」ばっかり言ってた気はしますが……

*9:だいたいスマブラするかボドゲやるか酒を飲むかアニメ見るかでした

Moleculeを使う際にTestinfraからAnsible Factsを参照する

概要

　Ansible公式のテストフレームワークであるMoleculeは，Ansibleによる構築の後に，デフォルトではTestinfraによるテストを実行します． Testinfraにはhost.ansible.get_variables()というAPIがあり，これを介してAnsibleの変数を取得できるように見えます．が，実際にはinventoryやhost_vars，group_varsに記載されているもの以外の値を取ることができません．

　ここでは，Testinfraによるテストコードから，gather_factsによって収集される変数やRoleのdefaultsやvars内で定義されている変数を参照するハックを紹介します．ただし，これは完全にAnsibleの挙動と同じであるとは言えないかもしれないという点に注意してください．

環境

• macOS 10.15.2 Catalina
• Python 3.7.5
• Ansible 2.9.2
• Molecule 2.22
• Testinfra 3.4.0

ここでは単体のRoleのテストのみを取り扱います．Roleのディレクトリの構造は以下の通りです．

$ tree -L 2 /path/to/role
/path/to/role
├── LICENSE
├── Pipfile
├── Pipfile.lock
├── README.md
├── defaults
│   └── main.yml
├── meta
│   └── main.yml
├── molecule
│   └── default
├── tasks
│   └── main.yml
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

Testinfraにおける問題点

　TestinfraはAnsibleと完全に統合されているわけではないため，構築の実行中に使用される変数を取得することができません．これにより何が起こるかというと，複数のプラットフォームに跨ったテストを書くときにifを大量に並べることになります．

テストコード中では以下のようにOSの情報を取得できます*1

def test_hoge(host):
    dist = host.system_info.distribution
    if dist == 'debian':
        # some action
    elif dist == 'ubuntu':
        # some action
    elif dist == 'darwin':
        # some action
    elif dist == 'centos':
        # some action

正直めちゃくちゃ面倒臭い……インストールするパッケージのバージョンチェックなども，このままではバージョンをハードコードすることになり，Role内の値を変更するときにテストコード内も全て変更したりする必要が出てきます．

　さて，ここで救世主のようにみえるTestinfraのAPIHost.ansible.get_variables()の実際の実装をみてみましょう．

https://github.com/philpep/testinfra/blob/3.4.0/testinfra/utils/ansible_runner.py#L172-L189

ansible-inventoryコマンドを叩いてインベントリの情報を収集している以外は過去のバージョンとの互換性を保つためのコードのようです．つまり，get_variables()とは言いつつも，実際にはインベントリに記述されている情報しか取っていません．

既存のアプローチ

いくつかのIssueで議論されています．

github.com

github.com

これらの中でも直接YAMLとして読み込んだり，include_varsやsetupを使用した方法が紹介されていますが，これらは誤った用法によりうまく変数を解釈できていません．

• YAMLとして読み取る
  • これは論外
• include_varsを使う
  • 一見うまく動作するように思えるが，これも実際には変数の解釈をしない
  • 例） hoge: "{{ ansible_python_interpreter }}"のようなYAMLをロードしても{"hoge": "{{ ansible_python_interpreter }}"}が返ってくるだけ
• include_vars + setup + ansible.template.Templar
  • https://github.com/philpep/testinfra/issues/345#issuecomment-468814489
  • かなり惜しい
  • 使い方が間違っている

Testinfraから変数を参照する

　ようやく本題です．変数を取得する方法は雑にいうとAnsibleのinclude_varsとsetupモジュールを使い，自分でファイル読み込みの優先順位を定義して順に読み取っていきます．読み込んだ変数を優先度順に ansible.template.Templar で解決していきます．
　Testinfraが内部で採用しているテストフレームワークであるpytestの作法に則って，fixtureとして実装します．

setup

まず，setupモジュールを使用してAnsibleのFactsを収集します．

import pytest

@pytest.fixture(scope='module')
def ansible_facts(host):
    return host.ansible("setup", "gather_subset=min")["ansible_facts"]

これはそれなりに重いので，

1. gather_subsetやfilterなどの引数を使って必要な変数のみ取得*2
2. fixtureのスコープをmoduleにすることで，複数回の取得を防ぐ

等で多少早くなります（たぶん）．

　このansible_factsというfixtureは単にいつも使っているFacts*3がそのまま返ってきます．

include_vars

　include_varsを使って各変数定義ファイルを読んでいきます．

from ansible.template import Templar
from ansible.parsing.dataloader import DataLoader

@pytest.fixture(scope='module')
def ansible_vars(host, ansible_facts):
    # リストの後にいくほど優先度が高い
    # host.system_infoを利用すれば，OSごとに読み取るvarsを変更している場合にも対応可能
    var_files = [
        "../../defaults/main.yml",
        host.ansible.get_variables(),
        "../../vars/main.yml",
    ]
    templar = Templar(loader=DataLoader())
    # 優先度順に読んでいく
    all_vars = {}
    all_vars.update(ansible_facts)
    for f in var_files:
        if isinstance(f, str):
            var_from_f = host.ansible(
                "include_vars", f"file={f}")["ansible_facts"]
        else:
            var_from_f = f
        # 変数の出現順に埋め込みを解決
        for key, val in var_from_f.items():
            templar.available_variables = all_vars
            all_vars[key] = templar.template(val)
    return all_vars

ディクショナリの順序が保証されているPython 3.6以降でしかうまく動作しない気はしています．

　templar.template()は引数にディクショナリも取ることができるのですが，その際，解決すべき変数がそのディクショナリ内に含まれている場合にうまく動作しません． 例えば以下のようなファイルを読み込み，そのまま渡すとうまく解決することができずにエラーになります．

---
hoge: "hoge"
hogefuga: "{{ hoge }}fuga"

そのため，まずはhogeという変数を解決してTemplarの持つ変数のディクショナリを更新し，次にhogefugaを解決するようにしました．

テストで使う

　実際のテストコードへの実装は非常に容易です．例えばインストールされているべきパッケージの一覧をinstalled_packagesとして定義しているなら，以下のようにします．

def test_hoge(host, ansible_vars):
    expected_packages = ansible_vars.get("installed_packages")
    for expected_pkg in expected_packages:
        actual_pkg = host.package(expected_pkg)
        assert actual_pkg.is_installed

メリット

• 煩わしいOSの判別を一部不要にできる可能性がある
• Role側がデフォルト値を変えただけなどの場合に，テストを手動で修正する必要が無くなる

デメリット

• そもそもRoleのデフォルト値が間違っていたりするとテストの意味がなくなる
• setupが重いため，内容次第ではテストが遅くなる可能性がある
• 完全にansible-playbookコマンドによる実行と同等とはいえず，また，内部のAPIを直接参照しているため，今後も互換性が担保されるかわからない

現時点での制限

• Role中のタスクでset_factしたりregisterしている変数は参照できない
• 変数の優先順位を人が解決する必要がある

などなど．現時点での実装があまり賢いとは思っていないので，もしより良い方法を知っている人がおられれば教えていただけると幸いです．

---

*1:https://testinfra.readthedocs.io/en/latest/modules.html#systeminfo

*2:https://docs.ansible.com/ansible/2.9/modules/setup_module.html

*3:https://docs.ansible.com/ansible/2.9/user_guide/playbooks_variables.html#variables-discovered-from-systems-facts

Ansibleの冪等性について深く考えたことはありますか？

はじめに

　僕は今，修士論文の執筆に向けて構成管理ツールと冪等性についての論文を複数読んでいます．それらを踏まえて，一般によく見られるAnsibleへの誤解についての自分の見解，そして2019年現在，構成管理ツールについてどういった研究がされているかを簡単に述べていきたいと思います．

冪等性

　そもそも冪等性とは「ある操作を一回行っても，複数回行っても，結果が変わらない」という概念です．例えば，

• 例えば1や0と任意の自然数のかけ算
  • 
  • 
• 絶対値の計算
  • 

などが冪等性を持った処理に当たります．

Ansibleにおける冪等性

　さて，Ansibleのモジュールを使用した操作はよく冪等であると言われています．ここで，Ansibleにおける「冪等」とは何でしょうか？Ansibleの用語集*1を引いてみます．

An operation is idempotent if the result of performing it once is exactly the same as the result of performing it repeatedly without any intervening actions.

訳すなら，「一度実行した結果が，介入する操作無しで繰り返し実行した結果とまったく同じならば，操作は冪等である」という感じでしょうか*2．うーんなんとなくいいかんじに思えますね！（？

　しかしこの「まったく同じ」というのは何を要求するのでしょうか．例えばlineinfileモジュールを用いて，あるファイルにある行が一文あるということを宣言したとします．

- lineinfile:
    path: /path/to/hoge
    line: "Some line"

実行したとき，必ず一度はその存在を確認するためにファイルにアクセスする必要があります．すると，その行がある場合も無い場合も，Linuxではそのファイル（ここでは/path/to/hoge）のatime，つまりアクセス日時が更新されてしまいます．また，（オフに設定しない限り）実行の度に対象のホストへログも書き込まれます．これは「冪等性」を満たすのでしょうか？

冪等性は主観によって決まる

　おそらくほとんどのケースでは，atimeの更新やsyslogへの書き込みのような，求める操作に伴う暗黙的な副作用は問題にならないでしょう．この場合には「（当人から見て）冪等性は満たされている」と言えるかと思います．しかし逆に，（あるのか知りませんが）atimeが重要で容易に更新されて欲しくないケースにおいてはどうでしょうか？もしかすると，「（当人から見て）冪等で無い」と考えるかも知れません．

　このように，構成管理ツールにおける冪等性というものは，実際にはその結果を観測した人の主観に左右されます．冪等なモジュールであるからといって，得られる結果が完全に何もかも実行前と同じとは限らないということに留意した上で，こうしたツールと付き合っていく必要があるでしょう．

　このような必ずしも何もかもが完全に同一とはならない現実のシステムにおいて，「冪等」という概念をそのまま適用することは非常に難しいと言わざるを得ません．あまりしっくり来る定義を見つける事ができなかったのですが，天才*3から教えてもらったRFC7231の4.2.2*4がなかなかしっくりくるなと思ったので紹介します．ここではGETやPUTなどのHTTPリクエストについて，どのような場合にそのリクエストを「冪等」と見なすかを述べています．

Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free to log each request separately, retain a revision control history, or implement other non-idempotent side effects for each idempotent request.

つまり，「冪等」と判定する要素は，ユーザが要求した属性についてのみであり，それに伴うサーバサイドでの副作用（例えば各リクエストについてログを取るなど）は感知しないということのようです．Infrastructure as Codeの文脈において考えてみても，各ツールはユーザが要求した属性（例えばファイルの存在とか）についてのみ冪等であることを保証できるように努力し，それに伴う副作用（サーバサイドにログが残る，atimeが更新される…etc）については保証しない，という考え方をすれば，比較的まともな「Ansibleにおける冪等性」への理解を得られるかと思います．

モジュールの冪等性

　現状構成管理ツールのあるモジュールによる操作が，（他の何らかの操作の介入を受けなかったとしても）完全に冪等性を保証することは知る限りでは証明されていません*5．つまり，Ansibleによる操作が完全に冪等であることを，誰も保証してくれません．もちろんIssueには冪等性（idempotence）に関するものも多くあり，努力はされていますが，最終的には自分で検証してなんとかするしかありません．
　このような現状なので，当然どのモジュールのドキュメントにも，「これは冪等なモジュールです」とは書いていません．Issueを漁っていると，過去に「冪等かどうかドキュメントに書いてくれ」というものが上がっていました．

github.com

これに関連したIssueコメントは以下です．

github.com

非常に短いメモが残されているだけなので，実際のその場での議論などは分かりませんが，

• 冪等でないモジュールもある
• でもそれらのために多大な労力を払って冪等かどうかを表示するのはコストが高すぎる
• 今のところ何もしない

というような決着を迎えたようです．以降これに関連したIssueは探しましたが見つからず，Ansibleの方向性として冪等性のしっかりとした証明は目指さず，あくまで努力目標であるということが伺えます*6．活躍するドメインから考えても，これはあくまで実務上のツールであり，理想を追い求める物ではないので，この判断は正しいことだと思います．

　とはいえ，冪等な操作を売りにしているツールにしては，そのやり方でみんな納得しているのか？という気持ちがあります．

Playbookの冪等性

　全てのタスクが冪等であったとしても，複数のタスク・ロールを束ねたときに，全体を通して冪等になるとは限りません．例えばあるミドルウェアをインストールするというロールと，そのミドルウェアをアンインストールするというロールを同時に使用すれば，毎回インストール→アンインストールを繰り返すことになり，冪等性が保たれなくなります*7．

　こうした事象を避けるためには，

• 一つのRoleの責務を小さくかつ明確にすること
• Ansible GalaxyなどでインストールしたRoleの中身に一度は目を通しておくこと

などが重要かと思います．

構成管理ツールについての研究の今

　それなりの数に目を通したのですが，ちゃんと研究になっているものとしては以下の3種類に分類できると考えました．現状この分野の研究はほぼPuppetのものに限定されており，Ansibleは構成管理ツールとしての紹介がされているのみです．

冪等であるかどうかをテストする系

　2013年にChefのCookbookを対象に，冪等性検証フレームワークを提唱した論文です．LXCを使用して実際にCookbookを実行するのですが，ただ二回実行するというような方法ではなく，STGという状態遷移グラフを構築して様々な実行パターンを検証します．状態の変化の検知にはOhai*8を使用していたようです．

Testing Idempotence for Infrastructure as Code | SpringerLink

2016年に上の論文の結果を受けてPuppetでの冪等性検証フレームワークの提唱をしたのが下記の論文です．Ohaiを参考にした上で，straceやptraceを使って任意のファイルの変更まで追いかけたのが特徴です．

Asserting reliable convergence for configuration management scripts

結果の可視可もよく出来ています．

citac.github.io

同じく2016年にPuppet向けの冪等性検証フレームワークとしてRehearsalというものを提唱した論文です．これは単にPuppetコードを実行するのではなく，Puppetの各リソースを彼らが提唱したファイル操作をするための小さなDSLに置き換え，Puppetの非決定的な実行順序による操作のコンフリクトを検証できます．

Rehearsal: a configuration verification tool for puppet

難しいのでしっかりとは読み込めていませんが，そもそも構成管理ツールのある操作は任意のファイルへの操作であると考えると，これは割と面白いアプローチかと思いました．

品質モデルを提唱する系

　2016年にMSRというリポジトリマイニングの国際会議にて提唱された，Puppetコードのコードスメル*9に関する研究です．いわゆるバッドプラクティスを検知して「匂う」コードを見つけようというものです．

Does your configuration code smell?

下記の論文では，Puppetコードの品質モデルを提唱しています．実際に開発者らへのアンケートからモデルを定義し，自社・他社のPuppetエンジニアによる品質の分類と，品質モデルによる分類を比べて，ある程度正確な品質モデルを定義する事が出来たと述べられています．

How good is your puppet? An empirically defined and validated quality model for puppet - IEEE Conference Publication

セキュリティ系

　以下の論文も又コードスメルの検出なのですが，内容がよりセキュリティに寄っています．

2019.icse-conferences.org

以下のブログに簡単なまとめがあります．

jagijagijag1.qrunch.io

IaCに関する研究はブルーオーシャン

　ここでは構成管理ツールに関する研究に絞っていますが，IaC（というかDevOps）という分野自体が若く，研究はあまり進んでいません．実務と結びついた領域であるために，研究者が手を出しにくい分野なのかもしれません．出すなら今ですよ！（？

　特にそのツールや概念に詳しい研究者を集めることは容易ではなく，GitHubなどから開発者らにメールを送ってアンケートに答えてもらう，など，泥臭いことが多々行われています．その回答率も芳しくなく，結果の信頼性としてもかなり微妙と言わざるを得ません．Ansibleはユーザコミュニティも活発で，実務で使用しているプロフェッショナルが多数います．研究にはもってこいなのでは？ 🤔

まとめ

• Ansibleに限らず，構成管理ツールにおける冪等性というものは，使用者の主観によって左右される
• 今のところ，Ansibleモジュールが真に冪等であることは証明されていない
• モジュールが冪等だから！と適当にやっていると容易に冪等性を失う
• IaCは実務に関わる部分が大きく，研究者にはなじみが薄いため，論文を書き放題
  • ツールへの造詣が深いエンジニアの意見を使って論文が書けるのは企業の強み
  • 是非いかがですか？

---

*1:https://docs.ansible.com/ansible/2.9/reference_appendices/glossary.html?highlight=idempotency

*2:ニュアンス違ったらすいません

*3:弊ラボのドクターです

*4:tools.ietf.org

*5:これは研究者の怠慢であるかもしれませんね

*6:続報があるとか何か知っておられる方いらっしゃれば教えてください

*7:こういうのをAnsibleのdry-run時に検知する方法とかないんでしょうか？

*8:github.com

*9:qiita.com