プライベートOpenstackクラウド展開でJujuを使用していますか？
内部で展開されたOpenstackクラウドでJujuを使用しようとすると、多くの問題が発生します。このほとんどは、DNSホストの解決と、当社の内部HTTPプロキシに対処する必要性に集中しているようです。
OpenStackの展開は、内部クラウドでホストされている各プロジェクト（テナント）へのVLAN割り当て）のアドレスのルーティング不可能な172.16.0.0/12ブロックに依存しています。インスタンスに、社内LANのルーティング可能なアドレスのブロックから割り当てられます。
現在、Openstackは、クラウドコントローラーで実行されているDNSMASQサービス以外にはインスタンス名を登録しません。そのため、内部DNS階層を介してこのアドレスを解決する方法はありません（この問題はBug＃945505として既に報告されています）。そのため、bootstrap私のJujuサーバーノードですが、ローカル（プライベート）ネットワーク名を解決できないため、Jujuクライアントを使用して接続できません。内部でルーティング可能な（つまり浮動）アドレスをノードに割り当てたら、ノードにsshできるようになり、次の問題につながります。
次に、クラウドで実行されているインスタンスにソフトウェアをインストールするには、内部プロキシアドレスが定義されている必要があります-apt.confファイルまたは環境変数を使用して。残念ながら、サーバーノードをブートストラップする場合、この情報をJuJu environment.yamlファイルを介してインスタンスに渡すことはできません（これがこの問題を処理する最良の方法である場合）。その結果、bootstrapノードは必要なパッケージをインストールできません。
私は、内部環境でOpenstackを展開した方法はおそらくユニークではないと思います（危険なことは知っています）。他の誰かがこれらの問題に遭遇しましたか？さらに重要なのは、回避策が利用できるかどうかです。
デプロイ/ブートストラップ後、Jujuはインスタンスのパブリックアドレスを介して環境への接続を試みます。知る限りでは、このアドレスはEC2 APIのdescribe_instance（s）呼び出しから直接取得します。ご使用の環境では、新しいインスタンスが内部/プライベートアドレスで生成され、パブリック（フローティング）IPは関連付けられていません。結果は、describe_instancesのプライベートアドレスフィールドとパブリックアドレスフィールドの両方にあるプライベートアドレスです。フローティングIPをインスタンスに関連付けると、パブリックアドレスフィールドに新しく関連付けられたアドレスが表示されます。
関連付けが完了すると、JujuはSSHを介して正常に接続できるようになります（できる限り）。したがって、「juju bootstrap」、IPをbootstrap node、「juju status」に関連付けることができます。また、展開された他のすべてのマシンにフローティングIPを関連付ける必要があります。1つのオプションはnova.confに「--auto_assign_floating_ip」を追加して、インスタンスのスポーン時にフローティングIPの関連付けが自動的に行われるようにします。
Proxy-to-aptの問題に関しては、Jujuが、Jujuエージェントをブートストラップするために新しいノードに渡されるcloud-configをユーザーがカスタマイズできるようにすることは素晴らしいことです。可能であれば、juju固有のcloud-configとともにaptプロキシを構成できます。これは現在サポートされていないため、1つのオプションは、環境のapt.confを含むカスタマイズされたクラウドイメージをGlanceに公開し、default-image-idをenvironments.yamlからそのAMI IDに追加します。