使用 KubeDB 托管 PostgreSQL 在 Kubernetes 上部署 FerretDB 实战指南
后端数据库文档数据库【免费下载链接】FerretDBA truly Open Source MongoDB alternative项目地址https://gitcode.com/gh_mirrors/fe/FerretDB点击查看免费下载FerretDB 是一款开源文档数据库它在 PostgreSQL 之上提供 MongoDB 兼容能力让开发者可以继续使用熟悉的 MongoDB 语法与命令而数据实际存储在 PostgreSQL 中。本指南以 KubeDBKubernetes 生态中流行的数据库生命周期管理工具为入口完整演示如何在 Kubernetes 集群中通过 KubeDB 托管 PostgreSQL 作为后端一键部署 FerretDB 实例并完成从获取凭据、mongosh连接、CRUD 操作到 PostgreSQL 侧数据验证的端到端流程。读完本文你将掌握两种部署形态由 KubeDB 全托管 PostgreSQL 的集成部署以及接入集群内外部自管 PostgreSQL 的解耦部署。为什么在 Kubernetes 上用 KubeDB 跑 FerretDB过去几年Kubernetes 已成为生产级数据库的主流部署平台。像 KubeDB 这类工具将数据库的供给provisioning、监控、升级、自动扩缩容、备份以及故障检测等运维任务自动化显著降低了在 Kubernetes 上运行有状态服务的门槛。FerretDB 的架构决定了它天然适合这种模式它是一个代理 翻译层式的服务对外暴露 MongoDB Wire Protocol对内通过 PostgreSQL 连接串将文档操作映射为 SQL 执行。因此一个可用的 FerretDB 实例至少需要两个组件FerretDB 服务本身提供27017端口的 MongoDB 协议监听PostgreSQL 后端存储全部文档数据。在 cmd/ferretdb/main.go 中可以看到FerretDB 服务端通过--postgresql-url对应环境变量FERRETDB_POSTGRESQL_URL指定后端 PostgreSQL 连接串默认值为postgres://127.0.0.1:5432/postgres而 MongoDB 协议监听地址默认为127.0.0.1:27017。KubeDB 正是把这两者的供给、编排与生命周期管理统一收编进了 Kubernetes 的声明式资源体系——通过一个FerretDB类型的 Custom ResourceKubeDB 会自动创建 FerretDB 的 StatefulSet 以及配套的 PostgreSQL 集群。与直接编写原生DeploymentService参考 website/docs/installation/ferretdb/kubernetes.md 中的基础示例相比KubeDB 方案额外获得了数据库级别的运维能力持久化存储编排、高可用副本、备份与恢复、监控集成等因此更适合对数据库 SLA 有要求的场景。前置条件开始之前请确认以下环境已就绪Kubernetes 集群可以是本地 Minikube、Docker Desktop 自带的 Kubernetes或任意云厂商托管集群AppsCode License集群 IDKubeDB 需要企业版许可先向 AppsCode 申请申请时会要求提供集群 IDHelm用于安装 KubeDB OperatorkubectlKubernetes 命令行工具用于应用资源与排查状态mongoshMongoDB Shell用于连接 FerretDB 执行数据操作。第一步获取集群 ID申请 AppsCode License 需要先拿到集群 ID。执行下面的命令kube-system命名空间的 UID 即为集群 IDkubectl get ns kube-system -o jsonpath{.metadata.uid}拿到该 ID 后到 AppsCode 的许可签发页面完成 License 申请并将 License 文件保存到本地后续 Helm 安装命令会用到它的路径。第二步通过 Helm 安装 KubeDB使用 Helm 以 OCI 仓库方式安装 KubeDB关键点有两个一是通过--set-file global.license传入 License 文件二是通过--set global.featureGates.FerretDBtrue显式开启 FerretDB 特性门控helm install kubedb oci://ghcr.io/appscode-charts/kubedb \ --version v2024.2.14 \ --namespace kubedb --create-namespace \ --set-file global.license/path/to/the/license.txt \ --set global.featureGates.FerretDBtrue \ --wait --burst-limit10000 --debug注意请务必将/path/to/the/license.txt替换为第一步申请到的 License 文件实际路径否则安装会失败。安装完成后验证 KubeDB 各组件 Pod 是否正常运行$ kubectl get pods --all-namespaces -l app.kubernetes.io/instancekubedb NAMESPACE NAME READY STATUS RESTARTS AGE kubedb kubedb-kubedb-autoscaler-5c97c8c7f9-lw64s 1/1 Running 0 11m kubedb kubedb-kubedb-ops-manager-7b8fc4d7bf-28qk4 1/1 Running 0 11m kubedb kubedb-kubedb-provisioner-6c89ddd5d8-fw24w 1/1 Running 0 11m kubedb kubedb-kubedb-webhook-server-6fc6c8b44f-pwdvr 1/1 Running 0 11m kubedb kubedb-sidekick-86c64c8f59-gvzd8 1/1 Running 0 11mKubeDB 会随安装注册多组 CRDCustom Resource Definition其中就包含FerretDB。可用下面的命令列出全部 CRD Group 进行确认kubectl get crd -l app.kubernetes.io/namekubedb第三种使用 KubeDB 托管 PostgreSQL 部署 FerretDB创建独立命名空间为 FerretDB 及其全部关联对象创建独立命名空间便于资源隔离与统一管理kubectl create namespace ferretdemo编写 FerretDB 自定义资源接下来创建 FerretDB 的 Custom Resource。将以下内容保存为ferret.yamlapiVersion: kubedb.com/v1alpha2 kind: FerretDB metadata: name: ferret namespace: ferretdemo spec: version: 1.18.0 storageType: Durable storage: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi backend: externallyManaged: false terminationPolicy: WipeOut各字段含义如下spec.versionFerretDB 镜像版本。KubeDB 在本文写作时对应 FerretDB v1.18.0仅支持该版本升级版本前请确认 KubeDB 的版本支持矩阵spec.storageType: Durable使用持久化存储而非内存型保证数据落盘spec.storage定义持久卷的访问模式ReadWriteOnce与容量1Gi实际大小可按需调整spec.backend.externallyManaged: false声明 PostgreSQL 后端由 KubeDB 一并托管创建这是本节的默认形态spec.terminationPolicy: WipeOut删除该 CR 时同时清理后端数据测试环境常用生产环境建议评估Retain等更保守的策略。应用该资源kubectl apply -f ferret.yamlKubeDB 会据此自动创建 FerretDB 及其全部附属对象StatefulSet、Service、PostgreSQL 集群等。验证部署结果查看ferretdemo命名空间下的全部资源$ kubectl get all -n ferretdemo NAME READY STATUS RESTARTS AGE pod/ferret-0 1/1 Running 0 4m42s pod/ferret-pg-backend-0 2/2 Running 0 5m15s pod/ferret-pg-backend-1 2/2 Running 0 5m10s pod/ferret-pg-backend-arbiter-0 1/1 Running 0 5m1s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/ferret ClusterIP 10.111.78.151 none 27017/TCP 5m18s service/ferret-pg-backend ClusterIP 10.99.57.62 none 5432/TCP,2379/TCP 5m18s service/ferret-pg-backend-pods ClusterIP None none 5432/TCP,2380/TCP,2379/TCP 5m18s service/ferret-pg-backend-standby ClusterIP 10.108.28.132 none 5432/TCP 5m18s NAME READY AGE statefulset.apps/ferret 1/1 4m42s statefulset.apps/ferret-pg-backend 2/2 5m15s statefulset.apps/ferret-pg-backend-arbiter 1/1 5m1s NAME TYPE VERSION AGE appbinding.appcatalog.appscode.com/ferret kubedb.com/ferretdb 1.18.0 4m42s appbinding.appcatalog.appscode.com/ferret-pg-backend kubedb.com/postgres 13.13 5m1s NAME VERSION STATUS AGE postgres.kubedb.com/ferret-pg-backend 13.13 Ready 5m18s从输出中可以清晰看到 KubeDB 的编排结果statefulset.apps/ferretFerretDB 本体1 副本通过service/ferret27017/TCP对外提供 MongoDB 协议statefulset.apps/ferret-pg-backend与ferret-pg-backend-arbiterKubeDB 托管的 PostgreSQL 高可用集群主从 仲裁者版本 13.13通过5432/TCP对外提供 SQL 服务appbinding与postgres.kubedb.com/ferret-pg-backendKubeDB 的应用绑定与 PostgreSQL 资源记录状态均为Ready。再单独确认 FerretDB 资源本身的状态$ kubectl get ferretdb -n ferretdemo ferret NAME NAMESPACE VERSION STATUS AGE ferret ferretdemo 1.18.0 Ready 9m6sSTATUS为Ready即表示部署成功。通过port-forward暴露本地访问集群内service/ferret是ClusterIP类型本地无法直接访问。先列出 KubeDB 创建的相关 Service$ kubectl get service -n ferretdemo | grep ferret ferret ClusterIP 10.111.78.151 none 27017/TCP 11m ferret-pg-backend ClusterIP 10.99.57.62 none 5432/TCP,2379/TCP 11m ferret-pg-backend-pods ClusterIP None none 5432/TCP,2380/TCP,2379/TCP 11m ferret-pg-backend-standby ClusterIP 10.108.28.132 none 5432/TCP 11m将ferretService 的27017端口转发到本地kubectl port-forward -n ferretdemo svc/ferret 27017从 Secret 中获取连接凭据通过mongosh连接前需要拿到数据库凭据。KubeDB 会自动将ferret服务使用的凭据以 KubernetesSecret的形式保存。先确认相关 Secretkubectl get secret -n ferretdemo | grep ferret其中ferret-pg-backend-auth保存了 PostgreSQL 后端的用户名与密码用下面两条命令解码echo $(kubectl get secret -n ferretdemo ferret-pg-backend-auth -o jsonpath{.data.username} | base64 -d) echo $(kubectl get secret -n ferretdemo ferret-pg-backend-auth -o jsonpath{.data.password} | base64 -d)输出即为连接 FerretDB 时使用的username与password。使用mongosh连接 FerretDB连接串格式如下其中authMechanismPLAIN是 FerretDB 对接 PostgreSQL 用户体系时的认证机制mongosh mongodb://username:passwordhost:27017/ferretdb?authMechanismPLAIN实际连接效果mongosh mongodb://postgres:p.i~glw7q9mdbpQ2localhost:27017/ferretdb?authMechanismPLAIN Current Mongosh Log ID: 662699b8fa65a75337cb3ec7 Connecting to: mongodb://credentialslocalhost:27017/ferretdb?authMechanismPLAINdirectConnectiontrueserverSelectionTimeoutMS2000appNamemongosh2.2.2 Using MongoDB: 7.0.42 Using Mongosh: 2.2.2 ------ The server generated these startup warnings when booting 2024-04-22T17:09:13.234Z: Powered by FerretDB v1.18.0 and PostgreSQL 13.13 on aarch64-unknown-linux-musl, compiled by gcc. 2024-04-22T17:09:13.235Z: Please star us on GitHub: https://github.com/FerretDB/FerretDB. 2024-04-22T17:09:13.235Z: The telemetry state is undecided. 2024-04-22T17:09:13.235Z: Read more about FerretDB telemetry and how to opt out at https://beacon.ferretdb.io. ------ ferretdb几点值得注意连接信息显示Powered by FerretDB v1.18.0 and PostgreSQL 13.13说明客户端实际连接的是 FerretDB而非真正的 MongoDB 服务启动警告中的 telemetry 状态默认undecidedFerretDB 会在运行一段时间后才决定是否上报匿名使用数据。仓库源码中通过--telemetry参数枚举undecided/enabled/disabled控制参见 cmd/ferretdb/main.go 与 ferretdb/ferretdb.go 中可嵌入模式的Telemetry配置项提示符进入ferretdb即表示连接成功可以开始执行 MongoDB 风格的数据操作。版本说明本文对应的 KubeDB 集成版本为 FerretDB v1.18.0v1.x 时代后端基于 PostgreSQL 的 pjson 存储方案数据库名称为ferretdb。当前 FerretDB 主线仓库已演进至 v2.x后端改用 PostgreSQL 的 DocumentDB 扩展相关 schema 约定见 internal/documentdb/documentdb.go服务端入口与FERRETDB_POSTGRESQL_URL等配置项保持一致。实操时请以所用 KubeDB 版本支持的 FerretDB 版本为准并参阅仓库根目录 CHANGELOG.md 了解版本演进。数据操作演练插入、更新与查询连接成功后先向weather集合插入一条天气记录验证写路径db.weather.insertMany([ { date: new Date(2024-04-22), location: { city: New York, country: USA, coordinates: { lat: 40.7128, lon: -74.006 } }, weather: { temperature: 18, conditions: Cloudy, wind_speed: 12, humidity: 80 }, remarks: Possible light rain in the evening. } ])接着演示条件更新更新纽约地区风速大于 10 km/h 记录的湿度字段。这里用到了嵌套字段路径location.city、weather.wind_speed与$gt比较运算符、$set更新运算符db.weather.updateMany( { location.city: New York, weather.wind_speed: { $gt: 10 } }, { $set: { weather.humidity: 85 } } )执行结果返回标准的 MongoDB 风格写入确认对象{ acknowledged: true, insertedId: null, matchedCount: 1, modifiedCount: 1, upsertedCount: 0 }最后用db.weather.find()读取数据确认更新已生效humidity已从 80 变为 85_id为 FerretDB 自动生成的 ObjectIdresponse [ { _id: ObjectId(66278976fba61a5fec8bad82), date: ISODate(2024-04-22T00:00:00.000Z), location: { city: New York, country: USA, coordinates: { lat: 40.7128, lon: -74.006 } }, weather: { temperature: 18, conditions: Cloudy, wind_speed: 12, humidity: 85 }, remarks: Possible light rain in the evening. } ]深入验证数据真实落在 PostgreSQLFerretDB 的承诺是文档操作透明落库。为验证这一点直接进入后端 PostgreSQL 容器查看数据。先 exec 进ferret-pg-backend-0并连接ferretdb数据库% kubectl exec -it -n ferretdemo ferret-pg-backend-0 -- bash -c psql -d ferretdb在 PostgreSQL 中将SEARCH_PATH设为ferretdb模式列出全部表ferretdb# set SEARCH_PATH to ferretdb; SET ferretdb# \dt List of relations Schema | Name | Type | Owner -------------------------------------------------------- ferretdb | _ferretdb_database_metadata | table | postgres ferretdb | weather_36404793 | table | postgres (2 rows)可以看到两张表_ferretdb_database_metadata元数据表与weather_36404793对应weather集合的数据表。查询该表内容ferretdb# SELECT * FROM weather_36404793;返回的结果是一条 JSONB 记录其中不仅包含原始文档字段还带有$s模式描述信息完整记录了每个字段的 BSON 类型如objectId、date、string、int、double这就是 FerretDB 在 PostgreSQL 中无损保存 MongoDB 文档类型语义的实现方式。humidity字段值已更新为 85与mongosh侧看到的完全一致。至此一条数据从mongosh写入、经 FerretDB 翻译、最终持久化到 PostgreSQL 的完整链路得到验证。第四种接入外部托管的 PostgreSQL上面演示了由 KubeDB 全托管 PostgreSQL 的集成形态。如果你的团队已经维护了一套 PostgreSQL 集群例如跨集群或由其他 Operator 管理FerretDB 也可以直接对接只需将backend.externallyManaged置为true并指向外部服务。YAML 配置如下同样部署到ferretdemo命名空间apiVersion: kubedb.com/v1alpha2 kind: FerretDB metadata: name: ferretdb-external namespace: ferretdemo spec: version: 1.18.0 authSecret: externallyManaged: true name: ha-postgres-auth storageType: Durable storage: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi backend: externallyManaged: true postgres: service: name: ha-postgres namespace: ferretdemo pgPort: 5432 terminationPolicy: WipeOut与托管模式的差异点集中在两个字段spec.authSecret声明认证 Secret 由外部管理。authSecret.name指向访问外部 PostgreSQL 时使用的认证 Secret 名称本例为ha-postgres-auth需要你自行在集群中预先创建好该 Secretspec.backend.externallyManaged: truespec.backend.postgres.service声明后端 PostgreSQL 不归 KubeDB 创建而是指向集群内已存在的服务。spec.backend.postgres.service.name、namespace、pgPort分别指定外部 PostgreSQL 的 Service 名称、所在命名空间与服务端口默认 PostgreSQL 端口为 5432。在这种形态下KubeDB 只负责编排 FerretDB 本体及其持久化存储PostgreSQL 的供给、备份、高可用等职责仍由外部系统承担。该模式适合已有成熟 PostgreSQL 运维体系、希望把 FerretDB 作为接入层叠加到现有数据库之上的场景。总结与建议本文完整走通了两种在 Kubernetes 上运行 FerretDB 的路径KubeDB 托管 PostgreSQL一个FerretDBCR 即可让 KubeDB 同时编排 FerretDB 与高可用 PostgreSQL 集群获得存储编排、凭据管理自动生成 Secret、健康检查等开箱能力适合快速起步外部 PostgreSQL通过backend.externallyManaged与authSecret.externallyManaged对接既有 PostgreSQL 服务适合已有数据库资产、需要统一接入 MongoDB 协议的场景。无论哪种方式客户端视角下 FerretDB 都表现为一个标准的 MongoDB 兼容服务27017端口、mongosh连接、insertMany/updateMany/find等 API 全部可用而数据最终沉淀在 PostgreSQL 中。在实际投入生产前建议关注三点确认所部署 FerretDB 版本与 KubeDB 的兼容矩阵版本更新记录可参阅仓库 CHANGELOG.md按数据安全要求设置合理的terminationPolicy在生产环境显式配置 telemetry 策略仓库源码中可通过--telemetry参数关闭匿名上报。赞分享后端数据库文档数据库【免费下载链接】FerretDBA truly Open Source MongoDB alternative项目地址https://gitcode.com/gh_mirrors/fe/FerretDB点击查看免费下载相关推荐JDK HotSpot 反汇编插件 hsdisCapstone、LLVM、binutils 三大后端的构建与使用实战指南JDK HotSpot 反汇编插件 hsdisCapstone、LLVM、binutils 三大后端的构建与使用实战指南 本文围绕 JDK 仓库中的 hsdi后端数据库文档数据库掌握 GitHub Copilot CLI 技能系统用 SKILL.md 打造可自动匹配的领域专家掌握 GitHub Copilot CLI 技能系统用 SKILL.md 打造可自动匹配的领域专家 本篇技术指南以 awesome copilot 仓库中 c后端数据库文档数据库OpenReplay 自托管 PostgreSQL 18 容器实战非 root 用户、fsGroup 与 Kubernetes 部署全指南OpenReplay 自托管 PostgreSQL 18 容器实战非 root 用户、fsGroup 与 Kubernetes 部署全指南 本指南以 Open可观测性开发工具前端后端创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

