最近我搭建了一个自己的个人博客管理系统 Cloud Blog Platform。这个项目最初只是想做一个能够发布和管理技术文章的个人博客，但在实际实现过程中，我希望它不仅仅是一个能运行的网站，而是一个包含容器化部署、反向代理、数据库、持续集成、自动发布以及监控告警的完整 Web 项目。
项目代码托管在 GitHub：
https://github.com/zhouzhouu07/cloud-blog-platform
项目整体架构
项目采用前后端分离架构，前端使用 React 和 Ant Design，后端使用 Go 语言的 Gin 框架，数据存储采用 MariaDB，Nginx 作为整个系统的统一访问入口。
用户访问博客时，请求首先到达 Nginx。普通页面请求由 Nginx 转发到前端服务，接口请求则转发到 Gin 后端。Gin 负责处理文章、用户、分类、标签等业务逻辑，并通过内部网络访问 MariaDB。
所有服务都计划运行在 Docker 容器中，再通过 Docker Compose 统一管理。这样可以把前端、后端、数据库和 Nginx 的运行环境隔离开，同时减少直接在宿主机上安装大量依赖带来的维护问题。
除了博客本身，我还计划加入 Prometheus、Grafana 和 Alertmanager，用于采集服务器和应用运行指标、展示监控数据并进行异常告警。
因此，这个项目最终不仅是一个博客系统，也是一套比较完整的小型 Web 应用部署与运维环境。
云服务器环境
项目部署在 Alibaba Cloud ECS 上，操作系统使用 Rocky Linux。
服务器初始化阶段主要完成了系统更新、基础工具安装、Swap 配置、防火墙设置以及 Docker 环境准备。
由于云服务器资源有限，我额外配置了 Swap，避免后续同时运行多个容器时因为内存不足导致服务被系统直接终止。
基础环境完成以后，安装 Docker Engine 和 Docker Compose，并配置镜像加速。Docker 负责运行各个服务，Docker Compose 则负责统一管理容器、网络、端口、数据卷和服务依赖。
这样后续整个项目基本可以通过一套 Compose 配置完成启动和关闭，而不需要单独管理每一个服务。
Nginx 与反向代理
项目最先部署的服务是 Nginx。
一方面是为了验证 Docker 和 Docker Compose 环境是否正常，另一方面 Nginx 本身也是后续整个系统的流量入口。
实际部署中，我不希望前端、后端和数据库分别向公网暴露端口，而是让用户统一访问 Nginx。Nginx 再根据请求路径，将流量转发到对应的服务。
例如普通页面由前端负责，而 /api/ 请求则交给 Gin 后端处理。
这样做的好处是外部只需要访问 80 和 443 端口，后端服务和数据库可以继续运行在 Docker 内部网络中，整体结构更加清晰，安全性也更好。
后续域名和 HTTPS 也会统一配置在 Nginx 上。
Docker Compose 容器化部署
随着项目逐渐加入 React、Gin、MariaDB、Nginx、Prometheus、Grafana 等组件，如果每一个服务都手动执行 Docker 命令，维护成本会越来越高。
因此整个项目采用 Docker Compose 进行编排。
每个服务都有独立的镜像、容器和配置，同时通过 Compose 网络进行通信。例如 Gin 后端连接数据库时，可以直接使用 MariaDB 的服务名称，不需要经过服务器公网 IP。
这种方式能够减少端口暴露，同时让项目具有更好的可迁移性。如果以后更换服务器，只需要准备 Docker 环境，再将项目配置和持久化数据迁移过去，就可以重新启动整个系统。
服务健康检查
项目部署过程中，我还加入了服务健康检查。
一个容器处于 Running 状态，并不一定代表里面的应用真正正常。程序可能已经无法处理请求，但容器进程本身仍然存在。
因此后端服务会提供健康检查接口，Docker 可以定期请求这个接口，从而判断应用是否能够正常响应。
这个健康状态后续还可以和 Prometheus 监控结合起来，用于发现接口异常或者服务不可用的问题。
这也是我在这个项目中比较关注的一点：不仅要让服务运行起来，还要能够知道它是否真正处于正常状态。
Gin 后端
博客后端采用 Go 和 Gin 实现。
Gin 主要负责文章、用户、分类、标签和评论等功能，并向前端提供 RESTful API。
例如文章相关功能会包含文章查询、新建、修改和删除，后台登录则需要加入身份认证和权限控制。
数据库方面使用 MariaDB 保存文章、用户以及博客配置等数据。数据库不会直接向公网开放，而是只允许后端通过内部网络访问。
相比单纯写一个能够返回数据的接口，我更希望这个项目能够逐步加入日志、统一错误处理、身份验证和健康检查等更加接近真实 Web 服务的功能。
React 前端
前端使用 React 开发，并计划使用 Ant Design 构建后台管理页面。
博客前台主要负责文章展示、分类、标签和文章详情，后台则负责文章发布、修改、删除以及系统管理。
前端与后端通过 API 通信。开发完成以后，React 会被构建成静态文件，再由 Nginx 提供访问。
这种前后端分离方式可以让前端和后端分别开发和部署，同时也方便后续单独升级某一部分。
CI/CD 自动部署
博客系统运行以后，如果每次更新代码都需要手动登录服务器、拉取代码、重新构建镜像再重启服务，整个流程会比较繁琐。
因此项目后续计划使用 GitHub Actions 和 Alibaba Cloud ACR 实现自动部署。
代码提交到 GitHub 后，由 GitHub Actions 自动进行构建，并生成新的 Docker 镜像。镜像推送到 Alibaba Cloud ACR 后，服务器再拉取新版本镜像并重新启动对应服务。
这样后续更新项目时，主要操作可以简化为提交代码。构建、镜像发布和部署过程则尽量通过流水线自动完成。
这也是项目中“自动化运维”部分最重要的一环。
监控与告警
项目后续还计划加入 Prometheus、Grafana 和 Alertmanager。
Prometheus 主要负责采集服务器、Docker 容器以及应用本身的运行指标，例如 CPU、内存、磁盘、接口响应状态和服务存活情况。
Grafana 用于展示这些数据，方便直观看到服务器和应用运行状态。
Alertmanager 则负责处理告警。当 CPU、内存、磁盘或者服务状态达到设定条件时，可以主动发送通知，而不是等网站无法访问以后再手动排查。
这部分会让博客项目从单纯的“部署上线”进一步扩展到“持续运行和维护”。
当前实现进度
目前已经完成云服务器初始化、Swap 配置、Docker Engine 和 Docker Compose 安装、Docker 镜像加速、Nginx 容器部署以及基础健康检查。
接下来会继续完善 Gin 后端、MariaDB 数据库、React 前端以及 Docker Compose 完整编排。
在核心功能完成以后，再加入 GitHub Actions、Alibaba Cloud ACR、Prometheus、Grafana、Alertmanager，以及最终的域名和 HTTPS 配置。
项目总结
Cloud Blog Platform 最开始只是一个个人博客项目，但在不断完善的过程中，它逐渐成为了一个用于实践 Linux、Docker、Nginx、Web 开发和 SRE 运维思路的综合项目。
相比单独学习某一个工具，我更希望通过这个项目理解一个 Web 应用从代码开发，到容器化，再到云服务器部署、自动发布、监控和告警的完整过程。
后续我也会继续记录项目中的具体实现，包括 Docker Compose 编排、Gin 后端开发、Nginx 反向代理、CI/CD 自动部署以及 Prometheus 和 Grafana 监控等内容。
项目仓库：
Comments NOTHING