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日リモートで、という
Dockerコンテナに入るなら SSH より nsinit が良さそう - Gosuke Miyashita
追記 はてブでつっこみもらいました が、実行するカレントディレクトリは /var/lib/docker/execdriver/native/$id を使うのが正しいようです。（情報読み違えてた。）こちらには container.json があるので、ソースツリーからコピーしてくる必要ないですね。 また、コンテナ ID 取得は、docker ps -q --no-trunc の方が良い、とも教えていただきました。 つっこみにしたがって、最後の方の説明とシェル関数書き換えました。 つっこみありがとうございます！ tl; dr タイトルまま 経緯 Docker でつくったコンテナの中に入って状態を確認するために、コンテナ内で sshd を立ち上げてアクセスする、ってなことを以前やってたんですが、コンテナ内で sshd を立ち上げる、というやり方がいまいちだし、そもそもコンテナの仕組みから考えれば
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 氏による
構築済みサーバを 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-lxc-test-box - Gosuke Miyashita
新たな Puppet のベストプラクティスを求めて、マニフェストの大規模なリファクタリングを行っています。 で、リファクタリングするからにはテストが必要だよね、ってことで、rspec-puppet でテストを書いてるんだけど、rspec-puppet はマニフェストがコンパイルされた「カタログ」というものに対してテストするもので、実際にマニフェストを流し込んだ状態が正しいかテストするわけではないので、これだとテストとしては不完全。 というわけで、Test Kitchen みたいに、同時にいくつも VM を立ててテストを走らせる、ってなことをやりたいんだけど、会社では KVM ベースの VM を利用してるので、VirtualBox ベースの Vagrant は使えないし、そもそもテストを動かす大元のホストも VM なので、VirtualBox どころか KVM も利用できない。 なので、まず
最小手順のVMイメージの作り方 - Gosuke Miyashita
先日カヤックさんの社内勉強会にお邪魔して話してきた Maglica は、既に作成済みの VM イメージを元にクローンをつくって必要な設定（root パスワードの設定やネットワーク設定など）を行う、といったことが簡単にできるが、元の VM イメージつくるのがめんどくさいことには変わりなくて、ここをなんとかしたいなー、と常々思ってた。 VM イメージをつくる手段としては、RedHat 系の場合は virt-manager, virt-install, Cobbler/Koan などがあるが、どれもインストーラを実行する形式であり、kickstart を利用すれば自動化できるとは言え、kickstart は問題が起きた場合の調査がやりにくい。（自分が効果的なやり方知らないだけかもしれないけど。） また、virt-install はオプション覚えられないし、Cobbler は初期のセットアップとか
RPM パッケージを Git で管理する方法（案） - Gosuke Miyashita
@trombik さんの 弊社ではtinderbox+gitですべて統一させてる — trombik (@trombik) December 27, 2012 という tweet を見て気になったので調べてみたところ、 Tinderbox はどうやら FreeBSD の ports を自動ビルドするためのシステムのようで、RPM でもこんなのないのかなー、と探してみたものの見つけられなかったし、Tinderbox が自分が求めてるものなのかどうかもいまいちピンと来なかったので、プロトタイプ的なものをつくってみることに。 現在 RPM パッケージの管理は、こんな感じで ソース/バイナリパッケージを直接リポジトリに突っ込んじゃってるんだけど、これだと以下のような問題がある。 バイナリパッケージのファイルサイズが大きすぎて、git clone や push や pull に時間がかかる パッケー
サーバエンジニアが「開発力」を持つ意味 - Gosuke Miyashita
初出: Software Design 2009年4月号（2009年3月18日発売） 宮下 剛輔 サーバエンジニアの定義 本特集では、サーバエンジニアが開発力を持つことにより、どのような力を得ることができるのか、日々の業務にどのように役立てることができるのか、具体例とともに紹介します。 本題に入る前にまずはここでのサーバエンジニアの定義を明確にし、特集全体のコンセプトについて説明します。 クライアント/サーバ型のシステムを考える場合、サーバ側は大まかに以下のようなレイヤーに区分できます。 アプリケーションレイヤー ミドルウェアレイヤー OSレイヤー ネットワークレイヤー これらのレイヤーのうち、ミドルウェアレイヤーとOSレイヤーを主担当とするエンジニアを、本特集記事でのサーバエンジニアと定義し、対象読者と想定します。その中でも特に、オープンソースソフトウェア（OSS）をメインで扱うエンジニ
ペパボでの GitHub の使い方 - Gosuke Miyashita
必殺！Github導入に向けて上司を説得する時に使える資料まとめ - DQNEO起業日記 でペパボも取り上げて頂いたので、ペパボでの GitHub の使い方について、少し詳しく書いてみます。 開発での利用 これは普通の使い方ですね。なので省略。 GitHub Enterprise は利用していない 金額的な面で GitHub Enterprise の利用は厳しいため、GitHub Enterprise ではなく、ノーマル（？）な GitHub を利用しています。（GitHub Enterprise にすると、現在のコストの 8 〜 9 倍ぐらいになってしまう。） ここはセキュリティ面とのバランスが難しいところではありますが… とはいえ、GitHub に何かあってソースコードが流出した場合に影響の大きさが懸念されるサービスについては、GitHub を利用しない、といった判断もしています。（で
Paperboy's engineer evaluation system - Gosuke Miyashita
今年から新たにペパボで導入された、技術者向けの評価制度については、こちらのエントリ で書いたのですが、本日、その一次評価が完了しました。 評価のプロセスは、一次はテクニカル・マネージャーによる評価、二次は経営会議メンバーによる評価、と二段階の評価となっています。 自分が担当した一次評価の詳細は、以下のようになっています。 シニア、またはアドバンスドシニアに上がりたい人には、自ら立候補してもらう。 立候補する人は、定められたフォーマットにしたがって、自分がそのポジションにふさわしいと思う理由や実績について Markdown で書き、指定した Git リポジトリに push する。（「定められたフォーマット」と言っても、最初に名前、次に希望のポジションを書いてもらうだけで、それ以外は自由。） 文書提出後、一人一人と面談を行う。 文書の内容と面談の結果にもとづいて、各人が提出した文書の末尾に、結
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最小手順のVMイメージの作り方（LVM 編） - Gosuke Miyashita