相关新闻

LSTM编码+层次聚类的无监督文本分析实战

LSTM编码+层次聚类的无监督文本分析实战

简介:本资源是一个面向人工智能初学者与Python开发者实践深度学习文本处理的轻量级工具包,聚焦文本分类与无监督聚类两大核心任务,适用于舆情分析、文档归档、智能客服语义分组等实际场景。压缩包共24个文件(61KB)&…

2026/9/23 21:56:51 阅读更多 →
抖音企业号后台入口全解析:手机端与电脑端管理路径指南

抖音企业号后台入口全解析:手机端与电脑端管理路径指南

企业号后台没有那么神秘,先搞清楚它藏在哪几步就够了做抖音企业号运营的人,十有八九都遇到过同一个尴尬:明明已经认证了企业号,可真要进去看看数据、改改主页、挂个组件的时候,对着手机屏幕能戳半天,愣是找…

2026/9/23 21:55:50 阅读更多 →
CDL调色交接全解析:从原理到实战,打通片场到成片的色彩链路

CDL调色交接全解析:从原理到实战,打通片场到成片的色彩链路

干过调色或者跟DIT打过交道的人,应该都遇到过这个场景:现场传来一个后缀是.cdl的小文件,导演那边等着看样片,剪辑那边等着上时间线,但把这文件拖进软件里一看,里面不是调好色的画面,而是几行数字…

