‫この動画は､ DockerCon 2017での私の講演の様子です｡
‫私はアメリカで2回､ ヨーロッパで1回､ DockerConsに参加しましたが､ この内容の多くは現在でも通用するもので､
‫実際､ 今もう一度やってもほとんど変わらないでしょう｡
‫ハードウェアの決定から始まり､ OSの暗黒バージョン､ イメージ､ そしてスウォームクラスターの構築､
‫その設計方法､ 規模､ マネージャーとワーカーなど､ その間にあるすべての詳細について､ ベストプラクティスの詳細を説明しています｡
‫今日の最後のセッションは､ キャプテンでもあるブレット・フィッシャーさんをお招きしています｡
‫彼は最初のコホートキャプテンの一人で､ Dockerのプロダクションでの経験を何年も持っています｡
‫彼は制作に至るまでコンサルティングを行い､ このセッションでは､ 知るべきことはもちろん､ 決めるべきことも説明します｡
‫この決断が必要なのも､ そうなんですね｡
‫もし､ 皆さんの中にライトに興味がある方や､ 古いオタクの方がいらっしゃいましたら｡
‫私はあなたより一つ上の本当の本当のオトナだから､ 意地悪な意味ではない｡
‫このセッションのテーマをお楽しみください｡
‫だから､ 私からそれを取り上げてください｡
‫ありがとうございます｡
‫私は墓場勤務の栄誉を得たので､ 来てくれてありがとう､ もうじきハッピーアワーだ｡
‫では､ なぜ私たちはここにいるのでしょう｡
‫彼は非常に簡潔にライトアップしましたが､ 私たちがここにいるのは､ おそらくあなたがDockerとプロダクションを望んでいるからです｡
‫Dockerのプロダクションが良いアイデアだと説得しに来たわけではありません｡
‫もう決めているのでしょう｡
‫これは､ コンサルティングとDockerから学んだ教訓と､ 実運用に入る前に行うべき多くの決定に関する彼らのベストプラクティスについての話です｡
‫また､ 昔のゲームファン､ レトロゲームファンの方もいらっしゃると思いますので､ トリビアを交えて少し楽しませていただこうと思っていますし､
‫皆さんにも聞いてみたいと思っています｡
‫子供の頃に好きだった名作ゲームの音楽とスクリーンショットをあげていくので､ 見覚えのある方は叫んでみてください｡
‫だから､ これはちょっとね｡
‫観客参加型で､ はじめましょう｡
‫まだお分かりでないかもしれませんが､ 私はオタクで､ 小学5年生の時にティアSを買って以来､
‫ずっとそうです｡ A. T. と､ 開発者気取りですが､ ほとんどシスアドのようなことをしています｡
‫以前から､ そしてここにリストアップされている｡
‫これが私のレジュメです｡
‫これは､ 私が子供の頃に持っていた､ 1990年代前半までのビデオゲームプラットフォームのリストです｡
‫だから､ 楽しもうよ｡
‫ストリートファイターが一人｡
‫それは良かった｡
‫彼は速い｡
‫つまり､ これは私がHDビデオゲームとダッカーについて下手な類推をしているのです｡
‫90年代､ 私は海軍の学校に通っていたのですが､ 軍隊ではメインフレームとピースを同時に学んでいたんです｡
‫このゲームのすごいところは､ 実際に学校にいるときに､ 友達を集めて部屋の中に持ってきて､
‫一度に8人のゲームプレーヤーと大きなトーナメント戦で対戦することができたことで､
‫勝った方がその週の王者になると宣言し､ その後はピースインピースやメインフレームの勉強に戻って､
‫素晴らしい時間を過ごしました｡
‫そこで､ 実際にスーパーストリートファイターターボのプロジェクトについてアドバイスし､ もしかしたら決断を下す手助けをするために､
‫ここに来ました｡
‫そして､ その最初の問題は､ 同時進行のイノベーションを制限してしまうことです｡
‫つまりこれは､ スコープクリープのスコープクリープという私の洒落た言い方です｡
‫だから､ スコープクリープのことはみんな知っているし､ 私も知っている｡ T. プロジェクトに参加しています｡
‫みんな初回発売で全部欲しいんだよ｡
‫そしてこれは､ インフラも同じです｡
‫そのため､ プロジェクトをスタートさせる際に､ よく見られる問題があります｡
‫通常､ クライアントがDockerを使い始めてから､ オーケストレーションのことを耳にするようになった段階で､ 私が参加することになります｡
‫彼らは20年かけて15年間VMインフラを構築してきたため､ この派手なオーケストレーションにすべてのものを求め､
‫それとまったく同じものを最初のコンテナと本番のバージョンに求めているのです｡
‫そこで､ もしかしたら必要ないかもしれないものへの言い訳をいくつか挙げてみます｡
‫まさに本番用コンテナのデプロイ､ そのひとつがICDです｡
‫今日それがあったとしても､ おそらくコンテナで動作させるために多くのことをする必要はないでしょう｡
‫そんな大げさなものではありません｡
‫CIAのプラットフォームはすべて､ コンテナをサポートしているようなものです｡
‫それでいいんですね｡
‫しかし､ もし今日CICを持っていなくても､ 最初のコンテナプロジェクト､ あるいは2番目のコンテナプロジェクトにそれを持つ必要はないのです｡
‫ダイナミック・パフォーマンス・スケーリングも､ オーケストレーションを導入すれば､
‫魔法のようにコンテナ内のすべてのノードがスケールアップ/ダウンすると思われている大きな要因ですが､
‫これは組み込みではありません｡
‫なぜなら､ インフラを自動的に拡張しようとする前に､
‫多くのことを学び､ その学びを得る必要があるからです｡
‫そして､ 永続的なデータから始めるというのは､ 本当に大きなことです｡
‫データベースをswarmクラスタに入れる最初のものにしないことです｡
‫悪いことではないのですが......ちょっとしつこいくらいにデータを扱うのが大変なんです｡
‫そして､ おそらく最もアジャイルなインフラストラクチャでもないでしょう｡
‫毎月データベースを新しいバージョンにアップグレードするのではなく､
‫毎週､ あるいは毎日､ 新しいコードをデプロイしているでしょうから､
‫永続データではなくアプリケーションコードからより多くの利益を得られるはずです｡
‫アプリケーションのプロジェクトでは､ コードを一切変更しないことを目標の1つとしています｡ アプリケーションのコードを変更する場合､
‫おそらく最も多いのは､ IPアドレスやコードなど､ アプリにハードコードされている環境を想定した場合です｡
‫もちろん､ それが間違っていることは分かっていますが､ 古いアプリでは､ 本当に古いアプリや10年前のアプリのようなものです｡
‫特定のIPやホスト名､ あるいは特定の環境変数にまつわる仮定が多く見受けられますが､
‫通常はそれらを取り出して環境変数に取り込む必要があります｡
‫通常､ 変更しなければならないのは､ このコードだけです｡
‫ファクターです｡
‫12ファクターは理想的なソリューションで､ コンテナやオーケストレーションの実装に必要なものではありませんが､
‫私はこのソリューションが完成したとは思っていません｡
‫私はどちらかというと､ 地平線として見ています｡
‫分散コンピューティングのベストプラクティスを学び､
‫それを時間をかけて実装していくことが目標です｡
‫はい｡
‫これがNHSと八百長か｡
‫それは昔の話です｡
‫しかし､ そのゲーム「スーパーマリオブラザーズ」は､ 30年間､ プラットフォームで最も売れたゲームのタイトルを保持しました｡
‫そのタイトルは私の人生の中で大きな位置を占め､ 実際に2つのコントローラーで同時にゲームをプレイできる初めてのゲーム機となりました｡
‫そのため､ ゲームにおける競争力を身につけるために､ 多くのゲームでは1人ずつしかプレイできないことを学びました｡
‫また､ Co-opモードもあり､ Co-opがどういうものかを知るにはとてもいいものでした｡
‫そこで､ デフォルトのパワーアップについて､ また､ あなたのドクター・ファイルをより良いものにし､ 本番に備える方法についてお話しましょう｡
‫だから､ 私はいつも皆さんに､ まずドクターファイルに集中するように言っているんです｡
‫私はむしろあなたがそれらの医師のファイルが本当によく､ いくつかの空想のオーケストレーション機能または完全に自動化されたC
‫ICDを調整する必要がありますこれらの医師のファイルは､ あなたの新しい請求書のドキュメントです｡
‫そのため､ コードや動物塩スタックパペットなど､ 必要なものを移動させる必要があります｡
‫シェルスクリプトなど､
‫以前はサーバを構築するために使っていたものが､
‫今はDoctorファイルに含まれています｡
‫そのため､ まずはアプリを動作させ､ クラッシュしないようにすることから始めますが､ 初日からうまくいくとは限りません｡
‫このプロジェクトを開始し､ ドクター・ファイルを作成し､
‫公式画像をベースにした場合､ うまくいけば起動し､ 動作し続けるようになります｡
‫それはアンチパターンですね｡
‫そして､ 今でもそうしている人をたくさん見かけます｡
‫FTD airとICD outに入れて､
‫Dockerにログを処理させ､ オーケストレーションにログを処理させる必要があるのです｡
‫多分､ チームのドクターファイルを作っている人がいて､ これをチームの他の人に渡してテスト実行してもらう必要があるのでしょう｡
‫ドッカーファイルの各領域について､ ドキュメントを入れることをお勧めします｡
‫もちろん､ これらのラインはビルドタイムの前に引き出されているので､ ビルドが遅くなることはありませんし､
‫そこにあるすべてのドキュメントの制作に影響を与えることもありません｡
‫だから､ 多くの人はまずリーンに注目します｡
‫画像の大きさを気にされる方が多いのですが､ 画像の大きさは1番でも2番でもないとお伝えしたいです｡
‫画像はどんなに大きくてもいいから､ 使い慣れた公式画像を使いたいだろうから｡
‫今日のサービスがUbuntuまたはSである場合｡ O. Sなどを使っている場合は､ それらを最初のプロジェクトのデフォルト画像にします｡
‫最終的には､ ビルドインしたバイナリだけでファットメグになるような､ 無駄のないアルパインイメージに仕上げることもできますし､
‫それはそれで素晴らしいことですが､ 初日からそんなことは必要ないのです｡
‫最初のコンテナプロジェクトでは必要ないでしょう｡
‫なぜなら､ これらのホストでは､ 画像はシングルインスタントストレージであり､ 各画像はシングルバージンであると仮定して､
‫一度だけ保存されるからです｡
‫たとえ5つのコンテナを使っていても､ 500メガや300メガの画像があっても､
‫大した問題ではありません｡
‫ですから､ 私は画像のサイズなど細かいことは気にせず､ Dockerファイルの品質と､ 変更率を下げることにもっと汗をかくと思います｡
‫ですから､ もしあなたがビルドのドキュメントをすべてapt getに基づいて作成しているなら､ 最初のDockerファイルでAlpineの全く別のパッケージマネージャに移動する必要はありません｡
‫むしろ､ 今日持っていたビルドドキュメントと同じものを使えば､
‫ドッグやファイルを取得することなく､
‫ドクター・ファイルで動作します｡
‫それで､ 右のようなスケールを作るのです｡
‫そして､ そのアプリケーションを複数のコンテナで同時に実行する場合､ それがデータベースであれば､
‫おそらくレプリケーションなど､ データベースレイヤーに必要なものがあります｡
‫しかし､ Webアプリやワーカーアプリなどについては､ スケールアウトできることを確認します｡ 1つのコンテナで動作するからといって､
‫5つのコンテナで自動的にオーケストレーターでうまく動作するとは限りませんから｡
‫そうですね｡
‫並行してソニック・ザ・ヘッジホッグの他の問題を扱っているセッション状態があるかもしれません｡
‫OKです｡
‫では､ 16ビットゲーム機戦争を覚えている人はいますか？
‫8ビットに16ビットが加わって､ スーパーと天童とセガジェネシスの戦いになって､ どっちが勝つかで大騒ぎになったのを覚えていますか｡
‫今でこそ128ビットの戦士が活躍していますが､ 「ソニック・ザ・ヘッジホッグ」は子供のころの私にとって大きな存在で､
‫実際に私もそうでした｡ R. S. というのは､ 90年代のキューチャットを見ると､
‫みんな覚えているんです｡
‫ええ､ そうです｡
‫だから､ ハンドルネームを考える必要があったんだ｡ もし､ みんながLINEをするようになったら､ 本名を使っちゃいけないんだ､
‫ハンドルネームがないんだ､ ってなるよね｡
‫それで結局､ ソニック・ザ・ヘッジホッグのいろいろなバリエーションに行き着いたんです｡ 当時はソニックが一番好きなゲームだったし､
‫彼は本当にカッコよかったからです｡
‫彼は実際､ とてもかっこよくて､ 丸くなってスクリーンの周りを叫びながらループして､
‫スクリーンを一周する機能がありました｡
‫当時は1秒間に3フレームとか､ とんでもなく遅かったので､ プレイヤーとしては画面に何が映っているのかわからなくなってしまったんですね｡
‫本当にアンチパターンを踏襲しているだけで､ これを防ごうとしていたんですね｡
‫前方にあるトゲや危険物にぶつからないようにするためですね｡
‫だから､ あなたは物に当たらないようにすることだけが仕事だった......アンチパターンのようなものです｡
‫あなたはただ､ それだけを観察していたのですね｡
‫これは私のひどい例えですが､ ちょっと暗い暗いファイルをパターン化して見ます｡
‫そして､ これらをかなり素早く打ち込みます｡ 最初に見たものはかなり明白です｡
‫ボリュームについては､ もうみんな知っていることでしょう｡
‫デバッグログやエアダンプログなど､ FTDを出し忘れたり､
‫ユーザーからの静的ファイルのアップロードや､ アプリのロード間に保存したいキャッシュファイルなどがある場合､
‫誤って追加のダークボリュームを追加するのを忘れてしまう人がいるようです｡
‫そのため､ オフィシャルイメージを使用している場合は､
‫その中にあるすべての永続的なデータのボリュームを確認し､ 最新のものを使用している場合は､ そのボリュームを確認してください｡
‫最新版という言葉は二度と入力しないでください｡ テスト用のDockerファイルを作る場合でも､
‫バージョンを入力する習慣をつけてください｡
‫ですから､ 今使っているバージョンを覚えて､ それを最前線に入力すれば､
‫この例のように､ 一番上のPDP公式のものは､ バージョン番号に類似したものを使っていることがわかります｡
‫2つ目は､ ブーツからそこへ｡
‫16,0,4にあるため､ 技術的にはアセンブラとして扱われますが､ 日付ベースになっています｡
‫だから､ アプリのパケットは､ 実際に入れたときにわかるんです｡
‫だから､ イメージが湧くのです｡
‫また､ この2つの例は､ 自分のイメージを構築するときに､ 自分のイメージと似たようなことをする必要はなく､
‫日付をベースにしたり､ アイデアをベースにしたりすることができます｡
‫このDockerファイルを見たときに､ 何百行もあるDockerファイルをスクロールして､
‫どのバージョンのnodeを入れたのかを知る必要がないように､
‫一番上に環境変数を設定しています｡
‫パケットパッケージのジェイソンとか､ コンポーザーとか､ そういうのは当然あるわけです｡
‫これはアプリの中にあるものなので少し別ですが､ 今回は､ コードを実行するためにアプリの中にある､
‫Dockerファイルの中で見失われがちな､ 更新を忘れてしまいがちな部分についてです｡
‫2つ目は､ ピン留めしているところです｡ ピン留めという言葉は適切ではありませんが､
‫app getパッケージのいくつかについて､ 正しいアップデート・バージョンを指定しているのです｡
‫私がプロジェクトに参加した当初は､ ほとんどの人がこれをやらず､ 私はそれが難しいことではないと思っています｡
‫必要だと思うバージョンをインストールするか､ 最新のものをインストールして､
‫APP getで簡単にバージョンを調べ､ それをドクターファイルに入れるだけです｡
‫PSPは､ 通常､ PSPアプリのために多くのアプリを取得する依存関係があるため､
‫これらのバージョンを固定することが困難です｡
‫このDockerファイルは毎日コードをコミットするたびにビルドされるので､ 依存関係のあるもののイメージバージョンがランダムになってしまう可能性があります｡
‫そして､ 完全な検死ICDを取得し始めると､ Mongoデータベースドライバーがアップデートされて突然あなたのMongoのバージョンをサポートしなくなったが､
‫あなたのテストではそのバージョンのMongoをテストしないので知らなかった､ というようにランダムな小さなクセがつき始めます｡
‫とにかく､ 私は自分の身に起こったことを苦々しく思っているわけではなく､ ただ､ あなたのバージョンにピンを刺せば､ 私から学ぶことができると言っているのです｡
‫デフォルトの設定は､ Peteのようなアプリで､ まあ本当にすべてPSPの私の続編を求めるMongo｡
‫Javaはかなりいいものです｡
‫多くの人は､ Dockerファイルの中にインフラが構築されているということを理解していませんし､ おそらく以前は､
‫Javaのメモリ制限の設定や適切なmy sequel設定ファイルの設定を他のチームに依存していたかもしれませんが､
‫それらは今やDockerファイルの責任であり､ そうあるべきなのです｡
‫というわけで､ これはかなりいい例です｡
‫エントリーポイントスクリプトについては今日は触れませんが､ エントリーポイントスクリプトはCFDを行う前にコマンドを実行させるものです｡
‫それは､ 設定ファイルをその場でセットアップするスクリプトかもしれませんし､ 実際に私の続編やPostgresの公式画像を見てきていただければわかると思います｡
‫それらの中には､ データベースが起動する前にいろいろなことを行うエントリーポイントのスクリプトがあります｡
‫デフォルトのデータベースを作成し､ デフォルトの管理者パスワードを追加し､ データベース用のカスタムユーザーを設定し､
‫すべてを行った後､ データベースを再起動してコマンドを実行します｡
‫これは､ 環境設定をDockerビルドにハードコーディングしないことで､ これらの問題の多くを解決できる方法です｡
‫実際の実行時設定には､ これらを入れないようにしたいものです｡
‫これは､ あるプロジェクトで見たことなのですが､ 同じ画像を何度も何度も､ 異なる環境のために異なる技術的な画像を作り上げていたのです｡
‫そこで､ 別のジェイソンを使うようにドッカーファイルを変更し､ 別のイメージを構築するのです｡
‫この業界に長くいれば､ 環境は無限であることをご存じでしょう｡
‫特に今は仮想化が進んでいるので､ 環境内にあるものは明日にはプラスワンになります｡
‫そのため､ Dockerファイルの理想的な環境を設定するために､ 常にそれらの環境設定をすべて引き出そうとすることになるのです｡
‫私は､ 後でインポートする他のファイルに記述するよりも､ ドッカーファイルで記述する方が､ 視認性が高まるので好きです｡
‫ですから､ 私はいつもドッカーファイルにできるだけ多くの環境設定をデフォルトとして保存し､
‫それを実行時に設定して､ ドッカーファイルを見る人がデフォルトが何であるかわかるようにします｡
‫他のレポやシステムから､ そのアプリケーションの設定ファイルを探し回る必要はないのですが､
‫より高度なドラゴンスレイヤーになると､ ちょっと大変です｡
‫はい......これはかなりイケてますね｡
‫実際､ それは最初のレーザーディスクゲームで､ レーザーディスクの時は83歳のノバ男でしたが､ 基本的には大都市......レコードサイズのとても大きな都市でした｡
‫そして､ これは手描きのアートです｡
‫実はこれ､ 映画を見ながらゲームをしていたんですね｡
‫実際､ 私の場合､ 常に死んでいたので､ ほとんどそのように見えました｡
‫難しいゲームで､ 当時はチートもなく､ ネットで調べることもできなかったので､
‫正しい動きを把握することができませんでした｡
‫ドラゴンスレイヤーか｡
‫世間が1ゲーム25セントの時代に､ 実は50セントのゲームだったのだ｡
‫ドルゲームや2ドルチェーンなど､ とんでもないものが出てきて､
‫まるでアニメを見ているように､ みんなで立ち止まって見ていたんですが､
‫実は10分間で最も売れたゲームの一つだったんです｡
‫このゲームでは30秒ごとに死ぬし､ 50セントで1ライフだから､ 基本的に10分で給料がなくなるんだ｡
‫だから､ かなり大変でした｡
‫ところで､ もし35年後であれば､ このゲームは今でも素晴らしいものになるでしょう｡
‫実際にスマホで遊べるようになったし､ 見た目もいい｡
‫では､ インフラストラクチャー・ドラゴンをやってみましょう｡
‫では､ インフラストラクチャについて､ 運用チームが下すべき3つの大きな決断についてお話ししましょう｡
‫そして､ 1つ目はVM､ あるいは各種VMやベアメタルなどのハードウェアです｡
‫そして､ 両方と言う｡
‫得意なことをやれということです｡
‫得意なことにこだわる｡
‫そして､ その1時間後に､ ベアメタルでスリープ・パフォーマンス・テストを実施するのです｡
‫ベアメタルを使ってダイナミックにデプロイするよりも､ VMSを使ったほうが､ メタルのパワーを本当に必要としている一部の人たちでない限り､
‫おそらくいい結果になると思います｡
‫もしVMを使用しているのであれば､ 後でベアメタルでスケールアップしてパフォーマンステストを行うことをお勧めします｡
‫オープンソースのツールを使えば､ 本当に簡単なことができます｡ 複雑なツールや購入するツールである必要はありません｡
‫というのも､ ご存知のように､ 今年の初めに112のコンテナがありました｡
‫HPとDockerと一緒にホワイトペーパーを作りましたし､ 他にもホワイトペーパーがあります｡
‫そのリンク先には､ 私たちが行った基本的なパフォーマンステストと､ コンテナ内のワークロードと犠牲者のワークロードの比較､
‫そしてベアメタル上のコンテナ内のワークロードの比較について説明した2つの資料があります｡
‫しかも､ コンプレックスが正しいからこうすればいいという一発芸のようなツイートはできない｡
‫VM内のコンテナ数を増やすと､ カーネルスケジューリングやカーネル設定､
‫ネットワーク設定などに気を配る必要が出てきます｡
‫そのため､ 成長するにつれ､ OSやディストリビューションについて少しずつ学んでいかなければなりません｡
‫だから､ 今はLinuxの話をしているんです｡
‫Windowsのコンテナを利用するのであれば､ 選択肢は1つであることは明らかです｡
‫それは､ いい意味で安易な選択ですね｡
‫しかし､ もしあなたがLinuxを使っているのなら､ ディストリビューションはカーネルほど重要ではありません｡
‫私が意味するイノベーションとフィックスは､ Dockerはもう4年ちょっと前のものです｡
‫コンテナは､ 実際にカーネルの将来や､ Linuxカーネルやオペレーティングシステムの作成方法､ デプロイ方法､
‫その他諸々に影響を及ぼしています｡
‫だから､ 5年前のカーネルバージョン3を動かしているようでは困るのです｡ 0 10はDockerの最小限のものであり､ 最小限のもので動作するからといって､
‫それがあなたが使うべきものであるとは限りません｡
‫そうですね｡
‫4をお勧めします｡ 0 Xカーネルは､ 最新バージョンをインストールすると3.0 Xカーネルになるかもしれないディストリビューションがまだいくつか存在します｡
‫0 なんかカーネル｡
‫だから､ 以前よりもっと気にする必要がある｡
‫つまり､ Apacheはあらゆるディストリビューションで同じように動作しますが､ Dockerはそうではありません｡
‫コンテナではありません｡
‫そうですね｡
‫だから､ もし意見がなければ､ Ubuntuを試してみてくださいと言いたいです｡
‫ここで贔屓しているわけではないのですが､ 特定のディストリビューションに特に思い入れがある人でなければ､ Ubuntuには4が付属しているということです｡
‫0
‫何かカーネルを箱から出して､ その素敵な長期的なサポートライフサイクルを持ちます｡
‫それはよくインターネットDockerのテストに重くそれがDockerストアで公式Dockerサポートディストリビューションの一つであることを文書化または多分試してみて､
‫空くとLinuxキットです｡
‫今､ この1つは､ あなたが独自のディストリビューションを構築し､ それが住んでいない場合､ 感染したLinuxで展開するこのタイプに慣れていない場合､
‫あなたのプロジェクトを遅らせるので注意事項です｡
‫そのため､ 最速の選択ではありませんが､ もしかしたらクールなものになるかもしれませんよ｡
‫そのため､ 製品の長さに影響します｡
‫Linuxキットの仕組みを学ぶため､ 少し遅れることになります｡
‫今週はLinuxキットのセッションがあり､ 明日も多分サミットでもっとあると思います｡
‫最後に......お店から配布されたものを確認することです｡
‫Dockerのデフォルトのディストリビューションは､ アプリのように若いそれらすべてを取得します｡
‫それはあなたにとって正しいバージョンではないでしょう｡
‫113になるのは一部なので､ 保証するつもりです｡
‫8ヶ月のものが10ヶ月になったんだから､ そりゃあね｡
‫ですから､ あなたはDockerの最新バージョンを入手したいのですが､ 最新の安定版は先月の17 0 9で､ これはストアを通じて入手することになるので､
‫Dr. を作ったのですが､ 実はドクターの意図するところと違っていないのです｡
‫これは､ 他のパッケージマネージャの古いディストリビューションでは実際にそうなっています｡
‫最後にご紹介するのは､ あなたの容器です｡
‫そして､ コンテナのイメージについてお話しましたが､ ベースとなるイメージについてお話しましたが､
‫多くのチームが中間イメージを持つことになります｡
‫つまり､ ストアやDocker Hubからベースを入手するわけです｡
‫JSFがない場合のチームの基準として､ 中級者がいるのでしょう｡
‫そのバージョンの自分なりのスタンダードを選んで､ それをいくつか持って､
‫その上に別のイメージを構築するのですが､ その方法は必要ありません｡
‫しかし､ 数人以上のチームであれば､ ある程度の基準を設けて臨みたいところでしょう｡
‫なんだか､ 昔のゴールデンイメージのVMのような発想ですね｡
‫それは､ 中級者でもできることかもしれませんが､ 画像サイズではなく､ それを基準に作るといいと思います｡
‫先ほども言いましたが､ 特定のディストリビューションに慣れているのであれば､ VMが何であるかに基づいているのは間違いないでしょう｡
‫イメージの中でその配分を始めればいいのです｡
‫そうすれば､ Dockerファイルに変換するときに､ ビルドのドキュメントをすべて変更する必要がなくなります｡
‫また､ アルパインでは､ 5メガというサイズもあり､
‫非常に使いやすいと思います｡
‫有名なセリフは､ ちゃんとした仕事をするのが好きなんです｡
‫実はこれが私のBlizzard入門作で､ 20年来のBlizzardへの愛着はこのゲームから始まったんです｡
‫実は､ 幸運にも一番最初のバージョンのベータ版に参加することができたんです｡
‫サウンドカードを買ってPに入れなければならないほど昔の話です｡ C. を再生できるようにする｡
‫実際にそれを楽しむように､ そのビデオだろうビデオゲームをプレイするために設計されていなかった元の作品は､ 私は推測したり､
‫少なくとも少しくだらない作品スピーカー以外の何かを持っていない｡
‫だから､ それ以来､ ブレイザーのゲームは全部買ったと思う｡
‫そうそう､ それが効いたんです｡
‫ここで､ スウォームアーキテクチャの話をしましょう｡ これは､ まさにスウォームレイヤー､ スウォームアーキテクチャの話です｡
‫これでOSがわかったわけです｡
‫私たちは今､ 自分たちのイメージを知ることができました｡
‫では､ その群れをどのように構築していくのか､ 基本的な設計をいくつか紹介しましょう｡
‫もし､ あなたが他のスウォームに関する情報を見ていないのなら､ スウォームとその仕組みについて読んでいないのでしょう｡
‫群れの中に明らかに深入りするつもりはないんです｡
‫月曜日には､ 素晴らしいワークショップが開催されました｡
‫実はこの前にローラ・フランクによるセッションがあり､ swarmやraftの内部､ コンセンサスの仕組みについて話しています｡
‫そこで､ ベビースワームとベビースワームから始まる基本的なデザインを紹介します｡
‫ちなみに､ スウォームを構築できるノードは1つだけで､ それはあなたのノートパソコンでもかまいません｡
‫ワンライナーでいいんです｡
‫そうですね｡
‫このようなデモは､ おそらく誰もが見たことがあり､ 試したことがあるはずです｡
‫実際にあることなので､ ちょっとお話ししたいと思います｡
‫大丈夫です｡
‫今日はインフラがありますね｡
‫皆さんの環境でも､ もしダウンしたらどこかに電話がかかってくるような､
‫可用性の低いシステムが1つはあるのではないでしょうか｡
‫SGIのシステムかもしれません｡
‫チケットシステムの通知システムとか､ ビジネスにとって重要でないものでも､
‫どこかにあるのかもしれません｡
‫だからswarmで実行する｡
‫で実行します｡
‫ダッカーに群がるようにやればいいんです｡
‫新しい機能がすぐに使えるし､ 秘密も守れるし､
‫コンフィグもできます｡
‫健康診断で利用できるそうです｡
‫ドクターランでは得られないものだから､ いきなりやってもいいんだ｡
‫次に考えられるのは､ 三文判です｡
‫2つの音符の形ではなく､ 偶数の形はやめてください｡
‫swarmには2種類のマシンがあり､ 仕事をこなすワーカーと､
‫NCDサーバーのようなラフトコンセンサスデータベースを持つマネージャーです｡
‫この場合､ あなたは趣味のプロジェクトやテストプロジェクトといった､ 非常に小さなプロジェクトです｡
‫すべてのマシンが作業を行いますが､ 同時にすべてのマシンが管理者でもあるため､
‫セキュリティ・リスク・プロファイルが少し高くなります｡
‫これは私が「ビッグスウォーム」と呼んでいるもので､ 高可用性のための最低限のインフラが欲しいだけで､
‫セキュリティや管理者の境界線についてはまだそれほど気にしておらず､ ただ高可用性が欲しいだけの小規模なスクラップ同然のスタートアップ企業に対してお勧めしているものです｡
‫というのも､ これならメンテナンスのために1つのノードをダウンさせても､ この中では2つの権利を失うことができるので､
‫フォールトレランスを確保することができるのでおすすめです｡
‫私たちは､ 常にマネージャー・ノードの過半数を占めなければならないのです｡
‫ということは､ 5人ということになりますね｡
‫そこから先は､ 自分たちで作っていくようなものです｡
‫ところで､ もしあなたがADA（米国医師会）会員なら､ この箱にTやCと書いてあっても無視し､
‫サイズは関係ありません｡
‫そこで今回は､ 実際に分けてみました｡
‫現在では､ 管理職を別のVLANやセキュリティ・グループといった安全な場所に配置し､ 管理職同士が会話してスワームをコントロールできるようにしていますし､
‫必要な数だけワーカーノードを作ることができます｡
‫OKです｡
‫そして､ ワーカーノードはさまざまなものになり､ 1つのスウォームで､ 異なるハードウェアプロファイル､ 異なるネットワークセグメント､
‫異なるアベイラビリティゾーンを持つことができるのです｡
‫そのワーカーノードを使って､ コンストレイントを使うなど､ いろいろなことができるんです｡
‫Docker用に作成したサービスに対して､ 「SSDを搭載しているのはここだ」とか､
‫「PCIコンプライアンス用に特定のサーバで実行するセキュリティ・プロファイル・スキャナだ」とか､ そういうことを伝えるためのメタデータです｡
‫そうですね｡
‫VPN INSを作成し､ VPN上のノードにラベルを割り当てて､
‫制約を加えて作業を行います｡
‫それは......本当に変わらないんです｡
‫労働者のノードが増え､ より多様なプロフィールを持つ場所が増えただけです｡
‫相変わらずの癖の強さを発揮していますね｡
‫もしかしたら､ インスタンスサイズが大きくなり､ マネージャーがそのRAFデータベースをメモリに保存しているため､ マネージャーをスケールアップしなければならないかもしれません｡
‫ですから､ 仕事が増えれば増えるほど､ RAFのデータベースも大きくなり､ RAMのMCPプロファイルも増えていくかもしれませんが､
‫交換はとても簡単です｡
‫1枚持ってきて､ 2～3行で持ち帰ることができます｡
‫医師がファイルする｡
‫石鹸箱の上でちょっとだけ警告しておくと､ くれぐれも牛をペットにしないようにね｡
‫アジャイルインフラに移行している多くの人々は､ アジャイルという言葉はいつも使い古されているので使いたくないのですが､
‫Dockerを使ったインフラはアジャイルになる可能性を持っているのです｡
‫もし､ ペットを作らないのであれば､ ホストにリポジトリをダウンロードしたり､ ホスト上で特別なことをし始めたりしないようにすることです｡
‫サーバを構築してDockerをインストールし､ それをswarmに追加してコンテナをデプロイするだけであれば､ メンテナンスが可能です｡
‫もしそれをそのままにしておいて､ Docker APIを通じてリモートですべてを行うか､ あるいは､ SSD時代には派手なシェルを使って何かを行うかもしれませんが､
‫実際にはハードディスクには何も保存しないのであれば､ そのノードは特別ではなく､ その必要もないでしょう｡
‫しかし､ 多くの人がマネージャーノードのひとつを自分のボックスにして､ そこでいろいろなことをして､
‫そのツールを使ってホストに何かをインストールするというのは､ 悪い習慣だと思います｡
‫何十年も前からある習慣なんです｡
‫トラブルシューティングやテストはすべてコンテナやスウォームで行うことができますし､
‫ホスト上に置く必要もありません｡
‫これはよくある質問で､ 実は以前にも質問やダンスセッションがありました｡
‫これらは､ 複数の群れを作る悪い理由です｡ 1つの群れで多くのことができ､ 難しい制限はありません｡
‫私たちは数千のノードをテストしましたし､ Dockerは数万か1万か､
‫あるいはその上位の数をテストしたと思います｡
‫このような理由がある場合､ 私は作戦担当者なので､ 複数のスウォームを作成する必要があります｡
‫So I love the idea of giving the ops team the chance to fail before production so give that give the opportunity for the
‫ops team to have a real swarm that other people care about like maybe the CIA platform or the testing
‫infrastructure give the ops person or the team a chance to have that so that they can learn they can make mistakes
‫on swarm and accidently delete the database off the swarm or whatever you know that people
‫do before they get all the way to production because if this is your first product and
‫this is your first swarm you're gonna learn lots you're gonna make mistakes
‫so it's great when you can make them not in production right management boundaries the docker API out of the box is an
‫all or nothing thing and you've probably if you've used Docker a while even before
‫swarm you know that it doesn't have our back built in it doesn't do that role based
‫access control out of the box you can do that with Docker e there's other third party tools there's
‫actually a plugin model that you can create of
‫Windows Server 2016は本当に新しいもので､
‫異なるOSのハイブリッドスウォームを持つことができるスウォームです｡
‫今年は､ Server 2016がこれを可能にした年であり､ 技術革新が速いので､ 数カ月ごとに､
‫SwarmやDocker全般の能力を拡張する新しい機能セットやウィンドウが提供されます｡
‫ですから､ もしあなたが純粋なWindows Server 2016のスウォームを作りたいのであれば､ コンテナのイノベーションが4年続いただけに､
‫そのマイナス面がある可能性があると言いたいです｡
‫モニタリングやロギングに関するオープンソースのプロジェクトはたくさんありますが､ その多くはLinuxのみです｡
‫ですから､ もしあなたがWindowsを使っているのであれば､ 少なくともLinuxとswarmの導入を検討することをお勧めします｡
‫Windowsの右に追い付く勢いです｡
‫また､ Windowsのライセンスに常に敏感で､ スウォームマネージャーがスウォームマネージャーとしての役割しか果たしていないのであれば､
‫Linuxにするのもいいかもしれませんね｡
‫そして､ WindowsのワークロードにはWindowsを使用し､ Windowsのライセンスは､ そこに座って意思決定をする管理者になるためだけに使用するのではないのです｡
‫だから
‫でも､ 明らかにできるんですよね......これがまた難しいんです｡
‫音楽の正しい使い方を少しでも説明する｡
‫Explain」は1993年のDOSゲームで､ 「Wolfenstein 3D」のようにマウスが必要な最初のゲームの1つだったでしょう｡
‫実際に宇宙でフライトシミュレーターを体験することができたのです｡
‫持っていたのです｡
‫スターウォーズのクラフトはどれもハズレが多いので､ いずれは飛ばせるようになるでしょう｡
‫このゲームは､ 少なくとも1年間は私にとって中毒のようなもので､ 実際に海軍のウォルマートのようなものであるNavy
‫any Xで初めてストアクレジットを手に入れ､ 素晴らしいサウンドトラックを再生するためにBoseスピーカーを買い､ フライトスティック用のコントローラのスティックを買ったほどです｡
‫基本的に余裕のないお金を使いすぎて､ ストアクレジットを手に入れたので､ やったー消費者金融の借金だ！と思ったらそのゲームのせいだったんですね｡
‫そこで､ スウォームの一部をアウトソーシングすることについてお話します｡
‫すべてを自社で行う必要はないのかもしれません｡
‫全部を革新する必要はないかもしれないので､ 「そうだね」と言うことにしています｡
‫ここに実装されていない症候群にご注意ください｡
‫基本的に､ ある部品に対応した製品が出回っています｡
‫つまり､ あらゆるものに対応した製品があるのです｡
‫全部アウトソーシングすればいいんだよ｡
‫そうですね｡
‫クラウドがあるんです｡
‫コマーシャルカンパニーがあります｡
‫でも､ もし自分で形にするのであれば､ 自分でやる｡
‫博士 を見ると､ 外注しやすい､ 交換しやすい､ いい部品があるのかもしれませんね｡
‫アウトソースというと､ SASや何かの商材を使うようなイメージですが､ 画像登録は本当に素晴らしいコメントです｡
‫その市場は､ ちゃんと定義されているんですよ｡
‫ログの一元化やモニタリングの一元化を実現する､ 優れたプレーヤーが何年も前から存在しているのです｡
‫それらはすべて､ 私にとっては当たり前の方法なのです｡
‫オープンソースのツールをすべて使う必要はありません｡ オープンソースは素晴らしいものですが､
‫通常は無料と利便性を交換することになりますから｡
‫だから､ 本当の意味での自由はないのです｡
‫そのため､ 穀物生産のためのコンテナプロジェクトからタイムラインを切り離す必要がある場合､ これらはプロジェクトを加速させるでしょう｡
‫このあたりを見てください｡ ちなみにCMC Fの素晴らしいURLもありますよ｡ ファンデーションです｡
‫エコシステムのビジュアル図みたいなものがあって､ ロギングプレーヤーやコンテナについてよく知らない人は､
‫そこにあるグラフィックでそれぞれのロゴを見れば､ どんなことを考慮する必要があるかがわかります｡
‫だから本当に早い｡
‫技術スタックの話をするのですが､ そのために呼びたくないのです｡
‫でも､ これは下から積み上げていくものでしょう｡
‫今日､ そして今､ 6カ月後には､ 私たちは会社を設立しているかもしれません｡
‫オプションでキューバ産の80年代を用意する予定です｡
‫だから､ このスライドは今日の話だからキューバンのアイデアが用意されているわけではないんです｡
‫そう､ これが今できることなのです｡
‫たとえば､ 一番下にfor Kitとterraform wrongのボタンでインフラをデプロイして､ ランタイムを若くするのは､ ここが暗くなっているからかもしれませんね｡
‫もちろんswarmを使うならオーケストレーションはDocker swarmで､ ネットワーキングはDocker
‫swarmのオーバーレイで､ ストレージはRex Rayというオープンソースプロジェクトを使って､ ホスト間の共有ストレージをオーケストレーションしているのかもしれません｡
‫Dell EMC Jenkinsのプロジェクトは､ かなりクールですね｡
‫入っているのを保存しているだけということです｡
‫このスタックのアイデアは､ オープンソースがすべて純粋なオープンソースで､ 自分のシステムかクラウドシステムで､
‫SASを使わずにデプロイするものです｡
‫Dockerディストリビューション＋Portis PortisはDockerのフリーレジストリの上にベッタリなので､
‫Dr.をやるだけなら登録は不要です｡ Paul registryはDockersの公式レジストリです｡
‫ハブや他のものを使いたくない場合は､ 自分専用のレジストリが必要です｡ これはレイヤー7プロキシのためのものです｡
‫E大丈夫多分あなたの愛のために集中的なロギング私はあなたがおそらくそれを聞いたことがあるほとんどだ｡
‫これもスウォームの集中監視と連動したもので､ PrometheusとGriffonがありますが､ Prometheusは実際にGriffonの監視をコントロールします｡
‫上に乗っているベタベタは､ いいグラフを出すためのものですか？
‫そして､ 最後にこのパートナーは､ たぶん､ 群れの上にベタベタと乗っているのでしょう｡
‫最後にもう一つ､ Functions as a Serviceに興味があるなら､ open FASを紹介しましょう｡
‫今週はAlexがopen fire shirtsについて話していますが､ これはformの上で動くので､ その上で独自のFunctions
‫as a Serviceを行うことができます｡
‫では､ SASの製品をいくつか上に配置した場合､ どのようになるかを簡単にお見せします｡
‫太字の項目が変更される項目です｡
‫Docker for AWOL usとDocker for Azureについてはお話しませんでしたが､ これらのクラウドでどのようにスワームを運用するのがベストかというDockerの意見であり､
‫テンプレートを提供しています｡
‫Google Cloudは現在ベータ版で､
‫Tuckerのウェブサイトからサインアップできます｡
‫最後にここでDr. エンタープライズ版｡
‫これは､ Docker for AzureやAWP sの上でDocker eを行うと､ Docker for AzureネイティブUになるので､ その分変化します｡
‫S. またはDockerから無料で提供されています｡
‫Docker eのランタイムを公式サポート版のEに変更すれば､
‫レイヤー7のプロキシやレジストリ､ gooyがあなたのために面倒を見てくれます｡
‫Docker eは､ 他にもさまざまなことを提供してくれます｡
‫基調講演やコンテンツ・トラストのデモで､ ロールベース・アクセス・コントロールのイメージ・スキャンをご覧いただきました｡
‫ニンニクに人生訓はない｡
‫食べ物を撮影しないでください｡
‫これは1985年のことだ｡
‫最大4人プレイが可能なブームとなったハック＆スラッシュのアーケードゲームです｡
‫そうですね｡
‫ちなみに､ この「レディ・プレイヤー・ワン」のことではありません｡
‫その映画は来年見る必要がありますが､ その前にウィル・ウィートンの本を読むかオーディオブックを聴かなければなりません｡
‫80年代を通しての旅も最高です｡
‫もしあなたが80年代ファンなら
‫私もそう思います｡
‫このゲームは1人用でも2人用でも楽しめます｡
‫周りの友達がこのゲームで一緒に協力できなかったからと言って､ あなたが遊べない､ 楽しめないということにはならないんですね｡
‫オーケストレーターも同じなんですね｡
‫多分､ 私はそのようなことは分からないと思いますが､ ホリデーシーズンが来るので､ コンテナとプロダクションを用意する必要があり､
‫クリスマスまでにコンテナを上司に約束しました｡
‫では､ それ以前にコンテナオーケストレーションができない場合はどうするかというと､ もしかしたら完全に自動化されたインフラを持っているかもしれません｡
‫ESDとAmazonを使用して､ VMを自動スケーリングし､ 犠牲者にアプリを置くことができるかもしれません｡
‫つまり､ VMの境界が好きなら､ VMごとに1対1のコンテナを作ればいいということです｡
‫この業界では､ そういう話はあまりしないんです｡ カッコ悪いと思われがちですが､ ちゃんと効果があるんですよ｡
‫こうすれば､ インフラをあまり変えなくても､ たくさんの利点があります｡
‫Dockerファイルの使い方を学べるということです｡
‫本番でDockerを管理する方法を学ぶということで､ これはその1つのVM上の1つのコンテナということです｡
‫もちろん､ このようなコンテナを1つのVMにまとめても､ 出入り口からスケールアウトすることはありません｡
‫もし､ 今日コンテナをやっていないなら､ もうやっているはずです｡
‫だから､ これは悪化していない｡
‫これが､ 正しい知識を身につけることになるのです｡
‫ただ､ オーケストレーションが全面に出ているわけではありません｡
‫だから､ これは実際に今起こっていることなのです｡
‫これは今に始まったことではありません｡
‫WindowsはハイパーVでこれを実現しています｡ ハイパーVのコンテナは､ 基本的にVMの中に1つのコンテナを入れています｡
‫Linuxは､ until until clearコンテナ・イニシアチブでこれを実現しています｡
‫これは非常に最小限のLinux OSXを作るというクールなプロジェクトです｡
‫これもLinuxのキットに付属しています｡
‫Linuxは今日もやっていますが､ これはWindows上のLinuxコンテナで､
‫アルコールはOSをほとんど使わずにWindows上でLinuxを走らせる方法です｡
‫それは､ 1つのVMに1つのコンテナがあるだけです｡
‫だから､ 今､ このようなことが起こっているのです｡
‫これは正当なアーキテクチャの決定だと､ プロジェクトで許可を与えているのです｡
‫その1つのVMにその1つのコンテナをデプロイすればよいのです｡
‫最後の1つは......本当に難しいですね｡
‫Nineteen Eighty Threeは音も出ないんですよ｡
‫ドラゴンブレスのオールライトダンジョン｡
‫これは実は1982年のゲームで､ Tier80で動作し､ 最初の3Dゲームの1つでした｡
‫そうでした｡
‫つまり､ あれを見ろということだ｡
‫それは､ 「ウルフェンシュタイン3D」の10年前の私です｡
‫彼らは3Dゲームを発明したわけではありません｡
‫実はこれより10年前に､ 「Maze war 3D」というよく似たゲームがあったんです｡
‫というわけで､ とにかくこれが私のオタク入門でした｡
‫当時は保存する方法がなかったから､ テープカセットで保存することもなかったんだ｡
‫とにかく､ プロジェクトに必要なオプションは切り捨てること､ 最初の数プロジェクトはDockerファイルに集中すること､
‫もしswarmを使うならcomposeファイルにも集中することです｡
‫Aに気をつけよう｡ I. そして､ 使い慣れたOSやイメージから､
‫プロジェクトの成長に合わせてスウォームを育てていくのです｡
‫群れを交換する必要はなく､ ただ育て続けることができます｡ 最後に､ 配管を外注する方法を見つけるか､
‫あるいは少なくしないかです｡
‫というのも､ これはアジャイル・インフラストラクチャなので､ あなたの最初の選択がベストな選択であるとは限らないからです｡
‫それでいいんです｡
‫それをよしとし､ 途中で変更することを厭わず､ こんなアプリがあるんだと感想を述べ､ 来てくれてありがとう｡