我已经成功部署了一个Google Cloud Run实例，该实例显示一个绿色的选中标记，并且我有一个地址可以访问该容器。我还可以看到日志显示uwsgi已启动。在本地尝试容器时，我可以在端口上访问它...
我怀疑系统的错误启动是由于以下原因造成的：
019-12-04T21：44：45.834539783Z容器沙箱限制：不支持 系统调用setsockopt（0x3,0x6,0x9,0x29eebd3f8794,0x4,0x0）。请参考 到https://gvisor.dev/c/linux/amd64/setsockopt以获得更多信息。
2019-12-04T21：44：45.834891693Z容器沙箱限制： 不支持的系统调用setsockopt（0x4,0x6,0x9,0x29eebd3f8794,0x4,0x0）。 请参考https://gvisor.dev/c/linux/amd64/setsockopt了解更多 信息。 2019-12-04T21：44：45.835166ZuWSGI http绑定 0.0.0.0:8080 fd 4 2019-12-04T21：44：45.841985Z生成uWSGI http 1（pid：3） 2019-12-04T21：44：45.844243Zuwsgi套接字0绑定到TCP 地址127.0.0.1:48977（端口自动分配）fd 3
有人对使容器在Cloud Run上运行有任何提示吗？
答案 0 :(得分：2)
很有可能，“不受支持的系统调用”日志实际上并未对您的应用程序造成任何问题。这些日志大多是警告，并且在大多数情况下，应用程序会回退到其他系统调用或选项以完成工作。
（许多Cloud Run用户在他们的日志中看到此警告，但是大多数情况下，他们的错误是由另一个问题引起的-但是此警告引起了他们的注意，因此他们倾向于认为这是根本原因。）
能否请您按照https://cloud.google.com/run/docs/testing/local的说明尝试在Docker上本地运行应用程序，并验证您的应用程序是否在本地启动正常？ （请在评论中让我知道）。
在这种情况下， console.log(
123456789..toString().replace(/(\d{3})/, "$1 ").replace(/(\d{1}$)/g, " $1")
)的0x9选项建议使用SO_DEBUG和SO_KEEPALIVE。我猜SO_DEBUG可能尚未实现。因此，如果您以调试模式运行WSGI服务器，也许尝试在prod容器中禁用它？
更新（2019年12月9日）：：setsockopt签名建议0x6 = SOL_TCP，0x9 = TCP_DEFER_ACCEPT。在这种情况下，我们的内部调查显示gVisor尚不支持set by uWSGI的setsockopt(0x4,0x6,0x9,..)选项。因此，我们已开始着手在gVisor中解决此问题。同时，此应用程序很可能无法在Cloud Run上运行。希望您稍后再试。
答案 1 :(得分：0)
在Cloud Run的故障排除文档中，我们看到名为“您的问题是由容器沙箱中的限制引起的吗？”部分。 （请参见here）。通过这些链接，我们发现容器在特殊的sandbox中运行，然后我们发现存在操作系统约束（限制）。在here之后，我们找到setsockopt()系统调用的这一行：
54 setsockopt Partial Support Not all socket options are supported.
我认为这是重点。容器中运行的代码正在进行setsockopt() OS系统调用，并传入gVisor运行时明确不支持/不允许的参数。我能想到的唯一解决方案是回顾运行容器的代码的逻辑，看看是否可以找到在哪里进行调用以及为什么进行调用。我们可能提供一些选择来避免这种情况。
答案 2 :(得分：0)
对不起，这不是一个完整的答案，但是我没有足够的“声誉”来发表评论！
更改我的DOCKERFILE以拉出图像google/cloud-sdk:latest之后，发生了完全相同的问题。我还没有找到一个很好的解决方法，但是我的应用程序运行得很好，除了我的日志因该警告而被发送垃圾邮件。我指出这一点是因为我相信此Docker映像中安装的应用程序之一是导致它的原因。