この記事はコーヒー Advent Calendar 2015の17日目の記事です． コーヒーを淹れること，豆を買いに行くこと，コーヒー器具を集めること，コーヒー関連の本を読むことが好きだ．コーヒーは趣味といっても過言でなない．自宅で美味しいコーヒーを淹れるために今までいろいろ試行錯誤してきたが，最近ある程度固まってきたのでその環境についてまとめてみる． 過去 最初に自分とコーヒーとの馴れ初めをつらつらと． 親がコーヒー好きなので実家では当たり前のように毎日コーヒーが淹れられていた．そのため家で自分でコーヒーを淹れて飲むのは当たり前のものとして育った．実家ではドリップマシンが使われていた．特にこだわりはなく出されるものをそのまま飲んでいたと思う． 自分でコーヒーを淹れるようになったのは大学生で一人暮らしを始めてから．最初は実家にあった使われていないドリッパー（確かHARIO）と近所のスーパー

最近マスタリングTCP/IP SSL/TLS編や暗号技術入門を読んでいた．理解を深めるためにGo言語で標準のcryptoパッケージを触り/実装を読みながら読んだ． cryptoパッケージは他の標準パッケージと同様に素晴らしい．Go言語にはどのような暗号化手法が実装されているのか実例を含めてざっとまとめる．なお本文に書ききれなかったものを含め全ての実装例はtcnksm/go-cryptoにある． 共通鍵暗号 まずは共通鍵暗号をみる．共通鍵暗号は暗号化と復号化に同じ鍵を用いる暗号化方式である．共通鍵暗号はブロック暗号とストリーム暗号の2種類に分けることができる．ブロック暗号は特定の長さ単位で暗号化を行う方式であり，ストリーム暗号はデータの流れを順次処理していく方式である． Go言語にはブロック暗号としてDES（Data Encryption Standard），DESを繰り返すtriple-D

Hashicorpから2015年秋の新作が2つ登場した． Otto - HashiCorp Nomad - HashiCorp Ottoがなかなか面白そうなのでコードを追いつつ，Ottoとは何か? なぜ必要になったのか? どのように動作するのか? を簡単にまとめてみる． バージョンは 0.1.0 を対象にしている（イニシャルインプレッションである） Ottoとは何か? 公式はVagrantの後継と表現されている．が，それはローカル開発環境の構築も担っているという意味で後継であり，自分なりの言葉で表現してみると「OttoはHashicorpの各ツールを抽象化し開発環境の構築からインフラの整備，デプロイまでを一手に担うツール」である．ちなみにOttoという名前の由来はAutomationと語感が似ているからかつ元々そういう名前のbotがいたからとのこと． なぜOttoか? なぜVagrantで

Apache kafka 最近仕事でApache Kafkaの導入を進めている．Kafkaとは何か? どこで使われているのか? どのような理由で作られたのか? どのように動作するのか（特にメッセージの読み出しについて）? を簡単にまとめておく（メッセージングはまだまだ勉強中なのでおかしなところがあればツッコミをいただければ幸いです）． バージョンは 0.8.2 を対象に書いている． Apache Kafkaとは? 2011年にLinkedInから公開されたオープンソースの分散メッセージングシステムである．Kafkaはウェブサービスなどから発せられる大容量のデータ（e.g., ログやイベント）を高スループット/低レイテンシに収集/配信することを目的に開発されている．公式のトップページに掲載されているセールスポイントは以下の4つ． Fast とにかく大量のメッセージを扱うことができる Scal

Herokuの'docker:release'の動き Introducing ‘heroku docker:release’: Build & Deploy Heroku Apps with Docker HerokuがDockerを使ったツールを提供し始めた．一通り触ってコードもちょっと読んでみたので現時点でできること，内部の動きについてまとめる． TL;DR Herokuのデプロイ環境とおなじものをDockerでつくれる Buildpackを使わないでDockerfileからSlugを作れる 自分の好きなDockerイメージをHeroku上で動かせるようになるわけではない． 何ができるのか まず何ができるようになったのかについて簡単に書く．プラグインをインストールするとDockerコマンドが使えるようになる． $ heroku plugins:install heroku-docker