2026/9/23 21:55:50 阅读更多 →

最新新闻

Flutter数值映射库num_remap在鸿蒙开发中的应用与优化

Flutter数值映射库num_remap在鸿蒙开发中的应用与优化

1. Flutter 三方库 num_remap 鸿蒙适配实战指南在 OpenHarmony 生态中开发动态交互应用时,数值范围映射是个高频需求场景。无论是处理传感器数据、手势操作还是动画效果,都需要将原始数据转换为适合 UI 展示的数值范围。传统的手写映射代码不仅冗长难维护…

2026/9/24 0:01:25 阅读更多 →
Lss-bev IndexPut插件:前端高效索引操作实践

Lss-bev IndexPut插件:前端高效索引操作实践

1. 项目背景与核心价值Lss-bev系列插件作为现代前端工程化体系中的重要组成部分,其IndexPut模块的部署实践直接影响着数据索引操作的性能表现。在实际项目中,我们经常遇到需要高效处理大规模索引更新的场景,而传统方案往往面临以下痛点&#…

2026/9/24 0:01:25 阅读更多 →
JSP+JDBC+MySQL+Servlet图书管理系统实战:从源码部署到性能优化

JSP+JDBC+MySQL+Servlet图书管理系统实战:从源码部署到性能优化

简介:面向Java Web初学者,这份图书管理项目源码以图书信息增删改查为主线,完整整合了JSP、JDBC、MySQL与Servlet技术栈,演示了从页面展示、请求处理到数据库读写的基本路径,适合用来理解MVC分层与原生Web开发流程。压缩…

