Electron(旧Atom-Shell)勉強会 #1 を主催＆話してきた #atom_shell

帰ってからブログを書くまでが勉強会です。
というわけで、Electron(旧:Atom-Shell)勉強会 #1で、私の方からはElectron(旧Atom-Shell)基礎+入門を話しました。

• Electron(旧Atom-Shell)基礎+入門
• 

経緯
vvakameさんにムチャぶりされて、ngJapanのイベント中に頑張ってAngular2をAtom-Shell上で動かすデモを作って、デモアプリ完成の10分後に飛び入りLTして発表したものの、TODOデモアプリ上をスライド代わりに使ってLTをするという暴挙にでるしかなかったので、もっとちゃんとAtom-Shellについて話したいと思ったので主催してみた。

勢いでガッとconnpassにイベントを建てたのはいいものの、Atom-Shellなんて誰も触ってないし、発表者は自分1人だと思っていたら、勉強会の1週間前にAtom-ShellからElectronにプロジェクト名が変更というハプニング。
おお、これは注目度が上がって来たからプロジェクト名変更になったのか？これは勉強会に力を入れなければ！と思ったら、リポジトリ名変更に伴い、いろんなビルドツールが軒並み転んでいたので、スライドを作るより先にgulp-electronを作るという作業に入って肝心のスライドがあんまり出来が良くなかったのはちょっと残念。

感想
強制的にconnpassにイベントを立てておいて締め切りまでにつくり上げる、マリオの強制横スクロール（水）みたいなメソッドがうまく行ったのですが、他の人もこのイベント駆動に巻き込まれたみたいで、リポジトリ作った、コミットした、pullreq投げた、等のアウトプットをした人が多かったので、これからも継続して行きたいですね。
あと、すごく感謝された。なんだかわからないけど面白かった、楽しかった、React勉強会の裏番組だと思ってたら予想以上に面白くて来てよかった、という言葉を貰って大変嬉しかった :)

やはり俺のイベントは間違っている。続

エッジな勉強会にはエッジな人が来るという法則が発動したのか、発表者が3人、LTが4人も集まって、みんなバラバラの言語、バラバラのフレームワークでやってて面白い発表が多かった。普通なら自分の興味のない言語の話をされても辛いのに、今回のイベントではLLイベントに似たワクワク感があった。

* TypeScript ←わかる
* Flux Framework ←わかる
* Scala.js ←うん？
* ClojureSciprt ← ファッ
* C言語との連携 ← あっ・・・
* ギャルゲを作る ← ？？？

・・・誰にも迷惑のかからない小さなツールを簡単に作れるという手軽さが、仕事で自分の好きな言語を書けないマイノリティ達を立ち上がらせたのだろうか？謎は深まるばかりだ。

次回
次回はハッカソンです。詰まっている所があれば隣の人に聞けるみたいな環境を作っておいて、知見がたまったらまた#2をやりたいと思います。
Electronはプロダクションでバリバリ使っているところもあれば、小さな趣味向けなところもあるので、ゆるゆるとやっていきたい。
イベント作るときはconnpassで作るので、Electron(旧Atom-Shell)勉強会グループのメンバーになっておけば、新しくイベント作られたらメール飛んでくるので、気になる人はconnpassで登録しておくとよいだろう。

資料

Electron(旧Atom-Shell)基礎+入門

ClojureでElectronアプリを作ろう

atom-shellでファイル無限吸い込み+sync機構を作る

TypeScriptでElectron

Electron 勉強会 #1にてElectronでFluxを動かす話をした #atom_shell

Rails プログラマが Electron でギャルゲをつくりはじめた

ElectronとC/C++ネイティブモジュール(node-ffi)

Docker Meetup Tokyo #2 を主催＆話してきた #dockerjp

帰ってからブログを書くまでが勉強会です。
というわけで、Docker Meetup Tokyo #2で、私の方からは今からでも間に合うDocker基礎+Docker0.9/0.10概要を話しました。

