前
今天遇到一个很有趣的问题,如何找到一个网站的真实IP,来获得可能存在的实际地区等信息。
目前的站点为了安全多半都是接入了CF/或者其他云服务商的代理服务,用来进行源站的保护。域名直接解析出来的是CF的边缘节点的地址,或者其他CDN的CNAME。 看起来拿到真实IP不大可行。
但是有一点,互联网上[……]
今天遇到一个很有趣的问题,如何找到一个网站的真实IP,来获得可能存在的实际地区等信息。
目前的站点为了安全多半都是接入了CF/或者其他云服务商的代理服务,用来进行源站的保护。域名直接解析出来的是CF的边缘节点的地址,或者其他CDN的CNAME。 看起来拿到真实IP不大可行。
但是有一点,互联网上[……]
自古CF出好物,在使用了CF免费的 mail proxy 非常爽的时候,新产品又免费了。
Cloudflare 出品的一个反向代理的产品 Cloudflare Tunnel。大厂品质值得信耐。
在[……]
之前辛辛苦苦折腾的 K8S 集群由于是在是太重了,感觉没有很好的运营起来,导致被最后一堆交错的问题劝退。
后面偶尔看到了 K3S这个东西,自己孤陋寡闻,以为又是国人搞得什么山寨项目(笑)
后面偶然机会去仔细看了下,发现真是个好东西,对K8S基本能做到全部兼容,自己拿来用是足够了。
全部的依赖都在二进[……]
今天在图书馆偶遇了一本书,书名就是上面写着的《每天5分钟玩转Kubernetes》,让我想到了之前在IBM社区里面看到的一个五分钟openstack的系列。看着书篇幅不大,就一百来页,所以就随手翻翻,也作为自己对K8S的入门,后面没准整站的系统需要从Swarm向K8S迁移了。
由于属性SWARM所以使用类比的方法,可以很好的理解K8S的设计。整本书大概花了7个?番茄时钟翻完。之前选择Swarm由于Docker本身就包含了这个组件,简单易得。这本书看完之后,发现K8s很多特性解决了现在的问题,结论是k8s更加优秀,比如在卷管理的地方,之前Swarm如果要实现的话需要用上NFS,就很麻烦,而K8S默认的就是多节点同步。等等的特性后面再写吧。迟早换。
[……]
这部书老早的都该翻完了,结果因为各种的使其overdue。另外,关于这本书,实际上并不是《代码整洁之道》,二更是偏向于后面的程序员职业修养的部分。其中的内容呢,更多的是作为工作中的“指南手册”。让我想到前面的一本书《时间管理–写给系统管理员》,里面写的是在工作时候的事情处理,以及一些情况的应对。
所以,这篇文章给这本书收个尾。
[……]
为每一个服务直接注册一个子域名,虽然干净利落,但是肯定没有直接改Nginx的配置来的快。想实现的功能呢?就是直接通过不同的路由路径直接进行不同端口的反向代理,但是经过尝试之后,发现,并没这么简单
[……]