はてなブックマーク

先日のエントリ で書いたとおり、今は基本フルタイムでクックパッドで仕事してるけど、実態はフリーランスなので、税金まわりちゃんとしないとなー、ということで、個人事業の開業届出書と青色申告承認申請書を提出してきた。 で、個人事業主は屋号をつけてもつけなくてもいいんだけど、つけられるんならせっかくだし、ってことで、Serverspec Operations という屋号にしてみた。 勘のいい人なら気づくかもしれないけど、 Heavy Water Operations からのインスパイア。serverspec も絡めた、インフラの構築や運用の自動化、というのをメインのテーマにこの屋号で活動するつもりなんだけど、やってる内容や利用する技術が、この会社ととても近いし、リスペクトもしているので。 「インフラ」といいつつも、その上のアプリケーションレイヤーとは断続しているわけではなく連続したものであり、かつ

今日は最終日で、昨日は Serverspec: The Simplest Server Testing Tool Ever というタイトルでプレゼンしてきました。海外でははじめての serverspec プレゼンなので、もっと基本的な、具体的な使い方とかデモといった内容にした方がいいのかなー、と思いつつも、そういうのはオフィシャルサイトとか見れば割と十分だし、自分以外の人でも話せる内容なので、開発者ならではの、開発をはじめたきっかけとか、開発する上での哲学とか、今後どうしていきたいのか、みたいな話をしました。(大体いい感じになるKeynoteテンプレート「Azusa」 を使わせてもらいました。ありがとうございます。あと、mirakui さんの真似して entypo や fontawesome も使ってみました。) 英語台本棒読みだし、Splunk の方から質問された内容が、なんかテストカバ

株式会社はてなに入社しました。 — Gosuke Miyashita (@gosukenator) March 31, 2014 ↑はエイプリルフールネタですが。 色々あって、3月に無職になって、4月からクックパッドで仕事してます。 基本的にはフルタイムコミットなんですが、諸事情により業務委託契約なので、実質フリーランスですね。 この機会に色々な可能性を模索したいので、何か面白そうな仕事があったら Twitter とか Facebook とか メール などでご連絡ください。 特に以下のような仕事は自分の価値を活かせるんじゃないかと思ってます。 Chef, Puppet, Ansible といったサーバ構成管理ツールの導入支援 serverspecをベースとしたテスト駆動インフラやインフラCIの導入支援 要件に合わせた serverspec のカスタマイズ（serverspec 本体や、テス

serverspec に関する論文を、あんちぽ さん 、@matsumotory さんと共著で書きましたので、GitHubリポジトリ ごと公開しておきます。 論文のPDF だけではなく、PDF 生成前の TeX ファイルとかもありますし、Issues を見ると、どんな風に執筆を進めていったのかが垣間見えます。 また、事情により研究会発表は欠席してしまったのですが、発表用スライドは作成したので、せっかくなのでアップしておきます。

内容自体は基本的に、第5弾 週末ランサーズ にお邪魔した時に お話した資料 と同じなんですが、この時よりも時間が少し長かったので、多少内容を追加しているのと、当時自分の中でうまく整理できてなかったけど、今は多少クリアになった部分もあって、そういった内容を盛り込んだりしてみました。 Togetter まとめ NAMIKAWA さんによるまとめ 一点お詫びしたいのは、登壇者に質問ができる Ask the Speaker というコーナーがあって、セッションが終わった後はそちらに移動、という段取りだったのですが、裏でやっていた OSS コミッタ大集合 の方でも登壇するために終了後すぐに E 会場に向かったため、Ask the Speaker コーナーに行けませんでした。もし質問するためにいらしてくださった方がいましたら、本当に申し訳ないです。 今回デブサミに登壇させて頂いた経緯については、会場で

serverspec とか specinfra の Changes を手で書くのがだるくなってきたので、自動化するために octorelease という gem をつくりました。 rubygems.org にもあげてあるので、gem install で入ります。 Rakefile の中に require "bundler/gem_tasks" require "octorelease" みたいに書いて、 $ rake octorelease すると、 こんな感じになります。 何をしてるかというと、rake release した後に、前のバージョンとリリースするバージョンの間に含まれるプルリクエストをgit logで拾って、各プルリクエストに Released as vX.X.X. とコメントをつけ、GitHub 上にリリースを作成し、リリースの本文にはプルリクエストへリンクを張る、ってなこ

