‫このセクションでは､ コンテナイメージのレジストリについて説明します｡
‫いろいろあるので､ 実は､
‫基本的にプランにイメージレジストリが必要だというところから始めます｡
‫コンテナ・エコシステムのオプションというわけではないのです｡ Dockerやその他のツールの設計では､
‫サーバーや開発者のワークステーションから離れた場所に､ 実際にイメージを保存する場所が必要なのです｡
‫技術的には､ ZIPファイルにして､ エクスポートとインポートをすればいいのですが､ それは本当に大変な状況です｡
‫だから､ インターネットでも個人でもいいから､ 本当に籍を入れる計画を立てたいものです｡
‫ここでは､ Docker Hubの詳細や自動ビルドのオプションについて､
‫さまざまなレクチャーを実際に行っていく予定です｡
‫今回はDocker Storeを中心にレクチャーを行い､ それが実はHubとどう違うのか？
‫Docker Cloudのオプションは､ Hubとは異なりますが､ Dockerツールセットのアドオンで､
‫サーバーやクラウドへのデプロイをより簡単にするためのものです｡
‫また､ Docker Cloudの新機能であるSwarmsについても､ 具体的なレクチャーをさせていただきます｡
‫そして､ 独自のレジストリを構築し､ ローカルマシンまたはDocker Swarm上にデプロイしてプライベートレジストリとして使用する方法を学びます｡
‫実はオープンソースなんです｡ そして､ Docker HubやオープンソースのDockerレジストリを使用したくない場合に備えて､
‫サードパーティのレジストリのオプションについても触れておきます｡
‫この講義では､ Docker Hubの高度なトピックをいくつか取り上げます｡
‫今では､ コンテナ用のイメージレジストリとして世界で最も普及していますが､ それだけではありません｡
‫これまで述べてきたことに加えて､
‫どんなことができるのか見てみましょう｡ まとめると､ Hubはレジストリでありながら､ イメージ構築も兼ねているということです｡
‫これは通常､ 例えばオープンソースのレジストリにはないもので､
‫そのため､ その場でイメージを構築できるような､ ちょっとした余分なものが入っているのです｡
‫ここでは､ その機能のいくつかに飛び込んでいきます｡
‫さらに､ GitHubやBitBucketのアカウントをHubと連携させ､ コミットに基づいて画像を構築するための自動構築機能をチェックすることについても説明します｡
‫そして､ イメージビルドをチェーンで繋ぐ周りの機能を紹介します｡
‫Docker Hubについては､ このコースの前半で初めてイメージについて学習したときに､
‫すでに少し取り上げました｡ しかし､ 他のレジストリのオプションに入る前に､
‫まだ議論していない他の機能を調べ､ Docker Storeと比較し､ Docker
‫Cloudが私たちのためにできることを話したいと思います｡
‫明らかに､ Docker Hubはレジストリです｡
‫このコースでずっと話してきたことです｡
‫Dockerのデフォルトレジストリであり､ すべてのイメージの取得方法です｡ しかし､ 圧倒的にそれだけではありません｡
‫今までのこと以外に何ができるのか､ お話ししましょう｡
‫ここにリポジトリがあるのは明らかです｡ 実はここに1つくらいはプライベートがあることがわかると思います｡
‫私立は､
‫1つは無料で､ 残りは有料です｡
‫通常のように課金アカウントを設定し､ その代金を支払うのです｡ リポジトリを作成する際､ また､ 公開・非公開にかかわらず､
‫それぞれの画像で､ 人に権限を与えることを選択できます｡
‫私が所有するリポジトリでは､ このような表示になります｡
‫これはたまたま公開されているものです｡
‫設定」を開くと､ 非公開と公開を切り替えられることがわかります｡
‫削除することができます｡ Webhookを作成することができ､ イメージがビルドされてDocker Hubにプッシュされるときに､
‫Webhookは本当に便利です｡
‫JenkinsやCodeship､ Travis CIなど､ 他のサービスにWebhookを送信して､
‫自動ビルドを継続させることができます｡
‫Webhookは､ GitやGitHubからDocker､ そしてサーバーにコードを転送するプロセスを自動化するために用意されています｡
‫コラボレーターは､
‫他の人があなたの画像に対して行うことのできる権限を設定するためのエリアです｡
‫そして､ 「Organization（組織）」もあります｡ つまり､ 自分のリポジトリに自分の権限を持ち､ さらに自分のリポジトリに他の人の権限を与えることができるのです｡
‫でも､
‫組織を作りたいならそれも可能です｡
‫完全無料です｡
‫例えば､ この組織の下には､ その組織のすべてのレポが表示されています｡ そして､ それぞれの権限を持っているので､
‫実際に中に入ってすべての設定を変更することができます｡
‫チームメンバーをコントロールできることがおわかりいただけると思います｡
‫通常のプライベート画像と同じように課金をコントロールできる｡
‫これは､ GitHubを使ったことがある人､ あるいはGitHubで何かにお金を払ったことがある人には､ とてもよくわかると思います｡
‫オープンソースのものはすべて無料で､ プライベートにしたいものはグループ内プランにお金を払わなければならない､
‫というのとよく似ていますね｡ そして､ Organizationの仕組みはGitHubと同じです｡
‫それ以外には特にないですね｡
‫ただ､ 使い始めるにあたって知っておくべきポイントをいくつか紹介したいと思います｡
‫1つは､ GitHubやBitBucketを使ってコードを保存している場合､ このボタンをクリックしてリポジトリを作成しないことです｡
‫また､ 最初に作成する前にDockerプッシュをしないでください｡ 本当にやりたいことは､ ここまで行って作成し､
‫自動ビルドを作成することです｡ 自動ビルドでは､ Docker HubがこのCIパスを作成し､
‫コードのコミットに基づいて自動的にイメージをビルドすることができます｡
‫これは､ 逆ウェブフックのようなものです｡
‫先ほど紹介したWebhooksは､ Docker Hubがイメージの処理が完了したことを他の何かに通知するためのものです｡
‫しかし､ この処理によって､ Docker Hubは何かあったときに通知されるようになります｡
‫私はいつも自分のリポジトリを自動構築するように設定しています｡
‫今回の場合､ 例えば､ 自分がアクセスできるリポジトリとGitHubを選んだだけです｡
‫そして､ 簡単な説明をつけると､ リポジトリを作成することができるのです｡
‫しかし､ この場合､ GitHubから来たものであることがわかるのです｡
‫特定の要件やブランチに基づくコミットがある場合はいつでも､ 実際に私のイメージをその場で構築してくれるのです｡
‫そうすると､ 成功したかどうかというメールが届くんです｡
‫そのため､ 多くの画像に自動ビルドであることが表示されています｡
‫この画像は､ ソースコードがどこにあろうと､ 常に最新である可能性が高いことを示すので､
‫これは品質のひとつの目安になります｡ あなたはここで､ 私たちがこのコースで以前に使用したJekyllサーバーのように､
‫私はこれらの自動化されたオプションのいくつかをここに持っていることがわかりますが､ 私は自動化のために設定されていない以前のリポジトリではありませんでした｡
‫そこで､ ここではビルドの詳細とビルドの設定について説明します｡ 作るたびに成功しているのは､ 歴史を見ればわかることです｡
‫そして､ ビルドの設定で､ ビルドするブランチを選択することができるんだ｡ もしあなたがDocker
‫Hubでイメージをビルドしていて､ 他のイメージから引っ張ってくるfromステートメントを使っているなら､
‫ここにリポジトリリンクを設定して､ ソフトウェアが変更されたときにあなたのイメージを再構築できるようにしておくことを強くお勧めします｡
‫なぜなら､ 時間とともにイメージは依存関係を持つようになり､ セキュリティ要件や新しいバグフィックスに基づくアップデートが必要になる可能性があるからです｡
‫そして､
‫私のイメージの中でRubyとJekyllを実行しているので､ Dockerファイルのfromステートメントが実際にJekyllであり､
‫私はそれらをここに置くと､ これらのイメージが再構築されるたびに､ 私のイメージも再構築されます｡
‫ビルドトリガーも作りたい場合は... ビルドトリガーは､ イメージを自動的にビルドするためのもうひとつのインバウンドの方法です｡
‫そこで､ それらのユニークな投稿URLを作成することができます｡