个人网站与博客项目复盘：从 Docker 到 RKE2 的基础设施实践

发表于 更新于 分类于 阅读次数： Changyan：

我有一套自己从零搭建、长期在线运行的个人基础设施——个人网站（Docker + Nginx + Certbot + systemd + Cloudflare DNS，跑在 CachyOS 上）和技术博客（Hexo + Cloudflare Pages，Markdown + Git 工作流），并基于这…

适用岗位：运维工程师 / 技术支持工程师 / AI 运维工程师 / DevOps 工程师

一、项目速览

一句话版本：我有一套自己从零搭建、长期在线运行的个人基础设施——个人网站（Docker + Nginx + Certbot + systemd + Cloudflare DNS，跑在 CachyOS 上）和技术博客（Hexo + Cloudflare Pages，Markdown + Git 工作流），并基于这套经验在公司/个人仓库里落地了 RKE2 基础设施实践（cloudreve / n8n / dnsmasq / sftpgo）与完整运维文档。

我介绍一下我的个人网站和博客项目。个人网站 liuxp.eu.org 是我自己搭的：Docker 容器化部署、Nginx 反向代理、Certbot 证书自动续签、systemd 进程守护，DNS 走 Cloudflare，跑在一台 CachyOS（Arch 系）服务器上，至今在线运行。技术博客 nustarain.pages.dev 用 Hexo + NexT 主题，托管在 Cloudflare Pages 上，通过 Markdown + Git 的工作流持续更新，GitHub 和 Gitee 双平台托管。除了这两个站点，我还在公司/个人仓库里做了 RKE2 基础设施实践：cloudreve 云盘（带 aria2 离线下载）、n8n 工作流自动化、dnsmasq 内网 DNS、sftpgo SFTP 服务，配套的运维文档也在持续沉淀。对我来说，这套东西既是技术名片，更是我学习和实践 Linux/运维的真实战场——从域名、DNS、证书、反向代理、进程守护到 K8s 部署，整条链路都是我自己独立完成、长期维护的。

亮点关键词（供面试官抓取）：Docker / Nginx / Certbot / systemd / Cloudflare DNS / Cloudflare Pages / Hexo / NexT / RKE2 / cert-manager / Ingress / PVC / 运维文档 / Git

二、项目背景（动机）

回答”为什么做这个项目”时按以下顺序讲，三个动机层层递进：

  1. 学习 Linux/运维的实践场：简历里写了”自学 Markdown 语法、Git 操作，搭建了自己的博客站”。对我而言，网站和博客不是简历装饰，而是把书本知识变成真实验证的地方——DNS 怎么解析、证书怎么签、进程崩了怎么拉起来，这些只有亲手做一遍才记得住、才讲得出。
  2. 内容沉淀：写博客是输出倒逼输入。踩过的坑、排查过的故障，写下来既是对自己的复习，也是长期可查的知识库；用 Git 管理文章本身就是在练习版本管理习惯。
  3. 技术名片：域名、HTTPS、个人介绍页这些细节本身就是运维能力的证明。面试官可以真的访问——页面能打开、证书有效、站点稳定，比简历上写一百句”熟悉 Nginx”更有说服力。

从个人到团队：网站跑顺之后，我把同样的思路（部署、证书、反向代理、文档化）复制到 RKE2 基础设施上——cloudreve、n8n、dnsmasq、sftpgo，并沉淀为运维文档。这解释了”为什么一个个人网站能支撑运维岗位面试”：它不是孤立的玩具，而是一整套基础设施实践的开端。

三、完成情况（技术架构）

1. 个人网站 liuxp.eu.org

  • 定位：个人介绍页”终端小子”，标签：运维开发 · Linux 爱好者 · 开源贡献者 · RHCE
  • 部署：Docker 容器化部署
  • 入口：Nginx 反向代理（统一收口 HTTP/HTTPS 流量）
  • 证书：Certbot 自动续签（HTTPS 全程有效）
  • 守护：systemd 进程守护（开机自启 + 异常拉起）
  • DNS：Cloudflare DNS（域名解析，可开启代理加速/隐藏源站 IP）
  • 系统：CachyOS（Arch Linux 系，优化内核 + 滚动更新）

