Capistrano 万能論に疑問符

IT エンジニア向けの記事です。

Capistrano は Ruby 製の deploy ツールだ。

中々良い出来だと思う。何ができるのか、何が良いのかはちょっと検索すればすぐに出てくるだろう。ただ、状況にもよるだろうが俺の場合 Capistrano を積極的に使う気にはなれない。

まず最初に、この手の deploy ツールを使うこと理想の方法とは思えない事だ。

Capistrano に限らず、この手のツールを使いたくなるのはどんな時だろう?プロジェクトで開発しているプログラムを数多くのサーバーに deploy したい時では無いだろうか?多くは Web サーバーに deploy する時だろう。bat サーバーの場合も有るかもしれない。ただ、 deploy ツールが機能するほとんどの場合は Immutable OS でも動作する。つまり、新バージョンのプログラムをデプロイした新しいサーバーを用意しておいて、古いサーバーを削除すれば良い。

俺の言っていることは理想論かもしれない。コンテナや仮想マシンの技術が当たり前になった今日において Immutable OS の手法は難しくないように見えるが、仕事には色々なシガラミや制限が付き物だ。スペアのサーバーが足りない、仕組みを構築する工数が無い、政治的に面倒、などなど。

ただ、ここで俺が言いたいのは「デプロイツールは妥協して使うものだ」という事。

次に、Capistrano を真面目に運用しようとすると以外とハードルが高い。

Capistrano を使うには、Ruby をインストールしなければ行けない。どのバージョンを?それから、Gem で Capistrano をインストールする。どのバージョンを?

セットアップする側としては、どうしても Ruby や Gem にはが不安定という印象がつきまとう。そして、万一アプリ側で Ruby を使い出したら問題はより深刻になる。Ruby がコンパチするじゃないか。「rbenv を使え」というのは間違いとは言わないが、やっぱり rbenv は個人の開発用マシンに入れるべき物のような気がする。サーバーで使うとインストールパスの問題とか各マシンでコンパイルする嫌らしさが付きまとうからだ。そこをまたゴチャゴチャやりだすと、どんどん複雑になっていく。そんな事に工数を使いたくない。kiss (keep it simple, stupid) の原則に反してしまう。

便利にするために使い始めた Capistrano が意外と面倒で、その結果が「理想形ではない」となると、使う気が失せる。

そして最後に、DSL 覚えるのが面倒。既に複数のプログラムと DSL を使わざるを得ない立場の俺としては、これ以上覚えたくない。

Ruby は良い言語だと思うし、Rails で開発する事には何の問題も無いと思う。(状況によって向き、不向きはあるけど) アプリを Ruby で作った場合、プログラマが Capistrano を使うのも良いだろう。個人的には、Capistrano に限らず一定レベルのプログラムの知識があればサーバーを管理できる事は Ruby の長所だと考えている(Ruby レベルで環境設定関連のツールが揃っている言語は多くないだろう。)

ただ、最低限の OS、インフラ管理の知識があって、普段の開発では Ruby 以外の言語で開発している立場からすると Capistrano はあんまり有り難く無いんだよね。

当たり前だけど、全ての状況で最適なスペシャルツールなんて無い。もし有ったとしたら、それは当たり前になってツールという印象が無くなるだろう。ちょうど、サーバー間通信にイーサネットを使うように。ただ、俺の調べ方が偏っているのかもしれないがネットを見ると「Capistrano バンザイ」的な発言が少し行き過ぎているような気がしたので書いてみた。

関西 Debian 勉強会行ってきた

2016年 4月 24日の関西 Debian 勉強会に行ってきた。

まだ東京で働いていた頃に仲の良い同僚に誘われたのがきっかけで、東京エリアでは何回か参加した事があるが、関西は初めて。去年から色々とあって(本当に色々とあって)1 年以上参加していなかったので久しぶり感もある

俺は結構 Debian のお世話になっていると思う。勉強会に頻繁に出ているし普段から使っているし。ちなみに、この blog も Debian で動いている。 ただ、その割に Debian 自体にあまり貢献して来なかった。発表は 1 回しかしていないし、debも作れない。東京では友達や DD (Debian Developer) の人に色々と教わったのだけど。(申し訳ございません。)ただ、お世話になりっぱなしも悪いので宣伝を兼ねて Debian 勉強会の紹介。

その前に、Debian について簡単な紹介。

よく「Debian は Linux ディストリビューションの一つ」と考えている人がいるけれど、正確では無いと思う。

Debian は Free な Universal OS だ。

「Free」とは「無料」じゃなくて「自由」と考えた方が良いだろう。関連する物全てが GPL とは行かないが、ライセンスには結構こだわっている。開発は DD (Debian Developper) を中心としたコミュニティ主導で行われており、その代表も定期的に選挙で選んでいる。非常に民主的なシステムだ。

「Universal OS」とは「色々な環境で動く OS」という意味。x86 や AMD64 の CPU はもちろん、ARM など出来るだけ多くの環境で動く事を目指している。

Free な Universal OS を作るための方法として現在は Linux を採用しているが、特に Debian として Linux にこだわりは無い。現にちょっと前は BSD ベースの Debian (kFreeBSD) を Linux と並行サポートしていた事もあった。Debian コミュニティの本音としては Linux だけに頼るのは宜しくないと考えているようだが、残念な事に工数の問題で 2016 年 4 月現在では Debian と言えば Linux のみである。

ところで Debian コミュニティの理想はよいとして、ユーザーから見て Debian はどういったディストリビューションだろう?