2026/9/24 0:01:25 阅读更多 →
Lombok与JDK版本冲突引发NoSuchFieldError:根因排查与修复指南

Lombok与JDK版本冲突引发NoSuchFieldError:根因排查与修复指南

如果你在某个平平无奇的下午执行mvn clean package,看到编译进度条卡在注解处理阶段,随之蹦出这么一行:java.lang.NoSuchFieldError: Class com.sun.tools.javac.tree.JCTree$JCImport does not have member field ...基本可以确认一件事&…

2026/9/24 0:01:25 阅读更多 →
面向对象综合训练:从图书管理系统掌握封装、继承与多态

面向对象综合训练:从图书管理系统掌握封装、继承与多态

面向对象学完语法之后,最尴尬的阶段就是“懂的都懂,一写就懵”。day09这个综合训练,说白了就是把前面封装、继承、多态、抽象这些概念,从“背概念”切换到“用概念”。这篇我把自己的练习过程完整拆开,从选题思路到代码…

2026/9/24 0:01:25 阅读更多 →
Windows系统安装全指南:从U盘启动盘制作到UEFI/GPT分区方案

Windows系统安装全指南:从U盘启动盘制作到UEFI/GPT分区方案

不管是给老电脑续命,还是给新装的机器做首次引导,Windows系统的安装都属于那种“看着简单,做起来全是细节”的活儿。我前前后后帮同事、朋友装了不下几十台机器,自己也因为手贱删错分区、改了引导方式导致安装失败过好多次&#x…