2. 技术博客 nustarain.pages.dev

  • 框架：Hexo 静态站点生成器 + NexT（Gemini）主题
  • 托管：Cloudflare Pages（无服务器、全球 CDN、免费额度）
  • 工作流：Markdown 写文章 → Git 提交 → 推送触发 Cloudflare Pages 自动构建发布
  • 托管：GitHub（lxp731）与 Gitee（nustarain）均托管（双备份 + 双触发）
  • 维护：持续更新

3. 附加基础设施实践（个人/团队可用）

  • cloudreve 云盘（k8s-services/cloudreve）：namespace / deployment / pv-pvc / service / ingress / cert-manager certificate 全套资源，并集成 aria2 做离线下载
  • n8n 工作流自动化：deployment / ingress / certificate / pvc
  • dnsmasq 内网 DNS：configmap + deployment + ingress + service（配置即代码）
  • sftpgo SFTP 服务：docker-compose + RKE2 两套部署方式，部署文档按日期记录（250410 / 250411 / 250414）
  • 运维文档：部署 RKE2、配置 HTTPS、LVM 扩容、2FA 等

四、负责内容

  • 全部独立完成：从 0 到 1 的架构选型、域名注册与 DNS 配置、服务器初始化、容器化部署、证书签发与续签、反向代理配置、进程守护、监控与故障处理
  • 长期维护：不是做完就丢——站点持续在线、博客持续更新、文档持续补充，把”维护”本身作为项目的一部分
  • 基础设施扩展：把个人网站的经验迁移到 RKE2 基础设施（cloudreve / n8n / dnsmasq / sftpgo），并产出配套运维文档
  • 内容输出：博客文章撰写、运维文档编写、开源项目双平台托管（GitHub lxp731 / Gitee nustarain）

五、完成成效

  • 持续在线运行：个人网站长期在线、HTTPS 证书持续有效、博客持续更新（面试官可访问验证）
  • 技术沉淀：博客文章（Markdown + Git 管理）+ 运维文档（RKE2 部署、HTTPS 配置、LVM 扩容、2FA），形成可复用知识库
  • 能力证明：Docker / Nginx / Certbot / systemd / Cloudflare / RKE2 / cert-manager / Ingress / PVC / 文档化，整条链路亲手做过并踩过坑

六、面试官提问与参考回答

第一组：基础问题（Q1–Q4）

Q1. 简单介绍一下你的个人网站和博客项目

  • 【面试官意图】考察表达是否清晰、是否真正了解自己写进简历的东西、有没有夸大。
  • 【参考回答】先讲定位，再讲技术。个人网站 liuxp.eu.org 是我的技术名片，一个个人介绍页，用 Docker 容器化部署、Nginx 反向代理、Certbot 自动续签证书、systemd 守护进程，DNS 在 Cloudflare，跑在 CachyOS（Arch 系）上。博客 nustarain.pages.dev 是内容沉淀，Hexo + NexT 主题，托管在 Cloudflare Pages，用 Markdown + Git 工作流维护，GitHub 和 Gitee 都托管了。另外我在公司/个人仓库里把同样的思路做到了 RKE2 基础设施上，cloudreve、n8n、dnsmasq、sftpgo 都有完整的部署配置和文档。
  • 【追问】
    • 追问 1：”网站和博客分别解决了你什么问题？” → 网站是实践场和名片，博客是知识库。网站逼我把部署、证书、反代、守护整条链路跑通；博客逼我把踩过的坑写下来，既复习也方便以后查。
    • 追问 2：”这两个项目里，哪部分是你最熟悉的？” → 最熟的是 Nginx 反向代理 + Certbot 证书这条链路，其次是 Cloudflare 的 DNS 和 Pages 构建流程，因为平时出问题最多的就是证书和反代。
  • 【岗位侧重】通用

