星空

背景MySQL的数据备份一直以来都是一个重要议题，近来我遇到了一些奇怪的事件，同时网络攻击也层出不穷，这让我更加认识到了MySQL数据备份的重要性。 目前，我在使用阿里云的RDS服务，无法进行物理备份，只能依靠mysqldump进行逻辑备份。然而，考虑到备份文件存放在本地磁盘的风险，一旦磁盘发生故障，备份工作就相当于无用功。 因此，我最终决定将数据库备份的SQL文件同时存储到阿里云的OSS对象存储和腾讯云的COS对象存储中。我在不同城市分别创建了不同的存储桶（Bucket），以最大程度地避免同一城市发生大规模故障的问题。这样做的目的是为了确保备份文件的安全性和可靠性。 具体使用了如下资源： 阿里云镜像仓库个人版 阿里云codeup(git仓库) 阿里云flow(持续集成) 阿里云OSS 腾讯云COS 备份脚本准备备份脚本是执行mysqldump 循环将对应数据库的数据以单个文件存储，shell如下： 1234567891011121314151617181920212223242526DB_HOST=""DB_PORT=""DB_U...

前言 最近在鼓捣一些奇奇怪怪的东西，例如waf什么的，偶然发现了一款直接适配nginx的waf：长亭科技的雷池，能做一些基本的防护，而且是基于nginx的生态。 简单说下WAF是什么->WAF 是 Web Application Firewall 的缩写，也被称为 Web 应用防火墙。区别于传统防火墙，WAF 工作在应用层，对基于 HTTP/HTTPS 协议的 Web 系统有着更好的防护效果，使其免于受到黑客的攻击。 部署雷池雷池部署还是比较简单的，官方文档，直接使用docker-compose部署，由于默认的compose.yaml自建了postgres和redis，在实际使用中，我自己有外部的postgres和redis可用，所以将官方的compose简单改了改就直接使用了。 官方的docker-compose.yaml 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646...

前言 Chat gpt的出现改变了世界，但是对国内多有封锁，但是总是有很多能人来帮助我们解决各种各样的问题。 国内的AI模型发展也是如火如荼，很早之前就在试用星火大模型，一直想要做一个自用站，不需要每次登录，这篇文章简单记录一下自建web网页使用星火大模型api。 过程星火大模型API准备工作先注册一下讯飞星火，然后申请免费的API额度，拿到app调用的相关信息。 One Api 优秀的AI模型工具One Api是封装所有的AI接口，通过标准的 OpenAI API 格式访问所有的大模型，开箱即用。 访问one api 查看如何部署，我是用的docker-compose部署服务，并将其配置反向代理，具体的可以参考文档。 主要使用流程就是登录账号之后，先配置一个API渠道，例如星火API，然后再创建一个令牌，记住对应的KEY，然后在web页面中使用。 渠道配置： 令牌配置： ChatGPT-Next-Web 优秀的AI调用前端页面ChatGPT-Next-Web 一键免费部署你的跨平台私人 ChatGPT 应用。 这个项目的部署非常简单：1、先fork ChatGPT-Next-...

起因因为工作地点和房子地点不在一个城市，所以家里装了移动宽带并且装了摄像头，但是摄像头频繁掉线，所以怀疑有以下几点原因： 1、宽带本身不稳定，有频繁掉线现象，经过查文档和论坛，和移动宽带分配公网IP方式有关 2、摄像头使用的是WIFI连接，有可能是摄像头wifi连接有问题 今天主要是观察是否是宽带问题，目前宽带使用的是默认光猫拨号并且使用光猫连接路由器，路由器对外提供WIFI。 所以决定先将光猫改成桥接模式，让路由器自己来拨号并且提供WIFI功能 过程 需要先配置光猫改为桥接，然后路由器来拨号。 光猫配置因为自己不在家，所以请朋友帮忙来配置，配置的过程比较简单：1、找安装宽带的师傅，要超级管理员密码，说要换桥接2、找光猫后面的IP地址：例如192.168.1.1 输入超管的账号密码进入3、进入到这个页面4、记住图片里的内容，把原有的配置删掉，然后新建一个，将vlanid填进去，然后保存 路由器配置路由器配置就很简单，把路由器连上光猫的lan1，然后配置拨号上网，拨号成功就完事了。 总结就是简单记录一下，这篇文章写了一半，间隔了接近1个月多，大部分都是根据回忆记录下来的。

简单说说最近在忙的事 经过近半年的停工之后，在不断的信访和维权的努力下，困难而曲折的房子在22年年底终于如期交房了。 交房之后的话紧接着就忙着过年的事，没有太多时间更新博客。 进入到年后一直在关注家里装修的事情，因为预算不足，所以没有直接找装修公司全包，所以每一项都需要自己去打听和研究，减少被坑。 然而还是不断的犯各种小错误，花冤枉钱，无奈啊 简单说说后面要做的事简单来说就是把技术博客更新这块抓起来，并且花一定的时间考虑家里的软装等等的购买，还有一些提前的还贷的想法实现。

