Los files eliminados o modificados entre las revisiones de git se eliminan automáticamente de las instancias

Fondo

Tengo una configuration activada por Jenkins con lo siguiente:

  • Los files que se van a implementar están preparados por ching, hablando con git server y tomando un git diff entre las revisiones git requeridas, en un server de compilation independiente, sin la participación del deployment del código AWS (hasta donde yo creo). La compilation de phing es desencadenada por Jenkins.
  • Solo agrego los files que se agregarán / modifican (basados ​​en la diferencia de git de revisiones) dinámicamente al file appspec.yml. Preparo solo los files para agregar / modificar a una ruta /home/jenkins/deployment/cd_deploy/codebase/ y he especificado la ruta /home/jenkins/deployment/cd_deploy/ en la opción "Usar espacio de trabajo personalizado" en "Proyecto avanzado" Opciones "del proyecto Jenkins que es básicamente la location en el server de compilation que debe cargarse en el depósito S3. Tenga en count que necesitaría eliminar los files de las instancias que se eliminan entre las dos revisiones de git.
  • Luego, Jenkins desencadena AWS Codedeploy con la información sobre el nombre de la aplicación, el grupo de implementación de Code deploy que he configurado.

Problema

Los files que agrego dinámicamente al file appspec.yml se están modificando / agregando en las instancias de EC2, como espero, sin embargo, curiosamente, los files que se van a eliminar también se eliminan. Verifiqué que no tengo lógica para eliminar esos files escritos en el enganche beforeInstall de mi file de appspec. Solo tengo un file beforeInstall.sh en mi gancho beforeInstall y ningún otro gancho. Tan pronto como elimine ese gancho del file de la aplicación, la eliminación se detiene. Aquí está mi file de aplicacionespec –

 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 de alguna manera está hablando con mi hosting git (estoy usando gitlab y ni siquiera github) y de alguna manera obtengo la información sobre los files que se eliminarán.

Actualizar

Más tarde observé que incluso después de eliminar completamente la sección de ganchos del file appspec.yml, y eliminar los files .sh correspondientes, es decir, beforeInstall.sh, afterInstall.sh, etc. del server central de compilation (donde está preparado el package S3), entonces que ninguna de mi lógica y ninguna reference a ella va a las instancias, los files que se van a eliminar todavía se eliminan automáticamente.

Actualización 2

Hoy descubrí que los files que se modifican entre las revisiones de git también se eliminan automáticamente. Tenía lógica para preparar dinámicamente el file appspec.yml. Modifiqué para no agregar algunos files. Entonces, había algunos files que estaban allí en el git diff, pero que no estaban en el file de la aplicación. Como resultado, se eliminan pero no vuelven a aparecer. Aparentemente, la implementación del código está haciendo una limpieza antes de la implementación. ¿Cómo dejo eso? Me gustaría agregar mi lógica de limpieza personalizada.

Actualización 3

Contenido de 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 

Y el contenido de beforeInstall.php que se llama desde arriba –

 <?php file_put_contents('/var/cake_1.2.0.6311-beta/deployment/deployment.log', "\n ".date("Ymd 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("Ymd H:i:s")." loadData to config ".$loadData, FILE_APPEND); ?> 

CodeDeploy está diseñado para implementar aplicaciones, no simplemente copyr un set específico y constantemente diferente de files.

Como tal, antes de implementar cada 'revisión', CodeDeploy primero limpiará todos los files desplegados por la revisión anterior . Dejame explicar.

Entonces, supongamos que la implementación de la aplicación anterior cargó tres files:

 File A File B File C 

Y luego, la siguiente implementación solo incluía estos files:

 File A File C 

Code Deploy primero limpiará los 3 files que desplegó en la primera revisión (A, B y C) y luego implementará su nueva revisión … Nunca carga los files previstos, siempre limpia primero los files viejos (determinados por mirando la 'revisión' anterior). Esto es importante porque arroja algo de luz sobre lo que parece ser un comportamiento misterioso en su caso. El resultado, después de la implementación es, por supuesto:

 File A File C 

Ahora, se vuelve interesante si ha agregado files manualmente a la mezcla fuera de CodeDeploy. Solo limpiará cosas que conoce, y tampoco sobrescribirá files en la revisión actual si esta fase de limpieza no los elimina. Esto se ve a menudo cuando las personas han instalado manualmente una aplicación y luego intentaron hacer una CodeDeploy en la misma carpeta … no hay una revisión previa, por lo que no hay nada que limpiar, y luego intenta copyr encima de los files existentes y saldrá el error Normalmente desea que su carpeta de destino esté 'desnuda' para que pueda comenzar el historial de revisión correctamente.

Por ejemplo, en ese escenario anterior, si anteriormente había cargado los files A, B y C manualmente , la implementación de los files A y B habría fallado porque no sabría primero limpiar A, B y C, y le daría un error al intentar sobrescribir los files A y B.

Un file (o carpeta) completamente fuera del deployment … es decir, que no forma parte de ninguna de las revisiones, digamos File D … no se tocará y se mantendrá feliz tanto antes como después del deployment sin quejarse. Esto es útil para colocar files de datos y cosas que pueden ser específicas de la implementación pero que no son necesariamente parte de la base de código que no desea volver a desplegar constantemente.

Ahora, puedes hacer muchas cosas interesantes usando los ganchos, por supuesto, pero se siente como la herramienta incorrecta para el trabajo que tienes entre manos. Los ganchos están destinados para hacer cosas como detener / iniciar services, etc., para no administrar la gestión de copy de files que está en el corazón de lo que CodeDeploy debería estar haciendo por usted.

Excluir todos los files de las especificaciones de la aplicación (es decir, no files especificados) y simplemente utilizar BeforeInstall y / o AfterInstall para realizar la copy lógica es un enfoque que puede funcionar para algunos escenarios.

En cualquier caso, tal vez esta mejor comprensión de cómo funciona CodeDeploy pueda ayudarlo a crear una solución. No creo que esté particularmente bien documentado. Mi comprensión proviene de observar y luchar con eso yo mismo.