‫さて､ スウォームでのDocker Registryはどうでしょうか｡
‫実はあまり変わらないんです｡
‫このように､ docker runコマンドを実行する必要がなく､ いつものようにdocker serviceコマンドや､ 前のセクションで説明したようなスタックファイルを実際に使用することができるのが良い点です｡
‫ローカルホストで行ったのと同じように動作します｡
‫なぜなら､ レジストリのためにスウォームに自分自身と話すように指示すれば良いからです｡
‫そのため､ 同じ127アドレスを使用し､ Docker Engineによってすでに許可されているため､
‫安全でないレジストリを有効にする必要はありません｡ Routing Meshは基本的に全てのノードがレジストリとローカルであるかのように会話できるようにします｡
‫これは永続的なデータ・コンテナであることを忘れないでほしいんだ｡
‫長期保存が必要なデータを保存しています｡
‫だから､ 現実の制作のようなシナリオで対応することになるのです｡ ボリュームドライバーとどう付き合うか､
‫基本的にはデータをどう保存するかというあたりで判断することになるでしょう｡
‫しかし､ ここではそれをしない｡
‫今回のSwarmの例では､ 実は少し変えて､ 前のセクションで使った3ノード・クラスターを使わないことにします｡
‫今回は実際にPlay With Dockerを使ってみます｡ play-with-dockerに行くだけなら｡ ロボットでないことを証明し､
‫ランダムに質問してくるかもしれないし､ そうでないかもしれない｡
‫それなら､ 私たちの出番です｡
‫最近､ Play With Dockerで､ テストフォームをさらに簡単に設定できる新機能が有効になり､
‫それがwrenchオブジェクトの下にあります｡
‫レンチなんでしょうね｡ このオプションは､ 基本的にスウォームをセットアップするためのテンプレートになっています｡
‫基本的には5ノードのスウォームでスタートします｡
‫レジストリを実行するだけで､ 以前とほとんど同じことができることを示すために､
‫本当に素早く実行します｡
‫わかりました｡ 現在､ 5つのマネージャノードがあり､ docker node lsを実行すると､ 5つのマネージャノードがあることがわかります｡
‫だから､ やったね｡ 群れをなしている｡ 実際にレジストリを実行してみましょう｡
‫今回は､ サービスの作成を使用して､
‫レジストリと呼びます｡
‫前回同様､ ポート5000で公開し､ イメージレジストリへ｡
‫これでよしとする｡
‫docker service ps registryを実行すると､ 実行中と表示されるのです｡ Play With Dockerでは､ Webアプリケーションを公開するたびに､
‫このような素敵な小さなボタンが表示されます｡
‫実際にポートが公開され､ ウェブアプリやウェブエンドポイントをテストするのに適したフレンドリーなURLが提供されます｡
‫でも､ レジストリの場合､ 根本は何もないんです｡
‫HTTP 200以外に返されるものはないんです｡
‫しかし､ どのレジストリでも､ 実際にカタログを見に行くと､ 単純なJSON配列が返ってきます｡
‫そのリポジトリが空であることに気づくでしょう｡
‫前回の講義でもローカルでできたのですが､ せっかくPlay With Dockerで簡単に解決できるのですから､
‫ここでちょっと遊んでみましょう｡
‫hello worldの先ほどと同じようにdocker pullをしたときに､ 同じことをやってみます｡ これからもう一度タグのリメンバーを行いますので､ タグ hello world と言って､ 名前を変更したり､
‫新しいリポジトリ127にタグを付け直したりします｡
‫0. 0. 1
‫5000､ docker pushしてみる｡
‫もう少し見やすくするために､ 拡大してみましょう｡
‫docker pushします｡
‫では､ 127をやってみましょう｡ 0. 0. 1 OKです｡
‫そして､ それを私たちのリポジトリにプッシュしたのです｡ 実際に確認する方法は､
‫この別のタブに移動して更新すると､ リポジトリに利用可能なリポジトリの名前が表示されていることに気づくでしょう｡
‫さらに追加していくと､ 実際に配列が拡張され､ すべての配列がそこに表示されるようになります｡
‫この時点では､ これまでと同じように､ その画像を実行すれば､ 期待通りに動作し､ スケールアップすることができたのです｡
‫その点だけを証明するために､
‫docker pull nginxを行うことができます｡
‫単純なnginxウェブサーバーを実行し､
‫docker tag nginxを実行し､
‫docker pushでレジストリにプッシュすることができます｡
‫それから､ ここに2つあるのがお分かりになると思います｡ そこには2つのリポジトリがあるんです｡ それから､ docker
‫service createをすると､ 普通にやるのと同じように､ nginx 80 80とやりますが､ 今回はこのようにイメージを指定することにします｡
‫Docker Hubのイメージを使ってサービスを開始するのではなく､
‫これを使いたいと伝えているのです｡
‫今度は､ いくつかのオプションを追加していきます｡
‫実際にレプリカ5を行い､ 各ノードで1つのnginxが起動するようにし､ 17で表示され始めた新しいオプションを行うつもりです｡
‫04確か､
‫detachはfalseに等しく､ これで実際にコマンドの実行をリアルタイムで確認することができます｡
‫つまり､ レジストリからノードにイメージをダウンロードし､
‫準備が整ったら実行に移すということです｡
‫ほら､ 終わったよ｡
‫引っ張ると､ 上から､ 新しいサービスなのでポート80が表示されているのがわかると思いますが､
‫ここに置いて､ 動いているのがわかると思います｡
‫これの何が面白いかというと､ スウォームの場合､ 1つのノードにしかない画像は使えないんですね｡
‫スウォームでは､ すべてのノードがアクセスできるレジストリにあるリポジトリから､ すべてのノードに画像を取り込むことができなければなりません｡
‫swarmの項では触れませんでしたが､
‫これは重要なポイントです｡ つまり､ ローカルに自分のイメージを構築することはできない､ 例えばこの場合manager1とすると､ manager2がmanager1のところに行ってイメージを取得することはできない､
‫ですね｡
‫これらはすべて､ どこかの中央リポジトリからプッシュ＆プルを行う必要があるのです｡
‫しかし､ ここではレジストリをサービスとして実行したため､ 127 zero zero oneへのアクセス方法をすべて知ることができ､
‫ルーティングメッシュは､ レジストリがノードのどこで実行されていても､ 実際に正しいコンテナへと誘導し､
‫必要なノードにnginxイメージを引き込みます｡
‫docker service ps nginx を実行すると､ 各ノードで 1 つずつ実行されており､
‫レジストリにあるイメージが使用されていることがわかります｡
‫さて､ SwarmがDocker Registryと非常によく似ていることを紹介するのはここまでです｡
‫最後に､ スウォームで使用する画像は､ どのレジストリからでもアクセスできるようにしておく必要がある､
‫という新しい情報をお伝えしました｡
‫すべてのノードからアクセス可能でなければならない｡ ノード同士で画像を共有することはできないので､
‫当然といえば当然なのですが｡ 実際には全員がレジストリから引き出す必要があるため､ 全員が到達できるようにしなければなりません｡
‫たまたま､ ルーティングメッシュを使えば､ それがずっと簡単に実行できるんです｡
‫最後にちょっとしたアドバイスとして､ もし自分でレジストリを実行する必要がないのであれば､ そうするのがクールかもしれませんが､
‫インターネット上のホストされたレジストリの1つを使用してください｡
‫冗長なんです｡
‫ストレージの管理には､ モニタリングや適切なものが必要です｡
‫特にオープンソースをやっている人は､ そのほとんどが無料です｡
‫プライベートな理由でやっていて､ プライベートな画像を保存する必要がある場合､ そのほとんどは非常にリーズナブルなコスト､ つまり画像を保存するのに非常に低いコストです｡
‫AWSやQuay､ Docker Hubなど､ さまざまな選択肢がありますが､ まずはそれらを試してみて､
‫インターネットに接続しなくても利用できるオフラインの要件がある場合､ あるいはセキュリティ上の制約があってホスト型のプラットフォームは使えない場合のみ､
‫自前のレジストリを使用することをお勧めします｡
‫なぜなら､
‫それは本当にユーティリティのひとつであり､ その問題を解決するために誰かに頼ることができれば､ それは素晴らしいことだからです｡
‫だから､ ぜひ遊んでみてほしいですね｡
‫この講義がない今､ 次の講義で新たなスタートを切るために､ 片付けを忘れないようにしましょう｡