mitchellh/panicwrap Go言語でpanicが発生したらどうしようもない．普通はちゃんとテストをしてそもそもpanicが発生しないようにする（もしくはトップレベルでrecoverする）．しかし，クロスコンパイルして様々な環境に配布することを，もしくはユーザが作者が思ってもいない使いかたをすることを考慮すると，すべてを作者の想像力の範疇のテストでカバーし，panicをゼロにできるとは限らない． panicが発生した場合，ユーザからすると何が起こったか分からない（Go言語を使ったことがあるユーザなら「あの表示」を見て，panicが起こったことがわかるかもしれない）．適切なエラーメッセージを表示できると良い．開発者からすると，そのpanicの詳しい発生状況を基に修正を行い，新たなテストケースを追加して二度とそのバグが発生しないようにしておきたい． mitchellh/panicw

Serverspec本の献本ありがとうございました．とても面白かったです．詳しい書評はすでに素晴らしい記事がいくつかあるので，僕は現チームでどのようにServerspecを導入したか，どのように使っているかについて書きたいと思います． Serverspec導入の背景 今のチームではサーバーのセッアップおよびデプロイにChefを使っている．本にも書かれているようにこのような構成管理ツールを使っている場合はそのツールを信頼するべきであり，Serverspecのようなテストツールは必要ない．僕らのチームもそのような理由でServerspecの導入には至っていなかった． しかしアプリケーションが複雑になりChefのレシピも混沌とするようになるとそれは成立しなくなる．見通しの悪いレシピはChefへの信頼度を落とす．信頼度の低下はデプロイ不信に繋がり人手（筋肉）によるテストが始まる． サーバーの数がそ

DockerイメージのビルドにPackerを使うべき理由 “Ask HN: Do you bake AMIs for AWS deployments?”での，Mitchell Hashimoto氏のコメントより．簡単に抄訳． ソフトウェアのインストールや設定の知識は，依然としてShellscriptやChef，Puppetに残っている．Packerを使えば，Dockerのコンテナの作成に現時点で存在している経験やCIプロセスなどを利用できる． 共通のフォーマットの設定．Dockerfileの記述は特有である．それは良いが，現状様々なイメージ(AMIやDockerのコンテナ，Virtualboxなど)が存在する．Dockerが全てではないとき，イメージをビルドするために様々なツールをメンテするのは負担になる．Packerを使えば，一つの方法で，さまざまなプラットフォームに対応できる．たとえ企

2014年の後半あたりからDocker，Docker Inc.への批判を多く見かけるようになった（もちろんもともと懸念や嫌悪を表明するひとはいた）．それを象徴する出来事としてCoreOSチームによる新しいコンテナのRuntimeであるRocketのリリースと，オープンなアプリケーションコンテナの仕様の策定を目指したApp Containerプロジェクトの開始があった． CoreOS is building a container runtime, Rocket 批判は，セキュリティであったり，ドキュメントされていない謎の仕様やバグだったり，コミュニティの運営だったり，と多方面にわたる．これらは具体的にどういうことなのか？なぜRocketが必要なのか？は具体的に整理されていないと思う．これらは，今後コンテナ技術を使っていく上で，オーケストレーションとかと同じくらい重要な部分だと思うので，ここ

Dockerを便利に使うためのaliasをつくった tcnksm/docker-alias いろいろなひとのTipや，自分がやったやつの寄せ集めで作った．以下で使えるようになる． $ curl -fsSL https://raw.github.com/tcnksm/docker-alias/master/zshrc >> ~/.zshrc && source ~/.zshrc コンテナの起動 インタラクティブモードでコンテナを起動する． alias dki="docker run -i -t -P" $ dki base /bin/bash デーモンモードでコンテナを起動する． alias dkd="docker run -d -P" $ dkd base /bin/echo hello コンテナの情報 最後に起動したコンテナのIDを取得する． alias dl="docker ps -l

