阅心笔记

家里网络环境比较简单，网络相关的硬件也比较少，所以也没啥能折腾的，只有以下几个设备：联通光猫型号是中兴的 F657GV9-C，在没有联通没有下发动态密码时改了桥接。本来还想破解一下开telnet，后来想想把桥接的配置备份出来就行了，没啥特别的需求就不折腾了。软路由彻视的N4100，4核4线程，基础频率1.1g，最高频率2.4g，性能比网上这几年流行的J4125还要差，但比arm架构的强多了。主机有4个 Intel I226 的 2.5G 网口，自己买了8G内存和128G的msata，又加了一个内置风扇，本身发热就不大，和光猫一起丢弱电箱夏天也不用担心散热。不打算折腾虚拟机，直接装一个路由系统足够带千兆的带宽了，重点是一套下来也才四百块。AP，是TP-Link XAP5400GC，单 AP 放在房子中间基本就完全覆盖了物理连接： 光猫（改桥接） ...

- 阅读剩余部分 -

最近有个需求是通过 Harbor API 获取 image 的最新 tag，来发送提醒进行更新，于是简单研究了一下 Harbor 的API 用法。Harbor 是一个功能丰富、易用且安全的开源 Docker Registry 项目，专为企业级容器镜像管理而设计。主要特性包括：安全与合规性：Harbor 提供安全扫描和漏洞管理功能，自动扫描镜像中的漏洞并生成详细报告。多租户支持：为每个项目提供独立的命名空间，支持自定义角色，实现多租户镜像管理。多镜像源：支持镜像在多个 Registry 之间的复制、备份和迁移。直观界面：提供易用的图形界面，支持镜像的推送、拉取、删除、日志查询和配置管理。垃圾回收：定期清理不再使用的镜像，释放存储空间。可扩展性：架构设计支持功能扩展和插件添加。Harbor REST-API 的认证和用法Harbor的 R...

- 阅读剩余部分 -

AWS 会对每个 EKS 版本提供14个月支持，同时 AWS 会强制更新太旧的 EKS 集群，因此可能导致生产服务中断。要升级 EKS 集群，首先要注意以下事项：验证与应用程序关联的容器映像版本是否可用，主要是排除应用异常导致的干扰。检查集群所在子网有足够的可用 IP，可用IP不足也可能会导致 EKS 升级失败。检查 node group 配置中的最大不可用性节点数量，这个数量表示每次更新期间节点组中可以替换的节点数。在大规模集群中，设置为百分比更有利于提高更新的速度。一、升级EKS的检查工作EKS 不允许跨版本升级，在升级 EKS 集群之前需要做兼容性的检查：1.1 与 Kubernetes 相关的变更每一个版本的 EKS 都有一些 API 已被弃用。 因此需要检查特定版本更改的详细信息，需要参考 Kubernetes 的变更日志和...

- 阅读剩余部分 -

家里的路由器基本上折腾差不多了，用的是小厂家的x86工控机，硬盘也是捡的垃圾，想到自己时不时的升级/重启/异常断电，还是备份一下的配置文件比较稳妥。我用的路由系统的基于debian的VYOS rolling版本，折腾了半个月已经非常熟悉了，用起来比较爽也很稳定，基本满足自己的各种需求。系统自带了同步配置的功能,每次commit前会先同步配置，支持以下几种方式： http://<user>:<passwd>@<host>/<path> https://<user>:<passwd>@<host>/<path> ftp://<user>:<passwd>@<host>/<path&g...

- 阅读剩余部分 -

MongoDB的分布式架构是通过使用Sharding（分片）来实现的，使用MongoDB的sharding可以带来以下好处：横向扩展：通过添加更多的shard，MongoDB能够处理更大的数据集和更高的并发访问，提供更好的性能和可扩展性。高可用性：通过将数据复制到多个shard上，并使用复制集提供数据冗余和自动故障转移，MongoDB能够提供高可用性。负载均衡：Mongos路由请求到不同的shard上，从而实现负载均衡，避免单个shard成为瓶颈。一、分片集群组件在一个分片集群中，包含以下组件：分片(shards)，实际存储数据的节点。集群配置集(config)，存储整个分片集群的metadata信息。路由(mongos)，作为应用接入路由节点，是mongodb数据的入口。1.1 Shards每个shard是一个独立的MongoD...

- 阅读剩余部分 -

之前写了一篇 借助 CloudWatch 和 WAF 缓解 DDOS 攻击,经过实践发现了一些问题：在受到攻击时 Cloudwatch 产生存储和查询的费用都高获取详细攻击信息使用了较多的 log 查询，查询次数多、时间长通过 Cloudwatch 中日志统计攻击 IP ，获取 IP 比较慢，且不够准确发生攻击时产生的请求已经非常多了，将请求转换成日志在分析，不是经济和有效率的做法。查了一下 boto3 的文档，发现 Waf 已经提供了一个获取被频率限制 ip 的 api : get_rate_based_statement_managed_keys而且通过分析 sampled request : get_sampled_requests 可以获取攻击的域名。既然可以直接获取攻击 IP 和域名，Cloudwatch 的...

- 阅读剩余部分 -

先来几张图说明一下做这个的原因：一、前提条件需要使用以下几个服务：AWS WAF 启用全局频率限制、全局黑名单、启用 logging 输出日志AWS CloudWatch 存储日志，攻击检测，发送告警到SNSAWS SNS 触发Lambda相关功能AWS Lambda 发送通知，更新 AWS WAF 全局黑名单Amazon EventBridge 定期执行 Lambda函数，更新 WAF 黑名单1.1 AWS WAF 配置需要在 WAF ACL 中设置以下几项：创建一个 IP Sets 作为全局黑名单创建一个全局黑名单规则，如果 IP 在全局黑名单中则 block，并设置优先级最高根据业务需求创建一个全局频率限制规则，优先级仅次于黑名单规则启用 WAF 的 logging，设置 Logging destination 为 C...

- 阅读剩余部分 -

在使用Cloudflare CDN时，CDN传给后端服务器中只传递了有限的 http request hearder。其中只包含了非常简陋的 ip 信息，例如只有 CF-IPCountry ，不足以实现一个查询ip信息的api，要想实现查询ip详细信息需要借助 Cloudflare Workers 来实现。Cloudflare Workers 传入的 HTTP 请求都被称为 fetch 事件，fetch 事件中都包含一个 Request 接口实例,在这个 Request 实例中就包括了访问 ip 的详细信息通过访问 Request.cf 可以获得 Cloudflare 提供的请求信息，包含了 ip 的详细信息；访问 Request.headers 则可以获得访客的 HTTP headers，写一个简单的 Workers 处理一下...

- 阅读剩余部分 -