☰

使用 Juju charms 进行持续部署

tag-icon • tag-icon juju continuous-deployment
使用 Juju charms 进行持续部署

我正在探索使用 Juju 部署我们的应用程序基础设施的可能性。

我的应用程序是使用 Play 框架构建的，并在 Java 虚拟机上运行。我设想以下设置：

  • 用于 SSL 卸载的代理服务器（如果不太难的话可能是多余的）
  • 运行应用程序和 JVM 的主节点
  • 运行应用程序和 JVM 的辅助节点（热备用）

代理服务器应仅在主节点关闭时使用辅助节点。应只有一个应用程序节点接收请求。我们不需要水平扩展，这会使业务逻辑复杂化。

上述设置似乎相当可行。当我考虑持续部署部分时，它（在我看来）变得更加复杂。

我的应用程序是使用私有 Jenkins 机器构建的，并生成一个 zip 文件，其中包含应用程序（作为可运行的 bash 脚本）及其所有依赖项。

部署它应采取以下步骤：

  • 将 zip 文件发送到服务器
  • 使用应用程序部署新的代理、主节点和辅助节点
  • 切换到新代理

我想为此创造一个魅力，但我不知道如何进行。

是否可以在 charm 内部署 charm 包？如果可以，如何部署？

请注意，欢迎任何建议。我不需要具体的实现，只需要指针和一般方向。

答案1

将“构建的”应用程序发送到您的环境实际上是一种相当常见的技术，特别是对于那些使用 docker 之类的工具的人来说。

通常情况下，您需要为环境中的每个组件创建一个 charm。在本例中，您似乎需要“代理”和“应用程序”。

因此，您需要创建一个代理 charm，除了和install钩子之外start，它还包含relation-joined和relation-broken钩子脚本。这些脚本将在关系连接时修改代理设置，以添加新的应用程序位置，随后在断开时删除应用程序位置。这将允许您保持代理正常运行并随意更换应用程序服务器。

应用程序服务将具有类似的钩子脚本，用于将其位置发送到代理服务。它还需要一个 charm 配置选项，用于指定需要部署的应用程序 zip 文件的位置。当应用程序install钩子运行时，它将在提供的位置下载 zip 文件，然后在钩子中运行它start。

持续部署是 Juju 真正出彩的地方。首先，您需要一个引导环境juju bootstrap <your-env-name>和juju switch <your-env-name>。

您的 Jenkins 实例将构建您的代理 zip 和应用程序 zip 文件，然后将它们上传到您的服务器可以访问的位置。如果您使用的是 EC2，则很可能是在 S3 上。然后，它会记录当前正在运行的代理和应用程序服务的位置路径和版本号以及服务名称。

然后它将运行：

juju deploy your-proxy your-proxy-<build-number>
juju deploy your-application your-application-<build-number>
juju add-unit your-application-<build-number> -n 2

此时，您可能希望定期检查代理和应用服务是否正常运行。此时，您需要将新的应用服务连接到代理，将流量切换到新代理并拆除旧服务。

juju add-relation your-proxy-<build-number> your-application-<build-number>
# add code here to switch to new proxy
juju destroy your-proxy-<old-build-number>
juju destroy your-application-<old-build-number>

这假设每次应用程序更改时您都会重建代理。如果不是，则只需从上述命令中删除代理步骤即可。这还假设应用程序需要时间才能启动，并且您不想导致停机，因此简单的挂钩upgrade-charm不起作用。

相关内容