2017-01-03 23 views
1

Я пытаюсь развернуть приложение в облаке приложений Swisscom с консоли. Он не сообщает прогресс, пока в конце концов, 504 без объяснения сообщается:Развертывание не выполняется с помощью 504

Updating app helloclass-fe-develop in org UCID-Bern Team/space HELLOCLASS-TEST as [email protected] 
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 

Несмотря на те сообщения, которые были бы указывают, что приложение было обновлено, я по-прежнему вижу старую версию приложения.


EDIT

После выполнения команды с параметром -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: 

Является ли это что-то cloudfoundry специфичным или скорее связанные с Swisscom AppCloud? Существуют ли ограничения времени тайм-аута для облачных вычислений?

+0

Насколько велика ваша заявка, как долго она висит на 'Uploading helloclass-fe-develop ...' и проверили ли вы свою пропускную способность для своего провайдера CF? Возможно, ваше приложение слишком долго загружается. Как упоминал @dkoper, у gorouters есть жесткий тайм-аут для всех входящих запросов. Он по умолчанию равен 900, но ваш провайдер может установить его на что-то большее/меньшее. Если вы делаете какую-то математику в заголовках даты запроса/ответа из вывода трассировки, вы должны уметь видеть, как долго она ждет, и если это может привести к таймауту. –

+0

Большое спасибо за вашу поддержку! Я загружал из корневого каталога вместо папки build/dist. Это вызвало тайм-аут. – paweloque

ответ

2

Вы можете запустить cf push с помощью -v или включить CF_TRACE, чтобы больше узнать о взаимодействии CLI с конечной точкой CF.
Сообщение об ошибке похоже на https://github.com/cloudfoundry/cli/issues/1042: Cloud Controller не смог выполнить запрос вовремя, и маршрутизатор, который перенаправил запрос API в Cloud Controller, больше не дождался и вернул 501 (тайм-аут шлюза) в CLI.

След должен сообщить вам, какой вызов API был истек.
CLI прервал операцию там, в то время как Cloud Controller, возможно, успешно завершил операцию.

я бы подумал операцию консоли будет выполнять здесь:

  1. отправить список файлов в вашем приложении и их контрольные суммы для сопоставления ресурсов (так что он может пропустить загрузку неизмененных бит приложения, что CC кэшируются от предыдущего толчка)
  2. файлов приложений загружаемых
  3. (перо) запустить приложение (которое включает в себя постановку)
  4. опроса & ждать, пока экземпляр приложения не возвращает, что он работает

Из вашего вывода на CLI я предполагаю, что первая операция была отключена, поэтому непонятно, как было перезапущено приложение.

+0

Большое спасибо. Многозначность показала источник. См. Редактирование в моем вопросе. – paweloque

+0

Мы уже знали, что из первоначального сообщения был возвращен тайм-аут шлюза 504.Что было бы интересно увидеть далее, это запрос API, который получил 504. Вы не включили его в трассировку: что было запрошено в журнале до ответа 504? (вы можете исключить длинную полезную нагрузку, если это вызов API соответствия ресурсов) – dkoper

+0

Большое спасибо за вашу поддержку! Я загружал из корневого каталога вместо папки build/dist. Это привело к таймауту. – paweloque