Q2. 为什么自己搭网站/博客，不用 WordPress 或直接写掘金/CSDN？

  • 【面试官意图】考察选型逻辑和”要不要造轮子”的判断力——运维岗位很在意”有没有必要自己搞”以及是否了解现成方案。
  • 【参考回答】两个原因。第一，我的目标是练运维，不是单纯写文章——WordPress 虽然省事，但 PHP、数据库、面板这些不是我想要练的东西；自己搭意味着 DNS、证书、反代、守护进程每一步都要自己处理，这才是我的目的。第二，静态博客在成本、速度和维护性上更适合我：Hexo 生成静态文件，Cloudflare Pages 免费托管、全球 CDN，几乎没有维护成本。至于掘金/CSDN，那是分发渠道，不是知识管理——自己维护一个 Git 管理的博客，内容所有权和长期性都在自己手里。
  • 【追问】
    • 追问 1：”如果让你用 WordPress 部署，你会怎么做？” → 也是 Docker 起一个容器配 MySQL，Nginx 反向代理，Certbot 签证书，思路和现在完全一样——这说明选型是基于目标，不是只会一种方案。
    • 追问 2：”静态站点没有后端，评论和搜索怎么做？” → 可以接第三方评论服务或用轻量静态搜索方案；个人博客的搜索需求很低，静态搜索就够。这体现我知道静态站的边界在哪。
  • 【岗位侧重】通用 / 运维

Q3. 网站和博客分别用了什么技术栈？为什么这么选？

  • 【面试官意图】考察技术细节的真实性，面试官很可能现场访问验证。
  • 【参考回答】网站是 Docker 容器化部署，Nginx 反向代理，Certbot 自动续签证书，systemd 进程守护，DNS 走 Cloudflare，系统是 CachyOS。博客是 Hexo + NexT（Gemini 主题）生成静态站，托管在 Cloudflare Pages。选型逻辑是”够用 + 可控 + 低成本”：个人网站体量小，一个容器加反代就够，但整条链路都是生产级做法；博客是纯静态内容，Pages 免费、全球加速、Git 触发构建，维护成本几乎为零。
  • 【追问】
    • 追问 1：”网站为什么不用 Pages 这种托管，非要自己买服务器？” → 因为我要练的就是服务器运维本身——systemd、Nginx、证书续签这些只有在自己服务器上才碰得到；这也是个人网站和博客定位不同之处。
    • 追问 2：”Hexo 和其他框架比，为什么选它？” → 我用博客时 Hexo 生态成熟、主题多、上手快，Git 工作流顺畅；如果以后需要更复杂的交互，再考虑迁移到动态方案。
  • 【岗位侧重】通用 / 运维

Q4. 现在还在维护吗？平时是怎么维护的？

  • 【面试官意图】验证简历”至今仍在维护”这句表述；面试官极可能真的去访问网站和博客。
  • 【参考回答】在维护。维护分三块：一是站点健康——证书续签失败或服务异常要能及时发现和处理；二是内容——博客用 Markdown 写文章，Git 提交推送，Cloudflare Pages 自动构建，GitHub 和 Gitee 双托管；三是基础设施——比如仓库里的 sftpgo 这类服务有版本化的部署文档（250410/250411/250414 的部署记录），RKE2 相关配置和文档也在持续更新。
  • 【追问】
    • 追问 1：”你多久检查一次证书和站点？” → 证书靠 Certbot 定时续签任务加日志检查，站点在线靠定期访问和日志观察；不用每天盯，但要有手段确认它没问题，而不是等浏览器报错。
    • 追问 2：”最近一次维护做了什么？” → 面试前看一眼网站/博客/Git 提交记录，用真实记录回答（比如最近一篇文章、最近一次文档更新）；不要说跟记录对不上的内容。
  • 【岗位侧重】通用 / 运维

第二组：深入问题（Q5–Q10）

Q5. liuxp.eu.org 的整体架构是怎样的？为什么这么设计？

  • 【面试官意图】考察是否真的理解每个组件（Docker / Nginx / Certbot / systemd / Cloudflare）的职责，以及设计取舍。
  • 【参考回答】架构是：DNS 在 Cloudflare 解析，流量进到 CachyOS 服务器，Nginx 反向代理统一收口，把请求转发给 Docker 容器里的应用；HTTPS 证书由 Certbot 自动签发和续签；systemd 负责服务的开机自启与异常拉起。这么设计的核心是职责单一：Nginx 只做入口和代理，应用在容器里与宿主机隔离，Certbot 管证书生命周期，systemd 管进程生命周期。对我这个规模来说，这个组合是生产级实践的最小完备集——每一层都是真实生产环境会用到的东西。
  • 【追问】
    • 追问 1：”Docker 容器有 restart 策略，为什么还要 systemd？” → systemd 管的是宿主机侧的服务编排、开机自启，还能配合日志和定时任务；容器 restart 策略管的是容器内进程崩溃。两者层级不同，配合用更稳。
    • 追问 2：”Nginx 反代都配了些什么？” → HTTP 强制跳转 HTTPS、证书路径、代理转发头（比如真实 IP 透传）、静态资源缓存这些基础项。
  • 【岗位侧重】运维 / DevOps