"Orchesrating Docker"という本をレビューした Orchestrating Docker | Packt Orchestrating Docker: Amazon.com: Books Packt Publishingから1月22日に出版された“Orchestrating Docker”という本にレビュアーとして参加した．本の中身は，Dockerの基礎とCoreOSやdokkuといった周辺ツールをサンプルコードとともに幅広く紹介するという内容になっている．日本の技術界隈では見かけなかった話題もちょくちょく含まれていて面白い． 英語の本をレビュー依頼を受けるのはよくあるらしいが，実際にやったひとの話は見かけないので簡単にどんな感じだったかを簡単に書いておく． 経緯 9月あたりにPacktの編集者からDocker本のレビューに興味がないかとメールが届いた．日本人の自分が選ばれ

CoreOSクラスタにDockerコンテナをデプロイする Docker Meetup Tokyo #4 CoreOSの概要とDockerを実際に運用しようと思ったときにDockerが抱える問題をCoreOSがどのようにそれを解決するかについて発表した．デモではTerraformを使ってDigitalOcean上にCoreOSクラスタを立てて，デモアプリケーションコンテナを動的にスケールさせる様子を実演した（ソースは全てtcnksm/docker-meetup-4-demoにある）． 雑感 簡単にMeetupの感想を書いておく． 今回はDockerそのものの発表よりも，オーケストレーションやサービスディスカバリーなどの周辺ツールやサービスの発表が多かった．ツール（もしくはDocker専用のOS）では，CoreOS，Kubernetes，RedHad Atomic host，サービスではAma

Werckerの仕組み，独自のboxとstepのつくりかた WerckerはTravisCIやDrone.ioのようなCI-as-a-Serviceのひとつ．GitHubへのコードのPushをフックしてアプリケーションのテスト，ビルド，デプロイを行うことができる． Werckerは，TravisCIのように，レポジトリのルートにwercker.ymlを準備し，そこに記述された実行環境と実行コマンドをもとにテスト/ビルドを走らせる． Werckerには，その実行環境をbox，実行コマンド（の集合）をstepとして自作し，あらかじめWercker Directoryに登録しておくことで，様々なテストからそれらを呼び出して使うという仕組みがある．実際，Werkcerで標準とされているboxやstepも同様の仕組みで作成されている（wercker · GitHub）． 今回，WerkcerでのGo

CoreOS is Linux for Massive Server Deployments · CoreOS CoreOS + Docker Meetup Tokyo #1に参加してCoreOSにめっちゃ感動したので，CoreOSに入門していろいろ触ってみた． まず，CoreOSの概要とそれを支える技術について説明する．次に実際にDigitalOcenan上にVagrantを使って実際にCoreOSクラスタを立てて，CoreOSで遊ぶ方法について書く． CoreOSとは何か CoreOSは，GoogleやFacebook，Twitterといった企業が実現している柔軟かつスケーラブル，耐障害性の高いインフラの構築を目的としたLinuxディストリビューションである．軽量かつ使い捨てを前提にしており，クラウドなアーキテクチャのベストプラクティスを取り入れている．CoreOSの特徴は大きく4つ挙

Dockerの再起動オプション Announcing Docker 1.2.0 | Docker Blog v1.2でもいくつかの面白い機能が追加された．例えば，今まで--privilegedオプションを使うと全権限を与えてしまっていたが--cap-addや--cap-dropオプションでそれを制限できるようになったり，–deviceオプションで利用したいデバイスを指定できたり，コンテナ起動時に/etc/hostsを編集できたり…など． 中でも再起動オプションが良さげなので，実際に触ってみた．docker runを実行するときに--restartオプションに以下を指定するとコンテナの再起動の挙動を変更できる: no - 再起動しない（デフォルト） on-failure - 終了ステータスがnon-zeroの場合に再起動する on-failure:X - 終了ステータスがnon-zeroの場

