‫この講義の要件は､ 画像とは何かを理解していること､ コンテナを少し扱ったことがあることです｡
‫この講義では､ Docker Hubの周辺をざっと見て回り､ その基本的な機能をいくつか紹介します｡
‫次に､
‫オフィシャルイメージと､ それと同じくらい良いイメージの違い､ そして良いイメージと悪いイメージの見分け方について説明します｡
‫次に､ 画像をダウンロードする方法と､ 使用するタグの違い､ アルパイン画像と他の画像オプションの違いについて少し説明します｡
‫hubにサインインしているはずです｡ ドッカーです｡ comを使用しています｡ サインインすると､ デフォルトのホームページはダッシュボードとなり､
‫公開・非公開を問わず､ すべてのリポジトリが表示されます｡
‫まだないだろうが､ ここにあるのがわかるだろう｡
‫すべて公開されています｡
‫プライベートが1つある｡ とりあえず一番上に行って､ nginxを検索してみましょう｡ 戻ってくるのはDocker Hubの検索結果で､
‫たくさんあることがわかると思います｡ 何ページでもスクロールできそうです｡
‫課題のひとつは､ Nginxのイメージが15,000個もあることです｡
‫多いですね｡
‫だから､ 私は結構､ 1つか2つしか使っていないんです｡
‫一番上にある公式のものは､
‫1000万回以上引っ張られています｡
‫何が正しい画像なのかを見極めるには､ いくつかの特徴があるんです｡
‫私のように､ 自分の仕事に関連するワークフロー用の画像を使い始めると､ 特定のものに慣れてしまうんです｡
‫特定のものを好きになる
‫通常､ 私たちはいつもオフィシャルから始めます｡
‫オフィシャルの下に実際に「オフィシャル」の文字があるのは､ このオフィシャルだけになりそうです｡
‫また､ 唯一､ 名前にフォワードスラッシュが付かないものになります｡
‫あなたや私がDocker Hubでイメージを作成するときは､ アカウント名を前面に出して作成しなければなりません｡
‫つまり､ 他のものを見てみると､ これらはアカウント名とスラッシュの画像リポジトリ名です｡
‫実はオーガニゼーションスラッシュのnginxとかかもしれませんね｡
‫でも､ レポの名前だけが出てくるものだけが公式とされているんです｡ 公式イメージとは､ Docker, Inc.が作成したものです｡
‫また､
‫Dockerfilesがベストプラクティスのルールに従って適切に配置されていることを確認するために､
‫Dockerfilesを管理するチームを持っています｡ 彼らは通常､ そのソフトウェアを実際に作っている公式チームと協力して､
‫そのソフトウェアがやるべきことをすべてやっているかどうかを確認します｡
‫というわけで､ こちらをクリックします｡
‫公式リポジトリについて､ いくつか見ていきましょう｡
‫先ほども言いましたが､ 最初は公式を使うことが多く､ そのうち少し変えたい､ 追加したいと思うことが出てきて､
‫自分で画像を作っていくことになります｡
‫オフィシャル画像は､ そのきっかけとなるものです｡
‫公式画像の良さのひとつは､ そのドキュメントにあります｡
‫どのように動作させるか､ どのようなオプションがあるか､
‫どのような環境変数があるか､ デフォルトのポートはどこか､ などなど､ いつも本当に素晴らしいドキュメントを提供してくれます｡
‫それでは､ 上部に戻って､ これらのバージョンに注目してください｡ バージョンは､ 公式リポジトリでよく見られる機能です｡
‫すべての画像にバージョンがある必要はありませんが､ 公式のものにはあります｡
‫ほとんどのオープンソースソフトウェアは､ 少なくとも数種類の公式バージョンが存在し､ 公式にメンテナンスとサポートが行われているからです｡
‫それがここにあるのです｡ 本線1があります｡ Nginxは11､ そしてNginxの安定版とされるブランチが1です｡
‫10. この小さな名前には､
‫stable jessie Dockerfileと書かれていることがわかります｡
‫わかりました｡
‫では､ これを分解してみましょう｡
‫1. 11. 9､ 本線､ 1､ 1｡ 11と最新です｡
‫これらはすべてタグです｡
‫画像の話を始めると､ 画像には必ずしも名前がついていない｡ 画像にはタグが付いています｡ 1つの画像に複数のタグを付けることができます｡
‫この点については､ 後日､ 自分で画像を作成し､ タグ付けを行う際に､
‫もう少し詳しく説明する予定です｡
‫docker image ls を実行すると､ 私のマシンでこれまでに作業した3つのイメージが表示されます｡
‫最新と書かれたタグが見えますね｡ 今最新は､ 特別なタグです｡
‫必ずしも常にリポジトリの最新のコミットであることを保証するものではありません｡
‫これは通常､ この製品の最新バージョンを入手したことを意味します｡ 公式リポジトリでは､ どのバージョンが欲しいのか今すぐにはわからない､
‫ただ最新のものが欲しいという場合に､ docker pull nginx と言えばいいように､
‫非常によく定義され､ 一貫しています｡ 最新のものをダウンロードすることになる｡
‫Docker
‫Hubから取得したイメージと一致することを確認するためにSHAをチェックし､ 「Hey I've already got
‫this image, it's up to date」と表示されました｡ " ドッカーイメージバージョン1をダウンロードしたい場合はどうすればよいのでしょうか？ 11. 9?
‫その画像をダウンロードするために何が必要かを確認しようとしたところ､ まったく同じバージョンなので何もする必要がないことがわかりました｡
‫このセリフは､ ここまでが意味するところです｡
‫この「メイン､ 最新」バージョンは､ このタグのどれかで参照することができるんだ｡
‫理由は､ もし私が1.の最新バージョンにとどまりたいだけなら｡ 0､ Nginxの場合はどうであれ､
‫1を指定すればいいんです｡ 画像をダウンロードする際に､ より具体的に､
‫1.の最新版が欲しいと思った場合｡ 11なら､ 1って入力すればいいんだけどね｡ 11のように､ .NETを省くだけです｡
‫9 して､ それをダウンロードすることになる｡
‫しかし､ 私の場合､ 実は1の中で最も具体的なものを指定したのです｡ 11. 9はポイントリリースを示すもので､
‫これは私が欲しいバージョンを正確に入手できるようにするためでした｡
‫ソフトウェアの場合､ ベストプラクティスは､ 実稼働に入るときや､ 他の人に使用する予定のソフトウェアを実際にテストするときに､
‫常に正確なバージョンを指定することです｡
‫本当にソフトウェアの自動更新を希望することは稀です｡
‫通常は､ 他のDevOpsツールでそのプロセスを制御したいと思うでしょう｡
‫しかし､ ローカルで開発したりテストしたりする場合､ オフィシャルイメージを使えば､ 名前を入力するだけで最新のものが得られると思い込んでしまうのは､
‫とても簡単なことなのです｡
‫だから､ ここに他のものがあることに気づくでしょう｡
‫1があります｡ 11. 9-alpineと､ これらはすべて最初のものとよく似た名前ですが､
‫すべてalpineという言葉が入っているのです｡
‫ベースイメージやディストリビューションについては後で説明しますが､ 一応､ Alpineは実はとても小さなLinuxのディストリビューションなんです｡
‫実際には5MB以下のサイズだと思います｡ このバージョンは実際にはAlpineのベースイメージから来ることを意味し､ 非常に小さく軽い状態を保ちます｡
‫一方､ デフォルトのものや最新のイメージは実際にはDebianディストリビューションであるjessieから来るものなのです｡
‫サイズは少し大きめで､
‫おそらく100MBを少し超えるくらいです｡
‫実際に､ ここに行って見ることができます｡
‫つまり､ nginxの182MBはここですね｡
‫アルパインのその正確なバージョンをダウンロードしたい場合､ 1． 11. 9-aplineでdocker image
‫lsを行うと､ 実はアルパイン版は54MBしかなく､ 最新版は182MBもあることがわかります｡
‫また､ イメージIDはDocker Hubにある各イメージの暗号SHAに基づいているので､
‫ダウンロードした3つのバージョンはすべて同じイメージIDを持っていることに気づくでしょう｡
‫だから､ これは実際には128MBの画像を3種類コピーしているわけではないんです｡
‫実はちょっとだけ騙されているんです｡
‫これは､ 全く同じ画像IDの3つのタグで､ 合計182MBを刻んでいるだけです｡
‫そして､ これは同じ画像IDに異なるタグを関連付けた別の2行です｡
‫しかし､ タグやバージョンについては､ 今はもう十分です｡
‫Docker Hubでもう少し確認してみましょう｡
‫検索バーでnginxまで戻ってもう一度検索してみると､
‫他にもたくさんのオプションがあり､ これらは誰でも作れることが改めてわかります｡
‫Nginxのカスタムバージョンを作ることができますし､ オープンソースソフトウェアで配布も無料なので､
‫ここに戻して公開することも可能です｡
‫これは､ オープンソースソフトウェアを保存できるGitHubのモデルに非常に似ていて､ 他の人のソフトウェアをフォークして､
‫またそれを提供することができます｡
‫こちらも同様です｡
‫他の人の画像を使ったり､ ダウンロードしたり､ 自分のものにしたり､ 再アップロードしたりすることができるのです｡
‫公式リポジトリを使用しないことを検討する場合､ 私が通常探すのは星の数と投票の数です｡
‫なぜなら､ 私にとっては､ 人気のあるリポジトリは信頼を確立する傾向があるからです｡
‫必ず事前にダウンロードし､ 点検することをお勧めします｡ Dockerfileを見てください｡ うまくいけば､
‫オープンソースのリポジトリがあり､ 彼らがどのようにそのイメージを作ったか､ 正確に見ることができます｡
‫500万回再生され､ 945個の星がついたものを見ると､ 明らかにこのパッケージには何か面白いものがあり､
‫多くの人が公式画像ではなく､ このパッケージを選んでいることがよくわかります｡
‫ここに来れば､ 彼らのリポジトリを見ることができます｡
‫右側にあるGitHubのリポジトリには､ この画像を構築しているオープンソースソフトウェアがリンクされており､
‫閲覧したり､ 画像以外の実際のソースコードをダウンロードしたりすることができます｡
‫しかし､ 彼は明らかにこのNginxのイメージで､ 公式のデフォルトより良いものを作っています｡
‫あと2つほど｡ 上のバーに「Explore」と表示されます｡ エクスプローラでは､ すべての公式画像をまとめて見ることができますし､
‫たくさんの画像を見ることができます｡
‫実際､
‫このセクションのリソースには､ 実際の公式イメージのリストへのリンクがあり､ 「ライブラリ」の下には､ すべての公式イメージとそのDockerfileが収められています｡
‫たくさんあるのがわかると思います｡ 今回の講義では､ Docker Hubについて､ それがコンテナのaptパッケージマネージャに似ていること､
‫そして公式イメージの見分け方とその使い方を簡単に説明しました｡
‫そして､ 良いパブリックイメージとそうでないものをどのように判断すればよいかを考える手助けをしました｡
‫それから､ ベースイメージに関するいくつかのヒントと､ Alpine のものが Debian のものよりも一般的に小さいということについて｡
‫ですから､ この続きでこのスキルを使っていきます｡