• スライド: http://www.slideshare.net/mainya/dockerdocker09-010
• Asciinemaのデモ: https://asciinema.org/a/7392

感想
機材トラブルもありましたが、なんとか開催出来たのはGoogle社及びMeetupスタッフの手厚いサポートのお陰です。本当にありがとうございました。
日経ソフトウエアの記事の執筆＆Dockerブログの翻訳＆HomeBrewアップデート＆Meetupイベントと、重なりすぎてて大変忙しかったですが、周りの人の助けも借りて無事乗り切れました。
自分の発表もまだまだ未熟であり改善点も多い（この記事書きながら録画動画を見てる。辛い＞＜）ですが、Docker Tシャツを眺めて気合を入れて次に活かす所存。
Linuxカーネルの話とか、Docker+etcdでレイトレーシングの話とか、凄すぎてまだ頭が着いて行ってないので何回も読み直さないと。Google先生の会場をお借りしているイベントでAWSの話が出てくるのもまた面白い。アンチベンダーロックインだ！
このイベントを機会に少しでも、日本のDockerユーザーと、Dockerコミュニティが増えると嬉しいなぁ。そしてDockerコントリビューターが増えると一番嬉しいです:)

次回
次回？次回ももちろんやりますよ！
今回、100人のイベントで355人が補欠という大変な状態で、Dockerウェーブを感じたのは嬉しいのですが、埋まるのが早すぎでした。Docker Meetup #3 は募集開始前に予めアナウンスをしたいですね。
しかし、Dockerの進化が早すぎるので、アウトプットしないとあっという間に置いて行かれます。Docker Meetup #3 に面白い話があるんだけど！という方は是非TwitterまたはFacebook Groupにどうぞ。会場も募集中です。

Docker Meetupのコンテナ化が一番望まれているのかもしれない。

http://www.slideshare.net/mainya/dockerdocker09-010

Docker 0.10リリースドキュメント日本語訳: 品質とOps Tooling

Docker 0.10が出たので例によってリリースドキュメントをざっくり翻訳してみました。間違い等見つけたら指摘お願いします！
個人的には日本人開発者が増えてきて嬉しい限りです:)
Docker 0.10のアップデートまとめ：バグ修正たくさん、シグナルハンドリングの修正、TLS認証サポート、Systemdプラグインサポート
翻訳元：http://blog.docker.io/2014/04/docker-0-10-quality-and-ops-tooling/

Docker 0.10: 品質とOps Tooling

今日はDocker 0.10をご紹介させていただきます。お気に召して頂けると幸いです！

私たちは、今回のリリースにコントリビュートしてくださいましたすべての素晴らしいコミュニティの人たちに御礼申し上げます: Tianon Gravi, Alexander Larsson, Vincent Batts, Dan Walsh, Andy Kipp, Ken Ichikawa, Alexandr Morozov, Kato Kazuyoshi, Timothy Hobbs, Brian Goff, Daniel Norberg, Brandon Philips, Scott Collier, Fabio Falci Rodrigues, Liang-Chi Hsieh, Sridhar Ratnakumar, Johan Euphrosine, Paul Nasrat そして、Dockerのすべての素晴らしい人たちに。

今回のリリースは、Docker 1.0の道のりの次のステップです。品質改善とOps Toolingに優先的に焦点を当てておりチェンジログは特に大きい。

品質

第一に、私たちは1.0が近いため品質に注力し続けてきました。今回リリースでは、１週間のスプリント結果のバグ、テスト改善、ドキュメント、UIの不具合のクリーンアップなどの修正が含まれています。その１周間では、48チケットをクローズし、68 Pull Requestをマージしました。少しサンプルとしてあげると次のとおりです。

