sourcebroker/deployer-extended

为 deployer (deployer.org) 提供一些附加任务的库。

19.0.0 2023-10-01 09:53 UTC

README

https://scrutinizer-ci.com/g/sourcebroker/deployer-extended/badges/quality-score.png?b=master http://img.shields.io/packagist/v/sourcebroker/deployer-extended.svg?style=flat https://img.shields.io/badge/license-MIT-blue.svg?style=flat

它做什么?

为 deployer (deployer.org) 提供一些附加任务的库。

设置文档

composer_version

安装特定的 composer 版本。使用标签。有效的标签在此 https://github.com/composer/composer/tags 。默认值为 null

composer_channel

从频道安装最新版本。将此变量设置为 '1' 或 '2'(或 'stable', 'snapshot', 'preview')。在 composer 文档中了解更多信息。默认值为 stable,将安装 composer 的最新版本。如果您需要稳定性,请将其设置为 '1' 或 '2'。

composer_channel_autoupdate

如果设置,则在每次部署时,将根据 composer_channel 设置检查 composer 的最新版本。默认值为 true

web_path

当不在项目根目录时,到公共路径的路径。必须是类似 "pub/" 的格式,没有起始斜杠和结束斜杠。

任务文档

buffer

buffer:start

开始缓冲到应用程序入口点的请求。应用程序入口点意味着此处可以是任何可以处理 HTTP 请求或处理 CLI 调用的 PHP 文件。对于大多数良好的框架,只有少数入口点。

请求被缓冲,同时如果您设置特殊的 HTTP 头(默认为 HTTP_X_DEPLOYER_DEPLOYMENT)并使用特殊值,您将能够进行常规请求。这可以非常方便地检查在切换(符号链接到当前)后应用程序是否正常工作,并预热一些缓存。

当您运行 buffer:stop 时,所有等待的请求将击中 HTTP 服务器(或 CLI 入口点)。

入口点来自变量 "buffer_config",它是一组入口点配置的数组。

选项

  • entrypoint_filename 必需:
    将用 "entrypoint_inject" PHP 代码覆盖的文件名。如果入口点在文件夹内,则写入此文件夹,如:'entrypoint_filename' => 'index.php'
  • entrypoint_needle 必需:默认值: <?php
    "entrypoint_filename" 中的 "needle",在它之后将注入 "entrypoint_inject" 中的 PHP 代码。
  • entrypoint_refresh 必需:默认值: 200000 μs (200ms)
    入口点多久会重新检查 .flag.requestbuffer 是否仍然存在。值以微秒为单位。100000 μs = 100 ms = 0,1 s。
  • entrypoint_inject 必需:
    实际执行缓冲的 PHP 代码。默认代码已预先填充变量(随机数、locker_filename、locker_expire、entrypoint_refresh)
    isset($_SERVER['HTTP_X_DEPLOYER_DEPLOYMENT']) && $_SERVER['HTTP_X_DEPLOYER_DEPLOYMENT'] == 'af37fd227cb6429c211168666dd28391' ? $deployerExtendedEnableBufferLo
    isset($_ENV['DEPLOYER_DEPLOYMENT']) && $_ENV['DEPLOYER_DEPLOYMENT'] == 'af37fd227cb6429c211168666dd28391' ? $deployerExtendedEnableBufferLock = false: $deployerExtendedEnableBufferLock = true;
    clearstatcache(true, __DIR__ . '/.flag.requestbuffer');
    while (file_exists(__DIR__ . '/.flag.requestbuffer') && $deployerExtendedEnableBufferLock) {
        usleep(200000);
        clearstatcache(true);
        if(time() - @filectime(__DIR__ . '/.flag.requestbuffer') > 60) @unlink(__DIR__ . '/.flag.requestbuffer');
    }
    
  • locker_filename 必需:默认值: .flag.requestbuffer
    当存在名为 ".flag.requestbuffer" 的文件时,请求将被缓冲。任务 buffer:stop 只会删除 ".flag.requestbuffer" 文件,而不会删除 "entrypoint_inject" 代码。
  • locker_expire 必需:默认值: 60
    在自动删除 .flag.requestbuffer 文件后的秒数。
    通常是其 buffer:stop 任务,该任务应该删除 ".flag.requestbuffer" 文件。不幸的是,有时部署可能会失败。如果在 buffer:start 任务之后和 buffer:stop 任务之前部署失败,则无论“locker_expire”时间如何,".flag.requestbuffer" 都将被自动删除。