拙作の serverspec が Open Source Rookies of the Year 2013 の 10 プロダクトのうちのひとつに選ばれました。 昨年末に、候補が20まで絞り込まれた段階で一度連絡があって、その後、今月中旬ぐらいに、選ばれたよ、おめでとう、という連絡が来ました。最初の連絡が来るまで、そもそもこの賞の存在を知らなかったので、どの程度影響力がある賞なのかはよくわかりませんが、Docker とか超有名どころと一緒に並んでるのは、嬉しいというよりもむしろ恐れ多いですね。 SourceForge.JP Magazine の日本語記事では、タイトルにも serverspec を含めて くれていてありがたいです。 それから、Thought Works Technology Radar January 2014 にも serverspec の文字が見えていて、すごいなー、これ

2012年はターニングポイント的な年だったし、自分自身注目を浴びることも多く、エンジニアとしてピークで後は落ちていくだけなんじゃないかと思ったので、珍しく振り返りエントリ を書いてみたわけですが、どうやらピークは今年だったようなので、また振り返りエントリを書いてみます。 3分で常松 2013年に自分が生み出した最大の成果がこの言葉ですね。残念ながら流行語大賞にはノミネートすらされませんでしたが、一部ではとても高い評価を頂いているようです。 この言葉が生まれたのは2013/2/20でした。 3分で常松 — Gosuke Miyashita (@gosukenator) February 20, 2013 言葉の由来は、一度飲み会で限られた人に話した以外は、長らくベールにつつまれたままだったのですが、先日ついに公表しました。 #3分で常松 の由来は、mirakuiさんの「3分でイナフ」と「俺の

specinfra v0.0.6 では、serverspec/configspec/Syllabus で実行する具体的なコマンドを SpecInfra::Command::* に統合しました。 以前のバージョンまでは「OS を自動判別し、OS に適したコマンドクラスを返す commands と呼んでいるレイヤー」を specinfra で提供していましたが、コマンドクラスは各プロダクト側で実装していました。 specinfra v0.0.6 では、コマンドクラスも specinfra 側で持つようになりました。 これで何がうれしいのかというと、オレオレ Configuration Management Tool が簡単に実装できるようになる、ということです。 Exec/SSH といったバックエンド実行形式の切り替えや、OSを自動判別して適切なコマンドを実行する部分はすべて specinfr

specinfra で ShellScript backend に対応 したので、configspec や serverspec で実行されるコマンドをシェルスクリプト形式でダンプできるようになった。 例えば configspec の場合 require 'configspec' include SpecInfra::Helper::ShellScript include SpecInfra::Helper::RedHat といった spec_helper.rb を用意して require 'spec_helper' describe package('httpd') do it { should be_installed } end といった内容の spec を書いて実行すると #!/bin/sh yum -y install httpd こんな内容の spec.sh というファイルを生

The backend of serverspec/configspec might have to be extracted to a gem to accommodate people's preferences to abstraction level. — kentaro (@kentaro) November 26, 2013 とあんちぽさんからごもっともな指摘をいただいたし、実際に configspec を書いてて、ほとんどが serverspec からのコピペで、今後開発をつづけるのであれば、共通部分を抜き出した gem をつくるべきだな、と思ったので、specinfra という gem をつくった。 specinfra で抜き出した処理は以下の部分。 SSH, ローカル、WinRM などの実行形式を抽象化している backend と呼んでいるレイヤー OS を自動判別し、O

