Deployment 部署失败，出现504错误_Deployment_Cloud Foundry_Swisscomdev

Deployment 部署失败，出现504错误

deployment cloud-foundry

Deployment 部署失败，出现504错误,deployment,cloud-foundry,swisscomdev,Deployment,Cloud Foundry,Swisscomdev,我正在尝试从控制台将应用程序部署到Swisscom应用程序云。它报告了进展情况，直到最后，报告了一个没有进一步解释的504： Updating app helloclass-fe-develop in org UCID-Bern Team / space HELLOCLASS-TEST as christian.cueni@iterativ.ch... OK Uploading helloclass-fe-develop... FAILED Error processing app files

我正在尝试从控制台将应用程序部署到Swisscom应用程序云。它报告了进展情况，直到最后，报告了一个没有进一步解释的504：

Updating app helloclass-fe-develop in org UCID-Bern Team / space HELLOCLASS-TEST as christian.cueni@iterativ.ch...
OK

Uploading helloclass-fe-develop...
FAILED
Error processing app files: Error uploading application.
Server error, status code: 504, error code: 0, message:

应用程序日志报告应用程序已更新：

2017-01-03 09:37:39 [RTR/0] OUT helloclass-develop.scapp.io - [03/01/2017:08:37:39.584 +0000] "GET / HTTP/1.1" 200 0 594 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.75 Safari/537.36 Google Favicon" 66.249.93.201:50868 10.0.18.35:64341 x_forwarded_for:"83.76.152.96" x_forwarded_proto:"https" vcap_request_id:8a8adcc7-9e97-4bd9-4492-68e92883ee3d response_time:0.001739219 app_id:310166b4-f3a6-4168-a9ac-530e45dbfb10 app_index:0
2017-01-03 09:37:39 [APP/PROC/WEB/0] OUT 83.76.152.96, 66.249.93.201, 66.249.93.201 - - - [03/Jan/2017:08:37:39 +0000] "GET / HTTP/1.1" 200 606
2017-01-03 10:05:50 [API/2] OUT Updated app with guid 310166b4-f3a6-4168-a9ac-530e45dbfb10 ({"name"=>"helloclass-fe-develop"})
2017-01-03 10:57:15 [API/1] OUT Updated app with guid 310166b4-f3a6-4168-a9ac-530e45dbfb10 ({"state"=>"STOPPED"})
2017-01-03 10:57:15 [CELL/0] OUT Exit status 0
2017-01-03 10:57:15 [APP/PROC/WEB/0] OUT Exit status 0
2017-01-03 10:57:15 [CELL/0] OUT Destroying container
2017-01-03 10:57:15 [CELL/0] OUT Successfully destroyed container
2017-01-03 10:57:16 [API/1] OUT Updated app with guid 310166b4-f3a6-4168-a9ac-530e45dbfb10 ({"state"=>"STARTED"})
2017-01-03 10:57:16 [CELL/0] OUT Creating container
2017-01-03 10:57:16 [CELL/0] OUT Successfully created container
2017-01-03 10:57:17 [CELL/0] OUT Starting health monitoring of container
2017-01-03 10:57:19 [CELL/0] OUT Container became healthy

尽管这些信息表明应用程序已经更新，但我仍然看到应用程序的旧版本正在被提供

编辑

使用

-v

参数运行命令后，我发现失败的原因是网关超时：

RESPONSE: [2017-01-03T13:32:39+01:00]
HTTP/1.1 504 Gateway Timeout
Connection: close
Content-Length: 176
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: text/html
Date: Tue, 03 Jan 2017 12:32:39 GMT
Expires: 0
Pragma: no-cache
Strict-Transport-Security: max-age=15768000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Vcap-Request-Id: 3ac831ef-e70b-4f4e-7c56-e308806f039e
X-Xss-Protection: 1; mode=block

<html>
<head><title>504 Gateway Time-out</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx</center>
</body>
</html>

FAILED
Error processing app files: Error uploading application.
Server error, status code: 504, error code: 0, message:

响应：[2017-01-03T13:32:39+01:00]
HTTP/1.1 504网关超时
连接：关闭
内容长度：176
缓存控制：无缓存，无存储，最大年龄=0，必须重新验证
内容类型：text/html
日期：2017年1月3日星期二12:32:39 GMT
过期日期：0
Pragma：没有缓存
严格的交通安全：最大年龄=15768000；包含子域
X-Content-Type-Options:nosniff
X帧选项：拒绝
X-Vcap-Request-Id:3ac831ef-e70b-4f4e-7c56-e308806f039e
X-Xss-Protection:1；模式=块
504网关超时
504网关超时
nginx
失败
处理应用程序文件时出错：上载应用程序时出错。
服务器错误，状态代码：504，错误代码：0，消息：

这是cloudfoundry特有的还是与Swisscom AppCloud相关？是否存在固有的超时限制

您可以使用

-v

运行

cf push

，或启用cf\u跟踪以查看CLI与cf端点的更多交互。
错误消息类似于：云控制器无法及时完成请求，将API请求路由到云控制器的路由器没有再等待，并将504（网关超时）返回到CLI

跟踪应该告诉您哪个API调用超时。
CLI在那里中止了该操作，而云控制器最终可能已成功完成该操作

我原以为CLI将在此处执行以下操作：

发送应用程序中的文件列表及其校验和以进行资源匹配（这样它就可以跳过上传CC从上一次推送缓存的未修改的应用程序位）

上传应用程序文件

（重新）启动应用程序（包括登台）

轮询&等待应用程序实例返回其正在运行

根据您的CLI输出，我假设第一次操作超时，因此不清楚您的应用程序是如何重新启动的。

非常感谢。长篇大论揭露了来源。请参阅我问题中的编辑。我们已经知道原始消息返回了504网关超时。接下来有趣的是接收到504的API请求。您没有将其包括在跟踪中：在504响应之前记录了什么请求？（如果是对资源匹配API的调用，您可以排除长负载）非常感谢您的支持！我是从根目录而不是build/dist文件夹上传的。这导致了超时。您的应用程序有多大，它在上传helloclass fe develop时挂起多长时间…并且您是否向CF提供商测试了带宽？可能只是因为你的应用程序上传时间太长。正如@dkoper提到的，gorouter对所有传入请求都有一个硬超时。默认值为900s，但您的提供商可能会将其设置为更大/更小的值。如果您对跟踪输出中的请求/响应日期头进行一些计算，您应该能够看到它等待了多长时间，以及是否会超时。非常感谢您的支持！我是从根目录而不是build/dist文件夹上传的。这导致超时。。