細かい特徴は色々とあるが、個人的には安定したパッケージが大量に存在する事が一番大きな特徴だと思う。少なくとも RedHat の提供する rpm より Debian の deb の方が数は多いし、安定していると感じる。もっとも「安定」については簡単に数値化できないので少し恣意的かもしれない。

また、少し Debian に入り込んでくると、今度は Debian ポリシーという物に遭遇する。Debian の最も凄い所はこの Debian ポリシーだという人もいる。俺もまだ勉強しだした所なので詳細には書けないが、Serverspec なんて比じゃないレベルの自動テストや並みの agile 顔負けのマネージメントの粋が詰まっている。世界中に散らばったボランティアの DD 達がどうやって協調作業できるのか、その答えがこれだ。

では、簡単な紹介が終わったところで Debian 勉強会の紹介にうつる。

まず、少し残念な事だが Debian 勉強会は一般の IT 系の勉強会と比べて参加者の人数が少ないように思う。東京エリア、関西ともに参加者は 10 名足らず。ただ、参加者目線ではこれは悪い事ばかりでは無い。例えば、勉強会に参加している凄い人との距離が近くなる。(Debian 勉強会に限らず、大抵の勉強会には凄い人が何人かいる物だ)それに、「発言の順番待ち」みたいな事も無い。

また、一般の勉強会に比べて色々とカジュアルだ。普段「怠惰は美徳」と言っているエンジニアも何故か勉強会となると本質と外れた部分で必要以上にクオリティを高めてしまう物だが、Debian 勉強会はそんな事が無い。発表する方も参加する方も肩の力を抜いて参加できる。(もちろん、発表する際は最低限の準備は必要だし、幹事の方は色々と準備していると思います。比較の問題です。)その代わり、ミーティングの場のディスカッションなどが濃い。ちゃんと聞いて質問や意見をしてくれる人がいる。あなた自身も質問十分質問できるし、脇で聞いているだけでも勉強になる。ただ、議題に上がる事の大体は初歩的な質問から専門的な質問まで誰か答えられる人がいると思うので、せっかくならば聞いてみると良いだろう。

最後に、いろんな分野のエンジニアが集まってくる。普通、勉強会には同じ業界の人ばかり集まってしまう物だが、Debian 勉強会はそうではない。俺は Web 系の人間だけど、組み込み系の人や計算屋さんも来る。。ちなみに、今回の発表は計算屋さんが流体力学の計算方法とそのデモをしてくれた。そのせいか勉強会終了後の打ち上げが面白い。普段聞けないような話が色々と出てくる。

そんな訳で、少しでも興味を持った方はぜひ Debian 勉強会に参加してみてください。あと、関西 Debian 勉強会に参加する人は自分で Wifi の準備をしておくと良いだろう。俺は携帯を換えたばかりなのでテザリングの方法がわからず、ネットが使えず涙した。現在は不明だが、1 年前の東京エリア Debian 勉強会の場合、会場の Wifi を使用できた。

俺は、会社で Ubuntu を使うことになりそうなので今度こそは真面目に Debian を勉強するつもり。(ご存知の方も多いと思うが、Ubuntu は Debian ベースだ。)なので、しばらくは勉強会に真面目に出るつもり。暗号通貨の開発をやっている人はなぜか Ubuntu ユーザーが多いので、それ以外を使うと面倒な事が多いのよね。ってな訳で、最低でもオレオレ deb は作成できないと行けないし、いっそのこと Debian ポリシーに則った作り方もできるようになりたい。

Debian の基礎知識を教えてくれて、さらに勉強会に誘ってくれた友人に感謝しつつ Debian 勉強会の勧めでした

vim の c++ 補完 on debian(個人メモ)

Debian で c++ の開発環境を整えるにあたって、少しトラブったのでメモ。

開発環境というか関数の補完機能を付けたかったわけだが、ちょっとググった範囲では、justmao945/vim-clangRip-Rip/clang_complete が有名 & 良さそう感じ。

ちょっと使った感じの違いとしては、vim-clang は速くてサクサク動く。
対して、clang_complete はちょっとモッサリしているが関数の戻り値や引数の型まで教えてくれる。
(clang_complete は boost を使うと挙動の遅さが少し気になるレベル。)

ただ、問題は両者とも gcc ではなく clang を前提としている事。
なので、mac では neobundle で vim のパッケージ入れるだけで OK だったが、debian では若干手こずる。

clang_complete だが、vim のプラグインと clang をインストールしただけでは動かなかった。
(vim のプラグインを入れた後、$ sudo apt-get install clang)
一応、debian sid, debian jessied で試したが、共に動かず

でも、「ubuntu で動かした」という記事が多く見られる。
試しに trusty (ubuntu 14.04) で、同じ方法でやってみる。
すると、問題無く動く。

そんなバナナ!

trusty、jessie ともに debian sid を freeze、ちょっとモゴモゴして作ったもの。
リリース時期は 2014年4月。
ほとんど変わらないはず。
canonical め、何をモゴモゴしたんだ!

まあ、どうせ library のパスか何かだろうなと思ってよく見ると、
上手く動かない debian では libclang が見つからないから g:clang_library_path をセットしろというメッセージが出ていうるではないか!
Rip-Rip さん、ちゃんとサニタイズ & エラーメッセージしてくれて、ありがとうございました。
対して俺は失格ですね。
エラーメッセージくらい、最初に見ろと。

まあ、結論から言うと
let g:clang_library_path = ‘/usr/lib/llvm-3.6/lib/libclang.so
とやったら、ちゃんと動いてくれた。
まあ llvm のバージョンは頻繁に変わると思うので注意。

vim-clang?
知らね。
個人的には clang_complete の方が気に入ったし、解決するの面倒。

一応、自分メモとして残しておく。