JujuとOpenstackのプロビジョニング
私はJujuとOpenstackを初めて使用し、現在、Juju手動プロバイダーを使用して2ノードおよび3ノードのOpenStackテスト環境を展開しています。最初の試みで、jujuデプロイの--toキーを使用して、ホストにサービスをデプロイしようとしました。
Jujuが同じホストにデプロイされたKeystoneとMySQLの間に関係を作成できなかったとき、何かがうまくいかないことに気付きました。サービスをデプロイするには、次の構文を使用しました。
juju deploy keystone --to 1
juju deploy mysql --to 1
いくつかのグーグルは私に askubuntuに関するこの質問 と このガイド を与えました。
したがって、私が理解しているように、手動環境でサービスをデプロイする正しい方法は、同じホストにデプロイされているサービスにlxcコンテナーを使用することです（もちろん、これらのサービスがコンテナーで機能する場合）。
Lxcにはサービスの独立性や分離のような利点があると思いますが、Jujuによってデプロイされたサービスをコンテナーに分離する必要がある理由はまだわかりません。ジュジュの設計上の欠陥ですか、それとも一時的な解決策ですか？
Lxcなしで同じホストにいくつかのサービスをデプロイする方法はありますか？
デプロイされている各サービスの構成ファイルを指定することで実行できると思いますが、これによりJujuのほぼすべての「マジック」とシンプルさが排除されます...
十重自体は気にしない。状況を処理するために展開するかどうかは、チャーム次第です。したがって、これはまったく問題として扱われていません。ジュジュがサポートするもの、チャームが通常サポートするもの、そして受け入れられたベストプラクティスの違いにすぎません。
この答えはマニュアルプロバイダーに固有のものではないと思います。すべてのプロバイダーに適用されます。
ほとんどのチャームは、展開先のマシン（またはコンテナー）を「所有」していると想定しており、以前は、これがそれらを展開する唯一の方法でした。
この分離により、チャームの開発とテストが容易になります。これにより、チャーム開発者が他のチャームとリソースを共有することを心配する必要がなくなります。モジュール式の導入により、複雑さの管理が容易になります。チャーム間の相互作用をジュジュの関係に限定することにより、それらはクリーンでよく理解されたままでいることができます。チャームの作成者は、他のチャームに悪影響を与える可能性のある「システム」レベルの変更を心配する必要はありません。これを正しく処理するのはコンテナ化次第です。これにより、あるチャームが別のチャームに悪影響を及ぼすバグのクラス全体が排除されます。
そのため、実際には、チャームは、一緒に動作するように特別に設計されていない限り、最低でも独自のコンテナーにデプロイする必要があります。 2つのチャームをコンテナーに配置せずに同じマシンにデプロイしたときに発生する競合は、通常、バグとして扱われません。
これはあまり影響しません。 LXCは軽量です。
これにより、独自のチャームを作成したり、既存のチャームを変更したりして、同じマシンまたはコンテナーにデプロイできるようになります。ジュジュはそれを許可しますが、それらが競合しないことを確実にすることは、そのとき魅力に任されています。
ジュジュの設計上の欠陥ですか、それとも一時的な解決策ですか？
いいえ-それは実際にはまったくジュジュのものではありません。これはチャームの作成者の間で選択されたベストプラクティスであり、チャームがサポートする必要のあるデプロイメント構成とサポートすべきでないデプロイメント構成に関する決定に関連しています。
便利でサポートが難しいエッジのケースがいくつかあります（たとえば、bootstrapノードで実行されているJuju GUI）ので、Jujuはそれを許可しています。ジュジュの変革へのサポート。