背景を少しお話しすると、私は 3 年間 Puppet を使っており、そのアーキテクチャをかなりよく理解しています。当社は、マイクロサービスに基づくアーキテクチャで製品全体をリファクタリングしており、継続的インテグレーション/デプロイメントの使用を開始しています。この機会を利用して、構成管理を Ansible に切り替え、デプロイメントと構成/オーケストレーションの両方に 1 つのツールのみを使用できるようにしました。
私たちのアーキテクチャは完全に AWS をベースとし、ライブ、ステージング、および 3 つの統合/QA 環境を備えています。各マイクロサービスには独自のデプロイ プロセスがあり、統合/QA 環境ではすべてのアプリケーションが 1 つのインスタンスに保持されますが、ライブ/ステージングでは複数のインスタンスが保持され、場合によってはマイクロサービスごとに異なるインスタンス プールが保持されます。
私の目標は、変数を使用して環境全体でテンプレートをパラメータ化し、すべての環境に対して単一の Ansible 構成/展開「リポジトリ」を用意することです。こうすることで、開発サイクル全体を通じて一貫した構成と展開プロセスが確保されます。
私が今疑問に思っているのは、これらの複数のアプリケーションのロール作成にどうアプローチするかということです。私が見つけた投稿のほとんどが簡単なチュートリアルか、単一のアプリケーションの展開例なので、このトピックを「グーグル」で検索するのはかなり難しいと思います。
私が今検討しているのは次のことです。
nginx、java、logstash など、必要な各「サービス」ごとにロールを分け、その中に各アプリケーション構成ファイルを用意します。こうすることで、ロールの再利用性が保たれ、2 つ以上のアプリケーションが、変数によって異なる設定ファイルを使用するときに、同じことを繰り返さずに済みます。また、すべてのデプロイ タスクを含むデプロイ ロールも用意します。これは、Puppet で作業するときに通常採用するアプローチですが、構成が分散して、1 つのアプリケーション構成の変更が別のアプリケーション構成に影響を与える可能性がある場合 (主に、1 つのテンプレートが複数のアプリケーションに対応しているため) に、いくつかのケースを見つけて追加することが「困難」になることがあります。
マイクロサービスに 1 つのロールを用意します。すべての構成と変数が同じロールにあるため、作業が簡単になりますが、マイクロサービスごとにタスクと構成を繰り返す必要があるため、少し面倒です。
この質問の理由は、同じ問題に直面している人々がどのように対処しているかを測定することです。Google 検索でこの問題に関する妥当な回答を見つけることはほぼ不可能と思われますし、Ansible/マルチ アプリ デプロイに取り組んでいる友人や知人もいないからです。
十分に明確でなかったり、混乱させてしまったりした場合は申し訳ありません。また、提供していただけるあらゆる洞察に感謝します。
答え1
私がやろうとしているのは、それぞれに役割を持たせることですシステムサービスアプリケーションに必要な遊ぶそして役割各アプリケーション/マイクロサービスごとに、グループおよび/またはホスト変数そしてロール変数とデフォルト何をすべきかを定義します。
私は PHP ベースのアプリケーションを多数展開しているので、次のような感じになります。
演劇をやりますapp_microservice.yml
:
---
- hosts: app_microservice_servers
roles:
- nginx
- mariadb
- php-fpm
- app_microservice
それで、私は役割 roles/app_microservice
コードをデプロイします。このプレイを実行すると、前提条件の nginx、mariadb、php-fpm がまだインストールされていない場合は、最初にインストールされ、設定されます。
コールに加えてroles
、プレイは任意の を実行することもできますtasks
。完全なロールが必要ないほど単純な場合は、これらを自由に組み合わせてください。
このプレイは他のすべてのプレイと一緒に実行されるall.yml
ため、時々 を実行できますansible-playbook all.yml
。ansible は puppet が試みるようなべき等性を保証しないので、この点には注意が必要です。
- include: app_microservice.yml
私が使うグループグループに共通するものを定義する変数(ただし、これらの変数の中には、役割変数またはデフォルト)、all
グローバルなもののためのグループ変数、そしてホストホストに固有のあらゆる変数。
たとえば、私はすべてのホストに一意の MySQL ルート パスワードを割り当てていますが、SSL 暗号とプロトコルを定義しておけばgroup_vars/all/main.yml
、変更が必要になった場合でも、信頼できる唯一の情報源になります。