• 新しいintegrationテストハーネスは、コマンドラインインターフェイスのレグレッション防止になります
• `docker build`中のアウトプットの問題が修正されました
• 同一マシン上でコンテナの数千を実行している場合の様々なパフォーマンスと安定性の問題が修正されました
• `docker build`中のシンボリックリンク処理が修正されました
• `docker build`コマンドは、プライベートGitリポジトリのPull時にクライアントの認証情報を使用できます
• device mapperストレージへの多数の信頼性とパフォーマンスの向上
• `docker build`中のキャッシュ問題が修正されました
• `df`や`mount`や同様のツールをコンテナ内で使用することができます
• `docker build`は MKNOD を必要とするコマンドを呼び出すことができます
• 数十のマイナーなドキュメントの改善
• 全面的により良いテストカバレッジ
• シェル補完を修正しました
• tmuxなどのコンソールツールをコンテナ内で使用することができます
• `docker cp`のコンテンツ検出が修正されました
• lxc execution driverは、lxc 1.0で動作するようになりました
• ネットワークポートのハイスループットのアロケーションに関する問題が修正されました
• `docker push`はDocker indexへのpushに、全てのタグの代わりに単一のimageがサポートされました
• エラーメッセージの内容とボリュームが読みやすくなりました
• `docker run -volumes-from` に関する問題が修正されました
• Ubuntuの特定のバージョンのAppArmorの問題が修正されました
• 競合状態、低速なメモリリークとスレッドリークが修正されました
• 一部のコマンドの出力を、より予測可能なように並び替えました

見て頂ければわかるように、こうした問題は個々では非常に些細なものです。しかし、全体でみれば大きな違いを生むのです！私たちは次のリリースに関して、大小の問題の修正を継続的に計画しています。あなたがより速く対処してほしい問題があった場合、何時でもissueをopenしたり、既存のissueにコメントしてあなたの興味を表明でき、私たちが注目できるようにしてください！もちろん、私たちはあなたのコントリビュートを求めています。私たちはあなたが指摘する注意が必要な問題に注視いたします。そしてあなたが取り掛かるのをサポートできます。Freenodeの#dockerのIRCチャンネルに来てhiと言ってください！

Ops Tooling

今回のリリースで、私たちは1.0: ops readinessに向けて新フェーズを開始している。プロダクションで使用されるためには、Dockerがクラッシュしないようにするだけでは十分ではありません。これは、システム管理者が現在使っているツールとうまく統合する必要があります。ロギング、システムの初期化、監視、リモート管理、バックアップなど。
明らかに1リリースだけでは、システム管理者フレンドリーな安息の境地に到達することはできません。しかし、0.10ではその方向でいくつかの重要なステップを進めています。

• Stop behavior： `docker stop` のデフォルトの動作では、"アプリケーションの安全性"の側にエラーになるように変更されています。特に、アプリケーションがSIGTERMシグナルに応答しない場合、SIGKILLによる強制killの代わりにDockerはエラーを返します。これは`docker stop`はthe most criticalや、脆性なアプリケーションでも、データの破損や他の副作用のリスクなしで安全に使用することができることを意味します。（それでも突然の終了でも回復できるようにアプリケーションを設計する必要があることに注意してください - Dockerは電源コードが引っこ抜かれるのは防げませんよ！）

• Signal handling：Docker デーモン自体は今と同じようにシグナルを処理します。SIGTERMを受信すると、Dockerは実行中のすべてのコンテナにそれを転送し、コンテナが正常に終了するのを待ってからDockerを終了します。コンテナが正常に終了しなかった場合、Dockerは透過的にその動作を公開し、永遠に待機します。外部ツールで 1)更に待機, 2)諦める, 3)SIGKILLによる強制終了 を選択できます。SIGKILLがどのように動作するか注意してください。DockerはアプリケーションにSIGKILLを転送できません。代わりに、次回起動時に"孤立"コンテナを検出し、その際コンテナにSIGKILLを送信します。要するに、コンテナがSIGKILL自体を受信するのを除き、DockerがコンテナにSIGKILLを送信することはありません。

