这是我在“安装”步骤中遇到的错误-
File already exists at location /var/cake_1.2.0.6311-beta/app/webroot/../../somefile.php
我无法总结这一情况的发展过程。但我记得的是-
- I then had several failed deployments (deliberately failed at various steps, e.g. beforeInstall by exiting with a non zero number).
此后,我甚至无法通过代码部署直接获得任何成功的部署。
背景
我检查了出现关联的这个问题,并尝试删除了/opt/codedeploy-agent/deployment-root/
中的所有内容,就像在答案之一中提到的那样,但是它导致了在我的实例中被破坏的代码部署,并且部署via Jenkins开始抛出这个错误,因为它试图查找最后一次成功的部署(它似乎被删除了)-
Jenkins触发的代码部署在ApplicationStop步骤中失败,尽管同一部署组通过直接代码部署正在成功运行。
然后,我在实例上重新安装了代码部署,上面提到的步骤就是我之后所做的工作。
更新-打开Bounty
正如Rodrigo M所回答的,从实例上的部署路径中删除这样的文件到目前为止对我是有效的,但是对于这个特定的文件来说也是一样的-
File already exists at location /var/cake_1.2.0.6311-beta/deployment/serverLoad.json
我核实了以下情况-
有趣的是,昨天我得到了多个文件的这个错误,当我找到它们并进行了一个新的构建时,我开始逐个删除它们。除了这一个文件之外,所有其他文件的问题都得到了解决,即使删除也不起作用。毫无线索!
注意:我现在所做的所有部署都是由Jenkins触发的(没有通过AWS代码部署触发的直接部署)。
下面是来自/var/log/aws/codedeploy-agent/codedeploy-agent.log
的日志跟踪,其中包含相关的错误堆栈strace -
2016-11-10 07:38:12 INFO [codedeploy-agent(16889)]: Version file found in /opt/codedeploy-agent/.version.
2016-11-10 07:38:12 INFO [codedeploy-agent(16889)]: [Aws::CodeDeployCommand::Client 200 0.025545 0 retries] put_host_command_complete(command_status:"Failed",diagnostics:{format:"JSON",payload:"{\"error_code\":5,\"script_name\":\"\",\"message\":\"File already exists at location /var/cake_1.2.0.6311-beta/deployment/serverLoad.json\",\"log\":\"\"}"},host_command_identifier:"WyJjb20uYW1hem9uLmFwb2xsby5kZXBsb3ljb250cm9sLmRvbWFpbi5Ib3N0Q29tbWFuZElkZW50aWZpZXIiLHsiZGVwbG95bWVudElkIjoiQ29kZURlcGxveS91cy1lYXN0LTEvUHJvZC9hcm46YXdzOnNkczp1cy1lYXN0LTE6Mzc3NzAzOTYxOTk4OmRlcGxveW1lbnQvZC1VOVFPR0RBWUkiLCJob3N0SWQiOiJhcm46YXdzOmVjMjp1cy1lYXN0LTE6Mzc3NzAzOTYxOTk4Omluc3RhbmNlL2ktZWNmYzU1YTkiLCJjb21tYW5kTmFtZSI6Ikluc3RhbGwiLCJjb21tYW5kUG9zaXRpb24iOjQsImNvbW1hbmRBdHRlbXB0IjoxfV0=")
2016-11-10 07:38:12 ERROR [codedeploy-agent(16889)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Error during perform: RuntimeError - File already exists at location /var/cake_1.2.0.6311-beta/deployment/serverLoad.json - /opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/installer.rb:115:in `generate_normal_copy'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/installer.rb:67:in `block (2 levels) in generate_instructions'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/installer.rb:55:in `each'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/installer.rb:55:in `block in generate_instructions'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/install_instruction.rb:68:in `generate_instructions'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/installer.rb:54:in `generate_instructions'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/installer.rb:34:in `install'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_executor.rb:114:in `block in <class:CommandExecutor>'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_executor.rb:62:in `execute_command'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_poller.rb:132:in `process_command'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_poller.rb:65:in `perform'
/opt/codedeploy-agent/lib/instance_agent/agent/base.rb:28:in `run'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:38:in `block in run'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:55:in `with_error_handling'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:37:in `run'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:70:in `block in run_with_error_handling'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:55:in `with_error_handling'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:69:in `run_with_error_handling'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:33:in `block in start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:22:in `loop'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:22:in `start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:206:in `block in spawn_child'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:204:in `fork'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:204:in `spawn_child'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:196:in `block in spawn_children'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:195:in `times'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:195:in `spawn_children'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:134:in `start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:37:in `block in start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:36:in `fork'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:36:in `start'
/opt/codedeploy-agent/bin/../lib/codedeploy-agent.rb:41:in `block (2 levels) in <main>'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/command_support.rb:130:in `call'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/command_support.rb:130:in `execute'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/app_support.rb:262:in `block in call_command'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/app_support.rb:275:in `call'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/app_support.rb:275:in `call_command'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/app_support.rb:69:in `run'
/opt/codedeploy-agent/bin/../lib/codedeploy-agent.rb:88:in `<main>'
更新2
通过重命名json文件并删除appspec.yml中的旧文件引用,我能够应用一个脏的修复。但是,在一个新的部署组上(使用新的ec2实例),新的json文件将导致相同的文件退出问题。每次更改文件名都很痛苦。对正在发生的事情非常恼火。
发布于 2016-08-08 07:38:24
作为其流程的一部分,CodeDeploy将查找有关应用程序/部署组先前部署的文件的信息。它使用此信息删除现有文件,根据需要为新修订的部署做准备。
http://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html#deployment-rollback
在这种情况下,有一些不一致的引用,因为您可能已经完成了以前的手动清理。
对于所有部署来说,一个很好的选择就是在BeforeInstall
钩子期间删除部署文件夹中的所有文件。这将解决这个问题,并向前推进。
发布于 2017-06-26 06:04:14
这是可以修复的。代码部署会对尚未部署的文件引发错误。但是在部署过程中有一种选择可以解决这一问题。
“内容选项:当目标实例上的文件与应用程序修订版中的文件具有相同的名称时,在部署过程中为同一目标位置选择AWS CodeDeploy的操作。”
您可以选择失败、覆盖和保留。这取决于你的情况。
你可以找到更多的信息
https://stackoverflow.com/questions/38832762
复制相似问题