最简单的配置示例

set('buffer_config', [
        'index.php' => [
            'entrypoint_filename' => 'index.php',
        ]
    ]
);

更多入口点示例。CMS TYPO3 8.7 LTS 的示例

set('buffer_config', [
        'index.php' => [
            'entrypoint_filename' => 'index.php', // frontend
        ]
        'typo3/index.php' => [
            'entrypoint_filename' => 'typo3/index.php', // backend
        ],
        'typo3/cli_dispatch.phpsh' => [
            'entrypoint_filename' => 'typo3/cli_dispatch.phpsh', // cli
        ]
    ]
);

更多配置选项示例

set('buffer_config', [
        'index.php' => [
            'entrypoint_filename' => 'index.php',
            'entrypoint_needle' => '// inject php code after this comment',
            'locker_filename' => 'deployment.lock',
            'entrypoint_inject' => 'while (file_exists(__DIR__ . ".flag.requestbuffer")){' . "\n"
                                   . 'usleep(200000);' . "\n"
                                   . 'clearstatcache(true, __DIR__ . "/.flag.requestbuffer")' . "\n"
                                   . '}'
        ]
    ]
);

buffer:stop

停止向应用程序入口点缓冲请求。它删除 ".flag.requestbuffer" 文件。

deploy

deploy:check_branch

检查您要部署的分支是否与主机上当前部署的分支不同。如果您有信息表明主机上的分支与您要部署的分支不同,则您可以决定是否覆盖它。

deploy:check_branch_local

检查您在本地已签出的分支是否与您要部署的分支相同。两个分支上的 deploy.php 文件可能不同,这可能会影响部署过程。

deploy:check_composer_install

检查当前实例中是否存在 composer.lock 文件。如果存在,则对 "composer install" 执行干运行。如果 "composer install" 返回需要更新或安装某些包的信息,则意味着可能开发者从仓库中拉取了 composer.lock 的更改,但忘记了执行 "composer install"。在这种情况下,部署将停止,以便开发者更新包、进行一些测试,然后进行部署。

deploy:check_composer_validate

检查 composer.lock 文件是否与当前的 composer.json 状态一致。如果不一致,则部署将停止。

deploy:check_lock

检查当前实例根目录中是否存在 deploy.lock 文件。如果存在该文件,则部署将停止。

您可以根据自己的需求使用它。想象一下,您在本地使用 "grunt watch" 开发 css/js。在您有可工作的代码后,您可能会忘记使用 "grunt build" 构建最终的 js/css,并且您将部署不会在生产中使用的 css/js,它读取编译后的 css/js。

为了防止这种情况,您可以让 "grunt watch" 生成文件 "deploy.lock"(其中包含文本 "Run 'grunt build'."),以通知您在部署应用程序之前遗漏了某些步骤。

file

file:backup

备份文件。单个任务可能使用定义的过滤器执行多个归档化。在执行此任务后,将删除旧文件。默认限制为 5。

配置描述

  • file_backup_packages 必需:默认值:类型:数组
    包定义
  • file_backup_keep 必需:默认值:5 类型:整数
    每个包的备份限制

示例配置

set('file_backup_packages', [
    'config' => [
        '-path "./etc/*"',
    ],
    'translations' => [
        '-path "./l10n/*"',
        '-path "./modules/*/l10n/*"',
    ],
    'small_images' => [
        [ '-path "./media/uploads/*"', '-size -25k' ],
        [ '-path "./media/theme/*"', '-size -25k' ],
    ],
]);

set('file_backup_keep', 10);

配置变量 file_backup_packages 存储有关备份包和文件过滤选项的信息。每个包定义了在 find 命令中使用的过滤器。第一级元素是组,它们将使用逻辑或运算符连接。如果组是数组类型,则组元素将使用逻辑与运算符连接。