• TLS認証: 何度もリクエストされている機能は、セキュアな方法で、ネットワーク経由でDocker リモートAPIを公開する機能です。Docker 0.10では、TLS/SSL証明書をビルトインでサポートしました。SSL証明書を使用して特定ホストだけにAPIへのアクセスを制限したりAppropriate証明書を使用してユーザーを制限できます。これは、リモートAPIを確保する上で最初のステップであり、私たちはよりきめ細かいロールベースのアクセス制御だけでなく、将来的には他の認証形式を提供する計画があります。

• Systemd slices: Dockerは、systemdプラグインをサポートしました。基礎となるホストがsystemdで初期化された場合に自動検出されます。systemdが検出された場合、Dockerはcontrol groupの管理のために、デフォルトでは直接/procディレクトリにアクセスするが、その代わりに自動的に低レベルの systemd APIを使用するようになります。現在、リソースの割り当てを管理するのにsystemdを使用しているシステム管理者にとっては、Dockerコンテナがsystemdに自動的に表示されることを意味します。

• Release hashes: Dockerのすべてのリリースでは、すべての成果物のビルドにSHA256とMD5ハッシュを含んでいます。これらはドキュメントサイトとダウンロードページに公開されており、あなたのインストールが改ざんされていないことを検証することができます。たとえば、公式のLinuxとDarwinバイナリビルドを次のコマンドでSHA256を検証できます。

 curl https://get.docker.io/builds/Linux/x86_64/docker-0.10.0.sha256
 curl https://get.docker.io/builds/Darwin/x86_64/docker-0.10.0.sha256

最後に、近い将来Docker 1.0のリリースに、積極的なDocker 0.10のテストをお願い致します。チケットにログを貼り、あなたのフィードバックをよろしくお願い致します！

サポートやヘルプをしてくださった全ての人に感謝を捧げます, and happy hacking!

The Docker maintainers

翻訳元：http://blog.docker.io/2014/04/docker-0-10-quality-and-ops-tooling/

Docker 0.9リリースドキュメント日本語訳: Execution driversとlibcontainer導入

Docker 0.9が出たのでリリースドキュメントをざっくり翻訳してみました。間違い等見つけたら指摘お願いします！
翻訳元：http://blog.docker.io/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/

Docker 0.9: Execution driversとlibcontainer導入

Fellow Dockers,
今日はDocker 0.9をご紹介させて頂きます。このリリースでは、私達は機能の品質向上、コアの縮小と安定化、全てのメジャーOSへのファーストクラスのサポート提供に、継続して注力してきました。
数十 の バグ修正に加え、Docker 0.9は2つのメジャーな改善が含まれています: Execution driversとlibcontainer
いつものように、改善点の完全なリストはCHANGELOGで見られます。

Execution drivers
その一、私達はExecution driversという、各コンテナの周囲の実行環境をカスタマイズできるAPIを導入しました。
これでDockerはインストールベースで利用可能になっている多数の隔離ツールをトレードオフとともに利用できます: OpenVZ, systemd-nspawn, libvirt-lxc, libvirt-sandbox, qemu/kvm, BSD Jails, Solaris Zones, 古き良きchroot。
これは、LXCに加え、独自のドライバーとして利用可能であり続けるでしょう。

複数のドライバを開発する進行中のプロジェクトが既に存在します。あなたも参加して楽しんでみませんか？Freenodeの #docker-dev でhiと挨拶するだけで、私達はあなたのドライバ開発のお役に立てるでしょう。

New default driver: libcontainer

その二、私達はLXCドライバと並んで新しいビルトインの実行ドライバを導入しました。このドライバはlibcontainerをベースとしています。私達は、他の依存関係なしで直接カーネルのコンテナAPIアクセスするためにPure-Go言語でドライバを開発しました。

libcontainerのおかげで、Dockerは既存の枠を超えて、namespaces, control groups, capabilities, apparmor profiles, network interfaces, firewalling rulesを操作できるようになりました。
これら全ては、LXCやその他のuserland packageに依存しない一貫して予想可能な方法です。
Dockerの可動部品数を大幅に減らすことで、LXCのさまざまなバージョンやディストリビューションに起因するその副作用からDockerを隔離できました。
実際、libcontainerをデフォルトにすることを決めてから安定性向上を提供してくれました。
言い換えてしまえば、Docker 0.9では、LXCは必須ではなくなったのです。
LXCドライバに切り替えるには、単にDockerデーモンをdocker -d -e lxcで再起動するだけです。もちろん、今後もLXCドライバをサポートしていきます。

