Docker Swarmについては、より多くの実践経験が必要かもしれません.
数人のクラウドが今日もたらしたこの記事では、Dockerがアプリケーションのライフサイクルの各段階で果たす役割と、Swamクラスタに移行する際に考慮すべき問題を共有します.
Dockerによる開発
Dockerは仕事をもっと楽にします.MySQLデータベースをインストールするか、Ghostをインストールするか、Redisデータベース、PostgreSQL、Rubyなどをインストールする必要があります.実際にはこれらはDocker化コンテナ化とミラー化されている.
1つのコマンドで実行できます.
ダウンロード(ミラー)—使用済み-廃棄され、ローカル開発環境を混乱させるプログラムはありません.
既存のコンテナを拡張するのは簡単で、Dockerの基礎知識が十分であれば、ネットからダウンロードしたDockerミラーが役に立つミラーかどうかを判定することができます.
Dockerは開発者の利器であり,開発環境に追加するメリットは言うまでもない.
Dockerに詳しい場合は、Docker-composeのコマンドを使用して開発環境スタック全体を起動することがよくあります.
たとえば、一般的なDocker-composeファイルは次のようになります.
次に、次のように実行します.
PostgreSQLアクセスアドレス:postgresql://database
Redisアクセスアドレス:http://redis
これは極めて簡便な方法であり、開発環境スタック全体を数行のコードで記述し(development stack as a code)、バージョン制御機能を内蔵している.以下、生産環境について説明します.
生産環境の要件
生産環境は普通ではない.ここでは、中程度の負荷量のサーバ要件を示します.可用性:すべての時点でサービスが利用可能であり、ダウンタイムを最小限に抑える必要があります. パフォーマンス:サーバは大量の訪問者リクエストを処理する必要があるため、パフォーマンスも重要です. は、導入とロールバックが容易です. ログと指標を収集します. 負荷分散:一部のサービスまたはサーバが失敗した場合は、Webサイトが正常にアクセスできることを期待します.
Dockerは準生産の解決策として、実際には多くの人に過小評価されています.約1年前、PvP Center(https://beta.pvpc.eu/)の過程でDockerファイルシステムの問題で、いくつかの失敗も経験しました(現在、私はOverlay 2ファイルシステムを使っていますが、問題はもう存在しません)、今振り返ってみると、これは良い決定です.
本番導入で元のDockerコマンドを使用するかDocker-composeを使用するか
この問題が発生した場合は、新しいバージョンのアプリケーションを自動的にダウンロードし、コンテナに自動的に配置するように設定します(Ansibleプロファイル:https://rock-it.pl/managing-m... ).次にリストを表示します.パフォーマンス:Dockerプロセスは、通常のカーネルプロセスであり、顕著なリソースオーバーヘッドは発生しません. の導入が容易:ワンタッチの導入.Ansibleは複数の判断条件をチェックするため、容器のバージョンだけではないので、少し時間がかかります. ロールバック:すべてのコンテナミラーが異なるラベルを使用した後、コンテナウェアハウスに保存されます.データベースの移行を後方互換化すると、ロールバックが容易になります.
しかし、以上の方法でも問題が発生します.
1.バックエンドのダイナミックなロードバランシングノードを維持するため、アプリケーションの導入が要求されたときにサーバがダウンタイムをゼロにするという非常规の要件を満たすことはできません.複数のサーバに容易に拡張することはできません.
2、持続的な統合/持続的な導入システム(CI/CD)を統合するには、極めて賢い手段と方法が必要である.
3、特定のアプリケーションを別々に保存する場合、配置の依存度は異なるアーキテクチャ倉庫内にある.プロファイルが変更されると、ロールバックが非常に困難になります.
このようなやり方をしばらく堅持して、何の問題もありませんが、何かが欠けているような気がします.迅速な配置とプロファイルの修正が必要なので、Ansibleの配置も私を刺激しました(遅すぎます).しかし、Docker Swamへの移行を本格的に促進する決定的な理由は、1台のサーバに拡張するための特性です.同じ方法でクラウドに適用し、外部負荷イコライザを使用することができますが、負荷イコライザノードを動的に追加または削減することは依然として痛みです.特定のアプリケーションのプロファイルをAnsibleから削除し、これらのプロファイルをアプリケーションウェアハウスに送信します.
Docker Swarm
Docker Swarm設計の目的は、Dockerコマンドを使用して複数のサーバ間のコンテナスケジューリングを容易に管理することであり、かなり最先端の新機能新特性である(Docker 1.12バージョンから).要点:Dockerを実行する複数のサーバに同時に接続できます. は簡単です.Kubernetesと比較して、Docker Swamの方が上手です. 高可用性–クラスタには、MasterノードとWorkerノードの2つの異なるタイプのノードがあります.
いずれかのMasterノードはLeaderであり、現在のLeaderがダウンタイムで使用できない場合、他の健康なMasterの1台が自動的にLeaderになります.Workerノードのダウンタイムが使用できない場合、ダウンタイムノードのコンテナインスタンスは、他の健全なWorkerノードに再スケジュールされます.宣言構成:どのアプリケーションとどのインスタンスのコピーをパブリッシュするかを明確にするだけで、スケジューリングシステムはこれらのアプリケーションのインスタンスのパブリッシュを自動的にスケジュールし、指定された制限条件などに従います. スクロール更新:Swarmはコンテナをパブリッシュするときの構成を保存します.プロファイルが新しくなると、コンテナも一括更新されるため、サービスは常に利用可能になります. 内蔵サービス発見と負荷等化:Docker-composeが実現した負荷等化と類似しています.サービス名を参照することで、コンテナがどこのサーバにあるかはまったく重要ではありません.これらのロード・バランシング・ノードは、フロントエンドからのトラフィックを受信します.デフォルトはポーリング・ポリシーです. Overlayネットワーク:コンテナがサービスポートを露出している場合、このサービスポートはクラスタ内でアクセスできます.これは、外部負荷イコライザの使用に役立ちます.
いつになったらDocker Swamを使うか考えるべきです
Docker Swarmの使用を検討する前に、次の5つの質問を繰り返します.アプリケーションは2台以上のサーバに拡張する必要がありますか?複数のサーバは、単一のサーバよりも複雑であるか、またはより高い構成の単一のサーバを購入したいだけですか? アプリケーションで利用可能な要件はありますか? コンテナ化を適用した後、本当に無状態化されていますか?Swarmの下でコンテナを走るのはストレージボリュームを使用するべきではありません.理論的にはストレージボリュームを使用することができますが、テストで使用するときは、安定した信頼性ではありません.マルチメディアファイルをアマゾンS 3に移動し、データベースをDocker Swarmの外で実行することも考えられる. には、ELKなどの統合ログシステムがあるかどうか(これはすべての分散システムに適用されます). は、Kubernetesなどの他のより成熟したソリューションにすでに存在する高度な機能と特性を必要としますか?Kubernetesに詳しいのはDocker Swamに詳しいよりずっと難しいことを覚えておいてください.
生産環境でのDocker Swarm使用経験
これまで、アプリケーションがSwamの上を走って6ヶ月が経ち、Docker-composeからSwamへの移行に1週間かかりました(移行方法の学習など).アプリケーションコンテナが完全に無状態になるようにプロファイルを調整し、外部集中ログと指標収集を使用する必要があります.ピーク時には35個のノードが動作した.クラスタの管理が便利です.
例:
スクリーンショットは次のとおりです.
配置プロセスは次の図のとおりです.
Deploy領域では、最新のDocker-compose v 3版の構文とDocker stack deployコマンドを使用します.アプリケーションコンテナをパブリッシュするプロファイルをVCSに格納する作業は、これまでにないほど簡単になりました.構成を手動で変更する必要がなく、Swarmクラスタに適用コンテナを簡単に配置できます.
プロファイルの例:
配置コマンド全体は1行のみです:docker stack deploy application.もちろん、ここではGitlabを使用しています.comの流れ、結果は下図の通りです.
Webインタフェースでロールバック操作を行うことができ、携帯電話でロールバック操作を実行することもできます.
締めくくり
以上は、Docker Swamに対する個人的な観点です.他のオプションを使用することは考えられていましたが、アプリケーションをコンテナ化し、複数のサーバに拡張したい場合は、現在の方法が最善です.
Jakub Skałecki原文リンク:https://rock-it.pl/my-experie...
数人のクラウド微信の公衆番号に注目してください.後続の文章があれば、私たちは最初の時間にフォローします.
Dockerによる開発
Dockerは仕事をもっと楽にします.MySQLデータベースをインストールするか、Ghostをインストールするか、Redisデータベース、PostgreSQL、Rubyなどをインストールする必要があります.実際にはこれらはDocker化コンテナ化とミラー化されている.
1つのコマンドで実行できます.
docker run name_of_programe_you_needダウンロード(ミラー)—使用済み-廃棄され、ローカル開発環境を混乱させるプログラムはありません.
既存のコンテナを拡張するのは簡単で、Dockerの基礎知識が十分であれば、ネットからダウンロードしたDockerミラーが役に立つミラーかどうかを判定することができます.
Dockerは開発者の利器であり,開発環境に追加するメリットは言うまでもない.
Dockerに詳しい場合は、Docker-composeのコマンドを使用して開発環境スタック全体を起動することがよくあります.
たとえば、一般的なDocker-composeファイルは次のようになります.
version: '2'
services:
web:
build: .
command: npm run dev
ports:
- 8080:80
redis:
image: redis
database:
image: postgres次に、次のように実行します.
docker-compose up # --build if you want to rebuildPostgreSQLアクセスアドレス:postgresql://database
Redisアクセスアドレス:http://redis
これは極めて簡便な方法であり、開発環境スタック全体を数行のコードで記述し(development stack as a code)、バージョン制御機能を内蔵している.以下、生産環境について説明します.
生産環境の要件
生産環境は普通ではない.ここでは、中程度の負荷量のサーバ要件を示します.
Dockerは準生産の解決策として、実際には多くの人に過小評価されています.約1年前、PvP Center(https://beta.pvpc.eu/)の過程でDockerファイルシステムの問題で、いくつかの失敗も経験しました(現在、私はOverlay 2ファイルシステムを使っていますが、問題はもう存在しません)、今振り返ってみると、これは良い決定です.
本番導入で元のDockerコマンドを使用するかDocker-composeを使用するか
この問題が発生した場合は、新しいバージョンのアプリケーションを自動的にダウンロードし、コンテナに自動的に配置するように設定します(Ansibleプロファイル:https://rock-it.pl/managing-m... ).次にリストを表示します.
しかし、以上の方法でも問題が発生します.
1.バックエンドのダイナミックなロードバランシングノードを維持するため、アプリケーションの導入が要求されたときにサーバがダウンタイムをゼロにするという非常规の要件を満たすことはできません.複数のサーバに容易に拡張することはできません.
2、持続的な統合/持続的な導入システム(CI/CD)を統合するには、極めて賢い手段と方法が必要である.
3、特定のアプリケーションを別々に保存する場合、配置の依存度は異なるアーキテクチャ倉庫内にある.プロファイルが変更されると、ロールバックが非常に困難になります.
このようなやり方をしばらく堅持して、何の問題もありませんが、何かが欠けているような気がします.迅速な配置とプロファイルの修正が必要なので、Ansibleの配置も私を刺激しました(遅すぎます).しかし、Docker Swamへの移行を本格的に促進する決定的な理由は、1台のサーバに拡張するための特性です.同じ方法でクラウドに適用し、外部負荷イコライザを使用することができますが、負荷イコライザノードを動的に追加または削減することは依然として痛みです.特定のアプリケーションのプロファイルをAnsibleから削除し、これらのプロファイルをアプリケーションウェアハウスに送信します.
Docker Swarm
Docker Swarm設計の目的は、Dockerコマンドを使用して複数のサーバ間のコンテナスケジューリングを容易に管理することであり、かなり最先端の新機能新特性である(Docker 1.12バージョンから).
いずれかのMasterノードはLeaderであり、現在のLeaderがダウンタイムで使用できない場合、他の健康なMasterの1台が自動的にLeaderになります.Workerノードのダウンタイムが使用できない場合、ダウンタイムノードのコンテナインスタンスは、他の健全なWorkerノードに再スケジュールされます.
いつになったらDocker Swamを使うか考えるべきです
Docker Swarmの使用を検討する前に、次の5つの質問を繰り返します.
生産環境でのDocker Swarm使用経験
これまで、アプリケーションがSwamの上を走って6ヶ月が経ち、Docker-composeからSwamへの移行に1週間かかりました(移行方法の学習など).アプリケーションコンテナが完全に無状態になるようにプロファイルを調整し、外部集中ログと指標収集を使用する必要があります.ピーク時には35個のノードが動作した.クラスタの管理が便利です.
例:
docker service scale name_of_service=30 or docker service update --env-add SECRET_ENV=youdontneedtoknowit name_of_serviceスクリーンショットは次のとおりです.
配置プロセスは次の図のとおりです.
Deploy領域では、最新のDocker-compose v 3版の構文とDocker stack deployコマンドを使用します.アプリケーションコンテナをパブリッシュするプロファイルをVCSに格納する作業は、これまでにないほど簡単になりました.構成を手動で変更する必要がなく、Swarmクラスタに適用コンテナを簡単に配置できます.
プロファイルの例:
version: '3'
services:
web:
image: registry.gitlab.com/example/example # you need to use external image
command: npm run prod
ports:
- 80:80
deploy:
replicas: 6
update_config:
parallelism: 2
delay: 10s
restart_policy:
condition: on-failure配置コマンド全体は1行のみです:docker stack deploy application.もちろん、ここではGitlabを使用しています.comの流れ、結果は下図の通りです.
Webインタフェースでロールバック操作を行うことができ、携帯電話でロールバック操作を実行することもできます.
締めくくり
以上は、Docker Swamに対する個人的な観点です.他のオプションを使用することは考えられていましたが、アプリケーションをコンテナ化し、複数のサーバに拡張したい場合は、現在の方法が最善です.
Jakub Skałecki原文リンク:https://rock-it.pl/my-experie...
数人のクラウド微信の公衆番号に注目してください.後続の文章があれば、私たちは最初の時間にフォローします.