‫Dをするように､ 特定の順番でコンテナを遅らせるには､ どのような戦略が良いのでしょうか｡
‫B. ウェッブ・ラビットなど｡
‫つまり､ 1番は､ これは分散コンピューティングのことだと言っている開発者のOPでもないんですね｡
‫Docker composeのようなものを使ったローカルな開発ワークフローではなく､ 本番環境について話しているのだと思います｡
‫しかし､ 本番環境では､ すべてのアプリケーションで失敗や再試行が可能でなければならないのですね｡
‫Dockerが登場する前であろうとなかろうと､ 基本的にそこで使っているものは､ 自分以外のサービスと会話できない状態から何らかの方法で回復しなければならないのです｡
‫そして､ これは分散コンピューティングの核となる原理です｡
‫実際､ リソースとは何かというと､ 12 factor 12 factor dot netは､
‫クラウドネイティブと分散コンピューティングという考え方に関する10年来の原則のようなもので､
‫この2つは異なるけれども似たタイプのものです｡
‫そしてその答えは､ スタートアップは問題の一部に過ぎないから､ スタートアップを正しくコントロールすることはできない､ というものです｡
‫コンテナや他のサービスが一瞬ダウンして､ 他のコンテナとの接続が切れた場合､ コンテナを交換する必要がありますが､
‫その際､ コンテナを使用している他のサービスもすべて復旧させなければなりません｡
‫昔はサーバーが1台あって､ Webサイトのデータベースも同じサーバーに置いて､ それがダウンするまで常に利用可能でオンラインだったのですが､
‫今はそれが簡単になりました｡
‫しかし､ この世界ではディストリビューション・コンピューティングがあり､ コンテナやすべてのサービスがそれを念頭に置かなければなりません｡
‫そのため､ リトライが必要になるのですが､ 開発をしている場合､ ほとんどの開発者は残念に思っています｡
‫ほとんどのデータベースドライバにはリトライ機能が組み込まれていて､ Mongo Dのように実際にリトライすることができます｡
‫B. とノードがあります｡ jsにはバッファープロトコルがあり､
‫接続できないときは､ データベースがオンラインに戻るのを待つために､ コマンドを少し保留しておくことができます｡
‫開発言語のドライバに組み込まれているだけなので､ そういうものはたくさんありますよ｡
‫そして､ もしあなたのアプリがそのようなことを何もせず､ ただ失敗してしまったとしたら｡
‫コンテナ・オーケストレーションを使っている場合､ オーケストレーターの仕事の一部として､ コンテナが何かの原因で接続を失ってクラッシュしたときに､
‫オーケストレーターが再起動し､ 基本的にどこか別の場所でその新しいコピーを開始することができます｡
‫そして､ それが失敗から立ち直るための一つの方法なのです｡
‫しかし､ Dockerの別の方法として､ アプリをクラッシュさせ､ Dockerが設定に基づいてアプリを再起動させるという方法もあります｡
‫だから､ それは小さなクリックボタンではないだろうとは思っています｡
‫たくさん答えてください｡
‫というのも､ コンテナを使い始めると､
‫より頻繁にコンテナをアップデートすることになります｡
‫そうすると､ パズルの1ピースでも他のピースが倒れても対応できるようにしなければならず､
‫スタートアップオーダーではそれができないのです（笑）｡
‫お役に立てれば幸いです｡
‫レガシーアプリを扱っている場合は､ 解決するのが難しい問題ですが､ これは連続したものです｡
‫アプリがすべて失敗を処理できるようにするためには､ 継続的に作業を続けなければなりません｡
‫本来は簡単な問題ではないのですが｡
‫それは､ it's a process to go throughです｡