Team Topologiesを読んだ
https://teamtopologies.com/ DevOps consultantとして技術と組織の両面からDevOpsの支援を行なってるMatthew SkeltonとManuel Paisによる本．Consultant本は大体中身が薄く感じることが多くなり手に取ることは少なくなってきたが，各所で見かけたり，2人によるDevOpsにおけるチームのあり方のパターンをまとめたWhat Team Structure is Right for DevOps to Flourish?が良かったので読んでみた． 本書はDevOpsの視点から高速なDeliveryを実現するためにどのようなチームや組織を作るべきかについてまとめている．個人ではなくチームをDeliveryの最も重要な単位と考え（Team first-thinking），チームが最大限にパフォーマンスを発揮するために，チームの人数
社内PlatformチームのProduct Management
現職においてPlatform チーム（社内基盤チーム）として働き始めて2年近くがたった．このチームにおいて自分はTech Leadをメインに努めてきたが，同時にPlatformの「どのような機能を」「どのような優先度で」作るか? を決めるProduct Manager的な役割も果たしてきた（ちなみにTech Leadに関してはメルカリのテックリードが学んだ、HowよりWhyを重視することが大切なわけ で少し話した）．これは何度も失敗しながら悪戦苦闘しつつやってきたが自分たちなりのフレームワークをつくり実際に回すことができている． 未だに試行錯誤しているのでここで書いていることが正解だとは思っていないが，今後同じようにPlatformチーム的なことを始めるひとに向けて現状自分たちがどのようにやっているのかについて簡単にまとめておく（他の会社がどのようにやってるのかも聞きたいのでもし同じような
GolangでFlame Graphを描く
アプリケーションのパフォーマンス問題の解決やチューニングで大切なのは問題のコアやボトルネックに最短パスで到達することである． 基本的なパフォーマンス分析の入り口はアプリケーションのスレッドがon-CPUで時間を消費しているかoff-CPUで時間を消費しているかを理解するところから始まる．on-CPUの場合はそれがuserモードかkernelモードかを特定し，さらにCPUプロファイリングによってどのcode pathがCPUを消費しているのかの分析に向かう．off-CPUの場合はI/OやLock，pagingといった問題の分析に向かう． Flame Graphはon-CPUでのパフォーマンスの問題が発覚した時に行うCPUプロファイリングを助ける．どのcode pathがボトルネックになっているのかを1つのグラフ上で理解できる．本記事ではFlame Graphとは何か? なぜ必要なのか? を解
なぜMicroservicesか?
現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った．未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった．本記事ではそもそもMicroservicesアーキテクチャとは何かを整理し，なぜやるべきか?・なぜ避けるべきかを整理する． Microservices? Microservicesアーキテクチャとは「Single purpose，High cohesion，そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である．それぞれの原則をまとめると以下のようになる． Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の
コマンドラインツールを作るときに参考にしている資料 | SOTA
コマンドラインツールについて語るときに僕の語ること - YAPC::Asia Tokyo 2014 コマンドラインツールが好きで昔からつくってきた． 今年のYAPCで，そのコマンドラインツールをつくるときにどういうことを意識して作っているのか？どのような流れで開発しているのか？といったことを語る機会をもらえた． 具体的な内容については，是非トークを聴きに来てもらうとして， スライドをつくるにあったって過去に読んだ資料や，よく参考にしている記事を集め直したので，その一部を参考資料としてまとめておく． UNIXという考え方 UNIXという考え方 Mike GancarzによるUNIXの思想や哲学をまとめた本．古いが全然色あせてない． コマンドラインツールの作り方を書いた本ではないが，これらの思想の上で動くツールはこの思想に準拠して作られるべきだと思う．何度も読んで考え方を染み付かせた． 小さい
使いやすいシェルスクリプトを書く
できればシェルスクリプトなんて書きたくないんだけど，まだまだ書く機会は多い．シェル芸やワンライナーのような凝ったことではなく，他のひとが使いやすいシェルスクリプトを書くために自分が実践していることをまとめておく． ヘルプメッセージ 書いてるシェルスクリプトが使い捨てではなく何度も使うものである場合は，本体を書き始める前に，そのスクリプトの使い方を表示するusage関数を書いてしまう． これを書いておくと，後々チームへ共有がしやすくなる．とりあえずusage見てくださいと言える．また，あらかじめ書くことで，単なるシェルスクリプトであっても自分の中で動作を整理してから書き始めることができる．関数として書くのは，usageを表示してあげるとよい場面がいくつかあり，使い回すことができるため． 以下のように書く． function usage { cat <<EOF $(basename ${0})
Hashicorp Ottoを読む
Hashicorpから2015年秋の新作が2つ登場した． Otto - HashiCorp Nomad - HashiCorp Ottoがなかなか面白そうなのでコードを追いつつ，Ottoとは何か? なぜ必要になったのか? どのように動作するのか? を簡単にまとめてみる． バージョンは 0.1.0 を対象にしている（イニシャルインプレッションである） Ottoとは何か? 公式はVagrantの後継と表現されている．が，それはローカル開発環境の構築も担っているという意味で後継であり，自分なりの言葉で表現してみると「OttoはHashicorpの各ツールを抽象化し開発環境の構築からインフラの整備，デプロイまでを一手に担うツール」である．ちなみにOttoという名前の由来はAutomationと語感が似ているからかつ元々そういう名前のbotがいたからとのこと． なぜOttoか? なぜVagrantで
OctopressからHugoへ移行した
このブログは2年ほどOctopressを使って生成してきたが，不満が限界に達したので，Go言語で作られたHugoに移行した． Octopressへの不満は，とにかく生成が遅いこと．100記事を超えた辺から耐えられない遅さになり，最終的には約150記事の生成に40秒もかかっていた．ブログは頻繁に書くのでかなりストレスになっていた． Hugoのうりは生成速度．試しに使ったところ，明らかに速く，すぐに移行を決めた．最終的な生成時間は以下．爆速． 他に良いところを挙げると，まずとてもシンプル．Octopressと比べても圧倒的に必要なファイルは少ない．また，後発だけあって嬉しい機能もいくつかある．例えば，draftタグを記事のヘッダに書いておけば，ローカルでは生成されても，本番用の生成からは外されるなどなど． インストール Go言語で書かれているのでgo getして，デザインテーマをCloneする
Packerを使ってChef/Puppet/AnsibleでDockerのイメージをつくる
Packerを使ってChef/Puppet/AnsibleでDockerのイメージをつくる Packerは，Vagrantの作者であるMitchell Hashimoto氏によって開発が進められているVirtualBoxやVMWare，Amazon EC2などの仮想マシンのテンプレートの作成を行うツール．VagrantのVirtualBox用のBoxを作るveeweeに置き換わるツールとして知られている．最近のアップデートでDockerのイメージのビルドをサポートした． TL;DR Packerを使えばDockerのイメージをDockerfileを使わずビルドすることができる つまり，Dockerfileの特有な記述を使わず，今まで慣れ親しんできたChefやPuppet，Ansibleのようなプロビジョニングツールを使ってDockerのイメージをビルドできる． 参考 Dockerイメージの
デプロイ自動化とServerspec
Serverspec本の献本ありがとうございました．とても面白かったです．詳しい書評はすでに素晴らしい記事がいくつかあるので，僕は現チームでどのようにServerspecを導入したか，どのように使っているかについて書きたいと思います． Serverspec導入の背景 今のチームではサーバーのセッアップおよびデプロイにChefを使っている．本にも書かれているようにこのような構成管理ツールを使っている場合はそのツールを信頼するべきであり，Serverspecのようなテストツールは必要ない．僕らのチームもそのような理由でServerspecの導入には至っていなかった． しかしアプリケーションが複雑になりChefのレシピも混沌とするようになるとそれは成立しなくなる．見通しの悪いレシピはChefへの信頼度を落とす．信頼度の低下はデプロイ不信に繋がり人手（筋肉）によるテストが始まる． サーバーの数がそ
DockerのHost networking機能
DOCKER 0.11 IS THE RELEASE CANDIDATE FOR 1.0 1.0のRCである0.11はいくつかの新機能が追加された．例えば，SELinuxのサポートや，Host networking機能，Link機能でのホスト名，Docker deamonへのpingなど． この中でもHost networking機能がなかなか面白いので，実際に手を動かして検証してみた．事前知識として“Dockerのネットワークの基礎”も書きました．ネットワークに関して不安があるひとが先にみると，Host Networing機能の利点／欠点もわかりやすいと思います． TL;DR Host networking機能を使うと，異なるホスト間のコンテナの連携がちょっぴりやりやすくなる．SerfやConsulのようなサービスディスカバリーツールとの相性も良さそう． まだ出たばかりの機能で実際に使っ
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
HerokuとGithubを使った統一的なツール配布
HerokuとGithubを使った統一的なツール配布 Go言語ではクロスコンパイルがとても簡単で，複数プラットフォーム向けのバイナリをつくってそれを配布するというのがさらっとできる． 単純にやるなら， クロスコンパイルした各バイナリをzip等に固める Github Releaseやbintray，Dorone.ioなどにホストする そして，ユーザには自分のプラットフォームに合ったものをダウンロード／展開してPATHの通ったところに置いてもらう． 開発者からすると，すごい簡単．ホストするまで完全に自動化できる．でも，ユーザからすると若干めんどくさい． もっとツールを使い初めてもらうまでの敷居を下げたい． TL;DR 全プラットフォーム共通で以下のようにツールをインストールできるようにする．若干長いが1コマンド！ $ L=/usr/local/bin/ghr && curl -sL -A "`
複数プラットフォームにGoアプリケーションを配布する
複数プラットフォームにGoアプリケーションを配布する tcnksm/jj 最近試しにGo言語でCLIアプリケーションを作成した．joelthelion/autojumpをシンプルにしただけのツールで，ディレクトリを保存して，どこからでもその保存したディレクトリへの移動を可能にする． Goの環境さえあれば，このようなGo言語のアプリケーションの配布はとても簡単で，インストールは以下のようにするだけでよい． $ go get github.com/tcnksm/jj_ これだけではなく，Goはクロスコンパイルが簡単で，様々なプラットフォーム向けにバイナリを生成することができる．つまり，Goがインストールされていない環境に対しても簡単にツールを配布することができる． Packerなどの最近のHashicorp制のツールは，Go言語で書かれており，OSX，Linux，Windows，FreeBSD
好きなPodcast
twitterでちょっとつぶやいてたけど，最近自分がよく聴いてるPodcastをまとめてみる．Tech系以外もすこし混じってる．他にオススメあれば教えてください． 日本語 Rebuild - Podcast by Tatsuhiko Miyagawa - Podcastを聴くという習慣はここから始まった．大学院生のころからずっと聴いてる．Liveもできる限り聴いてる．大ファン．取り上げる技術もすごい尖っていて面白い．全エピソード好きだけど，敢えてあげるなら，“3: MessagePack”，“14: DevOps with Docker, chef and serverspec”，“27: Dragon Quest, Docker and AngularJS”，“35: You Don’t Need API Version 2”, “37: N Factor Auth”，“42: When
Vagrant + DockerでSinatraを動かす
Vagrant + DockerでSinatraを動かす tcnksm/docker-sinatra 簡単なsinatraアプリケーションをDocker上で動かしてみた． まずはsinatraアプリケーション．特別なことはなく，Procfileとconfig.ruを準備して，foremanで動かす．外部からのアクセスを有効にするため，ListenAddressを指定しておく． #Procfile web: bundle exec rackup config.ru -p 4567 -s thin -o 0.0.0.0 次に，Vagrantの設定．VagrantはDockerのprovisioningが有効な1.4を利用する．vagrantのインストールは以下のBrewfileを準備して，brew bundleする． tap phinze/homebrew-cask install brew-
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
