本想着使用 Cloudflare 的容器做无服务应用部署。 折腾了10多个小时，还是无法验证部署服务的启动端口。 容器的部署没有想象中的那么简单，不是说在一个服务器上直接装一个 Docker 的引擎，就可以直接部署上去，没有问题。 无服务的容器部署相对来讲，可能出现的问题很多。 验证端口 同样的服务部署在 Docker 容器的纯服务器上就没有问题。     更糟糕的是服务一直起不来，查看日志，服务已经起来了，端口也是对的，地址绑定也没问题，但是容器的连接校验就是不对。 下面的日志显示的是 Spring Boot 的日志输出，因为他们的日志读取模式和普通的日志读取模式不一样， 查找起来很不直观。 冷启动 同时还有另外一个问题，就是容器的冷启动问题。 因为系统的访问量在短期之内不会有那么多的访问量，因此容器的在线时间会被设置在10分钟左右。 就是因为这个设置会导致容器的冷启动，意思就是说在10分钟以内容器的应用没有访问的话，容器会被停止运行。     比如说现在容器的运行状态就是Ready，不是 active。 作为 SpringBoot 的应用程序来讲，下一次接受访问的时候，容器会被启动，启动的时间会要好几分钟。 据说这样做的目的是为了节约使用费用，因为当没有访问的时候容器被停止，被停止的容器是不会被计费的。 我感觉这个调试上来就是很麻烦。 容器更新 在开发的过程中，我们会对同一个 Darker 的 image 进行多次同一版本多次推送。 因为程序代码的变化没有，所以在部署到容器上面去的时候，容器会默认为这次没有变化，然后整个容器不更新。 这个就给调试带来很大的麻烦，有时候甚至都不知道容器部署上去，到底有没有更新。     比如说我们这里已经推送过多次了，但是在版本这里还是显示 V1 的版本，没有办法检测更新的状态。 这个也是无服务容器更新的一个痛点。 正是因为有上面的这么多痛点，我们最终还是回归到普通的服务器容器部署模式。   https://www.isharkfly.com/t/cloudflare-container/2322

最近刷视频，正好因为是高考和中考，老会刷到孩子的学习问题。 更多的是很多孩子，因为成绩不好或者成绩不是非常理想，家长也非常崩溃。 我想说一下我们家的真实事情，事情过去已经有一段时间了，现在就感觉纯粹是当做好玩来说这件事情。 我和孩子妈妈都是硕士毕业，很多时候对孩子的成绩总感觉确实有点丧心病狂。     我们家也老大经常丢三落四，有一次是因为有一个材料是应该要从学校带回家的或者要按时交回给学校，学校老师的消息都邮件到我们邮箱了，但是孩子跟我说的是，嗯学校打印机缺纸了所以没有把东西带回家。 这么拙劣的谎言，作为家长，只要是没有丧失理智，基本上都会知道孩子在说谎。 说实话，当时我知道他在逃避责任，孩子妈妈了一句，“嗯，看来你们学校纸张还是比较紧张，要不然我们考虑捐点打印纸吧。” 我觉得当时我们的选择是尽量不要去拆穿孩子，给他一点缓冲的时间。 当孩子听到妈妈这么说的话，孩子说要不然我明天去学校找一下老师，再重新打印一份吧。 我和孩子说，那你明天去找老师再要一份，记得按时提交可以吗？ 说实话，哪怕是就这样提醒，孩子还是没有按时交作业，结果这门课老师给的成绩不高。 不过好在跟老师沟通以后，老师重新给了一次提交的机会，最后孩子还是按时把作业给交上去了拿到想要的成绩。 事情转机发生在半年之后，在有一天去接孩子的路上，孩子突然跟我这么讲的，爸爸，我觉得学校打印机好像是不缺纸。 我的回答是：噢，原来是这样啊，然后我就问孩子，那你当时说的话是对的吗？那孩子告诉我，嗯，好像不对。 然后我跟孩子说做作业和按时提交作业是你的日常责任，如果你需要爸爸，妈妈帮助你，我们可以一起努力，让爸爸妈妈一起帮你把我们该做的事情做好，可以吗？ 就是感觉非常释然，然后说好的，下次一定会记得按时交作业的。 在整个交谈的过程中，孩子和我们都全程在笑着说，其实很多时候不戳穿孩子往往是更好的一个选择。 教育 我觉得在中国的教育中，给孩子留给孩子反省的时间太少，社会、家庭、学校从来没给孩子一个喘息的机会。 其实孩子随着年龄的增大，他们对自己做的事情是有感触的，但是在当前的竞争环境下，家长也好，社会也好，学校也好，从来没有说孩子你应该慢一点，好好想想你该做的事情。 结果看到很多视频说的就是硬生生的把一个好孩子完全的逼向另一个极端。 每一个孩子的成长轨迹是不一样的，有些孩子智力发育的比较早，成绩会相对好一点了，但是人生就是一场马拉松，不是说你起跑跑得快，你人生最后是赢家。 当前的筛选机制也让很多家长没有太多的选择。 但是我想说的是孩子成绩不好，可能是每个孩子的发育轨迹不一样，只要智商在线的话，可能就是孩子比较晚熟，仅此而已。   https://www.isharkfly.com/t/topic/2319

