我发现在尝试将 Juju 与内部部署的 Openstack 云结合使用时遇到了很多问题。这些问题大多与 DNS 主机解析以及处理公司内部 HTTP 代理有关。
我们的 Openstack 部署依赖于不可路由的 172.16.0.0/12 地址块，用于将 VLAN 分配给我们内部云上托管的每个项目（租户）。用户可以选择将一个或多个浮动地址分配给实例，这些地址是从我们公司内部 LAN 上的可路由地址块中分配的。
目前，Openstack 不会向云控制器上运行的 DNSMASQ 服务以外的任何服务注册实例名称。因此，无法通过我们的内部 DNS 层次结构解析此地址（此问题已报告为 Bug #945505）。因此，即使我可以引导我的 Juju 服务器节点，也无法使用 Juju 客户端连接到它，因为它无法解析本地（私有）网络名称。一旦我为它分配了一个内部可路由（即浮动）地址，我就可以 ssh 到该节点。这导致了下一个问题。
接下来，要在我们的云中运行的实例上安装软件，它必须定义我们的内部代理地址 - 无论是在 apt.conf 文件中还是通过环境变量。不幸的是，在引导服务器节点时，没有规定通过 JuJu environment.yaml 文件将此信息传递给实例（如果这是处理此问题的最佳方法）。因此，引导节点无法安装所需的软件包。
我假设（我知道这很危险）我在内部环境中部署 Openstack 的方式可能不是独一无二的。还有其他人遇到过这些问题吗？更重要的是，有解决方法吗？
答案1
部署/引导后，Juju 将尝试通过实例的公共地址连接到环境。据我所知，它直接从 EC2 API 的 describe_instance(s) 调用获取此地址。在您的环境中，新实例会生成一个内部/私有地址，并且没有关联的公共（浮动）IP。结果是 describe_instances 的私有和公共地址字段中都有一个私有地址。将浮动 IP 关联到实例后，公共地址字段现在应该显示新关联的地址。
一旦关联，Juju 应该能够通过 SSH 正常连接（就像您一样）。因此，您应该能够“juju bootstrap”，将 IP 关联到 bootstrap 节点，“juju status”。您还需要将浮动 IP 关联到部署的所有其他机器。一种选择是将“--auto_assign_floating_ip”添加到 nova.conf，以便在实例生成时自动进行浮动 IP 关联。
至于代理到 apt 的问题，如果 Juju 允许用户自定义传递给新节点以引导 Juju 代理的云配置，那就太好了。如果可能的话，您可以在 juju 特定的云配置旁边配置您的 apt 代理。由于目前不支持，一种选择是将自定义云映像发布到 Glance 中，其中包含适合您环境的 apt.conf，并default-image-id在 environment.yaml 中设置为该 AMI ID。