Q6. Certbot 证书自动续签是怎么实现的？续签失败怎么办？

  • 【参考回答】Certbot 通过定时任务（systemd timer 或 cron）定期检查，证书到期前自动尝试续签。关键细节有三点：一是验证方式——我用基于 Nginx/webroot 的方式，续签前 Certbot 要能访问到验证文件，所以 Nginx 配置里要保证验证路径可达；二是续签成功后要 reload Nginx 让新证书生效，否则页面还在用旧证书；三是续签失败要能发现——看日志、看证书有效期告警，而不是等浏览器报错。
  • 【追问】
    • 追问 1：”webroot 方式和 DNS 插件方式有什么区别？” → webroot 要在 80 端口放验证文件，适合 80 端口可达的站点；DNS 插件通过修改 DNS 记录完成验证，适合不方便开 80 端口或域名在 CDN 代理下的场景。我的域名在 Cloudflare，两种方式都了解，实际用哪种取决于站点情况。
    • 追问 2：”续签失败你具体怎么排查？” → 第一步看 Certbot 日志；第二步确认 80/443 端口和验证路径是否正常；第三步手动跑一次 certbot renew --dry-run 复现问题；修好后再验证新证书确实被 Nginx 加载。
  • 【岗位侧重】运维 / DevOps

Q7. 为什么选 CachyOS（Arch 系）当服务器？滚动发行版当生产环境不担心吗？

  • 【面试官意图】考察对发行版差异的理解，以及”个人生产环境 vs 企业生产环境”的取舍判断——这是很好的压力转化点。
  • 【参考回答】选 CachyOS 的原因：一是我的主力系统就是 Arch 系，熟悉度最高，出问题能自己解决；二是 CachyOS 默认带优化内核和性能调优，个人服务器追求的就是可控和性能。关于滚动更新的风险我有清醒认识：个人站点没有企业级的稳定性和审计要求，我可以接受”更新后自己修”的代价，而且我习惯更新前快照、更新后验证。但如果是公司生产环境，我会选 Debian/Ubuntu 或 RHEL 系，用 LTS 和稳定的包管理——个人项目讲可控，企业讲可预期，这是两种不同的取舍。
  • 【追问】
    • 追问 1：”你会把 CachyOS 用到公司生产吗？” → 不会。公司生产环境用 RKE2 那套也是跑在标准 Linux 上，发行版选择以团队已有标准和稳定性为准，个人项目经验不能直接照搬。
    • 追问 2：”滚动更新出过问题吗？” → 更新后服务起不来的情况遇到过，处理方式是回滚快照或用 systemd 排查服务状态——这也是我熟悉 systemd 的原因之一。
  • 【岗位侧重】运维 / DevOps

Q8. Cloudflare Pages 托管 Hexo 博客的构建流程是怎样的？讲讲 Markdown + Git 工作流

  • 【面试官意图】考察对 CI/CD 和托管平台的理解，以及”从写到发布”全流程的熟悉度。
  • 【参考回答】流程是：本地用 Markdown 写文章，放在 Hexo 的 source 目录，Git 提交后推送到远端仓库（GitHub lxp731 和 Gitee nustarain 都托管了），Cloudflare Pages 检测到推送自动拉代码、装依赖、执行 Hexo 构建命令生成静态文件，然后发布到全球 CDN。整个过程是”提交即发布”，不需要手动部署。因为内容源是 Markdown，文章就是纯文本加 Git 历史，天然可备份、可回滚、可多人协作。
  • 【追问】
    • 追问 1：”构建失败怎么办？” → 看 Pages 的构建日志定位是依赖问题还是内容问题，本地先跑一遍 hexo clean && hexo generate 复现，修好重新推送。
    • 追问 2：”Pages 的构建命令和输出目录怎么配？” → 在项目构建设置里指定构建命令（比如 npm install && hexo generate）和输出目录（public），Cloudflare 按配置执行。
  • 【岗位侧重】DevOps / 通用