2026/9/24 0:00:20 阅读更多 →

日新闻

基于YOLOv8的渔船作业监控系统:从环境搭建到边缘部署全流程

基于YOLOv8的渔船作业监控系统:从环境搭建到边缘部署全流程

简介:这是一套面向计算机、人工智能、自动化等专业学生与教师的毕业设计级项目资源,围绕YOLOv8实现渔船作业监控系统,可用于毕设、课程设计、大作业或项目立项演示。压缩包共97个文件,约24.21MB,以70个Python源码文件为…

2026/9/24 0:00:19 阅读更多 →
单细胞注释实战:基于Scanpy的标记基因与参考映射流程解析

单细胞注释实战:基于Scanpy的标记基因与参考映射流程解析

简介:一份基于单细胞RNA测序数据的细胞类型注释算法研究Python毕业设计源码,针对计算机相关专业正在做毕设或需要项目实战的学习者,可用于课程设计与期末大作业。项目代码完整、经导师指导评审通过,可直接运行,覆盖数据…

2026/9/24 0:00:19 阅读更多 →
C#源生成器实战:用增量生成器替代反射,告别AOT崩溃

C#源生成器实战:用增量生成器替代反射,告别AOT崩溃

第一次在项目里被反射卡住,是在一个老旧的WinForms模块里:几十个类依赖PropertyChanged通知,运行时反射读属性、发通知,每次启动慢半拍不说,一上.NET Native/AOT裁剪模式几乎全面崩盘。后来我把这段逻辑全部改成C#源生…

