水底

ScalaとかC#とかネットワークとか

DockerHubとDockerCloudの使い分け

DockerHubがまともにアップデートされなくなって暫く経ちましたが、例えば「--build-arg が使えなくて困ってる…」なんて方もいるのではないでしょうか。そんな方向けの記事になります。

TL;DR;

DockerCloudでautomated buildしよう

現在のDockerHubの位置づけ

DockerHubと言えば皆さんご存知の通り、docker pull 等した時にデフォルトで利用されるDockerRegistryです。Imageを公開したければとりあえずここに上げるのがデファクトになっています (※privateもできますが)。

一方で、GitHubやBitbucketと連携して、「pushされたら自動的にImageをbuildする (automated build)」といったこともできます。よく利用されている機能ですが、数年前から機能追加がほとんど行われおらず、機能不足が否めません。

DockerHubはあくまでImage置き場で、build周りは後述のDockerCloudを利用するべきです。

(実際のところ、hooksでbuild-argを渡すこともできるのですが、例えば対象がcredentialであってもGitHubリポジトリに含まれてしまい使い物になりません)

DockerCloud

DockerCloudは元々、build・Registry・Containerの実行環境の3つを提供していましたが、Containerの実行環境としてのサービスは既に打ち切られてしまいました。また、Registryは内部的にDockerHubを利用しているため (=デフォルトのpush先がDockerHub)、実質build専用のサービスとなっています (実はbuild機能も内部的に共通部分があったりとややこしい…)。DockerHubと比べると遥かに多機能で、BuildContextや環境変数を利用したbuild-arg、簡単に複数タグ指定等などできます。

辿り着いた結論

GitHubのDockerfileを含むリポジトリでautomated buildを行う例で紹介します。

  1. DockerHubで、対象のGitHubリポジトリを指定してautomated buildなリポジトリを作成 (※automated buildの設定は行わない)
  2. When active, builds will happen automatically on pushes. のチェックを外す
  3. DockerCloudで、1. と同じ対象のGitHubリポジトリを選択してautomated buildの設定を行う (リポジトリはDockerHubで作成したものがそのまま見える)
  4. GitHubに変更をpushすると、DockerCloudのautomated buildが走り、DockerHubにpushされる

実はDockerHubを一切開かなくともDockerCloudのみでautomated buildできるのですが、そうしてしまうと、DockerHubでリポジトリのページを開いたときに「automated buildであるかどうかが分からない」・「対応するDockerfileが見れない」といった弊害があるため、敢えてDockerHubで作成するフェーズを挟んでいます。

おまけの戯言

  • automated buildでないリポジトリって、どんな工程で作られたImageか分からなくて使う気起きないですよね。
  • 「automated build」と名乗っている割に、実は手動でもpushできる。謎い。