libcontainerをあなたのGo-langプロジェクトで使う方法

libcontainerを開発したのは、他のプロジェクトがこれを再利用するのを期待してのことです。もしあなたがnamespaces, cgroups, capabilitiesなどのLinuxのネイティブコンテナの機能興味があるなら、私たちはハッキングを推奨します！Go言語パッケージを取得し、APIドキュメントをチェックアウトを開始するには：

 go get github.com/dotcloud/docker/pkg/libcontainer
 godoc github.com/dotcloud/docker/pkg/libcontainer

1.0での目標地点

本リリースは、安定したプロダクション対応である1.0のリリースに向けた大きな一歩です。次のリリースは0.10を計画しています。0.10は、1.0の最初のrelease candidateです。

以前から述べている通り、Docker 1.0の目標は、次のとおりです。

• プロダクション品質
• すべての主要なOSでのファーストクラスのサポート
• 小さなコアと安定したプラグインというアーキテクチャ
• 十分なドキュメント
• Dockerとパートナーによって、商用サポートができること
• Dockerの長期的なサポートを提供することができること

私たちは既に0.10の準備作業に励んでいます。私達が考えるあなたが気に入るであろういくつかのエキサイティングな改善です。もし覗き見したいと思ったり、貢献したいと考えたときは・・・ここに来てhi!と言いましょう！私たちはFreenodeの#dockerにいます。私たちは、すべてのレベルのDockerファンを歓迎し、あなたの最初の貢献をお手伝いすることができます。
これまでと同様の、コントリビューター、コミュニティーに感謝します。今では総勢352人！

Thanks and happy hacking!

The Docker team

boot2dockerのisoからGCEのInstanceを起動するbash scriptを書けませんでした(WIP)

いつかはカーネルハッカーの高みに登るんだ・・・！
と胸に秘めた思いをせっかくの休日なのでこの思いを捧げようと思って、boot2dockerのイメージをそのままGCEで動かそう！と思ったけど、タイトル通り。とりあえずbash script書いてみたけどダメでしたー。マシンの起動はするけどBootloaderまで行けてない模様
うーむ。boot2dockerのisoをそのままrawイメージにして起動しようとしてるけど、そもそもboot2docker.isoがBootableなisoじゃないくて、自分でPXEブートとBootloaderを入れたisoを作れば行けるような気もする・・・
isoダウンロードとGCSにアップロード、GCEインスタンス起動まで書いちゃったから余計なコードが多いけど現状こんな感じ。これが動いたらpacker使って今風に書いたりもしてみたい。
一応の成果物：https://gist.github.com/mainyaa/8936794

使い方：

$ wget https://gist.github.com/mainyaa/8936794/raw/539b989139226aa8894b0d24536bda02f282dfc1/gce-boot2docker-image-boot.sh
$ chmod +x gce-boot2docker-image-boot.sh
$ ./gce-boot2docker-image-boot.sh <GCE_PROJECT_ID>

起動後のシリアルコンソールはこんな感じ。Bootloaderが見つかっていないという推測は合っているのだろうか。はたして。

