‫だから､
‫早く行くんです｡
‫わかりました｡
‫それでは､ 時間を過ぎましたので､ 番組を終了します｡
‫皆さんのご意見をお聞かせください｡
‫わかりました｡
‫最初に登場するのはジェイコブ｡
‫ここには､ たくさんのドキュメントがあります｡ ところで､ 私はドキュメントDockerfilesが大好きです｡
‫好きなだけ入れても全然いいんですよ｡
‫これは実際にはYAMLファイルなので､ 今はComposeについて話しているのです｡ DockerfilesやComposeファイルでのドキュメント｡
‫どっちでもいい｡
‫常に良いものを
‫わかりました｡
‫だから､ 彼はバージョン3を使っているんだ｡ 0 7 つまり､ Swarm用か､ Compose on Kubernetesの機能セットを使ったKubernetesのような本番環境用だと思われます｡
‫そこにあるElasticの公式画像を使っているそうです｡
‫健康診断の結果を見てみましょう｡
‫ファンタスティック｡
‫健康保険があるじゃないですか｡ それは素晴らしいことです｡ コンフィグがあるじゃないですか｡
‫それは素晴らしいことです｡
‫特定のネットワークに設定し､ ポートにホストモードを設定することで､
‫オーバーレイネットワークやルーティングメッシュを経由せずに､ NICに直接アクセスできるようにしています｡
‫それはいいことだ｡
‫では､ 見てみましょう｡
‫ここに配備するんだ｡
‫ああ､ エンドポイントモードのDNSラウンドロビンをやっているんですね｡
‫クドいですね｡
‫これは､ 多くの人が気づいていないことです｡
‫Swarmで何かを動かしていて､ オーバーレイサービスの前にある仮想IPを無効にしたいときは､
‫ノードが1つしかないデータベースのためにそうしたいですよね｡
‫つまり､ あるサービスに1つのインスタンスがあり､ そのインスタンスのコンテナのタスクは､ 通常､ その前に仮想IPを配置したくはないでしょう｡
‫これもNATの翻訳です｡
‫潜在的な問題が増えるからです｡
‫ここでエンドポイントモードをDNSラウンドロビンに設定すると､ 事実上VIPがオフになり､ そのコンテナに直接アクセスできるようになります｡
‫クドいですね｡
‫あれはみんな釣れないから､ あまり見ないですね｡ レプリカも使っているんですね｡
‫ギガで4Gのリソース制限......すごいな｡
‫可能であれば､ リソースの制限や予約をしておくと､ クラスタ内でうまく機能するようになります｡
‫そうですね｡
‫Docker Swarm上で動作しているようです｡ 甘い｡
‫コーディネートマスター
‫わかりました｡
‫同じものをもっと
‫いいものですね｡ いいものですね｡
‫ボリュームをバインドマウントしています｡ バインドマウントじゃないんですね｡ ネームドボリュームを使っているんですね｡
‫ここでは配置の制約があるため､ 特定の名前にハードコーディングされたノードにこれを配置しています｡
‫これはそのノードだけで走らせたいんでしょう｡
‫もちろん､ ここでの弱点は､ そのノードがダウンした場合､ 他の場所に配置できなくなることです｡
‫その点を考慮していただければと思います｡
‫わかりました｡
‫Master2､ そういうことですか｡
‫マスター1､ マスター2が別々のサービスとしてハードコーディングされているように見えますが､ マスター3も同様です｡ 多くの人は､ 複数ノードのデータベース・クラスターを持つ場合､
‫それぞれを独立したサービスとして置く方が簡単だということで､ このような方法をとっているのです｡
‫ということをしたんですね｡ 3つのレプリカで1つのサービスを作れればいいんですけどね｡
‫オートパイロットパターンを使ったいくつかの例でそれを確認することができます｡ autopilotパターンIOを調べたり､ お使いのデータベース技術をautopilotという単語でググると､
‫一つのサービスで全てを行うための設定や自動化スクリプトが見つかることがあります｡
‫それぞれに長所と短所がありますね｡
‫私自身は､ あなたのやっている方法で済ませることが多いですね｡
‫YAMLが増え､ 少し冗長になったとしても､ よりシンプルになったような気がします｡
‫ここで一つ､ できることがあります｡
‫ひとつ大きな改善点は､ ここにある部品がすべて同じものであるかどうかです｡
‫そうですね｡
‫同じものをすべてテンプレート化し､ テンプレートブロックに入れるだけで､ このファイルを大幅に短縮することができます｡
‫それについては､ この...で詳しくお話ししています｡
‫ここだよ､ ジェイコブ これはチャットに書いておきます｡
‫これは､ 多くの人が使っていない､ 3種類の高度なDocker Composeの機能です｡
‫そのひとつが､ テンプレート化についてです｡
‫ですから､ この例を見ていただければ､ そこにテンプレを投げることができるのです｡
‫基本的には､ このテンプレートにはこう書いてほしい､ この場所にはこう書いてほしいというのを､
‫各画像というか各サービスに何度も何度も書いてほしいということです｡
‫そのため､ 全体をテンプレート化したり､ 部分的にテンプレート化して複数のテンプレートを用意したりと､
‫定型的なものが多く､ Dockerにはそれに関するドキュメントが用意されています｡
‫そうすれば､ ファイルを小さくすることができるので､ ドライと呼んでいます｡
‫そうですね｡
‫物事を一回で済ませること｡ 繰り返さないこと｡
‫D R Y そんなこともできるんですね｡
‫そうすれば､ 特にヘルスチェックや配備に関する反復的な作業を軽減することができます｡
‫そして､ データノードの出来上がりです｡ すべて順調です｡ 健康保険を使っているんですね｡ ネットワークが設定されましたね｡
‫あなたのボリューム この一部を過去にさかのぼって紹介します｡ 各ノードにハードコーディングしているんですね｡
‫本当は､ 「走るな」と言う方法があればいいのですが...｡
‫のように､ ここに配置の制約があります｡
‫他のものが走っているところにあるものには実行しないでください｡
‫希望はある｡ ここでできることは2つあります｡ 配置の好みを見ることができます｡
‫もし､ 異なるノードをアベイラビリティゾーンに配置し､ AWSなどのようにデータベースが各アベイラビリティゾーンに1つのコピーを持つようにしたい場合､
‫各ノードにラベルを追加することができます｡ それなら､ 私のラベルの上にこれを広げてほしい､ と言えばいいのです｡
‫制約ではなく､ ラベルと配置の優先順位を与えるだけで､ 異なるゾーンの異なるサーバーにそれらを配置することができます｡
‫しかし､ クールなのは､ あるゾーンやあるサーバーがダウンしても､ それを別の場所に再割り当てできることです｡
‫最悪のケースは､ 同じサーバーで2台が動作している場合ですが､ これはおそらくそれほど悪いことではなく､
‫もしあなたが... つまり､ 1つは､ データがあるゾーンから他のゾーンへ取得することかもしれません｡
‫その問題をある程度解決したら
‫そうですね｡
‫そうですね｡ つまり､ 制約を使って､ 物理ノードの1つを失うことを許容する､ ということですね｡
‫そうですね｡
‫ここで重要なのは､ Nodeのホスト名に割り当てることで､ 少しもろくなっていることです｡
‫特定のホストを立ち上げる必要があります｡ AWSとかでサーバーを自動作成させるようなのが理想的ですね｡
‫つまり､ サーバーが死ねば､ すべて新しいサーバーが作られるのです｡
‫そうですね｡
‫それをすべて説明したのであれば､ 素晴らしいことです｡ このように配置の制約があることは､ 何も悪いことではありません｡
‫ただ､ そのノードがないと､ そのコンテナは死んでしまうということです｡
‫もうひとつは､ 19年に新しい機能が登場します｡ 03 そして､ これらの新機能を知るには､ githubのDockerにアクセスし､
‫Docker-ceのリリースを見ることです｡ チャットに投稿しますので､ Swarmの新機能を調べてみてください｡
‫Swarmの新しい機能バージョンでは､
‫レプリカを実行することができますが､ 同じノードでこれらのレプリカをX個以上実行しないように指示します｡ 非常にクールな機能で､ データベースがすべて同じノードに割り当てられないようにするのに役立ちます｡
‫同じノートにならないように､
‫より柔軟な方法としてチェックしておくといいかもしれませんね｡
‫スウォームまで下にスクロールすると思います｡
‫そうですね｡ ノードあたりの最大レプリカ数を指定できるようにしました｡ それが､ 近日発売の19の新機能です｡ 03のリリースは､ 現在すでにプレリリース中ですので､
‫今後数週間から数ヶ月のうちに見ることができると思います｡
‫それを確認することができます｡
‫それが制約の助けになるかもしれません｡
‫わかりました｡
‫少し先に進みたいと思います｡
‫全部見直せないのが残念です｡ 下の方に移動させています｡
‫ネットワーク､ アタッチャブルトゥルー､ プロキシを手に入れたんですね｡
‫すべて順調のようです｡
‫ボリュームがあるので､ デフォルトのボリュームドライバを使っているわけです｡
‫共有ストレージがある場合は､ REX-Rayや他のボリュームドライバを検討し､ そのディスクからストレージを取り出せるようにするとよいでしょう｡
‫そうすれば､
‫一方のノードに障害が発生し､ それを別の場所に作りたいときに､ もう一方のノードでそのデータベース・ボリュームを再アタッチすることができるのです｡
‫わかりました｡
‫もうご覧になったかもしれませんね｡ traefikの証明書を持っていますね｡ しばらくその話をしたいのですが､
‫時間がなくなりそうです｡ トラフィック証明書の話はまた別の機会に｡
‫それから､ コンフィグなどのファイルもありますね｡
‫これはすごいことです｡ すべてのコンフィグを使用する
‫当然のように｡
‫ここにシークレットはありません｡ ある時点でシークレットが必要になると思いますが､ そのシークレットをどこかに保存しておく必要があるかもしれません｡
‫それ以外は素晴らしいYAMLです｡ 間違いなく､
‫私が見た中では良いものの一つです｡
‫ここでやることはほとんどないと思います｡
‫完璧な機能をすべて使っているような作りになっているという点では､ そう思います｡ テンプレはアレだけど｡ さまざまなボリュームドライバーを検討し､
‫新機能を検討する｡ 配置設定でない場合は､
‫ノードあたりの最大レプリカ数に関する新機能を使用します｡
‫ご視聴ありがとうございました｡
‫SUBSCRIBEと通知ベルをクリックすると､ 私がライブに参加したときにアラートが表示されるので､ 参加してDevopsやDockerに関する質問をすることができます｡
‫私の他のビデオを見ることもできますし､ 私がこれからするように､ ただ昼寝をすることもできます｡