Dokploy 部署 Ghost 博客

Dokploy 部署 Ghost 博客
Photo by Alexa Williams / Unsplash

我的博客站点是基于 Ghost 开源部署的,最初是用 Nginx + Docker 进行部署管理,后来接触到了 Dokploy,就把所有的服务都统一交由 Dokploy 部署了,体验很丝滑,本文介绍使用 Dokploy 部署 Ghost 博客的详细操作。

首先在 Dokploy 面板,创建一个 Project

CleanShot 2025-02-24 at 15.42.50@2x.png


CleanShot 2025-02-24 at 15.43.39@2x.png


因为 Ghost 直接就在 Dokploy 的模板市场里面,所以直接 Create Service -> Template

CleanShot 2025-02-24 at 15.44.06@2x.png

在模板市场,搜索 Ghost,然后创建

CleanShot 2025-02-24 at 15.45.23@2x.png


创建完成之后,可以看到已经展示在 Service 列表了,点击进入

CleanShot 2025-02-24 at 15.47.10@2x.png

直接点击 Deploy 即可,如果需要更改配置,在 Raw 里面进行 Docker 配置的修改即可。
在 Provider -> Raw 这里,将 url 改为最终要部署的线上地址,我这里是配置了我的自定义域名:

CleanShot 2025-02-24 at 21.08.35@2x.png

在 Domains 里面将自己的域名添加上去,关于自定义域名的配置,Dokploy 里面提供了比较详细的文档,点击进入

CleanShot 2025-02-24 at 15.50.20@2x.png


选择 ghost 的 service,将自己的域名填写到 Host 里面,并且打开 HTTPS 开关,选择 Certificate Provider 为 Let's Encrypt,这样就拥有了免费证书以及提供 HTTPS 服务的能力。

CleanShot 2025-02-24 at 20.58.49@2x.png

我的域名是在 Cloudflare 托管的,参考官方 Dokploy & Cloudflare 配置文档

CleanShot 2025-02-24 at 16.11.55@2x.png


在 Cloudflare 中添加相关的 DNS 解析即可。

CleanShot 2025-02-24 at 20.59.33@2x.png

在 SSL/TLS 中设置类型为 Full(strict)

CleanShot 2025-02-24 at 21.00.55@2x.png

📢 添加完自定义域名之后,记得需要重新部署一下(重新点击一下 Depoloy 按钮)才能更新域名!按上述流程配置好之后,Ghost 博客站点就可以访问了。

Read more

从事 SEO 12 年的大佬总结的要点

从事 SEO 12 年的大佬总结的要点

从事 SEO 12 年后,以下是我能想到的所有 SEO 技巧: 1. 在 H1、H2 和 URL 部分中使用主要关键词。 2. 停止追逐虚荣指标。流量固然重要,但转化率才是最重要的。 3. 内部链接可以将“几乎完成”的页面转变为表现最佳的页面。 4. 定期检查你的网站是否有坏链接,这是一个简单的 SEO 胜利。 5. Google Search Console 是您最好的朋友,使用它来重新优化排名在第 3-7 位的页面。 6. 90% 的反向链接应来自相关的高权威网站。 7. 速度决定一切——或许应该说,速度不足会扼杀一切。确保加载时间在 2 秒以内。 8. 持续更新内容将帮助你的页面保持更高的排名。 9. 使用 NLP

Pnpm 构建 Monorepo

Pnpm 构建 Monorepo

最近开始搭建 monorepo 的项目,了解到以下方案: * lerna 有强大完善的依赖管理和构建、打包发布流程,而且 v5 版本将 nx 与 lerna 整合了,提升了性能和速度 * 业界大多使用 lerna + yarn workspace 的方式来管理,yarn 用来管理依赖,lerna 用于管理发布 之前简单使用过 lerna ,不过再加上 yarn workspace , 学习容多、配置多又得折腾,太费劲🤪,暂时搁置。 最终尝试使用单一的 pnpm workspace + changesets 的方式来构建 monorepo,本身我就使用 pnpm 作为包管理工具,目前我的场景简单,pnpm 就已足够。 本文记录自己使用 pnpm workspace 搭建 monorepo

HTTP Web 缓存总结

HTTP Web 缓存总结

友情提示:缓存什么的,是完全依赖相关http header头信息来标记和判断的 缓存读取顺序: 首先读取本地缓存,如果条件满足就取本地缓存,否则往后走代理缓存,同理,条件满足就是从代理缓存取资源(可能存在多级代理缓存) 如果一条链路上的资源都不符合,那么就去源服务器获取 缓存优先级:Cache-Control > Expires > Etag > Last-Modified 缓存的分类和优先级 * 强缓存 状态码 200 (比如 200 (from cache)) * Expires 服务器下发的绝对时间,而判断的时候以浏览器时间为准,客户端和服务器有可能会不一样 * Cache-Control 相对时间,以客户端相对时间为准 * 协商缓存 状态码 304 * Last-Modified If-Modified-Since * Etag If-None-Match 强缓存优先级高于协商缓存,强缓存不会询问服务器,直接使用缓存。协商缓存会询问服务器关于文件的可用性 对于传输过程中的中间节点,本文都称为代理服务器,包括proxy、

关于 Webpack 使用 Babel 与 Vite 使用 ESBuild 的一些思考

关于 Webpack 使用 Babel 与 Vite 使用 ESBuild 的一些思考

虽然 Vite 是基于 esbuild 构建的,并且 esbuild 在构建速度上有显著优势,但 Webpack 目前并没有直接使用 esbuild 构建的原因涉及多个方面,主要是 架构设计差异、功能需求 和 兼容性 等问题。下面是一些关键的原因: 1. Webpack 的复杂性与扩展性 • Webpack 的高度可扩展性:Webpack 的设计目标是一个 高度可配置和可扩展的打包工具。它提供了丰富的插件和 loader 机制,支持各种复杂的构建需求(如代码分割、热更新、各种资源处理等)。这些功能要求 Webpack 必须具备更细粒度的控制能力,而 esbuild 的设计理念相对简化,主要关注高速构建和基本的模块转换功能。 • Loader 和 Plugin 系统:Webpack 的强大之处在于其 loader 和