Q9. 你在公司/个人仓库里的 RKE2 基础设施（cloudreve、n8n、dnsmasq、sftpgo）是怎么做的？

  • 【面试官意图】这是从”个人玩具”到”可复用资产”的关键论据，考察 Kubernetes 资源的基本功。
  • 【参考回答】我在 k8s-services 仓库里用声明式的方式管理这些服务。以 cloudreve 云盘为例：namespace 隔离，deployment 跑主应用，pv/pvc 挂数据卷，service 做集群内访问，ingress 暴露外部访问，证书用 cert-manager 的 certificate 资源自动签发，另外集成了 aria2 做离线下载。n8n 类似，deployment + ingress + certificate + pvc。dnsmasq 做内网 DNS，用 configmap 管理配置，配置即代码。sftpgo 是 SFTP 服务，有 docker-compose 和 RKE2 两套部署方式，配套文档按日期（250410/250411/250414）记录了部署过程。
  • 【追问】
    • 追问 1：”cert-manager 的 certificate 和 ingress 是怎么配合的？” → certificate 资源声明域名和签发方式，cert-manager 自动向 CA 申请证书并生成 secret；ingress 的 TLS 配置引用这个 secret，证书到期前 cert-manager 自动续签并更新 secret，ingress 自动加载新证书。
    • 追问 2：”PVC 用的什么存储？数据备份怎么做？” → 取决于集群的存储类，个人环境可能用本地卷或 NFS；数据备份靠定期备份卷内容或数据库导出，这块在文档里有记录。
  • 【岗位侧重】运维 / DevOps / AI 运维（n8n 是工作流自动化，可往 AI Agent 编排方向延伸）

Q10. 讲讲你的运维文档？systemd 进程守护具体怎么用？

  • 【面试官意图】考察文档化能力和对 systemd 的实际掌握——运维岗位非常看重”能不能把操作沉淀成可复现的文档”。
  • 【参考回答】我沉淀了完整的运维文档：部署 RKE2、配置 HTTPS、LVM 扩容、2FA 等。写文档的原则是”照着文档能复现操作”——步骤、命令、验证方法都写清楚，因为文档是给未来的自己和同事看的。systemd 方面，服务器上的服务和容器都用 systemd 管理：写 unit 文件，配置开机自启（enable）和失败重启（Restart=on-failure），用 journalctl 看日志排查问题，证书续签也走 systemd timer。
  • 【追问】
    • 追问 1：”LVM 扩容这个场景，文档里是怎么写的？” → 磁盘空间不足时先看卷组剩余空间，扩展逻辑卷，再扩展文件系统；文档会把每一步命令和验证结果写出来，比如 lvextend、resize2fs，最后用 df -h 验证。
    • 追问 2：”2FA 文档讲的是什么场景？” → 服务器 SSH 登录开启两步验证（如 TOTP），文档覆盖安装、配置、恢复码保存，以及防止把自己锁在门外的注意事项。
  • 【岗位侧重】运维 / 技术支持（文档能力）/ AI 运维

第三组：刁钻 / 压力问题（Q11–Q14）

Q11. “就这？”——个人网站就是个介绍页，含金量在哪？

  • 【面试官意图】压力测试：看你会不会心虚、会不会被问倒，考察自我定位是否客观。
  • 【参考回答】我理解这个质疑，它确实不是流量型项目，我的定位也从来不是流量，而是”持续运营的基础设施实践场”。它的价值在三点：一是技术栈覆盖面——域名、DNS、证书、反代、容器、守护进程、托管平台，这条链路每一层都是真实生产环境要用的；二是真实运行——它不是 demo，是长期在线、证书持续有效、我持续维护的系统，出过问题、我修过；三是我把它扩展成了团队可用的资产——RKE2 上的 cloudreve、n8n、dnsmasq、sftpgo 和全套运维文档，这些是能直接支撑运维工作的。规模小我承认，但”亲手把整条链路跑通并长期维护”这个能力，恰恰是运维岗位最需要的。
  • 【追问】
    • 追问 1：”那它跟公司里跑着几百台服务器的运维有什么区别？” → 区别在规模和管理工具，不在原理——单机上的反代、证书、守护进程，在集群里对应 ingress、cert-manager、systemd/控制器，我在 RKE2 实践里已经在做这个迁移。
    • 追问 2：”如果重做一遍，你会改什么？” → 一开始就把监控和告警做上（证书到期提醒、站点探活），把更多服务迁到 RKE2 上练手——这就是我后续在做的方向。
  • 【岗位侧重】通用