configspec とか Immutable Infrastructure について、@kazuho さんから色々とありがたいツッコミをいただきまして、その中で 個人的にはSCMあるいはLVMの管理下において、record-cmd yum -y install httpd とかすると、コマンドがSCMのコメントに残りつつ、ファイルシステムに発生した差分が変更履歴として保存されるくらいでいいんじゃないかと思う — Kazuho Oku (@kazuho) November 26, 2013 といった tweet があり、それは Docker でやれるけど、configspec でやることではないなー、と思っていたところ、ふと configspec から Dockerfile を生成する、というアプローチもありな気がしてきた。 — Gosuke Miyashita (@gosukenator

Immutable Infrastructure の有用性 - Togetter の流れの勢いで、インフラ系技術の流れ とか Rebuild: 25: Immutable Infrastructure (Naoya Ito, Gosuke Miyashita) とかで言ってたような、冪等性とか依存関係とかを考慮しないシンプルな Configuratin Management Tool である configspec をつくってみました。rubygems.org にもアップしてます。 この手のツールに自分が望む要件は以下の様な感じ。 冪等性とかどうでもいい まっさらな状態からのセットアップでしか使わない 依存関係とかどうでもいい ファイル名順、上から書いた順で実行してく 対象サーバに余分なものをインストールしたくない 対象サーバに SSH さえできれば OK シェルスクリプトよりは抽象度を高め

ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による

ブログを書くまでが YAPC、ってことなので書きます。 YAPC 懇親会で @hirose31 さんと「日本人の作ったプロダクトでとても優れていて日本では知名度抜群なのに、海外では全然知られてない、みたいの割とあるけど、どうやったら serverspec みたいに海外でも認知されるようになるんですかね」みたいな話をしました。 serverspec の海外での知名度、といっても、日本での知名度と比較すればまだまだ全然、という感じですが、たまに海外の方の tweet を見かけたり、Serverspec the New Best Way to Learn and Audit Your Infrastructure というブログエントリを書いてくださった方がいたり、Food Fight という Podcast で取り上げられたり、O'Reilly の Test-Driven Infrastruct

hbstudy #45 や Tatsuhiko Miyagawa's Podcast ep14 なんかで、serverspec の並列処理が課題、ってな話をしていて、Net::SSH がイベントドリブンな処理になってるのがネックになりそうだなー、どうしようかなー、と悩んでたんですが、とりあえず試してみた方が早いだろう、ってことで parallel_tests を試してみた。 6つの VM に対して 311 examples を実行した結果で比較。 parallel_tests を使わない場合。 $ rspec spec .........................................................................................................................................

注意！ v0.11.0 からは attr, attr_set ではなく、property, set_property とメソッド名が変更されています。attr, attr_set は近い将来使えなくなります。最新の情報はこちらを参照してください。 注意！ ここで解説する方法は v0.3.0 から利用できます。 Provisioning Frameworks Casual Talks vol.1 に行ってきた #pfcasual - TAKUMI SAKAMOTO'S BLOG で触れられている attributes 周りについて、この辺は必要になるだろうなー、と前から思ってはいたので、それを実現するための極々簡単な仕組みを 試験的に実装してみた 。 これは単に attr_set と attr という2つのヘルパーメソッドを使えるようにしただけのものなんだけど、以下のような感じで使える。 今

tokuhirom さんにより開発されている Ukigumo を利用して、Puppet の CI 環境を構築してみた。やってることは以下の通り。 Puppet マニフェストを Git リポジトリで管理 Ukigumo Server を立てる puppet-lxc-test-box で Puppet マニフェストを流し込むシステムコンテナを必要なロールの分だけ用意 自前の Ukigumo クライアントスクリプト を cron で定期的に走らせ以下を実行 Puppet マニフェストリポジトリの master ブランチが更新されていたら、git pull して Puppet マニフェストをシステムコンテナに適用し、適用結果を Ukigumo サーバに投げる serverspec によるテストをシステムコンテナに対して実行し、結果を Ukigumo サーバに投げる Ukigumo のトップ画面はこ

Puppet や Chef で構築したサーバを RSpec でテストする で書いた仕組みを使いやすくするために serverspec という名前で gem 化してみた。 rubygems.org にも登録してあるので、gem install でインストールできる。 $ gem install serverspec インストールしたら、適当なディレクトリで serverspec-init を実行。すると、雛形となるディレクトリやファイルを生成する。 $ serverspec-init + spec/ + spec/www.example.jp/ + spec/www.example.jp/httpd_spec.rb + spec/spec_helper.rb + Rakefile spec/www.example.jp/httpd_spec.rb がサンプルテストコードで、こんな感じになって

Note: I made serverspec gem for this purpose. Please see the entry serverspec - a rubygem for testing provisioned servers with RSpec. I've made a Puppet module for creating LXC system containers.Next I've tried to the basis for writing test code easily. With rspec-lxc-test-box, you can write code for testing server status like this. require 'container_spec_helper' describe 'nrpe' do it { should be

追記 ここに書いてあることを実現する serverspec という gem をつくりました。詳しくはこちらのエントリで。 Puppet マニフェストをリファクタリングするからテスト書くぞ、ってことで、 puppet-lxc-test-box に書いたように、テストするためのシステムコンテナを簡単に作る仕組みをつくったので、今度は実際にテストコードを書くためのベースをつくってみた。 rspec-lxc-test-box こんな感じでテストが書ける。 require 'container_spec_helper' describe 'nrpe' do it { should be_installed } it { should be_enabled } it { should be_running } end describe 'nagios-plugins-all' do it { shou

新たな Puppet のベストプラクティスを求めて、マニフェストの大規模なリファクタリングを行っています。 で、リファクタリングするからにはテストが必要だよね、ってことで、rspec-puppet でテストを書いてるんだけど、rspec-puppet はマニフェストがコンパイルされた「カタログ」というものに対してテストするもので、実際にマニフェストを流し込んだ状態が正しいかテストするわけではないので、これだとテストとしては不完全。 というわけで、Test Kitchen みたいに、同時にいくつも VM を立ててテストを走らせる、ってなことをやりたいんだけど、会社では KVM ベースの VM を利用してるので、VirtualBox ベースの Vagrant は使えないし、そもそもテストを動かす大元のホストも VM なので、VirtualBox どころか KVM も利用できない。 なので、まず

Vagrant の base box をつくるためのツールとして VeeWee があって、これはこれで素晴らしいツールなんだけど、VeeWee は裏で ISO イメージをダウンロードしたり、インストーラを走らせたりで、時間もかかるし大げさな感じがするので、もっと簡略化できないか、ってことでやってみた。 最小手順のVMイメージの作り方 で紹介したシェルスクリプトで作成した VM イメージに対して、以下のようにコマンドを実行するだけで、package.box ができあがる。 # VBoxManage convertfromraw --format vmdk /tmp/sl63.img /tmp/sl63.vmdk # VBoxManage createvm --name SL6.3-x86_64 --register # VBoxManage modifyvm SL6.3-x86_64 --m

開発や検証で利用する VM は、最初はディスクサイズを小さくして、後から必要に応じて大きくする、といったことをよくやるので、最小手順のVMイメージの作り方 のスクリプトを、/ と swap を LVM にするように変えてみた。 あとはディストリビューションを選択できるようにとか、指定したホスト名を設定する、とかもやりたいけど、シェルスクリプトは大きくなってくるとメンテナンス厳しいので、Ruby で書き直す。

先日カヤックさんの社内勉強会にお邪魔して話してきた Maglica は、既に作成済みの VM イメージを元にクローンをつくって必要な設定（root パスワードの設定やネットワーク設定など）を行う、といったことが簡単にできるが、元の VM イメージつくるのがめんどくさいことには変わりなくて、ここをなんとかしたいなー、と常々思ってた。 VM イメージをつくる手段としては、RedHat 系の場合は virt-manager, virt-install, Cobbler/Koan などがあるが、どれもインストーラを実行する形式であり、kickstart を利用すれば自動化できるとは言え、kickstart は問題が起きた場合の調査がやりにくい。（自分が効果的なやり方知らないだけかもしれないけど。） また、virt-install はオプション覚えられないし、Cobbler は初期のセットアップとか

MHA for MySQL の導入を検討していて、まずは社内の技術者向けに、MHA for MySQL の概要を伝えようと、主に オフィシャルなドキュメント からポイントを抜粋して社内向けの Wiki に書いてみた。本当なら、オフィシャルドキュメント全体に目を通してもらうのがいいんだけど、英語なので、はじめの一歩としては敷居が高く感じる人もいるだろう、ということで。 特に外に出してまずい情報があるわけでもないので、このブログでも曝しておきます。 MHA の概要 MySQL エキスパートとして世界的にも著名な松信嘉範氏による、MySQL マスターの HA 化を行うためのツール。Perl 製。 最小限のダウンタイムで、データの不整合を防ぎつつ、マスターのフェイルオーバーを行う、というのが主な機能。 また、既に動作している MySQL に影響を与えることなく導入できる。 機能は大きくわけると以下