Discourse 中开启 Discourse ID 服务，需要把 Discourse 升级到最新版。 以站点管理员身份进入管理员控制台，搜索关键字 Discourse ID 。     直接启用上面的配置就可以，不需要重启，也不需要重新构建。 随后使用浏览器的无痕模式，单击用户注册或者登录按钮。     页面中会看到提示登录 Discourse ID。 点击上面的按钮会网站导航到 Discourse 的官方界面：https://id.discourse.com/signup 如果在这个地方你已经注册了discourse ID 账号或者用户名的话，可以直接输入你的邮箱地址继续。 这个网站会发送一个验证码到你的邮箱地址。   输入验证码后单击继续。 在随后的界面中可以看到你注册的几个 discourse 社区。   点击上面的链接就可以返回到刚才的页面上，然后就已经登录了。 总结 Discourse ID 的目的是官方希望把用户名管理起来，其核心还是调用了 discourse 的单点登录。 但是这个单点登录和其他单点登录是分开的。 如果你是 discourse 站长管理员，建议开启这个功能，因为可能对一些其他的用户已经注册了discourse 的其他网站，那么他们也可以直接在你的网站上进行注册了。 https://www.isharkfly.com/t/discourse-discourse-id/2315

最早开始接触 AWS 是从S3对象存储开始的，这个已经都是快 20年了。 随着 AWS 的使用越来越深入，会发现 AWS 的很多配置设置的过于复杂和过于琐碎。 但是 AWS 非常擅长于宣传，他们给市场的说法是，AWS只是像乐高一样提供组件。 但是对很多公司来说，他们真正用不到AWS过多的功能，可能用的比较多的是存储、数据库以及一些计算能力。 就现在 AWS 配置来说，随便一个小的改动，可能会涉及到好多组件，对 AWS 自己来说，给人的感觉是很多东西他们自己内部其实都不怎么能通畅通信，很多团队只负责自己一小块，至于怎么跟其他团队去进行更好的有机整合，以及为客户提供更多的便利，他们不管。 正是基于这种考虑，最近在尝试使用 Cloudflare 的 R2 对象存储。     主要的还是因为最近在使用 Cloudflare 的无服服务计算。 只需要把代码推上去就可以提供服务，给人的感觉是非常方便，并不需要像AWS一样设置一大堆乱七八糟的，花了一两天的时间，还不知道自己要干什么。 而且对初始团队来讲，它的部署和解构非常迅速，价格也比 AWS 亲民，提供了足够的免费试用量。     正是因为这种考虑，于是尝试使用一下 R2 对象存储。 至少从界面来讲，把数据从 AWS 搬到 R 上面还是非常方便的，直接使用他们的数据合并工具，就可以把对象拉过来。 相对功能来讲，比如说在界面中移动文件夹，R2 没有提供这个操作，UI 上面的功能比 S3 要小一些。 对于应用来讲，如果是纯程序操作，并且需要使用 CDN 的话，我觉得是可以使用 R2 做一些替代性尝试。   https://www.isharkfly.com/t/cloudflare-r2-aws/2317

出现“点击链接正常，但刷新页面提示 404 Not Found”的原因是，您的 Vue 项目使用了 history 路由模式 。 当您在前端点击页面时，是通过 JavaScript 改变的 URL ；而直接刷新页面时，浏览器会向服务器（Cloudflare）请求真实的 URL，如果服务器找不到对应的文件，就会返回 404。 使用 Cloudflare Workers 您可以在 wrangler.toml (或 wrangler.jsonc) 配置文件中，直接加上 single-page-application 的配置，无需修改任何代码： [assets] directory = "./dist" # 或您的打包输出目录 not_found_handling = "single-page-application" # 关键配置：让找不到的页面回退到 SPA     这个配置参数很关键。 single-page-application 在 Cloudflare Workers 中处理 not_found (404) 取决于你的部署方式：是纯逻辑 Worker 还是带有静态资源的 Worker（如 Workers Sites / Pages / 绑定 Assets）。 如果你的 Worker 托管了前端应用（如 React/Vue SPA），你可以通过 wrangler.jsonc (或 wrangler.toml) 配置资源未找到时的处理行为。 在配置文件中添加 not_found_handling。 单页应用 (SPA) 模式 ，将未匹配的路径重定向到 index.html，交给前端路由处理。     SPA 在 Github 上有讨论。   https://www.isharkfly.com/t/cloudflare-worker-404-not-found/2309

这个问题出现再 Jenkins 多分支构建。 比如说我们现在有 2 个分支。     在没有创建 PR 的时候，Jenkins 的构建是 2 个，如下图：     随后，我们在代码库中创建一个 PR。     现在的问题是 Jenkins 将会删除原始分支构建，随后为 PR 创建一个构建。     我们希望不删除原始构建，因为这会导致在代码库中的详细界面中的构建错误。     解决 要解决这个问题的办法也很简单，在 Jenkins 针对这个代码的构建中，选择所有分支。     这样只要 PR 不合并，Jenkins 也会持续构建。   https://www.isharkfly.com/t/discuz-7-v5/2306

