这是我在“安装”步骤遇到的错误-
File already exists at location /var/cake_1.2.0.6311-beta/app/webroot/../../somefile.php
我无法断定此方案带来了什么事件。但是我记得是这样的-
注意-这是appspec.yml文件的files部分中的第一个文件。
据我所记得,我直接通过代码部署在同一部署组上进行了一些部署(很可能使用了与詹金斯在上述步骤中创建的同一S3文件),该部署已成功完成。
此后,即使直接通过代码部署,我也无法获得成功的部署。
背景
我检查了这个似乎相关的问题,并通过删除其中的所有内容进行了尝试/opt/codedeploy-agent/deployment-root/
,如其中一个答案中所述,但是,这导致损坏的代码在我的实例中部署,并通过Jenkins部署开始引发此错误,指出存档文件中的appspec文件(试图寻找最后一次成功的部署,但似乎没有被删除)-
Jenkins触发的代码部署在ApplicationStop步骤失败,即使通过代码部署直接进行的相同部署组已成功运行
然后,我将代码重新安装在实例上,上面提到的步骤是我在此之后所做的。
更新-开放赏金
如Rodrigo M的回答,到目前为止,从实例上的部署路径中删除此类文件对我来说一直有效,但对于该特定文件却不起作用-
File already exists at location /var/cake_1.2.0.6311-beta/deployment/serverLoad.json
我验证了以下内容-
在所有实例上从上述位置删除文件后,我进行了新部署。我观察到该文件再次出现,但仍然引发与上述相同的错误,并且部署失败。
没有删除,我将文件更改为777。结果相同。
有趣的是,昨天我收到多个文件的错误消息,然后在找到它们并采用新版本的过程中将其逐个删除。除此文件外,所有其他文件的问题均已解决,即使删除也不起作用。我没有线索!
注-我现在正在执行的所有部署都是由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文件导致同一文件退出问题。每次更改文件名都是很痛苦的。对发生的事情非常恼火。
作为其过程的一部分,CodeDeploy将在app/deployment组的先前已部署文件中查找信息。如果这样,它将使用此信息删除现有文件,并根据需要为新修订的部署做准备。
http://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-
steps.html#deployment-
rollback
在这种情况下,由于您之前可能已经进行过手动清理,因此存在一些不一致的参考。
对于所有部署,一个不错的选择是在BeforeInstall
挂接过程中简单地删除部署文件夹中的所有文件。这将立即解决此问题,并将继续解决此问题。
问题内容: 我正在尝试使用AWS CodeDeploy将我的最新更改从Github拉到服务器。我遇到的问题是在安装步骤中,我收到此错误: 我的appspec.yml看起来像这样: 我的问题是它是否应该使用CodeDeploy拉动git,为什么我得到文件已存在错误?难道我做错了什么? 问题答案: 您是否在不同的部署组中部署了相同的git repo,还是以前手动进行过部署?如果目标文件夹中已经存在相同
问题内容: 通过Jenkins(代码部署插件)触发时,出现以下错误- 但是,如果我直接通过代码部署触发部署到同一部署组中,并在S3中指定相同的zip(通过Jenkins触发器获得),则此步骤通过。 这是什么意思,我如何找到解决方法?我目前正在整合一些东西,因此需要同时通过代码部署和Jenkins进行部署。当我需要确保较小的单元运行正常时,我将运行代码部署触发的部署。 更新资料 只要提及另一点,以防
问题内容: 詹金斯的新手:我正在詹金斯建立我们的团队。设置构建步骤以运行nodejs脚本(使用Sencha Touch 2将脚本将构建的应用程序带入本地iOS应用程序的脚本)。nodejs脚本需要一个扳手库。 Jenkins用户似乎在不同的上下文中运行。它看不到我的节点安装或npm安装。作为构建步骤的一部分,我必须将路径导出到node和npm。现在,我已经完成了,构建可以看到node和npm命令。
我不知道我应该从哪里开始,因为我必须通过安装4j安装程序在JBoss上部署一个网络应用程序。 我已经创建了动态Web应用程序,我想在JBoss上部署这个应用程序,但是部署一个war文件并在客户端机器上配置JBoss不是一个好主意,因此我想创建一个安装程序文件(. exe)文件,它将处理以下事情: > 在客户机上安装JBoss服务器 在JBoss服务器上部署我的应用程序 所以我只需要把安装程序文件给
问题内容: 我有这个 Dockerfile : 和这个 Jenkinsfile : 这将导致以下错误: 我尝试使用,但没有成功。 我在docker jenkinsfile声明上使用args 时有些运气,但这会创建root拥有的目录和文件,这些文件和目录不能由用户Jenkins在下次运行时删除。 我不想在Dockerfile上进行操作,因为实际上Install步骤正在运行一个make文件,而不是我想
通过作曲家安装照明/数据库失败并生成以下错误: “无法将您的要求解析为一组可安装的程序包。” 问题1-照明/数据库v5。2.0需要照明/支持5.2.*- 照明/支持v5。2.7需要外部mbstring*- 要启用扩展,请验证它们是否正确 在那些地方启用。ini文件:-/etc/php/7.0/cli/php。ini-/etc/php/7.0/cli/conf.d/10-opcache。ini-/e