フリーランスになって1年が経った - Gosuke Miyashita
4月からクックパッドで仕事してます というエントリを書いてからちょうど1年経ったので振り返ってみる。 フリーランスになった経緯 そもそも最初からフリーランスになるぞ、と思ってなったわけではなく、なんとなく流れにしたがってたらフリーランスになってた。 もう少し詳しい経緯。色々あって2014年3月に無職（有給消化中のファッション無職じゃなくガチ無職）になって、普通に正社員として次の会社を探していて、知り合いに声をかけて話を聞いて回っていた。その中でクックパッドに決めたのは、セコンさん や mirakui さん の、これからクックパッドの技術やインフラをこうして行きたい、という思いや考えに共感し、そこに自分が価値を提供できるイメージが具体的に沸いたから。 ただ、事情があって最初から正社員ではなく、お互い様子見ということで、正社員になる前提で半年間業務委託契約という形で仕事してみましょう、というこ
Dockerコンテナに入るなら SSH より nsinit が良さそう - Gosuke Miyashita
追記 はてブでつっこみもらいました が、実行するカレントディレクトリは /var/lib/docker/execdriver/native/$id を使うのが正しいようです。（情報読み違えてた。）こちらには container.json があるので、ソースツリーからコピーしてくる必要ないですね。 また、コンテナ ID 取得は、docker ps -q --no-trunc の方が良い、とも教えていただきました。 つっこみにしたがって、最後の方の説明とシェル関数書き換えました。 つっこみありがとうございます！ tl; dr タイトルまま 経緯 Docker でつくったコンテナの中に入って状態を確認するために、コンテナ内で sshd を立ち上げてアクセスする、ってなことを以前やってたんですが、コンテナ内で sshd を立ち上げる、というやり方がいまいちだし、そもそもコンテナの仕組みから考えれば
2013年の振り返り - Gosuke Miyashita
2012年はターニングポイント的な年だったし、自分自身注目を浴びることも多く、エンジニアとしてピークで後は落ちていくだけなんじゃないかと思ったので、珍しく振り返りエントリ を書いてみたわけですが、どうやらピークは今年だったようなので、また振り返りエントリを書いてみます。 3分で常松 2013年に自分が生み出した最大の成果がこの言葉ですね。残念ながら流行語大賞にはノミネートすらされませんでしたが、一部ではとても高い評価を頂いているようです。 この言葉が生まれたのは2013/2/20でした。 3分で常松 — Gosuke Miyashita (@gosukenator) February 20, 2013 言葉の由来は、一度飲み会で限られた人に話した以外は、長らくベールにつつまれたままだったのですが、先日ついに公表しました。 #3分で常松 の由来は、mirakuiさんの「3分でイナフ」と「俺の
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 シェルスクリプトよりは抽象度を高め
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
インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
自分のプロダクトを海外でも認知してもらうには - Gosuke Miyashita
ブログを書くまでが 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
ProPuppet00 - Gosuke Miyashita
#!html [wiki:ManagingInfrastructureWithPuppet Managing Infrastructure With Puppet] の中でも少しだけ触れた、Pro Puppet についてメモ。 こちらは内容盛りだくさんで、Puppet をヘビーに使っている人でも読みごたえがあるんじゃないかと。たとえば、バージョン違いの Puppet を混在させる方法、といったところもフォローされていたり。 ただし、Puppet や、Git といった周辺ツールのインストール方法まで詳細に書かれていて、この辺は自分には必要ないなー、と思ったりもした。 とはいえ、最近の Puppet 動向を追いかけていない自分には、とても有意義な内容が多かったので、その辺についてメモしてみる。 （あんまり書きすぎると出版社の人に怒られそうなんで、さらっと。あと、量が多くなりそうなので、何度かに
MHA for MySQL の概要 - Gosuke Miyashita
MHA for MySQL の導入を検討していて、まずは社内の技術者向けに、MHA for MySQL の概要を伝えようと、主に オフィシャルなドキュメント からポイントを抜粋して社内向けの Wiki に書いてみた。本当なら、オフィシャルドキュメント全体に目を通してもらうのがいいんだけど、英語なので、はじめの一歩としては敷居が高く感じる人もいるだろう、ということで。 特に外に出してまずい情報があるわけでもないので、このブログでも曝しておきます。 MHA の概要 MySQL エキスパートとして世界的にも著名な松信嘉範氏による、MySQL マスターの HA 化を行うためのツール。Perl 製。 最小限のダウンタイムで、データの不整合を防ぎつつ、マスターのフェイルオーバーを行う、というのが主な機能。 また、既に動作している MySQL に影響を与えることなく導入できる。 機能は大きくわけると以下
serverspec のテストをホスト間で共有する方法 - Gosuke Miyashita
今回は serverspec のテストをホスト間で共有する方法について説明します。 serverspec-init を実行して生成されるひな形ファイルは以下のようになっています。 |-- Rakefile `-- spec |-- spec_helper.rb `-- www.example.jp `-- httpd_spec.rb これを見てわかる通り、テスト対象となるホスト名でディレクトリが掘られ、その下に対象ホストに対する spec が置かれる、という形になっています。 したがって、複数の役割が同じホストに対してテストを実行しようとすると、こんな感じで同じ内容の spec ファイルが重複して置かれることになります。 |-- Rakefile `-- spec |-- app001.example.jp | `-- ruby_spec.rb |-- app002.example.jp
構築済みサーバを 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 がサンプルテストコードで、こんな感じになって
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
「Sqale の裏側」資料 at 札幌 Ruby 会議 2012 - Gosuke Miyashita
札幌 Ruby 会議 2012 、まだ会期中ですが、一足お先に帰ってきました。（大学の必修科目である、基礎数学のスクーリング授業が今日から3日間あるため。） YAPC::Asia 2011 の個人スポンサーTシャツを着て参加したのですが、Rubyist の皆さんの心が広いためか、宮川神のご加護があったからか、殴られたりせずに済んで一安心。 ペパボ は徐々に Ruby にスイッチしてきており、Ruby が動く PaaS である Sqale もリリースされたことから、宣伝も兼ねて Sqale の裏側 というタイトルで発表させてもらいました。 Sqale は、 Ruby が動く PaaS でもあるし、Sqale 自体の開発も、フロントもバックもバリバリ Ruby が使われているのですが、Ruby の話はほとんどしない、出てくるコードも Lua と C の方が Ruby よりも多い、というトーク内
Sqale + Route 53 で Naked Domain を割り当てる方法 - Gosuke Miyashita
ペパボ が提供する PaaS Sqale では ELB を利用しているため、Sqale 上でホストしているアプリに独自ドメインを割り当てる場合には CNAME を利用する必要があり、Naked Domain（ホスト名がないドメイン）を割り当てることができません。 Amazon Route 53 が持つ A レコードの Alias 機能を利用すれば、Naked Domain の割り当ても可能になりますが、自分の管理下ではない ELB がターゲットとなるため、もし Sqale 側で ELB の再作成が行われたりすると、新たな ELB の FQDN を調べて、Alias レコードを更新する必要があり、対応が面倒です。（そもそも、ELB が再作成されても気づけない可能性が高い。） そこで以下のような、自動で Alias レコードを追加・修正するスクリプトを作成してみました。これを cron などで
スクショをとってコメントつけて Git にアップする Automator Application つくってみた - Gosuke Miyashita
Gyazo にコメントつけてアップしたい、といった要望があって、それと似たようなことを実現する Automator Application をつくってみた。 この Application を起動すると、 といったダイアログが出るので、領域選択してスクショを取得、すると、 とコメントダイアログが出るので、コメントを入力して OK をクリックすると、入力したコメントをコミットメッセージとして、git commit & git push してくれる。 実際にこれを使ってスクショを GitHub にあげてみた履歴がこちら 。 Application は こちらからダウンロード できます。利用の際には、画像保存先となる Git リポジトリがあるディレクトリ部分を適宜修正してください。 以下、Automator Application の各パーツを参考のために貼り付けておきます。
Paperboy's engineer evaluation system - Gosuke Miyashita
今年から新たにペパボで導入された、技術者向けの評価制度については、こちらのエントリ で書いたのですが、本日、その一次評価が完了しました。 評価のプロセスは、一次はテクニカル・マネージャーによる評価、二次は経営会議メンバーによる評価、と二段階の評価となっています。 自分が担当した一次評価の詳細は、以下のようになっています。 シニア、またはアドバンスドシニアに上がりたい人には、自ら立候補してもらう。 立候補する人は、定められたフォーマットにしたがって、自分がそのポジションにふさわしいと思う理由や実績について Markdown で書き、指定した Git リポジトリに push する。（「定められたフォーマット」と言っても、最初に名前、次に希望のポジションを書いてもらうだけで、それ以外は自由。） 文書提出後、一人一人と面談を行う。 文書の内容と面談の結果にもとづいて、各人が提出した文書の末尾に、結
paperboy is hiring - Gosuke Miyashita
今までペパボの人事評価制度では、管理職のキャリアプランしか想定されていなかったのですが、今年から導入された制度では、管理職とは別に、技術職用の等級が設けられ、能力に応じて待遇が向上する仕組みが導入されました。 具体的には、シニア、アドバンスド・シニア、という2つの役職が設けられ、以下のような待遇となっています。 シニアは年俸500万円〜。フレックスタイム。 アドバンスド・シニアは年俸600万円〜。裁量労働。 実運用に入るのはまだこれからなのですが、今までペパボでは技術者がステップアップしていく道がなかったので、これはペパボの技術者にとって、とても大きな一歩です。 で、本題。 新しい技術者の評価制度をベースに、今までペパボにはなかったポジションの技術者を、東京と福岡、両方で募集しています。 「技術基盤整備エンジニア」という言葉でピンと来る方もいるかと思いますが、クックパッド さんの開発基盤グ
37歳で大学生になりました - Gosuke Miyashita
この4月に、帝京大学理工学部情報科学科 通信教育課程の第2学年に編入学しました。通信教育課程なんで、仕事は続けたままです。 今日は、なぜこの歳（37歳）で大学に入ろうと思ったのかについて書いてみようと思います。 自分の現在の立ち位置は、ソフトウェアエンジニアだと思っているんですが、出身は経済学部経営学科です。それが悪いとは思ってないですし、そういう人は身近にたくさんいるんですが、情報工学や計算機科学なんかの学位を持ってない、といったことに、ほんの微か、あるかないかぐらいの、引け目なんだかコンプレックスだかなんだかわからないけど、そんなようなものをずっと持ち続けています。 それはあまり意味のないことで、別にそんな感情持つ必要ないじゃん、と思いつつも、ずっとひっかかりはあって、この感情ってこの先ずっと残るのかな、とか思ってたわけですが、だったら学位取っちゃえば、そんなつまらないこと考えずに済む
Paperboy's engineer evaluation system - Gosuke Miyashita
今年から新たにペパボで導入された、技術者向けの評価制度については、こちらのエントリ で書いたのですが、本日、その一次評価が完了しました。 評価のプロセスは、一次はテクニカル・マネージャーによる評価、二次は経営会議メンバーによる評価、と二段階の評価となっています。 自分が担当した一次評価の詳細は、以下のようになっています。 シニア、またはアドバンスドシニアに上がりたい人には、自ら立候補してもらう。 立候補する人は、定められたフォーマットにしたがって、自分がそのポジションにふさわしいと思う理由や実績について Markdown で書き、指定した Git リポジトリに push する。（「定められたフォーマット」と言っても、最初に名前、次に希望のポジションを書いてもらうだけで、それ以外は自由。） 文書に提出後、一人一人と面談を行う。 文書の内容と面談の結果にもとづいて、各人が提出した文書の末尾に、
paperboy is hiring - Gosuke Miyashita
今までペパボの人事評価制度では、管理職のキャリアプランしか想定されていかったのですが、今年から導入された制度では、管理職とは別に、技術職用の等級が設けられ、能力に応じて待遇が向上する仕組みが導入されました。 具体的には、シニア、アドバンスド・シニア、という2つの役職が設けられ、以下のような待遇となっています。 シニアは年俸500万円〜。フレックスタイム。 アドバンスド・シニアは年俸600万円〜。裁量労働。 実運用に入るのはまだこれからなのですが、今までペパボでは技術者がステップアップしていく道がなかったので、これはペパボの技術者にとって、とても大きな一歩です。 で、本題。 新しい技術者の評価制度をベースに、今までペパボにはなかったポジションの技術者を、東京と福岡、両方で募集しています。 「技術基盤整備エンジニア」という言葉でピンと来る方もいるかと思いますが、クックパッド さんの開発基盤グル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