2026/9/24 0:00:19 阅读更多 →

周新闻

Flutter for OpenHarmony游戏卡片渐变背景实战:从原理到性能优化

Flutter for OpenHarmony游戏卡片渐变背景实战:从原理到性能优化

直接铺开项目本身吧。这几个月我一直在折腾一件事:用Flutter给OpenHarmony做一款游戏集合类的App,说白了就是把若干小游戏塞进一个壳里,用统一入口分发。这个方向本身不算新鲜,真正让我花了不少心思的,是首页那堆游戏卡…

2026/9/23 4:55:02 阅读更多 →
Word表格编号全攻略:从列表编号到题注交叉引用

Word表格编号全攻略:从列表编号到题注交叉引用

写Word文档,最让人头疼的往往是那些“看起来不起眼”的小问题。比如表格编号这事:今天在表后面多加了两个空白行,明天给客户交稿前发现整个章节的编号全部错位,光是挨个改序号就能耗掉大半个下午。我前阵子帮人整理一份上百页的技…

2026/9/23 4:49:06 阅读更多 →
从第一个站到第二个站:独立开发者的静态网站选型与落地实践

从第一个站到第二个站:独立开发者的静态网站选型与落地实践

1. 项目概述1.1 核心需求解析做独立开发者这几年,说实话,第一个网站上线的那天晚上我兴奋得没睡着。但等它跑了半年,流量惨淡、功能臃肿、代码自己都懒得看第二遍之后,我才慢慢琢磨明白一个道理:第一个网站是练手&…

