isotoma.recipe.postdeploy 0.0.6

基本用法

考虑一个简单的yaybu配置

resources.append:
    - Execute:
        name: some-script
        command: ${buildout.buildout.directory}/bin/somescript
        user: root
        creates: ${buildout.buildout.directory}/stuff.cfg

您可以将此连接到buildout，如下所示

[buildout]
parts =
    postdeploy

[postdeploy]
recipe = isotoma.recipe.postdeploy
config = config.yay

要查看配置的“展开”形式 - 填充了所有变量 - 您现在可以在运行buildout之后这样做

$ ./bin/postdeploy show
resources:
  - Execute:
      name: /var/somedir/bin/somescript
      user: root
      creates: /var/somedir/stuff.cfg

此命令可选地接受 -v，它将显示更详细的配置转储。

您可以使用 simulate 命令来模拟应用配置的情况，而不会损害系统。

$ ./bin/postdeploy simulate
/---------------------------- Execute[some-script] -----------------------------
| # /var/somedir/bin/somescript
\-------------------------------------------------------------------------------

如果它认为不需要更改，则此命令将返回退出代码 254；如果成功模拟应用了一些更改，则返回 0；其他任何返回值都表示您的配置存在问题。它是一个理想的监控工具，因为它可以警告手动篡改或不完整的部署。

最后，您可以使用 apply 命令应用配置。

$ ./bin/postdeploy simulate
/---------------------------- Execute[some-script] -----------------------------
| # /var/somedir/bin/somescript
| Here is the stdout from your command
| ....
| ....
| Success!
\-------------------------------------------------------------------------------

必选参数

config

要应用到此计算机的 Yay 文件。它将访问您的 buildout 中的元数据。

可选参数

searchpath

一组目录或 URL，用于搜索配置此网站所需的资产。

history.track

要监控的值列表。当您有一组由 buildout 管理但需要在 postdeploy 中创建符号链接的部件时，这很有用。使用历史跟踪，您可以确保如果它们从 buildout 中删除，则它们也会从系统中删除。

例如

[buildout]
parts =
    ${parts:apache}
    postdeploy

[vhost1]
<snip>

[parts]
apache =
    vhost1
    vhost2

[postdeploy]
recipe = isotoma.recipe.postdeploy
history.track =
    parts:apache

并在您的 Yaybu 配置中

resources.append:
  .foreach vhost in history.parts.apache:
    - Link:
          name: /etc/apache2/sites-enabled/${buildout.sitename}-${vhost}
          policy: remove

首次运行 buildout 时，将创建一个包含当前状态的数据文件。现在，如果您从 buildout 中删除 vhost2 并运行 postdeploy，Yaybu 将确保您的符号链接被删除。此数据会跨越多个 buildout，因此即使在您忘记运行 postdeploy 的情况下也是安全的。

存在多种历史类型。默认是 removed。另一个例子是 max，它将跟踪字段曾经持有的最大值。如果您有一个具有可伸缩数量的服务的 buildout，并且想确保在更新 buildout 时停止旧服务，这将很有用。

[postdeploy]
history.track =
    environment:zopes max

然后我可以在我的 Yaybu 配置中这样做

.foreach i in range(buildout.environment.zopes, history.environment.zopes):
  - Execute:
      name: stop-forgotten-zope-${i}
      command: kill-command zope${i}
      unless: some-manual-pid-check

history.db

通常不需要更改此设置。

因为此配方必须支持 Python 2.4，所以它不能将其作为主数据存储使用 Yay。这是 Python 磁带路径。

默认值是 ${buildout:directory}/var/${partname}-history.db

history.yay

通常不需要更改此设置。

history.db 中的数据以 yay 的形式持久化，当您运行 bin/postdeploy 时，将从此处加载。

默认值是 ${buildout:directory}/var/${partname}-history.yay

executable

要使用的 Python 可执行文件。默认为用于调用 buildout 的同一可执行文件。这是为了支持 Python 2.4 buildout，因为 Yaybu 需要 2.6 或 2.7。

存储库

此软件可在我们的 配方存储库 在 github 上找到。

许可证

版权所有 2012 Isotoma Limited

根据 Apache 许可证版本 2.0（“许可证”）；除非您遵守许可证，否则您不得使用此文件。您可以在以下位置获得许可证副本：

https://apache.ac.cn/licenses/LICENSE-2.0

除非适用法律要求或书面同意，否则根据许可证分发的软件按“原样”分发，不提供任何明示或暗示的保证或条件。有关许可证的具体语言管理权限和限制，请参阅许可证。

0.0.6 (2012-04-08)

• 尚未更改。

0.0.5 (2012-04-07)

• 不要在输出中包含空映射。

0.0.4 (2012-04-03)

• 首先处理命令行选项。

0.0.3 (2012-03-20)

• 现在支持跟踪字段的最高版本。

  [postdeploy]
  history.track =
      environment:zopes max

  默认跟踪操作称为 removed。

  在此示例中，history.environment.zopes 将是此 buildout 部署所拥有的最大 zopes 数。用例是您的 buildout 刚才销毁了那些旧 zopes 的启动/停止脚本，并且您想确保它们实际上已经停止。然后我可以在我的 Yaybu 配置中这样做

  .foreach i in range(buildout.environment.zopes, history.environment.zopes):
    - Execute:
        name: stop-forgotten-zope-${i}
        command: kill-command zope${i}
        unless: some-manual-pid-check

0.0.2 (2012-03-17)

• 现在，所有简单元数据和未从部分引用的部分现在都将在部署后配置中可用。请注意，如果一个部分没有通过已安装的部分引用并且使用变量，则无法包含它：检查它可能会执行额外的构建配置。

0.0.1 (2012-03-16)

• 修复打包

0.0.0 (2012-03-16)

• 初始发布。