+ gcutil getserialportoutput vm-boot2docker-1392134379
INFO: Zone for vm-boot2docker-1392134379 detected as us-central1-a.
Changing serial settings was 0/0 now 3/0
Start bios (version 1.7.2-20131007_152402-google)
No Xen hypervisor found.
Unable to unlock ram - bridge not found
Ram Size=0x26600000 (0x0000000000000000 high)
Relocating low data from 0x000e10a0 to 0x000ef780 (size 2161)
Relocating init from 0x000e1911 to 0x265d07a0 (size 63291)
CPU Mhz=2600
=== PCI bus & bridge init ===
PCI: pci_bios_init_bus_rec bus = 0x0
=== PCI device probing ===
Found 4 PCI devices (max PCI bus is 00)
=== PCI new allocation pass #1 ===
PCI: check devices
=== PCI new allocation pass #2 ===
PCI: map device bdf=00:03.0  bar 0, addr 0000c000, size 00000040 [io]
PCI: map device bdf=00:04.0  bar 0, addr 0000c040, size 00000020 [io]
PCI: init bdf=00:01.0 id=8086:7110
PIIX3/PIIX4 init: elcr=00 0c
PCI: init bdf=00:01.3 id=8086:7113
Using pmtimer, ioport 0xb008, freq 3579 kHz
PCI: init bdf=00:03.0 id=1af4:1004
PCI: init bdf=00:04.0 id=1af4:1000
Found 1 cpu(s) max supported 1 cpu(s)
MP table addr=0x000fdaf0 MPC table addr=0x000fdb00 size=240
SMBIOS ptr=0x000fdad0 table=0x000fd9c0 size=269
Memory hotplug not enabled. [MHPE=0xffffffff]
ACPI DSDT=0x265fe1f0
ACPI tables: RSDP=0x000fd990 RSDT=0x265fe1c0
Scan for VGA option rom
WARNING - Timeout at i8042_flush:68!
All threads complete.
Found 0 lpt ports
Found 0 serial ports
found virtio-scsi at 0:3
Searching bootorder for: /pci@i0cf8/*@3/*@0/*@0,0
Searching bootorder for: /pci@i0cf8/*@3/*@0/*@1,0
virtio-scsi vendor='Google' product='PersistentDisk' rev='1' type=0 removable=0
virtio-scsi blksize=512 sectors=20971520
Searching bootorder for: /pci@i0cf8/*@3/*@0/*@2,0
...省略
Searching bootorder for: /pci@i0cf8/*@3/*@0/*@255,0
Scan for option roms
Searching bootorder for: HALT
drive 0x000fd950: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=20971520
Space available for UMB: 000c0000-000eb800
Returned 122880 bytes of ZoneHigh
e820 map has 6 items:
  0: 0000000000000000 - 000000000009fc00 = 1 RAM
  1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
  2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
  3: 0000000000100000 - 00000000265fe000 = 1 RAM
  4: 00000000265fe000 - 0000000026600000 = 2 RESERVED
  5: 00000000fffbc000 - 0000000100000000 = 2 RESERVED
Unable to lock ram - bridge not found
Changing serial settings was 3/2 now 3/0
enter handle_19:
  NULL
Booting from Hard Disk...
Booting from 0000:7c00

書いてから気づいた。CoreOSのLive ISO作るbash scriptを書きました CoreOSのこれが参考になりそう。あとでまた試す。

Docker0.8とboot2dockerがhomebrewに入った件

Docker 0.8がリリースされてMacが公式サポートされたのはいいのですが、公式のインストール方法が複雑で、homebrewにはまだ入ってない状態でした。

boot2dockerをhomebrewに入れるpullreqは、依存関係のdockerがhomebrew-binaryにあることからかなり頓挫してたところへ、颯爽とdockerメンテナが現れて、ソースからのビルド方法を書いていったのが今回のハイライト。

そしてソースからビルドしたdockerのpullreqも無事にhomebrew本体に入り、boot2dockerもHomeBrewに入りました。いやー。Macユーザには嬉しいですねぇ。

これでMacでDocker0.8のインストールが非常に簡単になりました。

$ brew update
$ brew install boot2docker # <- dockerホストv0.8 (依存しているdocker v0.8も一緒に入ります
$ export DOCKER_HOST=localhost
$ boot2docker init
$ boot2docker up
$ docker version
Client version: 0.8.0
Go version (client): go1.2
Git commit (client): cc3a8c8d8ec57e15b7b7316797132d770408ab1a

Server version: 0.8.0
Git commit (server): cc3a8c8
Go version (server): go1.2
Last stable version: 0.8.0

なお、GCE+Dockerハンズオンで使ったdvmの機能は殆どboot2dockerが実装してしまったので、これからはboot2dockerさえあれば大丈夫です。

最速Docker研究会(DockerのTipsを20個上げていくぜ編)

にゃんぱす〜

最近Dockerにどっぷりなんですが、Dockerについて色々地雷Tipsがあるのでそれをベストプラクティス風にまとめてみました。
Dockerコマンドが動いたけど、これからプロジェクトのDockerfileを書くようにしてみたいんだけど。。。みたいな人にオススメ。

インストール編

1. MacでDockerのインストールで詰まった

なんかよくわからないエラーが出てインストール出来ないんだけど＞＜
versionを確認して最新の環境にしましょう。とくにxCodeとVirtualBoxとvagrantのバージョンは最新のものでないとダメです。

$ brew -v
Homebrew 0.9.5

$ VirtualBox --help
Oracle VM VirtualBox Manager 4.3.6
(C) 2005-2013 Oracle Corporation
All rights reserved.

$ vagrant -v
Vagrant 1.4.3

$ docker version
Client version: 0.7.6
Go version (client): go1.2
Git commit (client): bc3b2ec
Server version: 0.7.6
Git commit (server): bc3b2ec
Go version (server): go1.2

Dockerで環境構築編

2. docker -t -i + docker commitはなるべく使わない

使うとしたら、バグっぽい動作しているDockerfileのentrypointを削除してdocker -t -i /bin/bashで入るとき。Dockerfileを作りましょう

3. docker build時には必ずタグを付ける。

タグ名は/。例えば、mainyaaのredisならmainyaa/redis。この時のはDocker indexにアップロードするときのユーザー名になる。

$ docker build -t mainyaa/redis .

4. fswatchで監視してビルドする(Mac only)

Dockerfileを編集してbuildしてのサイクルは自動化しましょう

$ brew install fswatch
$ fswatch . "docker build -t <yourname>/<tag> ."

5. dvmを使う

vagrant上で動かすのはなるべく軽いゲストOSを選ぶ（boot2dockerかcoreosがオススメ）。
vagrant sshなしでMac上からvagrantのdockerコマンドを叩けるdvmを入れる。dvmはvagrantの薄いラッパー＆管理ツール。dvmはboot2dockerをゲストOSに使う。CoreOSより軽い。
Dockerはとにかくディスクを圧迫するので、常に軽くすることを意識する。
本体のVagrantfileは~/.dvm/にある。clangビルドしてるとメモリ足りないよーとかで、Dockerのメモリを増やしたいときなどは~/.dvm/dvm.confで設定できる
インストール：

$ brew install dvm

dvmの起動とenv設定：

$ dvm up
$ eval "$(dvm env)"
$ echo << 'EOF' >> ~/.bashrc
if [ -f dvm ]; then
  eval "$(dvm env)"
fi
EOF
source ~/.bashrc

6. GCEやAWS上のdockerを叩くときにsudoが聞かれてうざいとき。

$ sudo gpasswd -a <username> docker
$ sudo service docker restart
$ exit

シェルを初期化するために一旦ログアウトしてください。

Dockerfile編
さて、ここからが本編です!
個人的にはここが一番重要だと思ってます。ハマりどころがたくさんあるので、ここを参考に

7. Dockerfileのapt-get updateやyum updateの前にはミラーサーバーを書く

run echo "deb http://us.archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list

8. 一つ前のコンテナIDを取得するalias

$ cat << 'EOF' >> ~/.bashrc
alias dl='docker ps -l -q'
EOF

使い方（ログを見たり）：

$ docker logs`dl`

9. ディスクがいっぱいになってきたんだけど

/var/lib/dokcerを別のディスクに割り当てるといいかもしれません。

10. Dockerfileの各所で要らないものを削除する

Dockerはファイルサイズとの戦いです。少しでも削りましょう。

run apt-get update && apt-get upgrade -y # こうではなく
run apt-get update && apt-get upgrade -y && apt-get clean && rm -rf /var/cache/apt/archives/* /var/lib/apt/lists/* #こう書きましょう
run apt-get install -y openssh-server # こうではなく
run apt-get install -y openssh-server --no-install-recommends # --no-install-recommendsオプションを付ける

11. ローカルの１週間以上前のコンテナを削除

ローカルのコンテナはどんどん消しても問題ありません。
Dockerfileさえあればいつでも元に戻せます

$ docker ps -a | grep 'weeks ago' | awk '{print $1}' | xargs docker rm

12. ローカルの１週間以上前のコンテナを削除はよく使うのでaliasも設定しておこう

$ cat << 'EOF' >> ~/.bashrc
alias dkwrm="docker ps -a | grep "weeks ago" | awk '{print $1}' | xargs docker rm"
EOF

13. docker run時に WARNING: IPv4 forwarding is disabled. って出るんだけど

IPv4 forwardingの設定をしましょう

$ sysctl -w net.ipv4.ip_forward=1
$ echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf

14. apt-get updateで変なエラーが出るんだけど！(debian/ubuntu)

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LANGUAGE = (unset),
    LC_ALL = (unset),
    LC_CTYPE = "UTF-8",
    LANG = "en_US"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

対策：Dockerfileに以下の行を足しましょう。

run locale-gen en_US.UTF-8
run update-locale LANG=en_US.UTF-8
env LC_ALL C
env LC_ALL en_US.UTF-8

補足：これはMacのiTermがlocaleのenvを自動送信しているのが原因です。
Preferences > Profiles > Terminalの “Set locale environment variables on startup” のチェックを外せばうまくいくらしいですが、試してないです。
これのおかげで特に設定しなくてもツールやmanが日本語になっていたりします。

15. apt-getするとpromptのところで止まってしまう

Dockerfileに、

env DEBIAN_FRONTEND noninteractive

を設定しましょう。

まとめ

さて、以上の地雷を回避したDockerfileはこんなかんじになると思います
（後述するDockerfileをTDDするためにはopenssh-serverも必要かもしれません。

from ubuntu:12.04
maintainer KazuyukiMori <mainya@gmail.com>

# set locale
run locale-gen en_US.UTF-8
run update-locale LANG=en_US.UTF-8
env DEBIAN_FRONTEND noninteractive
env LC_ALL C
env LC_ALL en_US.UTF-8

run echo "deb http://us.archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list
run apt-get update 
run apt-get install -y redis-server --no-install-recommends
run apt-get upgrade -y && apt-get clean && rm -rf /var/cache/apt/archives/* /var/lib/apt/lists/* 

expose 6379
entrypoint ["/usr/bin/redis-server"]

15. Advanced Tips: DockerfileをCIで回す

serverspec
configspec ならDockerfileまではけていいですが出来たてなので、とりあえず、開発が活発そうなserverspecで。configspecはserverspecの冪等性を捨てただけのものです。

僕もまだちゃんとした環境を作れてないので、以下のブログを参考にしてください。
serverspecとdocker-apiでDockerfileをTDD
これの何が嬉しいかというと、Dockerは差分ビルドなので、ビルドがあっという間に終わり、書いてて楽しいということです。

Dockerfileの中身はただのshellscriptなので、スクラッチから環境構築をいつでもやり直せるという安心感があります。
普段あなたが叩いているビルドコマンドやデプロイコマンドをDockerfileに書くだけです。Chef/puppetが使いたい人は別に使っても良いのです。
AWSが嫌になったらGoogle Compute EngineでもDegial OcealでもRackspaceでも、どこでもほぼ確実にプロダクション環境が用意できる

なお、Dockerのproduction環境で動かすのは推奨されていません。気をつけてね☆

あれ？数えてみたら15個しかなかった。まあいいか。

参考にしたリンク

via: The Docker Guidebook
via: Dockerfile Best Practice
via: serverspecとdocker-apiでDockerfileをTDD
via: 以前開催したGCE + Dockerハンズオンの発表資料