最新

嗨，HN， 我自己托管邮件基础设施，不依赖第三方工具来发送邮件。但在微服务架构中，管理所有的SMTP配置很快就变得令人厌烦。过了一段时间，我的凭据和设置总是散落在应用程序属性、bash脚本和环境文件中。 因此，我开发了Brieferl，这是一款应用程序，您可以在其中添加SMTP服务器，并通过一个简单的JSON负载通过单一API发送电子邮件。您还可以查看邮件发送的时间和地点的日志，以及消息的HTML预览。 我很想知道你们对此的看法。您可以仅用电子邮件创建一个免费账户，添加SMTP服务器和API密钥，然后开始发送邮件。（目前没有额外收费或付费计划） 这还处于早期阶段，虽然它已经可以正常工作，我最初是为自己开发的，但一个朋友告诉我他也很想使用这个，所以我想为什么不问问其他开发者的想法呢。 这是你们会使用的东西吗？有没有什么功能能让它对你们更有价值？还是说这是我一个人的感受？

Proxmox-GitOps 实现了一个自包含的 CI/CD 控制平面，专为 Proxmox VE 设计，能够从单一的代码库引导并在管理的 LXC 容器中递归管理自身。 <p>代码库：<a href="https://github.com/stevius10/Proxmox-GitOps" rel="nofollow">https://github.com/stevius10/Proxmox-GitOps</a></p> <p>演示（1分钟以上）：<a href="https://youtu.be/2oXDgbvFCWY?si=gSSACmVi0mO6v8xx" rel="nofollow">https://youtu.be/2oXDgbvFCWY?si=gSSACmVi0mO6v8xx</a></p> <p>架构</p> - 本地引导（`./local/run.sh`）启动一个 Gitea 实例和运行器，初始化管道，并创建一个初始的 PR。合并此 PR 将系统转变为自我管理；后续的提交将 Proxmox LXC 容器中的期望状态进行汇聚。 - 系统使用一个自包含的单一代码库，包含可重用的容器库。Ansible 负责针对 Proxmox 的资源配置，而 Cinc（Chef）则在声明性建模不足的情况下执行期望状态的汇聚和跨层编排。 <p>概念</p> - 递归自我管理：控制平面在管理的容器内执行，以最大化可重现性并最小化漂移。 - Git 作为当前期望状态：操作映射到标准的 Git 工作流（提交、合并、回滚），采用无状态管理模型。 - 基于约定的可扩展性：通过从库中复制容器定义、添加最小的食谱和 `config.env` 来添加服务；管道处理资源配置、配置和验证。 - 松耦合：容器保持独立可替换，并在没有手动后续操作的情况下继续运行。 <p>环境</p> - Proxmox VE 8.4–9.0，默认使用 Debian 13 LXC。 - 通过 Docker 进行本地引导；后续操作由代码库驱动。 <p>安装</p> - 在 `. /local/config.json` 中配置 Proxmox 凭据。 - 运行 `./local/run.sh` 来引导环境。 - 在 `localhost:8080/main/config` 的 Gitea 实例中接受初始 PR。 - 推送更改以触发 Proxmox VE 上的资源配置、汇聚和验证。 <p>权衡</p> - 递归引导增加了复杂性，以保持从代码库重建的语义和确定性行为。 - 在 Proxmox 9 上，更严格的令牌权限限制某些操作；自动化使用根上下文 API 访问，在令牌不足的情况下进行操作。

亲爱的国际社会，请倾听我们的痛苦与恐惧。我们邻国泰国如此无法无天，毫无尊重国际法，也缺乏对和平总统唐纳德·特朗普和东盟主席马来西亚的尊重。 #唐纳德·特朗普