文件刪除或git的版本之間修改自動得到從實例

Question

背景刪除

我有詹金斯與以下引發的設置 -

• 的文件進行部署的phing準備，通過與git服務器交談，並在所需的git修訂版本之間採用git diff，在單獨的構建服務器中，無需AWS代碼部署（據我所知）。詹金斯觸發了phing的構建。
• 我只將要添加/修改的文件（基於版本的git差異）動態添加到appspec.yml文件中。我只準備將要添加/修改到路徑/home/jenkins/deployment/cd_deploy/codebase/的文件，並且我已經在Jenkins項目的「高級項目選項」下的「使用自定義工作區」選項下指定了路徑/home/jenkins/deployment/cd_deploy/，該選項基本上是構建服務器中需要的位置上傳到S3存儲桶。 請注意，我需要從兩個git修訂版之間刪除的實例中刪除這些文件。
• 然後，Jenkins使用有關應用程序名稱的信息觸發AWS Codedeploy，我配置的代碼部署部署組。

問題

，我動態地添加到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文件從中央構建完全去除鉤部，並且刪除相應的文件.SH，即beforeInstall.sh，afterInstall.sh等後服務器（準備好S3套件），這樣我的邏輯和任何對它的引用都不會進入實例，要刪除的文件仍然會自動刪除。

更新2

今天，我發現，在git的版本之間修改的文件也越來越被自動刪除。 我有邏輯動態準備appspec.yml文件。我修改了不添加一些文件。所以，有一些文件在git diff中，但在appspec文件中沒有。因此，他們正在被刪除，但不會重新出現。 看起來，代碼部署在部署之前會自動進行清理。我如何阻止？我想添加我的自定義清理邏輯。

更新beforeInstall.sh的3

內容 -

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 

代碼部署會先清理 3個文件它部署在第一個修訂版本（A，B和C）上，然後部署新的修訂版本......它從不簡單地上傳預期的文件，它總是首先清理舊文件（通過查看先前的「修訂」來確定） 。這很重要，因爲它可以讓你瞭解一些看起來像是神祕的行爲。結果，經過部署，當然：

File A 
File C 

現在，如果你已經手動添加文件到CodeDeploy外的組合變得有趣起來。它只會清理它所知道的事情，如果這個清除階段不會刪除它們，它也不會覆蓋當前修訂版本中的文件。當人們手動安裝一個應用程序，然後嘗試對相同的文件夾執行CodeDeploy時，通常會看到這種情況...沒有以前的修訂版，因此沒有任何可以清理的內容，然後嘗試複製現有文件，會出錯。您通常希望您的目標文件夾是「裸體」的，以便您可以正確啓動修訂歷史記錄。

例如，在前面的方案，如果您有之前上傳的文件A，B和C 手動，然後& B將失敗，因爲它不知道該清理的文件的部署， B和C首先，然後它會給你一個錯誤，試圖覆蓋文件A和B.

一個文件（或文件夾）完全外部部署...即不是任何修訂的一部分，比如File D ...會保持愉快，在部署之前和之後都會毫無怨言地保持開心。這對放置數據文件以及可能特定於部署的事物很有用，但不一定是您不想經常重新部署的代碼庫的一部分。

現在，您可以使用鉤子做很多有趣的事情，當然，但它感覺就像是手頭工作的錯誤工具。這些掛鉤用於執行諸如停止/啓動服務等操作，而不是管理文件複製管理，這是CodeDeploy應該爲您做的核心。

排除應用規範中的所有文件（即，沒有指定文件），並簡單地使用BeforeInstall和/或AfterInstall步驟來執行復制邏輯是一種適用於某些情況的方法。

無論如何，也許這更好地理解CodeDeploy的運作方式可能會幫助您制定解決方案。我不認爲它特別有據可查。我的理解來自於自己的觀察和掙扎。