読者です 読者をやめる 読者になる 読者になる

めもめも

このブログに記載の内容は個人の見解であり、必ずしも所属組織の立場、戦略、意見を代表するものではありません。

Literate Automation(文芸的自動化)についての考察

何の話かというと

www.slideshare.net

上の資料で解説されている "Literate Computing for Reproducible Infrastructure" という取り組みを進めているチームの方と一緒に仕事をさせていただく機会があり、この取り組みの「心」を聞かせていただいたのですが、むしろこれは、「Literate Automation(文芸的自動化)」と呼んだ方がしっくりくる気がして、ちょっと、私なりの観点でまとめてみました。

Ansibleの悩み所

Ansibleで運用オペレーションをPlaybook化して自動化するという動きが広がっていますが、実運用で本格的に使っていると、悩みもでてきます。

・どのマシンにどのPlaybookを適用したかという記録を残さないと、結局、現在の状態がわからなくなる。
・Playbookを適用する前提条件のチェックは、それなりに必要。
・Playbookの内容がブラックボックス化すると、違う環境に適用しようとする際に困る。
・そうは言っても、Playbookの適用に失敗することはあって、その時に何をチェックするかは、結局人間が判断する。
・Playbookの一部を適用する場合、タグを使うのがいいのか、そこだけ取り出したPlaybookを用意するのがいいのか、いろいろ悩む。

・・・やはり人類にはまだAnsibleは早いのか?!

という気にならなくもないですが、ここでのアイデアは、従来の手順書を丸ごとがっつりPlaybookに置き換えてしまうのではなく、

・手順書という形態はそのまま残しつつ、Jupyterを利用して、「実行可能な手順書」を実現する

という事です。この際、人間が1つのまとまりと理解できる(失敗した時に何が失敗したかを直感的に理解できる)単位で自動化して、その単位で実行手順を記載するという方針を取ります。

まずは具体例から

まずは、とっても簡単な具体例を示してみます。

enakai00.hatenablog.com

上記の記事では、MySQL + Etherpad-Lite を例として、

(1) テナント環境を整える(公開鍵登録、セキュリティグループ作成など)
(2) VMインスタンスを起動する
(3) Cinderボリュームを接続する
(4) Cinderボリュームをフォーマットしてマウントする
(5) コンテナでアプリをデプロイする

という一連の作業を全部まとめてPlaybook化する話をしています。

これを前述の方針で分解した上で、Jupyter Notebookによる「実行可能な手順書」に書き直すと、次のようになります。(リンク先のGitHubでNotebook形式で閲覧できます。)

Deploying therpad-Lite

実際にこのNotebookを利用できる環境の作り方も簡単に示しておきます。

itpro.nikkeibp.co.jp

(1) 上記の連載記事の手順で、OpenStack環境を構築して、Dockerをインストール済みのVMテンプレート「Docker01」を作成する。
(2) Docker01からVMを起動する。(セキュリティグループでTCP8888へのアクセスを許可しておく。)
(3) VMにログインして、次の手順で、Jupyterコンテナを起動して、コンテナ内にAnsibleをインストールしておく。

$ sudo -i
# docker run -itd --name jupyter -p 8888:8888 -e PASSWORD=hogehoge enakai00/jupyter_tensorflow:latest
# docker exec jupyter pip install ansible==2.0.1.0 shade==1.5.1 

(4) Webブラウザーから上記のVM(フローテイングIP)の8888番ポートにアクセスして、パスワード「hogehoge」でJupyter環境にログインする。
(5) 先ほどのNotebookをアップロードして使用する。

なお、これは、あくまで説明用の簡単なサンプルですが、冒頭で紹介したチームの方々は、この手法でわりと本格的にHadoopクラスターやOpenStack環境のメンテナンスをしていたりします。

www.slideshare.net

活用方法のアイデア

ここからは、先ほどのNotebookをGitHub上でじっくり眺めながら考えてみて欲しいのですが、これを利用すると前述のいくつかの悩みが解決できる可能性が見えてきます。

・何も考えずに丸ごと自動化したい人は、Notebookの内容を全部自動実行すればよい。
・Notebookの各ステップは、修正しながら実行することができるので、環境ごとに変更が必要な点は、Notebookの説明を読みながら書き換えて実行することもできる。
・実行結果そのものがNotebookに残るので、別名保存する(というか、最初にNotebookをコピーしてから使用する)ことで、作業記録として保存することができる。作業時に気づいたことなどもNotebookにそのまま記録できる。
・Notebookの一部の作業だけを選択的に実施することもできる。
・各ステップを実行した後の確認作業も、手順として記載できる。

最後の確認作業については、ある程度、手順が安定的に確立してくれば、確認作業自体も自動化するという手もあります。

今後の課題

上記のような活用を進めていくと、Notebookのモジュール化、リファクタリングという作業が必要になるのは、容易に想像できるでしょう。複数の手順書に共通の作業について、AnsibleのPlaybookとして共通化するのは容易ですが、そうではなく、前後の説明を含めたNotebookの一部(1セクション)をモジュール化して、複数のNotebookにはめ込むような機能です。

あるいは、既存のNotebookの一部をリファクタリングして改善したり、既存のNotebookをフォークして流用したり・・・というアイデアもでてきます。

これって結局、

・手順書を「プログラムコードにそのまま置き換える事無く、手順書という形式のままで」プログラムコードのようにメンテナンスしたい

って話ですよね。

というわけで、こういう感じの機能がJupyterで実現できるといいなぁー、と思うのですが、みなさんはいかがお考えでしょうか?