前言 docker诞生至今，不过短短九年时间，已经风靡世界，引起了科技世界一场巨大的革命。 然而因为国内外网络不通，所以导致我们部署开源镜像的时候，经常无法拉取镜像，这个问题曾经也苦恼了我不短的时间。 在一开始的时候解决这个问题就是自己使用国外的服务器来拉取镜像，然后push到国内的仓库，但是一段时间过后发现做的都是重复的工作，从工程师的角度来说，重复的工作会浪费大量不必要的时间，最好可以引入自动化工作来替代它，解放双手，何乐而不为呢。 过程我的镜像仓库主要是使用的是阿里云的镜像仓库，基本上免费，在国内速度还快，我提前配置好了阿里云的镜像仓库和命名空间，账号密码到github的secrets中，在此就不多做赘述。 自动化的过程分为了两个阶段，第一个阶段是人工智能半自动化，我使劲研究了github的action文档，发现可以使用矩阵的方式来同步多个镜像，如下： 12345678910111213141516171819202122232425262728293031323334353637383940414243# This is a basic workflow to help...

前言 最近也是没有中断过折腾，最近主要解决了kubesphere控制台使用Nginx代理会一直报http2错误的问题，也参考过kubesphere论坛上一些其他的答案，基本上都是配置很多很多的location，但是这样好像并没有解决实际问题。 后来在某论坛找到了一个靠谱的解决方案，参考链接 配置直接看我的nginx配置文件： 123456789101112131415161718192021222324252627282930313233343536server { listen 80; server_name kube.abc.com; return 301 https://$http_host$request_uri; }map $http_upgrade $connection_upgrade { default upgrade; '' close;}server { listen 443 ssl http2; #实测http2 非必须 ...

前言 前段时间搭建了跨公有云厂商的k3s集群，部署了几个比较小的服务来测试一些稳定性。 结果还是有些让人失望的，跨越地域传输数据的网络的稳定性还是比较差，经常出现服务无法访问的情况，在网上也找了很多用其他软件构建虚拟内网的文档，试着搭建了一下，发现稳定性还是很脆弱。 奈何暂时放弃了使用公有云集群作为自己的生产k8s集群的方案，比较生产集群稳定性还是有一定要求，我自己自建了很多的服务，包括 spug 云上ssh工具，可以管理云主机，在必要的时候连接到云主机 bitwarden 非常好用而且开源的密码管理器，我现在的各种网站的密码都是使用的随机密码，大大降低了数据泄露的风险 outline 文档管理工具，自建的wiki，这篇文章就是使用outline写的 linkace 书签管理器 这篇文章叫《公有云安装k3s集群实践（二）》，实际上应该是《k3s公有云集群从入门到放弃》。 基于多方面考虑，直接搭建单节点k3s，把原来的k3s卸载，然后直接重新安装k3s，就能直接使用了。 12345678#卸载k3s-server/usr/local/bin/k3s-uninstall.s...

前言 刚刚入手一台天翼云的服务器，配置8H16G，要不折腾点啥过不去，之前一直想整k8s，但是k8s比较复杂，而且需要的服务器配置比较高，我那么多1H2G的机器整不起来，然后公网IP通信也是个让人头疼的问题。 幸好看到了多云搭建 K3S 集群 这篇文章，然后就有了些许思路（给作者点赞），可以整一个k3s集群来承载我现在分布在各个服务器上的服务。 原来的六台服务器上，每个服务器都有不同的服务，每次都是ssh上去，然后docker-compose，除了大部分是自动调度的，手动维护还是挺费劲的，所以考虑着将部分服务搬到k3s集群上管理，然后通过api接口调度，是不是能节省了时间还学习到k8s的一些基础知识。 在做准备工作前先说几句废话： k3s集群搭建本身很简单，稍稍有些麻烦的是环境准备还有内网互联问题 作为新手，k3s仍属于k8s，了解各种概念非常繁琐，不如使用现成的可视化工具：kubesphere 来进行操作，能迅速的帮助理解概念，从各种陌生的词汇中暂时挣脱出来 集群不是搭好初始版本就能用的，需要你不断的看官方文档，不断的对集群进行改进，甚至包括重新安装 我是在重新安装k3s集...

前言 接近一个多月没有更新了，忙于工作，忙于生活，忙于自我救赎。没有成功抵达乌兰察布看草原，但是坐在回家的高铁上领略了另外一番绿色的风景，人生无常，且行且珍惜吧。 说到caddy,我的上一篇文章就说到它的优点：比nginx配置简单，自动SSL，方便安装部署。并且已经在闲暇时间把我的所有服务器都从Nginx迁移到caddy了。 但是好景不长，突然发现caddy出现了两个严重的问题，导致我关停了一小段时间我的小站（防隐私泄露，防攻击）。 过程caddy在我这边出现的问题就基本上比较致命，出现了一次就会感觉损失巨大： 1、caddy自动续约证书成功，但是没有自动刷新网站的SSL证书，导致网站不可访问 2、caddy的forward_auth功能失效，导致网站没有经过我的authelia网关直接就能访问，导致我的个人信息网站被裸露访问（我访问网站时，查看caddy日志，发现直接失效，没有请求authelia进行验证是否有效） 我使用的是centos7系统，caddy版本是最新的2.5.2，然而这个翻车让我觉得重要的组件还是不能轻易更换，以免造成更大的损失。 结果我是新建了一个git仓库...