git修订版之间删除或修改的文件会自动从实例中删除

Question

背景

我有一个由Jenkins触发的设置,其中包括:

• 要部署的文件是通过phing,通过与git服务器交谈并git diff在单独的构建服务器之间进行所需的git修订,而不涉及AWS代码部署(据我所知)来准备的.詹金斯触发了phing构建.
• 我只是将要添加/修改的文件(基于修订版的git差异)动态添加到appspec.yml文件中.我只准备要添加/修改到路径的文件,/home/jenkins/deployment/cd_deploy/codebase/并/home/jenkins/deployment/cd_deploy/在Jenkins项目的"高级项目选项"下指定了"使用自定义工作区"选项下的路径,该选项基本上是构建服务器中需要上传到的位置S3桶.请注意,我需要从两个git修订版之间删除的实例中删除文件.
• 然后Jenkins触发AWS Codedeploy,其中包含有关我已配置的应用程序名称,Code部署的部署组的信息.

问题

我动态添加到appspec.yml文件的文件正在EC2实例中进行修改/添加,但是,奇怪的是,要删除的文件也会被删除.我验证了我没有逻辑删除我在appspec文件的beforeInstall钩子中编写的文件.我的beforeInstall挂钩中只有一个beforeInstall.sh文件,没有其他挂钩.一旦我从appspec文件中删除该挂钩,删除就会停止.这是我的appspec文件 -

version: 0.0
os: linux
files:
{Pair of files dynamically generated}
  - source: config/deployment_config.json
    destination: /var/cake_1.2.0.6311-beta/deployment
permissions:
  - object: .
    pattern: "**"
    owner: sandeepan
    group: sandeepan
    mode: 777
    type:
      - file
hooks:
  BeforeInstall:
    - location: beforeInstall.sh

AWS Codedeploy以某种方式与我的git托管(我正在使用gitlab而不是github)进行交谈,并以某种方式获取有关要删除的文件的信息.

更新

我后来观察到,即使从appspec.yml文件中完全删除了钩子部分,并从中央构建服务器(准备好S3捆绑包)中删除了相应的.sh文件,即beforeInstall.sh,afterInstall.sh等,所以我的逻辑和对它的任何引用都没有进入实例,要删除的文件仍然会被自动删除.

更新2

今天我发现在git版本之间修改的文件也会被自动删除. 我有动态准备appspec.yml文件的逻辑.我修改为不添加一些文件.因此,有一些文件存在于git diff中,但在appspec文件中没有.结果,它们被删除但不再出现.似乎代码部署在部署之前自动进行清理.我怎么阻止它？我想添加我的自定义清理逻辑.

更新3

beforeInstall.sh的内容 -

OUTPUT="$(w | grep -Po '(?<=load average: )[^,]*')"
rm -f /var/cake_1.2.0.6311-beta/deployment/deployment_config.json
path="$PWD"
php $path"/deployment-root/"$DEPLOYMENT_GROUP_ID"/"$DEPLOYMENT_ID"/deployment-archive/beforeInstall.php" ${OUTPUT}

/usr/local/nagios/libexec/check_logwarn -d /tmp/logwarn_hiphop_error /mnt/log/hiphop/error_`(date +'%Y%m%d')`.log #Just run a nagios check, so that counter corresponds to the line in the log corresponding to current timestamp/instant. Do not care about output. Note that we are not even looking for error hinting keywords (and hence not using -p because it needs to be used alongwith), because all we need to care about here is incrementing the nginx counter.

/usr/local/nagios/libexec/check_logwarn -d /tmp/logwarn_nginx_access /mnt/log/nginx/access_`(date +'%Y%m%d')`_`(date +'%H')`.log #Just run a nagios check, so that counter corresponds to the line in the log corresponding to current timestamp/instant. Acceptable http codes are also not being read from deployment_config.json.
printf "\n `date +%Y-%m-%d:%H:%M:%S` End of beforeInstall.sh"  >> /var/cake_1.2.0.6311-beta/deployment/deployment.log
exit 0

以及从上面调用的beforeInstall.php的内容 -

<?php 
file_put_contents('/var/cake_1.2.0.6311-beta/deployment/deployment.log', "\n ".date("Y-m-d H:i:s")." - Load print  ".$argv[1], FILE_APPEND);
$loadData = json_encode(array("load" => intval($argv[1]), "access_error_check_day" => date("Ymd"), "access_error_check_hour" => date("H"))); //error_check_day -> day when nagios error check was last run. We will accordingly check log files of days in between this day and the day of afterinstall (practically this can include a span of 2 days).

file_put_contents("/var/cake_1.2.0.6311-beta/deployment/serverLoad.json",$loadData); //separate from deployment_config.json. serverLoad.json is not copied from build server.
file_put_contents('/var/cake_1.2.0.6311-beta/deployment/deployment.log', "\n ".date("Y-m-d H:i:s")." loadData to config ".$loadData, FILE_APPEND);
?>

Answer 1

CodeDeploy 旨在部署应用程序，而不是简单地复制一组特定且不断变化的文件。

因此，在部署每个“修订版”之前，CodeDeploy 将首先清理先前修订版部署的所有文件。让我解释。

因此，假设之前的应用程序部署上传了三个文件：

File A
File B
File C

然后下一次部署仅包含这些文件：

File A
File C

Code Deploy 将首先清理它在第一个修订版上部署的 3 个文件（A、B 和 C），然后部署您的新修订版...它绝不会简单地上传预期的文件，它总是首先清理旧文件（由查看之前的“修订版”）。这很重要，因为它可以揭示您案例中看似神秘的行为。部署后的结果当然是：

File A
File C

现在，如果您在 CodeDeploy 之外手动将文件添加到混合中，事情就会变得有趣。它只会清理它知道的内容，并且如果此清理阶段不删除当前版本中的文件，它也不会覆盖它们。当人们手动安装应用程序，然后尝试对同一文件夹执行 CodeDeploy 时，经常会看到这种情况...没有以前的修订版，因此没有任何需要清理的内容，然后它尝试复制现有文件并会出错。您通常希望目标文件夹是“裸露”的，以便可以正确启动修订历史记录。

例如，在前面的场景中，如果您之前手动上传了文件 A、B 和 C ，那么文件 A 和 B 的部署将会失败，因为它不知道先清理 A、B 和 C，并且然后，尝试覆盖文件 A 和 B 时会出现错误。

完全在部署之外的文件（或文件夹）...即不属于任一版本，例如文件 D...将不会受到影响，并且在部署之前和之后都保持愉快的状态，而不会抱怨。这对于放置数据文件以及可能特定于部署但不一定是您不希望不断重新部署的代码库的一部分的东西很有用。

现在，当然，您可以使用钩子做很多有趣的事情，但感觉它对于当前的工作来说是错误的工具。这些挂钩旨在执行停止/启动服务等操作，而不是管理文件副本管理，而文件副本管理是 CodeDeploy 应该为您执行的核心操作。

从应用程序规范中排除所有文件（即未指定文件）并简单地使用 BeforeInstall 和/或 AfterInstall 步骤来执行复制逻辑是一种可能适用于某些场景的方法。

无论如何，更好地了解 CodeDeploy 的运作方式可能会帮助您制定解决方案。我认为它没有特别详细的记录。我的理解来自于我自己的观察和斗争。