docker-machineとの死闘


本記事はDocker Advent Calendar 2015の2日目の記事です。

最初に

今年、Docker Advent Calendarの人気ないですね…… みんな、使ってないのかな?そんなことないと思いますが、まあ、ノリで記事書く時期が終わって、みんな普通に使う感じになってるのなら良いですね。

今年は、コンテナ部分だけでなく、その下のマシン群をあれこれするツールを使うフェーズだったように思います。私の場合は、1つのマシンに1つのコンテナしか載せないとゆーポリシーでプロダクトをデザインしていて、複雑な管理は必要としていませんので、3兄弟の中では、docker-machine しか使わないとして、ワークフローをあれこれしてきました。

3兄弟で1番素直そうな子に仕事を頼んだら、この子が結構天然だったので、今日はそんなお話をしようと思います。

リリースノートに書いてる新機能が動かない

自分のTweetを検索してみたところ、docker-machine に初めて言及しているのが、このTweet。EC2のインスタンスを立てるのに、docker-machineを使い始めたのが、この頃。Tweetの翌28日付(実際には現地時間なので日本だと2日後ぐらい)で、v0.3のrc1が出て、これのリリースに書いてあったのが、

Drivers
・AmazonEC2
Support for Spot instances

の文字。

「これでお布施が減る!」

ビルドをクリーンに行いたいのでdocker-machineでEC2起動してビルドしてたり、負荷試験のためにクラスタ構成のターゲットをクラスタ構成のLocustでイジメたりしてたので、Spot instances対応は福音にな、るはずでした。

「うーん、動かない……」

githubのissue眺めたり、irc眺めたりで、見つけたのが、自分と同じ症状の報告。31日にやり取りが行われた後、その日の夜にはmasterの方に修正をコミットしたとゆーので、早速、野良ビルド。

やっぱ最新版の野良ビルドに限るなー、とゆーわけで、毎夜、野良ビルド回して、Jenkinsさんには毎日フレッシュなdocker-machineを使ってもらうようにしました。

ただ、この時、私は気付くべきだったのです。リリースノートに載ってる新機能が動かないって、ないよねってことを。新機能なんか1番テストするよねと。ircに、開発者が、昔のEC2は良かった、今のは超複雑だぜ、とか書いてるのに気付くべきだったのです。

グローバルのIPアドレスはいらないんだが

開発環境は外に晒す必要がないので、VPCでプライベートなネットワークを作って、その中に立てたマシンからはNATで外に出れて、作業する時はVPNサーバを踏んで入る、とゆー環境を作って使っています。この中にdocker-machineで、ビルドやらテストやらのマシンを立てるので、パブリックなアドレスは不要です。逆に邪魔です。なので、「–amazonec2-private-address-only」オプションを指定して、パブリックなアドレスを付けないようにしていました。が、ある日

とゆーことに気付いてしまいます。しまいには、

コードをちゃんと読んでない(goをサクサク読めるほどの腕前はないです)ので、断定的なことは言えませんが、「–amazonec2-private-address-only」オプションに関する記述は現行のコード内にもありますし、削除されたわけではなさそうですし、何より、公式のドキュメントに今も掲載されています。 また、v0.5のリリースには

Drivers
・AmazonEC2
–amazonec2-use-private-address option to use private networking

とゆー記述があり、コード内でも確認でき、ドキュメントにはない(公式サイトはもとより、リポジトリ内のドキュメントにもありません)、といった状況です。「private-address-only」、「use-private-address」、もう意味が分かんない。因みに、エラーがでない引数順で「–amazonec2-private-address-only」を指定し、合わせて「–amazonec2-use-private-address」を指定しても、パブリックなアドレスが付きます。

楽園は失われた……

 

CI の結果を覗いてみよう

 

ビルド方法が変わったため、野良ビルドが通らなくなっていたのですが、ビルドに関するドキュメント「Contributing to machine」を見つけて一安心。ってゆーか、「CONTRIBUTING.md」にビルド方法書いてあるって、そーゆーもんなのかな?で、そこに、あったのは、

TravisCI

CI、回ってるのか?確かに、リポジトリに「.travis.yml」とか入ってるし。どれどれ、見てみるか。

ok github.com/docker/machine/drivers/amazonec2 0.774s coverage: 25.4% of statements

クラウドのドライバのテストが1秒もかからないでパスって、基盤を叩くテストは入ってないってことですよね。まあ、入ってたら、上からズラズラ書いてきたようなこと、起きなかっただろうけど。

番外:一方、その頃、ECSは

AWSメインなんで、ECSも見ておこうと思って、ダッシュボード上からチュートリアルやったわけですが、既存のVPCを使おうとしたら上手くいかなかったり、環境の破棄が上手くいかなくてAWS CLIが必要だったり。破棄できなかった時はちょっと焦って、ググって、去年、同じ罠にハマった人の記事を見つけて、AWS CLIをインスコして、対応しました。何で、去年、明らかだった落とし穴、埋められてないのかな、みたいな。

まとめ

  • docker-machineのコードを誰か直して
  • 俺よりもっと上手くやれる人、募集中