CloudFlare Container 折腾半天还是打算放弃

本想着使用 Cloudflare 的容器做无服务应用部署。

折腾了10多个小时,还是无法验证部署服务的启动端口。

容器的部署没有想象中的那么简单,不是说在一个服务器上直接装一个 Docker 的引擎,就可以直接部署上去,没有问题。

无服务的容器部署相对来讲,可能出现的问题很多。

验证端口

同样的服务部署在 Docker 容器的纯服务器上就没有问题。

更糟糕的是服务一直起不来,查看日志,服务已经起来了,端口也是对的,地址绑定也没问题,但是容器的连接校验就是不对。

下面的日志显示的是 Spring Boot 的日志输出,因为他们的日志读取模式和普通的日志读取模式不一样, 查找起来很不直观。

冷启动

同时还有另外一个问题,就是容器的冷启动问题。

因为系统的访问量在短期之内不会有那么多的访问量,因此容器的在线时间会被设置在10分钟左右。

就是因为这个设置会导致容器的冷启动,意思就是说在10分钟以内容器的应用没有访问的话,容器会被停止运行。

比如说现在容器的运行状态就是Ready,不是 active。

作为 SpringBoot 的应用程序来讲,下一次接受访问的时候,容器会被启动,启动的时间会要好几分钟。

据说这样做的目的是为了节约使用费用,因为当没有访问的时候容器被停止,被停止的容器是不会被计费的。

我感觉这个调试上来就是很麻烦。

容器更新

在开发的过程中,我们会对同一个 Darker 的 image 进行多次同一版本多次推送。

因为程序代码的变化没有,所以在部署到容器上面去的时候,容器会默认为这次没有变化,然后整个容器不更新。

这个就给调试带来很大的麻烦,有时候甚至都不知道容器部署上去,到底有没有更新。

比如说我们这里已经推送过多次了,但是在版本这里还是显示 V1 的版本,没有办法检测更新的状态。

这个也是无服务容器更新的一个痛点。

正是因为有上面的这么多痛点,我们最终还是回归到普通的服务器容器部署模式。