fabric

意識の低い自動化

More than 3 years have passed since last update.


意識レベルを低く保ったまま自動化する話

世の中にはChefやらAnsibleやらPuppetやらと様々な自動化ツールがあって、

意識の高いはてな民は日々「Chef-soloはオワコン、いまやChef-zeroの時代」

「Ansibleなら対象サーバへの事前準備が不要、時代はAnsible」といった不毛な会話を繰り広げていると聞く。

「モダンなエンジニアは全員Chefを使いこなしているものだ」みたいな空気すらある。

なるほど、自動化ツールの学習は興味深いし楽しい。

大規模なサーバ群が次々と自動的にセットアップされてゆく様子は感動すら覚える。

が、私がやりたいことはリモートサーバのログを消したいだけなんだ、コマンド2つで済む内容なんだ・・・というときにはちと大仰すぎる。

「鶏を割くに焉んぞ牛刀を用いん」とはよく言ったものである。

シェルスクリプトで済むような内容、特に冪等性が必要ない場面、日常の中ではそういった小さな問題に出くわすことも多々あろう。小さな問題には小さなツールで対処したい。

そういう気持ちで以下のスライドを作りました。どうぞご笑覧ください。


スライド

以下のURLから見てください。

Qiitaってslideshareの埋め込みできないんですね


補足

はてブを見ていると、言葉足らずのために誤解させてしまっている部分があるようです。申し訳なく思います。

以下で補足させてください。


「シェルスクリプトのメンテとか絶対したくない。正気?」


『shellscriptメンテ不要は大嘘だし絶対に他人が書いたshellscriptのメンテやりたくない』 from mizchi http://b.hatena.ne.jp/entry/235456400/comment/mizchi


おそらく、「メンテナンス」という言葉の定義が違っています。mizchi氏は shellscriptベースだと可読性が落ちるので、自動化したい内容が変わったときに書き換えが困難になる ということをおっしゃっておられるのだと思います。

反対に、スライドでは 自動化したい内容は変わってないのに自動化ツールのアップデートによってスクリプトの書き換えが発生する ということを指しています。自動化ツールの文法が変わったり、コマンドが廃止されたり、自動化ツール自体が古くなったりするということです。

スライド内で記述している shellscriptはほぼノーメンテ とは、 shellscriptは30年以上文法が変わっていないので、(やりたいことが同じで、shellscriptから叩いているコマンドが変わらず実装されつづけているなら)30年前のshellscriptでもノーメンテナンスで使える という意味です。

そういう意味では、Python2.7は2020年まで使えることが確定していますし、Fabricもメジャーバージョンが1を越えていて、破壊的な変更が入る可能性は低いと思われます。実際にchangelogを見ても、ほとんどがbugfixとfeatureの追加のようです。

では、やりたいことが変わったらどうするんだ、 というご意見について。

shellscriptの可読性が低くなる大きな要因に、「文法の複雑さ」と「例外処理の弱さ」があることは皆さんも異論がないと思います。fabricは、shellscriptのそういった弱点をPythonに任せることで、可読性と学習コストの低さを両立させています。

以下にfabric/cuisineを使ったスクリプトの例を紹介します。一度目を通してみてください。びっくりするくらい読みやすいですよ。

https://gist.github.com/Vossy/1035890


「Python3に非対応みたいだけどどうするの?」


『うーん、分かるんだけど、Python2.xのみや追加の依存(Cuisine)が出てきてアレレ感。』 from habarhaba http://b.hatena.ne.jp/entry/235456400/comment/habarhaba


Python2.7は2020年まで使えることが保証されていて、Fabricは十分に枯れています。

移り変わりの激しい自動化ツール情勢を鑑みると、あと5年ほぼノーメンテで使えるツールって、魅力的じゃないですか?

2020年になったらまた別のツールを探すことにして、それまでは楽をしましょうよ。fabfileとして作業をまとめていれば、次の乗り換えの時もスムーズに移行できるはずです。


「Ansibleでもシェルコマンド叩けるよ?」


『Fabric よく知らんけどこれ見る限り Ansible の下位互換っぽい』 polamjag http://b.hatena.ne.jp/entry/235456400/comment/polamjag

『ansibleもシェルベースで書けるが?』 love0hate http://b.hatena.ne.jp/entry/235456400/comment/love0hate

『ansibleのほうがfabricより自動化らくよ。シェルかけるしハイブリッドにいける。』you21979 http://b.hatena.ne.jp/entry/235456400/comment/you21979


Ansibleにもcommandモジュール・scriptモジュールがあって、fabricと同等のことができる、というご意見かと思います。

なるほどその通りなのですが、Playbookやyamlといったことを学ばずとも使える、fabricの「意識の低さ」 = 「学習コストの低さ」をご理解いただけると嬉しいです。 まあPythonは学んでいただく必要があるわけですが。

またAnsibleと違い、fabfileがPythonスクリプトそのものなので、Pythonの豊富なモジュールを柔軟に利用できるのも大きな魅力です。

たとえば、botoGCE Python Client Libraryと連携させて、 アプリのテストが通ったら、GCEに新しいインスタンスを建ててデプロイし、Route53に登録しているドメインを書き換え、疎通が取れたら古いインスタンスを消す といったことがワンコマンドで可能です。

ちなみに、スライドではrun()/sudo()/local()しか紹介しませんでしたが、公開鍵認証によるSSHログインやテンプレートconfigを変数で書き換えながらリモートに設置等、サーバ管理に必要な豊富な機能も用意されています。

そういう意味では、Ansibleの下位互換というより、方向性の違う競合アプリというほうが正しいかもしれません。


その他


『「元スクリプトとちょっと違う挙動を求めるために新しいシェルスクリプトを書く」って作業が増えそうだけど、ありっちゃありか。』 ngsw http://b.hatena.ne.jp/entry/235456400/comment/ngsw


共通部分をPythonの関数に切り出してやれば、使い回せますよ :)


『capistranoに似てるのか。それにしてもPythonなりRubyなりを初期状態で導入するサーバ環境ってのも結構贅沢な気が…(WebAppサーバ≒Tomcatな職場にしか居たことがない人間)』 DustOfHumanDustOfHuman http://b.hatena.ne.jp/entry/235456400/comment/DustOfHuman


FabricとCapistranoには多くの類似点があります。実行したい内容を逐次書いていくところや、コマンドの引数もよく似ています。

CapistranoがRubyタスクランナー兼デプロイツールとして機能するように、fabricもタスクランナーやデプロイツールとして利用できます。

たとえば、静的サイトジェネレータのPelicanは、タスクランナーとしてfabricを採用しています。

デプロイやサーバ管理に限らず、柔軟かつ簡便にさまざまなタスクを記述できるのがfabricの特徴です。

ちなみに、Pythonをサーバ側にインストールする必要はありません。タスクを実行する手元のマシンに入っていればよく、対象のサーバにはsshで接続出来れば十分です。