Q12. 服务器被扫描/攻击过吗？怎么应对？

  • 【面试官意图】考察安全意识——暴露在公网的服务器一定会被扫描，答”没遇到过”基本等于没有安全意识。
  • 【参考回答】公网服务器被扫描是常态，我的做法是：第一，SSH 加固——禁用密码登录、只用密钥、关掉不必要的 root 密码登录；第二，部署 fail2ban 做失败尝试封禁，暴力破解超阈值自动拉黑 IP；第三，开启 2FA，仓库里有 linux_2FA 文档，记录的就是 SSH 两步验证的配置；第四，最小暴露——只开放必要端口，Nginx 收口，Cloudflare 代理模式下源站 IP 不直接暴露。我会定期看登录日志和失败记录，确认没有异常。
  • 【追问】
    • 追问 1：”fail2ban 是怎么工作的？” → 监控日志里的失败登录/访问模式，超过阈值就动态封禁来源 IP，同时配白名单避免把自己封了。
    • 追问 2：”你实际抓到过攻击吗？” → 主要是扫描和暴力破解尝试，fail2ban 日志里能看到封禁记录；真正的入侵没有发生过，因为攻击面收得小、密码登录关了。
  • 【岗位侧重】运维 / 技术支持 / AI 运维

Q13. 备份怎么做？服务器挂了/数据丢了怎么办？

  • 【面试官意图】考察运维最核心的素养之一——备份意识和恢复能力。
  • 【参考回答】我的备份思路是”内容层和配置层分开”。内容层：博客文章就是 Markdown 源文件，在 Git 仓库里，GitHub 和 Gitee 双托管，天然多份异地副本；云盘等有数据的服务，数据在 PVC/数据卷里，定期导出备份。配置层：所有部署配置都是声明式的、在 Git 仓库里（k8s-services），服务器挂了可以用仓库里的配置重建——这就是基础设施即代码的备份价值。恢复方面，静态站重建很快：重新部署容器或重新推送 Pages；有数据卷的服务恢复时间取决于数据量。
  • 【追问】
    • 追问 1：”有没有真正做过恢复演练？” → 静态站和部署类的恢复成本低，实际上通过 Git 重建过；数据库类的恢复做过导出和导入验证。按真实经历回答，面试前确认自己实际做过什么。
    • 追问 2：”3-2-1 备份原则了解吗？” → 三份副本、两种介质、一份异地。我的 Git 双托管接近这个原则，服务器数据卷的备份还有改进空间，这是我计划补上的。
  • 【岗位侧重】运维 / DevOps

Q14. 我现在访问 liuxp.eu.org 打不开/证书报错，你怎么解释”至今仍在维护”？

  • 【面试官意图】终极验证：简历说”至今仍在维护”，面试官可能现场访问；打不开时看你的反应——甩锅还是给出排查思路。
  • 【参考回答】先别慌，按顺序给排查思路：我先确认是我这边的问题还是网络/临时问题——自己访问一次，再看服务器状态（systemctl 服务状态、Docker 容器状态、Nginx 日志）、证书状态（certbot certificates 看是否过期）。可能的原因：服务挂了、证书过期、DNS 或 Cloudflare 侧临时异常。确认原因后按步骤恢复：服务挂了就 systemd 拉起或重启容器，证书过期就手动续签并 reload Nginx。如果面试官现场遇到，我会说明排查路径，并在面试后修复、给反馈。
  • 【追问】
    • 追问 1：”如果真是证书过期了，说明自动续签没生效，你怎么解释？” → 说明续签链路里有环节失效了，这正是我强调要看日志和加告警的原因——任何自动化都有失效的可能，运维的职责是让它可发现、可恢复；我会复盘是 timer 没跑、验证失败还是 Nginx 没 reload。
    • 追问 2：”你多久没访问过自己的网站了？” → 按真实情况回答，但无论多久，都要接上”我现在就去检查并修复”的动作。
  • 【岗位侧重】通用 / 运维 / 技术支持