コマンドラインツールについて語るときに僕の語ること - YAPC::Asia Tokyo 2014 コマンドラインツールが好きで昔からつくってきた． 今年のYAPCで，そのコマンドラインツールをつくるときにどういうことを意識して作っているのか？どのような流れで開発しているのか？といったことを語る機会をもらえた． 具体的な内容については，是非トークを聴きに来てもらうとして， スライドをつくるにあったって過去に読んだ資料や，よく参考にしている記事を集め直したので，その一部を参考資料としてまとめておく． UNIXという考え方 UNIXという考え方 Mike GancarzによるUNIXの思想や哲学をまとめた本．古いが全然色あせてない． コマンドラインツールの作り方を書いた本ではないが，これらの思想の上で動くツールはこの思想に準拠して作られるべきだと思う．何度も読んで考え方を染み付かせた． 小さい

“flynnの時代” “Docker meetup tokyo #3”で発表してきた．内容は，Dockerの応用の１つであるOSSでPaaSをつくるflynnというプロジェクトの概要とそのアーキテクチャーの紹介．このflynnというプロジェクトの中には，Dockerの面白い使い方がたくさん詰まってるため，今後Dockerを使う人が，その応用の際の参考になればという思いで紹介させてもらった． 今回の発表のために資料を集めまくり，理解できない部分は出来る限りコードも読んだ．発表スライドの補完にもなると思うので，そのメモ書き（一応体裁は整えた）を公開しておく． デモ 以下は，簡単なデモ． やっていることは以下． nodeのアプリケーションをデプロイ ルーティングの追加 スケール コマンドを含めた詳しい解説は以下で解説する． 前提知識 (Herokuの動作) まず，前提知識としてPaaS (ここで

高速にGo言語のCLIツールをつくるcli-initというツールをつくった tcnkms/cli-init・GitHub cli-initを使えば，Go言語コマンドラインツール作成時のお決まりパターンをテンプレートとして自動生成し，コア機能の記述に集中することができる． デモ 以下は簡単な動作例． 上のデモでは，addとlist，deleteというサブコマンドをもつtodoアプリケーションを生成している．生成結果は，tcnksm/sample-cli-initにある． 背景 Go言語で作られたコマンドラインツールを見ていると，codegangsta/cliというパッケージがよく使われている． これは，コマンドラインツールのインターフェースを定義するためのライブラリで，これを使えば，サブコマンドをもつコマンドラインツールを簡単につくることができる（Usageを自動で生成してくれたり，bash

カーネル読書会 #111でLTしてきた+Dockerによる次世代のPaaS “DockerでPaaSをつくる #ylug_111” @hyoshiokさんにカーネル読書会でLTをする機会をいただいた．内容はDockerの応用の１つでOSSのPaaSをつくるというもの．Herokuの内部実装を説明しつつ，Dockerによりいかに簡単にPaaSを作れるようになったかを話した． 最後にちょっと話した，次世代のPaaSもしくはHeroku++を目指すFlynnは，野心的ですごく面白い．簡単にいうとFlynnはHerokuの簡便さとAmazon EC2のような自由度を兼ね備えたPaaSを目指している．Flynnは以下の2つのレイヤーで構成される． layer0：CoreOSのetcdによるサービスディスカバリー層 layor1：Herokuのようなアプリケーションのデプロイ+管理層 このプロジェクト

できればシェルスクリプトなんて書きたくないんだけど，まだまだ書く機会は多い．シェル芸やワンライナーのような凝ったことではなく，他のひとが使いやすいシェルスクリプトを書くために自分が実践していることをまとめておく． ヘルプメッセージ 書いてるシェルスクリプトが使い捨てではなく何度も使うものである場合は，本体を書き始める前に，そのスクリプトの使い方を表示するusage関数を書いてしまう． これを書いておくと，後々チームへ共有がしやすくなる．とりあえずusage見てくださいと言える．また，あらかじめ書くことで，単なるシェルスクリプトであっても自分の中で動作を整理してから書き始めることができる．関数として書くのは，usageを表示してあげるとよい場面がいくつかあり，使い回すことができるため． 以下のように書く． function usage { cat <<EOF $(basename ${0})