2026/9/23 9:53:41 阅读更多 →

月新闻

持续集成 流水线自动化与 声明式交付 实践:原型怎样变成可用功能

持续集成 流水线自动化与 声明式交付 实践:原型怎样变成可用功能

持续集成 流水线自动化与 声明式交付 实践:原型怎样变成可用功能分类:[AI/大模型]细分主题:AI 增强型 CI/CD 流水线自动化与 GitOps 实践:Agent 工作流、工具调用与任务拆解:从原型到生产的验收清单很多团队在尝试用大…

2026/9/23 9:53:40 阅读更多 →
容器编排 生产环境运维与排障实战:复盘记录怎样真正派上用场

容器编排 生产环境运维与排障实战:复盘记录怎样真正派上用场

容器编排 生产环境运维与排障实战:复盘记录怎样真正派上用场分类:[工程技术]细分主题:Kubernetes 生产环境运维与排障实战:可复制的项目复盘模板与决策记录大部分团队的事故复盘报告,最后都变成了躺在 Confluence 或钉…

2026/9/23 9:53:40 阅读更多 →
容器 容器化技术与镜像安全管理:核心链路应该先拆哪一步

容器 容器化技术与镜像安全管理:核心链路应该先拆哪一步

容器 容器化技术与镜像安全管理:核心链路应该先拆哪一步分类:[工程技术]细分主题:Docker 容器化技术与镜像安全管理:核心链路的逐步实现与关键代码取舍面对一个积累了五六年历史包袱的单体架构应用(包含 Web 接口、后台…

2026/9/23 9:53:40 阅读更多 →