37歳の大学選び - Gosuke Miyashita
37歳で大学生になりました のつづき。 大学を選ぶにあたって、まず最初に考えたのは、以下の2点。 全日か？夜間か？通信か？ 大学か？大学院か？ 1 については、子供が5人いて妻は専業主婦であり、働かずに何年も暮らしていけるほどの貯蓄もないため、全日制はまず却下。夜間か通信かについては、職場か家から近くて通いやすいところであれば、夜間もありかな、とは思ったけれど、実際にそういった条件のところがなさそう、ということと、コンピュータについて学ぶ、ということであれば、曲がりなりにもプロとして15年近く IT 技術者やってるし、コンピュータは小学生の頃から触っていて、ベーマガで育った人間でもあるし、全然知らないわけではないので、決まった時間縛られるよりも、自分のペースで学びたい、ということで、通信にすることに。（どうでもいいですが、ベーマガの「読者の闘技場」のコーナー、書籍化されたりしないですかね。
Infrastructure as Code 再考 - Gosuke Miyashita
Infrastructure as Code という言葉が現れてから少なくとも8年ほど経過しており、この言葉もすっかり定着したように見えるが、Martin Fowler 氏が最近自身のブログで Infrastructure as Code について触れており 、また、氏の同僚である Kief Morris 氏が O'Reilly Media から Infrastructure as Code という本を出す（現在 Early Relase 版や Free Chapters が入手できる）ようなので、このタイミングで改めて Infrastructure as Code について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日本でも最近、サーバ/インフラ
フリーランスになって2年が経った - Gosuke Miyashita
株式会社はてなに入社しました。 — Gosuke Miyashita (@gosukenator) March 31, 2016 ↑はちょうど2年前の 4月からクックパッドで仕事してます と同様、エイプリルフールネタです（実際にありえそうなので判断に迷った人いそうだけど）。 フリーランスになって1年が経った というエントリを書いてからちょうど1年経ったので、この1年を振り返ってみる。 仕事について 1年目は、元々正社員になる前提で、様子見ということでクックパッドと業務委託契約を結んでいたので、基本フルタイムコミットで決まった時間にオフィスで仕事、という形だったけど、2年目はオフィスに行く日数を減らしたり、リクルートテクノロジーズの仕事の割合を増やしたりした。 2年目の前半は、クックパッドの仕事が週4日で、そのうち2日はオフィスに行き、リクルートテクノロジーズの仕事は週1日リモートで、という
株式会社リクルートテクノロジーズ Advanced Technology Lab 技術顧問になりました - Gosuke Miyashita
タイトルの通り、10月から 株式会社リクルートテクノロジーズ Advanced Technology Lab の技術顧問になりました。 技術顧問といっても、あまり顧問的な仕事ではないのですが、中の人として活動するにあたって肩書きが必要で、他にわかりやすい名称が思いつかなかったので、技術顧問という肩書きになりました（技術フェローの方が近いかな、という感じだけど、事情によりフェローは使えないので）。 ATL の中の人としての活動ですが、世の中に新しい価値観をもたらすような OSS の研究・開発、言い換えると、Serverspec のような OSS を新たに生み出すのがメインのミッションとなります。 クックパッドの方も業務委託は継続させてもらうので、ATL での研究開発と、クックパッドでの現場運用、双方で良いフィードバックサイクルを回し、お互いにメリットがあるような成果を出していければいいな、と
フリーランス2年目だけど家を建てることにした 其の1 - Gosuke Miyashita
フリーランスのソフトウェアエンジニアでしかも（確定申告的な意味での）実績が1年しかない人間が、ローンを組んで家を建てることになったので、その辺についてシリーズで書いていくことにしようかと。 フリーランスのエンジニアで家を建てた人の話としては、@a_matsuda さんの Hacking (My) Home という素晴らしいスライドがあったり、フリーランスではないけど、同業種のエンジニアが家を建てた話としては、元同僚の @morygonzalez さんの 2000 ブクマを超えるエントリ などもあったりするので、併せてどうぞ。 今回は、元々家を持つつもりは一切なくて、一生賃貸でいいや、というか、今後の家族構成の変化（子供が自立して出て行くなど）を考えると、断然賃貸の方がいいだろう、と思っていた人間が、なぜ家を建てることになったのか、そのきっかけになった出来事について。 ゴールデンウィーク中に
フリーランス2年目だけど家を建てることにした 其の2 - Gosuke Miyashita
ブログ書くまでが YAPC、ってことで、YAPC でお会いした方々に「家づくりエントリの続き楽しみにしてます」とか「続きまだですか」とか言われたので、其の2を書く（YAPC まったく関係ない）。 前回のエントリ のような流れで家を建てることになったわけだけど、それまで家を建てることなどまったく考えたことがなく突然のことだったので、家を建てる流れとかまったく知らず、何をしていいのかさっぱりわからないので、家づくりについて情報を集めることにした。というわけで、今回は、どんな風に情報を集めたかについて書く。 あくまでも自分の場合はこうだった、というだけの話であって、同じやり方を勧めるわけではないので、ご参考まで。 スーモカウンター まずインターネット上で検索してみたところ、スーモカウンター で 無料セミナー をやっているのを見つけたので、行ってみることにした。セミナーは色々あるけれど、1組様2講
Dockerコンテナに入るなら SSH より nsinit が良さそう - Gosuke Miyashita
追記 はてブでつっこみもらいました が、実行するカレントディレクトリは /var/lib/docker/execdriver/native/$id を使うのが正しいようです。（情報読み違えてた。）こちらには container.json があるので、ソースツリーからコピーしてくる必要ないですね。 また、コンテナ ID 取得は、docker ps -q --no-trunc の方が良い、とも教えていただきました。 つっこみにしたがって、最後の方の説明とシェル関数書き換えました。 つっこみありがとうございます！ tl; dr タイトルまま 経緯 Docker でつくったコンテナの中に入って状態を確認するために、コンテナ内で sshd を立ち上げてアクセスする、ってなことを以前やってたんですが、コンテナ内で sshd を立ち上げる、というやり方がいまいちだし、そもそもコンテナの仕組みから考えれば
フリーになったので開業してみた - Gosuke Miyashita
先日のエントリ で書いたとおり、今は基本フルタイムでクックパッドで仕事してるけど、実態はフリーランスなので、税金まわりちゃんとしないとなー、ということで、個人事業の開業届出書と青色申告承認申請書を提出してきた。 で、個人事業主は屋号をつけてもつけなくてもいいんだけど、つけられるんならせっかくだし、ってことで、Serverspec Operations という屋号にしてみた。 勘のいい人なら気づくかもしれないけど、 Heavy Water Operations からのインスパイア。serverspec も絡めた、インフラの構築や運用の自動化、というのをメインのテーマにこの屋号で活動するつもりなんだけど、やってる内容や利用する技術が、この会社ととても近いし、リスペクトもしているので。 「インフラ」といいつつも、その上のアプリケーションレイヤーとは断続しているわけではなく連続したものであり、かつ
4月からクックパッドで仕事してます - Gosuke Miyashita
株式会社はてなに入社しました。 — Gosuke Miyashita (@gosukenator) March 31, 2014 ↑はエイプリルフールネタですが。 色々あって、3月に無職になって、4月からクックパッドで仕事してます。 基本的にはフルタイムコミットなんですが、諸事情により業務委託契約なので、実質フリーランスですね。 この機会に色々な可能性を模索したいので、何か面白そうな仕事があったら Twitter とか Facebook とか メール などでご連絡ください。 特に以下のような仕事は自分の価値を活かせるんじゃないかと思ってます。 Chef, Puppet, Ansible といったサーバ構成管理ツールの導入支援 serverspecをベースとしたテスト駆動インフラやインフラCIの導入支援 要件に合わせた serverspec のカスタマイズ（serverspec 本体や、テス
configspec で Dockerfile を生成できるようにした - Gosuke Miyashita
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
Developers Summit 2014 で「サーバプロビジョニングのこれまでとこれから」という発表を行いました - Gosuke Miyashita
内容自体は基本的に、第5弾 週末ランサーズ にお邪魔した時に お話した資料 と同じなんですが、この時よりも時間が少し長かったので、多少内容を追加しているのと、当時自分の中でうまく整理できてなかったけど、今は多少クリアになった部分もあって、そういった内容を盛り込んだりしてみました。 Togetter まとめ NAMIKAWA さんによるまとめ 一点お詫びしたいのは、登壇者に質問ができる Ask the Speaker というコーナーがあって、セッションが終わった後はそちらに移動、という段取りだったのですが、裏でやっていた OSS コミッタ大集合 の方でも登壇するために終了後すぐに E 会場に向かったため、Ask the Speaker コーナーに行けませんでした。もし質問するためにいらしてくださった方がいましたら、本当に申し訳ないです。 今回デブサミに登壇させて頂いた経緯については、会場で
octorelease という gem をつくった - Gosuke Miyashita
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 上にリリースを作成し、リリースの本文にはプルリクエストへリンクを張る、ってなこ
specinfra をベースとしたオレオレ Configuration Management Tool/オレオレ serverspec 構想 - Gosuke Miyashita
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
configspec という Immutable Infrastructure 用 Configuration Management Tool をつくってみた - Gosuke Miyashita
Immutable Infrastructure の有用性 - Togetter の流れの勢いで、インフラ系技術の流れ とか Rebuild: 25: Immutable Infrastructure (Naoya Ito, Gosuke Miyashita) とかで言ってたような、冪等性とか依存関係とかを考慮しないシンプルな Configuratin Management Tool である configspec をつくってみました。rubygems.org にもアップしてます。 この手のツールに自分が望む要件は以下の様な感じ。 冪等性とかどうでもいい まっさらな状態からのセットアップでしか使わない 依存関係とかどうでもいい ファイル名順、上から書いた順で実行してく 対象サーバに余分なものをインストールしたくない 対象サーバに SSH さえできれば OK シェルスクリプトよりは抽象度を高め
インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
Ukigumo と serverspec で Puppet の継続的インテグレーション - Gosuke Miyashita
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 でテストする - Gosuke Miyashita
追記 ここに書いてあることを実現する 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
構築済みサーバを RSpec でテストする serverspec という gem をつくった - Gosuke Miyashita
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 がサンプルテストコードで、こんな感じになって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
serverspec の論文公開します - Gosuke Miyashita
最小手順のVMイメージの作り方（LVM 編） - Gosuke Miyashita