Vps

本文永久链接 – https://tonybai.com/2024/11/07/exploring-caddy Go语言诞生十多年来，社区涌现出众多优秀的Web服务器和反向代理解决方案。其中，最引人注目的无疑是Caddy和Traefik。这两者都为开发者和系统管理员提供了更简单、更安全的现代化Web服务器和反向代理部署选项。尽管它们的目标略有不同，Caddy最初旨在满足开发者快速搭建反向代理的需求，特别关注配置的简易性，并在后期增加了自动HTTPS和全面的API支持；而Traefik则更强调云原生架构，适合基于微服务的应用，尤其是使用Docker或Kubernetes部署的场景，提供动态服务发现和灵活的路由能力。 我于2015年首次体验了开源发布的Caddy，其超简单的配置确实给我留下了深刻的印象。之后也一直关注着Caddy的发展，Caddy在支持通过ACME协议自动为服务的域名获取免费HTTPS证书的功能后，Caddy就被我部署在自己的VPS上，为Gopher Daily等站点提供反向代理服务，运行十分稳定。Caddy这一为域名自动获取免费HTTPS证书的功能是其简化站点部署初衷的延续，也为Caddy赢得的广泛的用户和赞誉，并且这一特性不仅使得Caddy在个人项目和小型部署中大受欢迎，也让它在企业级应用中占有一席之地。 ...

我们见到的Go包的导入路径常常以github.com、bitbucket.org等代码托管站点的域名为前缀，这样的包导入路径有一个问题，那就是当Go包的托管站点发生变更时(比如从github.om迁移到bitbucket.org或gitlab.com)，该包的使用者需要更新包的导入路径。当然，在支持go module+GOPROXY的情况下，如果使用者不再升级包版本，他/她完全可以继续使用原包导入路径，但这仅是特例。 还有一些包的导入路径并非以知名代码托管站点域名作为前缀，比如：Go官方扩展包text，它的包导入路径是golang.org/x/text，这种包导入路径被称为vanity import path，字面义是虚荣心导入路径，即以个人或组织官方域名作为前缀的包导入路径。采用vanity import path的包避免了包迁移对包使用者的影响。包使用者完全无需关心包的实际存储位置是在github上还是在bitbucket上或是私有服务器上。同时将vanity import path作为包的权威路径(canonical import path)，也方便go get等对包权威路径的检查，避免包路径变更的前后不一致。 ...

2020年1月28日，Linux之父Linus Torvalds正式将WireGuard merge到Linux 5.6版本内核主线： 图：WireGuard被加入linux kernel 5.6主线的commit log ...

时光荏苒。转眼间女儿已经成为一名小学生了，依稀还记得当年果果呱呱坠地的情景，独自回味，感慨万千。 果果3岁前，都是我来记录她的生活点滴和成长历程，那个时候她是我们生活舞台的主角。3岁后，果果学会了说话，上了幼儿园，开始学习各种知识、技能以及各种才艺。尤其是在幼儿园中班之后，她学会了写字、组词、造句和写日记，果果完全可以自己用文字来表达自己了! 我觉得是时候让她自己来记录她的成长历程了，我和她妈妈只是辅助和指导就好了。这种想法日益迫切，尤其是果果今年上了小学后，果果的成长更快了。我觉得迫切需要给她一个平台去表达她自己和记录她的成长。传统手段不能满足需求，于是我就想到给她搭建了一个博客站点，辅助她用网络文字、图片的形式记录自6岁上学之后的成长历程。于是这个周末就花了些时间，给女儿搭了一个博客站点。 ...

Go语言号称面向工程：对工程目录组织、代码风格（gofmt）、文档（生成）都制定的相应的“标准”，并提供了相应的工具帮助开发者满足这些工程specs。 gofmt用于格式化代码，形成统一代码风格。 godoc.org用于查看标准库或repo的doc。 go-talks.appspot.com则是用来查看go slide。 ...

在国内开发微信公众号、企业号以及做前端开发的朋友想必对ngrok都不陌生吧，就目前来看，ngrok可是最佳的在内网调试微信服务的tunnel工 具。记得今年春节前，ngrok.com提供的服务还一切正常呢，但春节后似乎就一切不正常了。ngrok.com无法访问，ngrok虽然能连上 ngrok.com提供的服务，但微信端因为无法访问ngrok.com，导致消息一直无法发送到我们的服务地址上，比如xxxx.ngrok.com。 这一切都表明，ngork被墙了。没有了ngrok tunnel，一切开始变得困难且没有效率起来。内网到外部主机部署和调试是一件慢的让人想骂街的事情。 ...

自从2012年初将Blog从Blogbus搬出来放到同事代理的虚拟主机上后，Blog运行一直很稳定，我也算 是比较满意。但同事的主机代理生意这两年来每况愈下，这促使他在前些时候做出了在今年年末放弃这门生意的决定，于是我又不得不为Blog另找落脚儿地了。 ...

目前的Blog托管在同事的一个共享主机上，由于种种原因，这个主机即将无法使用，我只能再次迁移我的WordPress，不得不感叹：铁打的Wordpress，流水的主机啊！ 这次迁移前，我仔细考量了一番，如何能让以后可能出现的Wordpress迁移最简化呢？虽然现在的迁移也不是特别复杂。我想到了近期研究的 Docker。目前很多国外的VPS都已经支持了Docker，我只需要在本地制作好Docker容器导出，再导入目标VPS的Docker中即可完成迁 移。在真正做迁移前，我打算在实验环境下测试一下。以下是将Wordpress迁移到Docker容器的测试过程。 ...