config:这是最简单的定义。对于此包,将备份目录 "./etc/" 中的所有文件。

translations:对于此包,将备份目录 "./l10n/" 中的所有文件。它还将包括 "modules" 子目录中所有 "l10n/" 目录中的文件。例如 "modules/cookies/l10n"。

small_images:此包将包含 "media/uploads" 和 "media/theme" 中的所有小(小于 25kB)文件。

如您所见,file_backup_keep 设置为 10,这意味着每个包只存储最新的 10 个备份。

file:copy_dirs_ignore_existing

除了在新版本中已存在的目录外,复制旧版本中的目录。

file:copy_files_ignore_existing

除了在新版本中已存在的文件外,复制旧版本中的文件。

file:rm2steps:1

允许在 "安全" 和 "速度" 两个方面分两步删除文件和目录。

安全性

有时删除包含大量文件的缓存文件夹只需几秒钟。在此过程中,新的前端请求可能击中HTTP服务器,并开始生成新的文件缓存,因为它会检测到一些缓存文件缺失,需要重新生成缓存。正在删除缓存文件夹的过程可以删除新生成的缓存文件。在这种情况下,缓存文件夹的输出不可预测,可能会使应用程序崩溃。

速度

如果您决定在buffer:start期间删除缓存文件夹,那么尽快完成操作至关重要,以便尽可能减少缓冲请求。

解决“安全”和“速度”两个问题的方法是首先将文件夹重命名为某个临时文件夹,然后在下一步中稍后删除它。重命名是原子操作,因此不存在新的HTTP击中将在同一文件夹中开始构建缓存的可能性。我们还获得了速度,因为我们可以在部署的末尾使用任务file:rm2steps:2来删除文件夹/文件,如果确实需要这样做,因为部署者的“清理”任务将删除旧版本。

file:rm2steps:2

file:rm2steps的第二个步骤。更多内容请参阅file:rm2steps:1

cache

cache:clear_php_cli

此任务清除CLI上下文的文件状态缓存、opcache和eaccelerator缓存。

cache:clear_php_http

此任务清除HTTP上下文的文件状态缓存、opcache和eaccelerator缓存。它执行以下操作:

  1. 在"{{deploy_path}}/current"文件夹中创建名为"cache_clear_[random].php"的文件。
  2. 通过选择的方法 - curl / wget / file_get_contents - 获取此文件,默认为wget。
  3. 清除缓存后不删除文件,原因在于它允许防止与realpath_cache相关的问题。更多信息请阅读http://blog.jpauli.tech/2014-06-30-realpath-cache-html/

您必须设置public_urls配置变量,以便脚本知道它应该从中获取php脚本的域名。以下是一个示例

server('prelive', 'example.com', 22)
  ->user('deploy')
  ->stage('prelive')
  ->set('deploy_path', '/home/web/html/www.example.com.prelive')
  ->set('public_urls', ['https://prelive.example.com']);

任务配置变量

  • cache:clear_php_http:phpcontent required: no type: string default value:
    <?php
      clearstatcache(true);
      if(function_exists('opcache_reset')) opcache_reset();
      if(function_exists('eaccelerator_clear')) eaccelerator_clear();
    

    将放入动态创建的文件中以清除缓存的内容。
  • public_urls required: yes default value: none type: array
    用于准备获取清除缓存php文件的URL的域名。预期它是一个数组,因此您可以将其放入其中以用于不同的目的,但在这里,对于此任务,将使用第一个域名。
  • fetch_method required: no default value: wget type: string
    可以是以下值之一:- curl,- wget,- file_get_contents
  • cache:clear_php_http:timeout required: no default value: 15 type: integer
    设置获取php清除缓存脚本的超时时间(秒)。
  • local/bin/curl required: no default value: "which curl"的值 type: string
    当前系统上curl二进制的路径。
  • local/bin/wget required: no default value: "which wget"的值 type: string
    当前系统上wget二进制的路径。
  • local/bin/php required: no type: string
    当前系统上php二进制的路径。

变更日志

请参阅https://github.com/sourcebroker/deployer-extended/blob/master/CHANGELOG.rst