DockerHub Automated Build を使ってみた

Google Test の過去のバージョンとの互換性テストのために、各バージョンの Google Test 環境を構築する必要が出てきました。
どこかしらの CI サービスで、毎回 git clone とか wget とかしてもよかったのですが、今回は DockerHub に各バージョンのコンテナを登録してそれを使うようにすることにしました。

DockerHub に Sign Up

まずはサインナップしましょう。
https://hub.docker.com/ にアクセスし、以下の手順で Sign Up しました。


トップページで好きなのアカウントIDとメールアドレス、パスワードを入力して、Sign Up します。



ログイン画面が出てきます。Sign Up は以上です。
登録したメールアドレスに確認メールが飛んでいるはずなので Confirm もしておきましょう。
　



ログインすると以下のようなダッシュボードが出てきます。

Github と連携する

つづいて、今回 Dockerfile の管理を GitHub で行っていますので DockerHub と GitHub を連携させます。
アカウントの Settings にある「Linked Accounts & Services」を開くと以下のような画面になるので、「Link GitHub」を選択します。


「Public and Private」か「Limited Access」の選択画面が開きます。
今回は、特に理由もないのでオススメの「Public and Private」を選びました。（Limited だと手動でなにかしないといけなさそうだったし）


「Select」ボタンを押すと連携されます。
完了すると以下のように GitHub のアカウントが表示されると思います。

自動ビルド設定

では、本丸の Automated Build をセットアップしていきます。

メニューバーの「Create」から「Create Automated Build」を選択します。


Github か Bitbucket か選択肢が出てくるので、目的の方を選択します。
（今回は GitHub）


リポジトリ一覧が出てくるので目的のリポジトリを選択します。


名前や Visibility を設定できますが、デフォルトのままで OK です。
簡易説明も任意で入力できます。（あとで変えられます）


「Create」ボタンを押して以下の画面になったら作成完了です。


では、次にビルドしていきましょう。

ビルドしてみる

Build Settings に入るとすでにトリガーが１つ設定されていますので、「Trigger」ボタンを押してビルドしてみましょう。
（もちろんリポジトリにはビルド可能な Dockerfile が push されている必要があります）


「Build Details」に移動すると、トリガーしたビルドの進捗が確認できます。


無事にビルドが成功すれば「Success」と表示されます。

使ってみて…

さて、ここからは使ってみた感想を書いていこうと思います。

パラメタライズドできない？

Docker イメージをつくるに際に latest の他に複数のバージョンを用意したいことがあると思います。また HogeHoge-alpine みたいなイメージをよく目にしますが、このようにベースイメージを変えたい場合もあると思います。
その場合、ビルドジョブ側でバージョンをパラメタライズドして、１つの Dockerfile から複数のバージョンを作れると便利だなーと思ったのですが…どうやらその機能はないもよう。

「Build Settings」でブランチや Dockerfile のパスを指定、タグ名も指定できるので、ブランチを増やすか、Dockerfile を増やせば対応できそうです。

バージョンブランチを作って各バージョンのイメージを作成する

今回は、Google Test の各バージョンの環境を作ることが目的でしたので、Google Test のバージョンごとにブランチを作成して、ブランチへの push をトリガーにビルドが走るように構築しました。
最終的な設定はこちら。



ここでのポイントは master 指定したトリガーと、指定なしのトリガーです。
master のトリガーは latest タグでビルドします。
指定なしのトリガーはブランチ名をタグにしてビルドします。

タグ名のところを空欄にすることで、ブランチ名がタグになる仕様です。

１つのブランチで複数のイメージを作成する

続いて、HogeHoge-alpine のように alpine イメージを作成する対応をしたいと思います。
ブランチを分けて対応することもできますが、今回ブランチは Google Test のバージョンで切って、alpine などのバリエーションはブランチ内の別 Dockerfile で対応することにしましたので、以下のような設定にしました。



Dockerhub では、ビルドに使用する Dockerfile のパスを指定することが可能です。
今回は、alpine 版の Dockerfile をリポジトリの alpine ディレクトリに置いて、そのパスを指定しています。

タグ名ですが、master の場合は明示的に latest-alpine としています。
バージョンブランチの方ですが、タグ名の設定ではブランチ名を {sourceref} で参照できるので {sourceref}-alpine のように後ろに -alpine がつくように設定しました。

Unexpected error...

さて、ビルド構成ができたので Google Test のイメージを作っていたのですが、たまに謎のエラーでビルドが失敗していました。
issues とか見てるとすごく不安定な時期・タイミングがあるみたいで、こちらではどうしようもない感じでした・・・
https://github.com/docker/hub-feedback/issues/1203

リビルドがめんどくさい

さて、上記理由でビルドがたまに失敗することがあり、対処方法がリトライだけでしたので、失敗したらリトライするか変更をコミットするかって感じでした。
で、リトライをするにも他の CI サービスのようにリトライボタンがビルドにはなく、空コミットを作って push してました。（ビルドトリガーを叩くでも可）

不安定な時期は何度も失敗するので、リトライボタンがほしいなーと思いました。
Webhook を受けて自動でビルドトリガー叩くってこともできるみたいですが・・・そこまでしてやりたくない・・・
https://github.com/axibase/atsd-use-cases/blob/master/how-to/docker/README.md#generate-webhook-when-docker-hub-build-fails

最後に

単純に１つのイメージをビルドするくらいなら Dockerhub で十分事足りるとは思いましたが、色々と痒いところに手が届かない感じでちょっと残念でした。（不安定なのはすごく困るし）
今は、Docker Cloud を使ったほうが良かったのかなーというお気持ち。機会があれば Docker Cloud も使ってみたいと思います。

では。