我在CloudFoundry中运行docker容器。
几天后，实例崩溃并出现以下错误：
实例变得不正常：exec 失败：container_linux.go：348：启动容器进程导致"exec：\"/tmp/lifecycle/healthcheck\"：stat/tmp/lifecycle/healthcheck：没有这样的文件或目录">
事实：
- 运行状况检查类型设置为"端口">
- 崩溃后，应用程序重新启动并运行正常
- 它在不同的空间多次发生
- 它也发生在一次没有处理任何请求的开发实例上
问题：
- 这是什么健康检查？
- 为什么要执行此检查？
- 如何预防？
这是什么健康检查？
Cloud Foundry 平台可监控您的应用程序。 当它检测到应用程序已"崩溃"时，它将为您重新启动它。 我把"崩溃"放在引号里，因为这是一个模糊的术语。
平台将"崩溃"定义为不再响应平台发送的健康检查的应用。 有三种运行状况检查。
第一种是基于 pid 的健康检查，平台在其中监控进程以确保它继续运行。 如果进程退出，平台会将其解释为崩溃并重新启动应用。
第二种是基于端口的运行状况检查。 有了这个，平台可以确保您的应用程序正在侦听已分配的端口。 只要平台可以与该端口建立 TCP 连接，你的应用就被视为正常运行。
第三种是基于HTTP的健康检查。 这实际上将 HTTP 请求发送到应用程序的终结点。 这必须使用成功的 HTTP 状态代码进行响应，否则您的应用将被视为已崩溃。
部署到 CF 的每个应用程序都使用第一个运行状况检查。 除了第一次运行状况检查之外，绑定了路由的任何应用程序都将使用第二次或第三次运行状况检查。
您的应用程序似乎正在使用基于端口的运行状况检查，即 #2。
为什么要执行此检查？
完成此检查是为了让平台知道你的应用是否正常运行。 如果不是，平台将尝试通过重新启动失败的应用程序实例来采取纠正措施。
如果未运行第二次或第三次运行状况检查，平台只能根据应用的 pid 状态判断应用是否正在运行。 这为错误留下了很大的空间，其中进程可以启动但挂起或以其他方式无法实际完成其工作。 这些额外的运行状况检查允许平台检测更多故障场景并自动更正它们。
如何预防？
您真的不想阻止运行状况检查。 您可以将其关闭，但如前所述，这可能会使您的应用处于无法运行状态。
如果您确实要关闭它，请将运行状况检查设置为"处理"。 这告诉平台只执行上面的pid检查(即#1(。
例如：cf push --health-check-type process
在这种情况下，我建议您联系您的Cloud Foundry运营商，看看发生了什么。 运行状况检查失败的原因似乎与您的应用程序无关。 他们应该能够平台日志以更好地了解故障。
希望对您有所帮助！