因项目有一个前端的部署需求，最开始的时候，我们是把前端构建在 Docker 容器中，然后使用AWS 的容器进行推送。 但我们感觉这样的部署方式实在太复杂了，而且就算我们使用了AWS的前端，在 DNS 层面，我们还是会使用 Cloudflare 的产品。 有一段时间用了Cloudflare 的 pages 这个产品，觉得在做文档技术文档上面还是非常方便的。 哪怕是一个比较复杂的 VUE 前端，使用 pages 其实也基本够了，后端只需要设置一下调用路由就可以与后端进行通信了。 本着继续扩展一下功能的想法，或者说希望能够对前端进行更多的控制，主要因为还是为扩展业务而准备，随后使用了下 workers 这个产品。     在集成部署方面，我们使用的是 Jenkins 推送构建代码，通过一天的调试，发现比使用容器快太多了。 workers 还提供了非常详细的访问参数，也提供了完整的访问日志。     对于免费版本每一天可以记录 20 万的事件，针对一些访问量不高的初创网站基本上也够了，如果觉得使用量不够的话，可以升级到付费版本。     记录可以升级到每一个月 2,000万 的事件，而且仅仅需要支付的费用是5 美元一个月。 在免费使用的额度上面，一直觉得 Cloudflare 比 AWS 要看的慷慨得多。 如果你有部署无服务前端的需求，真的是可以试一下 Cloudflare 的workers。   https://www.isharkfly.com/t/cloudflare-workers/2305

Cloudflare 是一个我比较喜欢的无服务前端部署工具。 对比 AWS 的无服务来说，cloud flare的部署非常方便。 如果你有一个文档库，同时你的文档是放在 GitHub上面的，你可以直接使用 Cloudflare 的 workers或者Pages直接把你的文档转换成网站。     对于项目的构建历史，Pages 是可以选择手动删除。 如果选择的是workers，那么在所有的部署历史中是无法手动选择删除。 根据官方的说法是 Cloudflare 保留最近的100个构建，因此也没有必要手动删除。 比较 Pages，workers提供了更加复杂和更加强大的功能。 同时也意味着 workers 的学习曲线更高。对于一些只是纯静态网页来说，使用 Pages 足够了，但是如果你想有更多的功能还是需要使用 workers。 而且 workers 是完全兼容 Pages 的，后期的扩展能力也更强，虽然学习曲线有一点陡峭，但是还是值得。 https://www.isharkfly.com/t/cloudflare-workers/2304

Anthropic 周五宣布，已收到美国政府指令，被迫对旗下最先进的两款AI模型Fable 5和Mythos 5实施全面访问限制。 美国商务部长卢特尼克致函Anthropic首席执行官Dario Amodei，将Fable 5和Mythos 5列入出口管制范围，限制对象涵盖美国境外的所有机构和个人，以及境内的所有外籍人士，包括Anthropic的外籍雇员。 针对商务部的这个管制而言，等于直接把这两个模型暂时摁住了，因为 Anthropic 自己也无法区分使用的人是否合规。 因为对人的限制来说，人是具有灵活性的，可以采用各种手段来伪造身份，规避限制。 所以通常在 IT 界使用的限制方式多是物理隔离的方式，根据你使用的计算机地理位置以及网络服供商的识别来确定使用的这台计算机在哪里，至于谁来使用计算机，通常技术层面很难去进行识别。 通过技术层面去识别使用的人，多是用户的账号和密码，但用户的账号和密码很多时候是可以伪造的。 使用电话号码的方式根本不可行，因为很多在美国的人，他可能不具有美国身份，但是他会拥有一张美国的电话卡。 对 Anthropic 来说，直接停用这两个模型是合规的唯一解决方案。 相信美国商务部也会认识到这个问题，但是就算美国商务部认识到了这个问题，为什么商务部还是要求 Anthropic 停用这两个模型？ 尤其是在现阶段 Anthropic 准备秘密 IPO，大模型的争夺愈演愈烈的关键时期做出这样的决定，还是美国政府感觉到 AI 的这个泡沫应该挤一挤或刹一下车了。 Anthropic 的逻辑也很简单，更强的模型为上市提供更强力的支撑，但是更强的模型意味着更强的监管。 为什么美国政府在这个时间点选择对 Anthropic 下狠手，给我的感觉不仅仅是因为模型强大的问题，模型强大和越狱只是技术上的说辞。     给人的感觉是美国政府更想敲打一下 Anthropic 这个企业。   https://www.isharkfly.com/t/fable-5-mythos-5/2962

怕是输入正确的用户名和密码，Jenkins 登录的时候都提示用户名和密码错误。 错误的信息为： The resource from “https://build.sharkdat.com/” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).     问题和解决 出现这个问题的原因是因为我们使用 Nginx 作为反向代理，反向代理使用的域名和 Jenkins 定义的域名不一样。 在 Jenkins 中，这个位置定义的域名必须要和反向代理使用的域名完全一致，才不会抛出这个错误。     修改上述域名后不需要重启就可以更新服务。   https://www.isharkfly.com/t/jenkins-firefox/10053