CF_STAGING_TIMEOUT 用于使用 Cloud Foundry 在 Bluemix 上部署 Shiny 应用程序答案

【问题标题】：CF_STAGING_TIMEOUT for deploying Shiny app on Bluemix with Cloud FoundryCF_STAGING_TIMEOUT 用于使用 Cloud Foundry 在 Bluemix 上部署 Shiny 应用程序
【发布时间】：2021-02-27 04:30:53
【问题描述】：

我有一个按预期在本地运行的 Shiny 应用程序，我正在努力使用 Cloud Foundry 将它部署到 Bluemix。我正在使用this buildpack。

应用程序构建的默认暂存时间是 15 分钟，但这不足以安装 R 和我的应用程序所需的包。如果我尝试使用默认值推送我的应用程序，我会收到有关超时的错误：

Error restarting application: sherlock-topics failed to stage within 15.000000 minutes

我更改了我的manifest.yml 以增加暂存时间：

applications:  
- name: sherlock-topics
  memory: 728M
  instances: 1
  buildpack: git://github.com/beibeiyang/cf-buildpack-r.git
  env:
    CRAN_MIRROR: https://cran.rstudio.com
    CF_STAGING_TIMEOUT: 45
    CF_STARTUP_TIMEOUT: 9999

然后我还在推送之前更改了 CLI 的暂存时间：

cf set-env sherlock-topics CF_STAGING_TIMEOUT 45
cf push sherlock-topics

然后会发生应用程序尝试部署的情况。它在容器中安装 R 并安装包，但只需要大约 15 分钟（稍长一点）。当它在 15 分钟后到达第一个新任务（包）时，它会出错，但会出现不同的、可悲的是没有信息的错误消息。

Staging failed
Destroying container
Successfully destroyed container

FAILED
Error restarting application: StagingError

日志中没有任何内容，只有关于正在安装的库的信息，然后是Staging failed。

关于为什么它没有继续超过 15 分钟标记的任何想法，即使在我增加 CF_STAGING_TIMEOUT 之后也是如此？

【问题讨论】：

标签： r shiny ibm-cloud cloud-foundry

【解决方案1】：

平台操作员控制暂存超时和应用程序启动超时的硬限制。 CF_STAGING_TIMEOUT 和 CF_STARTUP_TIMEOUT 是 cf cli 配置选项，它们告诉 cli 等待登台和应用启动的时间。

请参阅此处的文档以供参考：

https://docs.cloudfoundry.org/devguide/deploy-apps/large-app-deploy.html#consid_limits

作为最终用户，不可能超过平台运营商设定的硬性限制。

【讨论】：

我一直在看这个页面！它说“更改 cf CLI 的超时设置不会更改 Cloud Foundry 服务器端作业（例如暂存或启动应用程序）的超时限制。您必须在清单中更改服务器端超时。”这意味着我的manifest.yml 文件，对吧？
不，manifest.yml 只是向 cf cli 提供配置的另一种方式。 “服务器端”意味着操作员需要改变这一点，通常是通过更新他们的 Bosh 清单并运行bosh deploy。作为用户，您无法进行这些更改。
嗯，男孩，那这行不通。也许我会尝试使用 Docker 映像来部署它。
@AlexeyChekanov 如果您只是达到暂存限制，您可以尝试使用 docker 映像。您可以使用cf local 构建一个，它是 cf CLI 的一个插件，它将使用 buildpacks 在 Docker 中本地生成图像。然后，您可以使用 cf push -o 将其部署到 CF。您还可以查看使用 pack 和 Cloud-Native Buildpacks。这些是下一代构建包，但也是相当新的，因此您需要检查您的构建包是否受支持。无论哪种方式，您都将拥有一个没有暂存时间的 docker 映像，因为一切都是预先构建的。
它将使用 Cloud Foundry 支持的“官方”构建包列表。您的 CF 实例可以添加其他构建包。您提到的swift_buildpack 不在官方列表中。没什么大不了的，你只需要-b 标志，当你告诉它在哪里获取构建包。 -b 参数的值可以是本地路径或下载 zip 的 URL，也可以是 Git 存储库的 URL。

【解决方案2】：

我遇到了同样的问题。我还尝试部署一个具有大量依赖项的 shinyR 应用程序。

诀窍是将num_threads 属性添加到r.yml 文件中。这肯定会加快构建时间。

这可能是一个样子：

packages:
 - packages: 
    - name: bupaR
    - name: edeaR
   num_threads: 8

【讨论】：