cloudControlMySQLdアドオンがどのように機能するかは私にはわかりません。MySQLdについての私の理解は、無制限のアプリで動作できる/動作するMySQLサーバーであるということです。
ただし、すべてのアドオンはアプリベースのみであるため、これは、複数のアプリで同じMySQLdサーバーを使用できないことを意味する場合もあります。
1つのMySQLdインスタンスをcloudControlでホストされている複数のアプリで使用できるかどうかを理解するのを手伝ってもらえますか?
cloudControlMySQLdアドオンがどのように機能するかは私にはわかりません。MySQLdについての私の理解は、無制限のアプリで動作できる/動作するMySQLサーバーであるということです。
ただし、すべてのアドオンはアプリベースのみであるため、これは、複数のアプリで同じMySQLdサーバーを使用できないことを意味する場合もあります。
1つのMySQLdインスタンスをcloudControlでホストされている複数のアプリで使用できるかどうかを理解するのを手伝ってもらえますか?
cloudControl PaaS には 2 つの概念があります。アプリケーションと展開。アプリケーションは基本的に、開発者とデプロイメントをグループ化するだけです。各デプロイは、デプロイ名に一致するブランチからのアプリの個別の実行バージョンです。詳細については、アプリ、ユーザー、および展開のドキュメントを参照してください。
すべてのアドオンは常に展開ごとです。これは、ランタイム環境の一部としてすべての認証情報を提供できるためです。これは、バージョン管理されたファイルに資格情報を持つ必要がないことを意味します。これは、ブランチ間でマージする場合に大きな利点となります。たとえば、開発環境のライブ データベースと誤って通信するリスクがないためです。また、アドオン クレデンシャルは、アドオン プロバイダーの裁量でいつでも変更できます。
このため、デプロイメント間の分離は非常に理にかなっています。通常、開発デプロイメントでは、たとえば本番デプロイメントと同じデータベース能力は必要ありません。そのため、小規模なプランや共有データベース (MySQL など) を開発用に簡単に使用できます。コード内でこの機能を使用する方法については、アドオンのドキュメント を参照してください。
また、前に説明したように、アドオン資格情報は常にランタイム環境の一部として提供されます。資格情報は、アドオン プロバイダーの裁量でいつでも変更できるようになりました。これらの変更は環境に自動的に提供され、アプリ プロセスが再起動されます。2 番目のアプリに必要な資格情報をハード コーディングした場合、アプリでダウンタイムが発生する可能性があります。
大事なことを言い忘れましたが、通常、異なるリポジトリの 2 つの異なるコード ベースから同じデータベースに接続することは非常に悪い習慣です。これにより、あらゆる種類の潜在的な競合や依存関係が発生し、コードの変更やデータベースの移行を長期的に維持することが非常に困難になります。推奨される方法は、1 つのコード ベースのみがデータを所有し、2 番目のコード ベースからそのデータにアクセスするための API を提供することです。
以上のことから、複数のデプロイメントやアプリを同じアドオン (データベースなど) に接続することは技術的に可能ですが、強くお勧めしません。
2 つのアプリ/デプロイを同じデータベースに接続する正当な理由がある場合は、Amazon で RDS インスタンスを手動で起動し (MySQLd は RDS に基づいています)、カスタム構成アドオンを介してその資格情報を両方に提供することをお勧めします。アプリ/展開。
これがあなたの質問に答え、理由も説明してくれることを願っています。