Docker ドキュメント 全文検索
Results of 1 - 10 of about 39 for 障害 (0.002 sec.)
- アプリケーションのトラブルシュート — Docker-docs-ja 24.0 ドキュメント 15161
- アプリケーションのトラブルシュート アプリケーションのトラブルシュート 何事も失敗するのが、人生における現実です。これを前提に、障害が発生したらどのように対処すべきか考えるのは重要です。以下のセクションでは、いくつかの障害シナリオを扱います
...。 Swarm マネージャ障害 Consul（ディスカバリ・バックエンド）障害 Interlock ロードバランサ障害 ウェブ（web-vote-app）障害 Redis 障害 ワーカ（vote-w...orker）障害 Postgres 障害 results-app 障害 インフラ障害 Swarm マネージャ障害 現在の設定では、 Swarm クラスタには1つのホスト上で1つの...マネージャ用コンテナしかありません。コンテナが終了したりノード障害が発生したりしますと、クラスタを管理できなくなるだけでなく、修復や入れ替えも不可能になります。 Swarm マネージャ・コンテナが予... - https://man.mtool.work/docker/24.0/swarm/swarm_at_scale/troubleshoot.html
- swarm のスケールを試す — Docker-docs-ja 24.0 ドキュメント 12060
- swarm のスケールを試す swarm のスケールを試す ここで扱うサンプルは、 Swarm クラスタ上に投票アプリケーションをデプロイします。例では典型的な開発プロセスを使って説明します。インフラを構築すると、Swarm クラスタの作成やクラスタ上にアプリケーシ
...アプリケーションのテスト 追加作業:Docker Compose でデプロイ 次のステップ アプリケーションのトラブルシュート Swarm マネージャ障害 Consul（ディスカバリ・バックエンド）障害 障害の取り扱い Interlock ロードバランサ障害 ウェブ（web-vote-app）障害 Redis 障害...ワーカ（vote-worker）障害 Postgres 障害 results-app 障害 インフラ障害 関連情報 参考 Try Swarm at scale https://docs.docker.com/swarm/swarm_at_scale/...関連キーワード 障害 アプリケーション タスク Swarm デプロイ サンプル クラスタ swarm インフラ 構築 アーキテクチャ ステップ スケール 投票 Docker... - https://man.mtool.work/docker/24.0/swarm/swarm_at_scale/
- Docker Swarm — Docker-docs-ja 24.0 ドキュメント 10196
- Docker Swarm Docker Swarm Docker Swarm 目次 Docker Swarm Docker Swarm 概要 Swarm クラスタ作成を理解 ディスカバリ・サービス 高度なスケジューリング Swarm API ヘルプを得るには Docker Swarm の入手方法 インタラクティブなコンテナでクラスタを作成
...アプリケーションのテスト 追加作業:Docker Compose でデプロイ 次のステップ アプリケーションのトラブルシュート Swarm マネージャ障害 Consul（ディスカバリ・バックエンド）障害 Interlock ロードバランサ障害 ウェブ（web-vote-app）障害 Redis 障害 ワーカ（vote-w...orker）障害 Postgres 障害 results-app 障害 インフラ障害 関連情報 Docker Swarm の高可用性 プライマリとレプリカのセットアップ 前提条件 プ...エンドポイント Docker Swarm ドキュメント目次 関連キーワード Swarm Docker ステップ クラスタ ディスカバリ ノード ネットワーク 障害 関連 マネージャ タスク コンテナ アプリケーション フィルタ 目次 Engine ストラテジ セットアップ 確認 ドキュメント スケジュー... - https://man.mtool.work/docker/24.0/swarm/toc.html
- プロダクションで Swarm 利用時の考慮 — Docker-docs-ja 24.0 ドキュメント 9804
- プロダクションで Swarm 利用時の考慮 プロダクションで Swarm 利用時の考慮 目次 この記事は Docker Swarm クラスタを計画・デプロイ・管理の手助けとなるガイダンスを提供します。想定しているのは、ビジネスにおけるクリティカルなプロダクション環境です
...arm マネージャ、ディスカバリ・サービス用インスタンスやノードが1つまたは複数のネットワークにあるかもしれません。ネットワーク障害を埋め合わせるために、Swarm マネージャ、ディスカバリ・サービス、ノードが複数のプロダクション用ネットワークを横断することも可...ilable ）であるべきでしょう。つまり、長期間にわたる継続的な運用を意味します。高可用性を実現するのは、個々のコンポーネントで障害が発生しても切り抜ける環境です。 回復力のある高可用性 Swarm クラスタを構築するために、以下のセクションでは、いくつかの技術や...スケールするビジネスにおいては致命的なシナリオであり、許されません。 Swarm が提供する HA 機能は、Swarm マネージャで発生しうる障害を緩和します。クラスタ上に複数の Swarm マネージャを設定することで、Swarm の HA 機能を利用できます。3つの Swarm マネージャがア... - https://man.mtool.work/docker/24.0/swarm/plan-for-production.html
- ノードの挙動 — Docker-docs-ja 24.0 ドキュメント 9460
- プロダクションでアプリを実行 コンテナ設定 Swarm Swarm モードの挙動 ノードの挙動 ノードの挙動 目次 Docker 1.12 で swarm mode（スウォーム・モード）を導入しました。これは1つまたは複数の Docker エンジン上に、 swarm （訳者注:「群れ」の意味。sw
...維持します。swarm 上で 単一の manager しか実行しないのは、テスト用途であれば構いません。しかし、一つしかない swarm のマスタで障害が発生すると、サービスは動き続けるものの、復旧のためには新しいクラスタの作成が必要です。 swarm モードの耐障害性（fault-toler...Docker が推奨するのは、組織における高可用性の要件に応じ、ノード数を奇数にすることです。複数の manager があれば、manager で障害が発生したとしても、停止時間なく復旧可能です。 3 つのマネージャ がある swarm では、1つの manager の障害に耐えます 5 つのマネ...ージャ がある swarm では、最大で 2 つの manager ノードの同時障害に耐えます N つの manager クラスタは、最大で (N-1)/2 manager の障害に耐えます Docker が推奨するのは、 swarm に対して最大 7 つ... - https://man.mtool.work/docker/24.0/engine/swarm/how-swarm-mode-works/nodes.html
- Compose における起動順と停止順の制御 — Docker-docs-ja 24.0 ドキュメント 8222
- Docker Compose Compose における起動順と停止順の制御 Compose における起動順と停止順の制御 目次 depends_on オプションの使用で、サービスの起動順番と停止順番を制御できます。Compose は常にコンテナの依存関係の順番で、起動と停止を行います。この依
...の一部にすぎません。本番環境では、データベースが利用不可能になったり、常にホストを移動します。アプリケーションは、このような障害に対する :ruby:`回復力 <resilient>` が必要です。 これを扱うため、データベースで障害の発生後に、接続の再確立を試みるようアプリ...s 停止 depends 順番 コンテナ 準備 問題 接続 ラッパー スクリプト command Postgres 制御 ドキュメント サービス 依存 関係 理由 障害 ruby... - https://man.mtool.work/docker/24.0/compose/startup-order.html
- Docker Swarm の高可用性 — Docker-docs-ja 24.0 ドキュメント 8050
- Docker Swarm の高可用性 Docker Swarm の高可用性 目次 Docker Swarm の Swarm マネージャ は、クラスタ全体に対する責任を持ち、スケール時は複数 Docker ホスト のリソースを管理します。もし Swarm マネージャが停止したら、新しいマネージャを作成し、
...の作成・通信もできます。レプリカにリクエストすると、プライマリ・マネージャを自動的にプロキシします。プライマリ・マネージャで障害が起これば、レプリカが主導権を取ります。このような方法で、クラスタと通信し続けられます。 プライマリとレプリカのセットアップ...を実行したら、現在のプライマリ・マネージャ（ manager-1 ）は停止します。 自動フェイルオーバを待つ 直後に、他のインスタンスが障害を検出し、レプリカがプライマリ・マネージャの主導権を得ます。 例えば、 manager-2 のログを確認します。 user@manager-2 $ swarm...Cluster leadership acquired <--- 新しいプライマリ・マネージャに選出された [ ... ] これはプライマリ・マネージャ manager-1 で障害が発生しました。その後、 192.168.42.201:4000 のアドレスを持つ manager-2 のレプリカが障害を検出したため、主導権を（manager-1か... - https://man.mtool.work/docker/24.0/swarm/multi-manager-setup.html
- manage - Swarm マネージャの作成 — Docker-docs-ja 24.0 ドキュメント 7987
- manage - Swarm マネージャの作成 manage - Swarm マネージャの作成 動作条件:Swarm マネージャで manage を使う前に、 こちらのディスカバリのドキュメント に書かれているディスカバリ・バックエンドを構築します。 manage コマンドは Swarm マネージャを
...レプリケーション）を可能にします。プライマリからセカンダリにクラスタ情報のミラーを複製します。つまりプライマリ・マネージャで障害が起これば、セカンダリがプライマリ・マネージャになれます。 --replication-ttl - リーダー障害発生時のロック解除時間 --replic...です。マネージャはこの情報を Engine が正常（healthy）かどうか決めるために使います。接続できなければ、マネージャは対象ノードを障害（unhealthy）とみなします。マネージャは指定した間隔ごとに再度 Engine 情報の更新を試みます。規定回数の再試行して Engine が応答...、この間隔は 60 秒です。 --engine-failure-retry - Engine のリトライ失敗回数 --engine-failure-retry "数値" を使い、Engine が障害とみなすまでの再試行の回数を指定します。デフォルトでは、3回再試行します。 --engine-refresh-retry - 廃止予定 廃止予定; --en... - https://man.mtool.work/docker/24.0/swarm/reference/manage.html
- サービスの挙動 — Docker-docs-ja 24.0 ドキュメント 7768
- プロダクションでアプリを実行 コンテナ設定 Swarm Swarm モードの挙動 サービスの挙動 サービスの挙動 目次 Docker Engine が swarm モードで 動作時、アプリケーションのイメージをデプロイするには、サービス（service）を作成します。通常、サービスとは
...」と似ています。コンテナが稼働したら、スケジューラはタスクが実行中の状態であると認識します。もしもコンテナのヘルスチェックで障害が発生するか終了すると、タスクは終了（terminate）とみなします。 タスクとスケジューリング タスクとは、swarm においてスケジュ...り、タスクを実体化（インスタンス化）したものがコンテナです。もしも HTTP リスナーのタスクが、ヘルスチェックやクラッシュによる障害が起こると、オーケストレータは新しいレプリカタスクを作成、つまり、新しいコンテナを作成します。 タスクとは一方通行の仕組みです...。タスクは、割り当て、準備、実行など一連の状態を順々に進行します。もしもタスクで障害が起こると、オーケストレータはタスクとそのコンテナを削除します。それから、サービスを定義する期待状態（desired state）に従って... - https://man.mtool.work/docker/24.0/engine/swarm/how-swarm-mode-works/services.ht...
- docker service create — Docker-docs-ja 24.0 ドキュメント 7486
- コマンドライン リファレンス Docker CLI (docker) docker service docker service create docker service create 目次 説明 【API 1.24+】このコマンドを使うには、クライアントとデーモン API の両方が、少なくとも 1.25 の必要があります。クライアント
...行するコマンド --health-interval 【API 1.25+】確認を実行する間隔（ ms|s|m|h）（デフォルト 0s） --health-retries 【API 1.25+】障害と報告するために必要な、失敗を繰り返す回数 --health-start-period 【API 1.29+】 正常性確認をカウントダウン開始するまで、コンテ...時の処理（ pause | continue ）（デフォルト pause ） --rollback-max-failure-ratio 【API 1.28+】ロールバックを許容する :ruby:`障害率 <failure rate>` （デフォルト 0） --rollback-monitor 【API 1.28+】各タスクのロールバックが失敗するまで監視する時間（ ns |... - https://man.mtool.work/docker/24.0/engine/reference/commandline/service_create.h...