AWS ECRの東京リージョンも出たことだしShippableでそれを最大限活用してみる
Shippable記事が割と反応あったのにみんなが使ってるよって報告がなくてつらいです。
ちなみに先日教えて頂いたのですがShippableのキャラクターはアイアイだそうです。
南の島のおさるさんのアイアイです。日本人なら誰でも知ってる、みんなのうたのアイアイです。
これはもう最高にかわいいというのは疑問の余地はありませんね*1
ECR Tokyo Region
この前ECR*2の東京リージョンが来てましたね。
いままでDocker hubを使っていたのですがECRの東京リージョンはやっぱりはやいです。
イメージのpush/pullが遅いと暇をもてあまし気味なのではやいのはいいですね。
今回はShippableを使いながらECRを活用するためにやったことを紹介します。
BYON
ShippableにはBYONという機能があります。Bring Your Own Nodeの略です。
これを使うことで自前インフラでCIをまわすことができるようになります。
インフラは通常Shippableが用意してくれてるのですがこれを自前インフラに変える機能ですね。
具体的にはセキュリティ的な要件で自社インフラ以外を使えない人達向けの機能のようです。
ですが、それ以外にもメリットがあります。それはキャッシュです。
Shippableのインフラを使っている場合にはときどきキャッシュが消えることがあります。
たぶん向こうで定期的に殺してるからでしょう。自前インフラならキャッシュが消える心配は必要ありません。
具体的な設定方法は上記ページに詳しいのでここでは詳細は省きます。
ざっくり説明すると2種類の方法があります。
1つはShippableからのSSHを許可してShippableのssh-agentに実行してもらう形式です。
もう1つはスクリプトをダウンロードしてそれを対象のマシンで実行する形式です。
どちらも簡単ですし、どちらを選んでもいいと思います。ちなみに僕はスクリプトダウンロードするほうを選びました。
共通する注意点としては以下の2点です。
- 動作要件にRAM1.8GBがあるのでt2.small以上が必要
- 動作要件にSSD空き容量30GB以上があるのでボリュームの追加が必要
BYONの初期設定が終わったらあとは普通に使うだけです。
BYONの良い点
ECRの転送量がおさえられる
ECRの料金設定は主に2つあり、ストレージ容量とアウト転送量によって計算されます。インの転送量は関係ありません。
アウト転送量は同一リージョン内での転送なら無料なのでECRのアウト転送量は抑えられます。
はやい
Shippableだとキャッシュがのらないときはやはり遅かったですが、こちらはそんな心配はいりません。
CIが爆速であるというのは嬉しいです。まあ遅くて困るかっていうとそんなにはこまんないんですが……。
デバッグがしやすい
手元でOKなのにCIで落ちることってありますよね。
CIまわりやってて一番ストレスになるのがこれだと思うのですが、自前インフラなのでSSHできます。
落ちたときのイメージも残ってます。超手軽にデバッグできます。最高！
BYONの悪い点
Dockerのバージョンが古い
Docker 1.9です。
ウチではCI用自前イメージ内でdocker-composeしてテスト走らせてるのですが、version 2のdocker-compose.ymlは弾かれました。
もしかしたら走らせてるイメージの問題かもしれませんが……。
自前インフラなんだし、自分であげてもなんとかなるんちゃうのっておもって1.12をいれたら動かなくなりました。
ちなみにぶっ壊してももう一回同じセットアップスクリプトを走らせたら直ります。こういうのは便利。
インフラコストが高め
無料に比べたらt2.small以上 + SSD30GBつきになるので高くなります。
まあはやさとデバッグの楽さをお金で買ってるんだと思えば許せるレベル、かもしれません。
もしかしたらセットアップスクリプト実行のときに、スクリプトを書き換えたらそのへんの要件も突破できるかもしれません。*3
というわけでECR東京リージョン使うんだったらBYONで自前EC2インスタンスでCIまわすと便利だよ。
しかもセットアップは超カンタンだよ、って話でした。
日本語のShippableネタはまだまだ少ないのでみなさんのウチではこう使ってるよ話をお待ちしております。
