在博客里面自己加上了wiki,需要进行一定程度上的访问控制。预想的效果,是使用referer
来进行来源的控制,但是出了些问题。所以就在这里记录一下。
[……]
工欲善其事,必先利其器
发现有时候看看书很是很专注的。多读读书,不知不觉学到的还是挺多的。这里偶软遇到一句话,记下来:
我觉得,他的人生非常令人羡慕。不是因为取得的成就,而是因为每个人生阶段,他都在干不一样的事情:年轻时是程序员,中年时是科学家,老年时是新能源企业家。美国总统特朗普也是这种情况:年轻时是房地产商,中年时变成电视明星(《学徒》一口气拍了十季),老年时变成了总统。人生就好像一次旅行,不同时期能够从事不同的领域,就好像看到了不同的风景,体验了不一样的人生。
[……]
由于自己的本地主机的情况发生了重大变化,本地的两主机小机器的使命算是完成了。所以,最后没办法不得不上云了。网站整体的内容和域名不作改变。
还好还好,基于 Docker 的部署,所以整体的迁移是相当相当的方便的。本来想着折腾好久要,最后发现,前前后后没到20分钟,就差不多搞定了,也顺便解决了之前部署中的一些BUG。这一篇,主要就是记录迁移过程中的各种操作,后面可以很方便的进行复用。
[……]
这本书好久之前以及借到手了,可是各种原因,又是迭代阅读法,反反复复好多次才给读完(翻了一遍)
喜欢就去追寻
互联网本来是安全的。自从有了研究安全的人之后,互联网就变得不安全了。
这本书更像一个案例集,里面写了各种各样的时间案例,以及解决方案。还有各种关于运维职业的思考。
大胆的往前走吧,一切皆有可能,唯独那些实现不了的,都是我们人的问题,无它。
[……]
上一篇已经很OK的部署了一个 wordpress 的stack跑在Swarm 的集群上面,现在还挺稳定的,比较开心。
不过为了追求更快更好的体验,和对页面体验的提升,这里就要进行大优化了。
因为描述一下现状,现在的中间的隧道节点是很可怜的 1M 带宽的机器,怎么把这个 1M 的带宽用好就是关键了。
这里先给个数据:站点的加载内容为 205k
1M 带宽其理论上下行总和速度 : 125k/s
理论传输时间:205/125=1.64s
实际上传输时间: 2.6s +- 0.5
Not Special ,It’s unique
[……]
在有了前面的 Docker 的 PaaS 的管理,在这里一切变得简单起来了,写好 Compose 的文件,一个简简单单的 stack deploy
就可以直接跑起了这个服务栈,美哉美哉。
而且作为一个综合的建站的项目,涉及到的东西,还是相当的多的,从前面的建站,到后面的优化部分,笔者也算是投入了比较多的时间,这里总结整个过程,以及各种遇到的问题。另外这里的 compose 的文件都是可以直接使用的。 意味着,你也可以很轻松的搭建起一个 基于 Docker 的 wordpress 平台
(你所看到的内容是笔者因为没有开自动保存,第二次敲上去的 ?)
[……]