上一篇文章异地备份MYSQL数据库已经写明了如何备份Mysql数据库到oss和cos,如果使用的是postgres数据库,这种方法也仍然适用。
备份脚本基本和Mysql的备份脚本一致,工具是专用的工具:pg_dump
,对应的shell:
1 | !/bin/bash |
阿里云的flow支持直接在docker镜像内运行对应的脚本,所以要准备一个合适的docker镜像,需要满足三个条件:
注意: 我的postgres的版本是14.4 对应pgdump
要安装对应的版本,不然会提示版本不匹配。
直接根据对应的需求写一个简单的dockerfile:
1 | # centOS镜像 |
需要提前将对应的文件下载到本地,然后赋予执行权限:
1 | chmod +x coscli |
接下来就是build镜像,然后推送到镜像仓库(阿里云个人镜像):
1 | docker build -t aliyun-postgres:latest . |
创建一个空的git仓库,将cosconfig
、ossconfig
需要的ak等信息存储在仓库中,然后push到git仓库
cosconfig.yaml
示例:
1 | cos: |
ossconfig.yaml
示例:
1 | [Credentials] |
直接使用自定义镜像创建任务,将上述脚本写入到shell中,然后执行脚本,再设置定时触发,就可以定时备份postgres数据库了。
由于有了鼓捣mysql备份的经验,再去鼓捣postgres备份就快的多了,基本上就是写脚本,自己拼接合适的镜像,然后再定时执行脚本,这个事就办好了。
学而时习之,不亦乐乎。
]]>MySQL的数据备份一直以来都是一个重要议题,近来我遇到了一些奇怪的事件,同时网络攻击也层出不穷,这让我更加认识到了MySQL数据备份的重要性。
目前,我在使用阿里云的RDS服务,无法进行物理备份,只能依靠mysqldump进行逻辑备份。然而,考虑到备份文件存放在本地磁盘的风险,一旦磁盘发生故障,备份工作就相当于无用功。
因此,我最终决定将数据库备份的SQL文件同时存储到阿里云的OSS对象存储和腾讯云的COS对象存储中。我在不同城市分别创建了不同的存储桶(Bucket),以最大程度地避免同一城市发生大规模故障的问题。这样做的目的是为了确保备份文件的安全性和可靠性。
具体使用了如下资源:
备份脚本是执行mysqldump 循环将对应数据库的数据以单个文件存储,shell如下:
1 | DB_HOST="" |
然后就是对应执行mysqldump的环境了,因为的物理机服务器没有装mysql,直接使用阿里云的flow使用docker容器跑对应脚本就可以了。
阿里云的flow支持直接在docker镜像内运行对应的脚本,所以要准备一个合适的docker镜像,需要满足三个条件:
直接根据对应的需求写一个简单的dockerfile:
1 | # centOS镜像 |
需要提前将对应的文件下载到本地,然后赋予执行权限:
1 | chmod +x coscli |
接下来就是build镜像,然后推送到镜像仓库(阿里云个人镜像):
1 | docker build -t aliyun-mysql:latest . |
创建一个空的git仓库,将cosconfig
、ossconfig
需要的ak等信息存储在仓库中,然后push到git仓库
cosconfig.yaml
示例:
1 | cos: |
ossconfig.yaml
示例:
1 | [Credentials] |
创建任务主要是要选择自定义环境构建,使用上文中的docker镜像,执行对应的命令,图片中完整命令如下:
1 | DB_HOST="" |
最终任务详情如下图:
编写Shell脚本基本上没有花费太多时间,我直接使用了助理工具完成。在此过程中,也遇到了一些问题:
coscli
命令,所以我决定直接在centos:7
中安装所需的工具。yyyy-MM-dd HH:mm:ss
样式。备份并不是我们的终极目标,而是为了确保服务的长期稳定运行,以应对突发情况。在我们日常使用MySQL时,更需要关注MySQL本身的安全措施,包括限制端口的可访问性、避免对外暴露、使用复杂密码进行数据库访问并定期更改密码等等。
]]>最近在鼓捣一些奇奇怪怪的东西,例如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
1 | networks: |
我修改后的docker-compose.yaml
1 |
|
主要改了以下几个方面:
修改*.env*,内容如下:
1 | SAFELINE_DIR=/data/safeline |
试用雷池第一步实际上是需要用http的9443端口访问的,安全组线临时开一下端口,然后host:port正常访问
dns将waf.xxx.com解析到对应的ip,待正常访问后,关闭安全组的9443端口
全站截图,有正常访问量,正常的拦截
从实时攻击事件来看,确实是有一定的防护作用,也确实给网站减少了一些攻击事件,减少被攻击成功的概率,后续的话还需要接入更多网站,做可持续的观察。
如图:
在搭建到使用过程中,优缺点非常的明显,如下:
优点:
缺点:
雷池从搭建到使用,给人的体验非常的简单方便,再加上是直接基于nginx的,几户没有学习成本,很容易上手,后续准备接入更多的个人站点。
]]>Chat gpt的出现改变了世界,但是对国内多有封锁,但是总是有很多能人来帮助我们解决各种各样的问题。
国内的AI模型发展也是如火如荼,很早之前就在试用星火大模型,一直想要做一个自用站,不需要每次登录,这篇文件简单记录一下自建web网页使用星火大模型api。
先注册一下讯飞星火,然后申请免费的API额度,拿到app调用的相关信息。
One Api是封装所有的AI接口,通过标准的 OpenAI API 格式访问所有的大模型,开箱即用。
访问one api 查看如何部署,我是用的docker-compose
部署服务,并将其配置反向代理,具体的可以参考文档。
主要使用流程就是登录账号之后,先配置一个API渠道,例如星火API,然后再创建一个令牌,记住对应的KEY,然后在web页面中使用。
渠道配置:
令牌配置:
ChatGPT-Next-Web 一键免费部署你的跨平台私人 ChatGPT 应用。
这个项目的部署非常简单:
1、先fork ChatGPT-Next-Web 到你个人仓库里面
2、使用github账号登录 Vercel
3、创建一个Vercel项目,将github地址授权给项目
4、依次填入以下环境变量:
CODE
: 你的网页密码BASE_URL
你的one api反向代理地址OPENAI_API_KEY
你的one api 的令牌KEY值5、保存后部署,然后直接访问,输入上一步输入的CODE,问个问题,测试是否OK。
正常访问站点如下,有问题根据错误提示解决:
查看ONE API调用记录:
one api可以作为多个大模型的反向代理,而无需修改前端代码,简单省事,确实是一个非常棒的项目。
有啥问题可以留言交流。
最近GITHUB上有很多优秀的AI相关的项目,因为某些原因被GITHUB直接封禁,所以自用的项目最好备份一份到其他的GIT环境,防止项目某天突然不能访问。
]]>因为工作地点和房子地点不在一个城市,所以家里装了移动宽带并且装了摄像头,但是摄像头频繁掉线,所以怀疑有以下几点原因:
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文档,发现可以使用矩阵的方式来同步多个镜像,如下:
1 | # This is a basic workflow to help you get started with Actions |
以上我是通过自己手动写matrix的方式来实现同时同步多个镜像,突然有一天发现,好像这样也没有完全解放双手,我仍然需要不断的提交代码来同步别的镜像。
技术之所以称之为技术,是因为不同的技术它的思想是可以共通的。我想起不久之前自己同步github仓库使用的是github的api来进行仓库的同步,那么用github的api来做这件事情,可以不可以呢?答案是肯定的。
首先,看文档:使用矩阵来执行JOB
做技术的,文档就是代码的说明书,还是非常具有参考的价值的。
然后改造上面的docker-sync-api.yml
文件如下:
1 | # 同步镜像仓库的镜像到阿里云仓库 |
似乎一切都变得简单了,想要同步什么仓库镜像直接用api请求就可以了,立马就可以响应并且帮你把镜像同步到你想同步的地方。
注意点:
1、需要提前配置目标仓库的DOCKER_REGISTRY
、DOCKER_USERNAME
、DOCKER_PASSWORD
在项目的secrets中
2、创建github-token,点击此处 ,保存在本地待用,权限你看着给
3、配置好 docker-sync-api.yml
中的on.repository_dispatch.types
为你想要的名称,例如:sync_docker
4、请求githubApi,替换#github-token
、#username
、#repo
、#sync_docker
,和json中的client_payload
的内容即可,是一个数组,需要同步几个镜像就同步几个
1 | curl -X POST -H 'Accept: application/vnd.github.v3+json' -H 'Authorization: token #github-token' https://api.github.com/repos/#username/#repo/dispatches -d '{"event_type":"#sync_docker","client_payload":{"images":[{"source":"vaultwarden/server:1.26.0","target":"bitwarden:1.26.0"},{"source":"postgres:alpine","target":"postgres:alpine"}],"message":"github action sync"}}' |
5、详细看看client_payload
的内容,提前在json中写好,然后替换到curl 请求中,减少麻烦
1 | { |
以上步骤就完成了手动请求github-api,然后github-action自动触发同步镜像仓库的过程。
当你觉得做一件事情是重复且无趣的时候,那么就尽量想法办让它变成自动化的,在这个过程中享受作为技术人的快乐,节省时间来做更有趣的事情。
]]>最近也是没有中断过折腾,最近主要解决了kubesphere控制台使用Nginx代理会一直报http2错误的问题,也参考过kubesphere论坛上一些其他的答案,基本上都是配置很多很多的location,但是这样好像并没有解决实际问题。
后来在某论坛找到了一个靠谱的解决方案,参考链接
直接看我的nginx配置文件:
1 | server { |
最近也是一直着手将所有的服务都从docker-compose迁移到k8s集群,没有去看Kubesphere的控制台配置域名访问报错的问题,这个问题在前期确实也是花费了不少的时间去解决,但是当时也没有找到合适的解决方案。
最终看到上面那篇文章便尝试着去做,最终解决了问题,一开始也做过类似的配置,包括配置http2,配置websocket等,但是确实有更多的配置,官方有没有具体的文档说明。
一个问题没有找到答案,那就放下,也许后面的某一个不经意的瞬间就找到答案了呢。
]]>前段时间搭建了跨公有云厂商的k3s集群,部署了几个比较小的服务来测试一些稳定性。
结果还是有些让人失望的,跨越地域传输数据的网络的稳定性还是比较差,经常出现服务无法访问的情况,在网上也找了很多用其他软件构建虚拟内网的文档,试着搭建了一下,发现稳定性还是很脆弱。
奈何暂时放弃了使用公有云集群作为自己的生产k8s集群的方案,比较生产集群稳定性还是有一定要求,我自己自建了很多的服务,包括
这篇文章叫《公有云安装k3s集群实践(二)》,实际上应该是《k3s公有云集群从入门到放弃》。
基于多方面考虑,直接搭建单节点k3s,把原来的k3s卸载,然后直接重新安装k3s,就能直接使用了。
1 | #卸载k3s-server |
那我这篇文章要说什么呢?主要是讲一下我如何从docker-compose的服务管理,迁移到k8s的服务管理。
比对不同主要是从我自身的角度出发,作为个人开发者,在实际使用上的不同来进行简单的对比:
docker run -d -p 8080:80 -v xxx:xxx nginx
和能让容器有多副本,仅此而已kubeconfig
就能够访问到k8s集群进行服务部署,就是配置服务文件会有一些门槛,但是经过了使用可视化的web界面来实践之后,直接把对应的deloyment.yaml
文件拿下来改改就能够构建其他的服务,相比来说更灵活也更简单目前k8s有提供工具来从docker-compose.yaml
文件转化为k8s运行需要的yaml文件,但是仍然需要做些许修改才能正常使用。
1 | # Linux |
linkace的docker-compose.yaml
文件
1 |
|
linkace的.env
文件
1 | ## LINKACE CONFIGURATION |
可以看出结构非常的简单,我比较关心的主要是两个点
volumes
原来我的数据都是挂在宿主机上的,方便迁移到其他的机器.env
我的.env中存储的是容器运行所需的环境变量转化为k8s可执行文件
1 | #转化为k8s可执行文件 |
当看到一个简单的docker-compose.yaml
文件通过kompose转化为7个文件的时候我还是有点震惊的,正常情况下只需要两个文件即可:deployment.yaml
、service.yaml
开始手动修改link-deployment.yaml
文件让它变得更简单
生成的link-deployment.yaml
文件内容:
1 | apiVersion: apps/v1 |
修改完的link-deployment.yaml
文件
1 | apiVersion: apps/v1 |
主要修改的内容:
metadata 原来的很多meta都是以kompose的数据来的,然后我直接将我现在在kubesphere上下载下来的deployment.yaml
为模板来修改
env
这里使用了env
来生成了一个ConfigMap
的配置,然后直接在dpeloyment.yaml
文件中引用,格式是这样的
1 | - name: APP_KEY #env中kye的名字 |
volumes 的修改稍稍的麻烦一些,但是差不了太多,只是因为使用的volumes需要挂载到host
1 | #这块是容器里面的目录,需要挂载出来的 |
注意:
hostPath.type
支持很多种文件,我这里主要是四种用法:DirectoryOrCreate
文件夹,如果不存在则创建Directory
文件夹,不存在则报错FileOrCreate
文件,不存在则创建File
文件,不存在则报错volumes.name
要和上下对应,不然找不到service.nodePort
是你要在宿主机暴露的port,直接根据IP:nodePort对外可访问实际在k8s集群的网络联通测试上花了很多的时间和精力,但是确实么有特别靠谱的方法,所以暂时妥协用k3s单节点集群,就这其实也解决了我的服务从docker-compose迁移到k8s的问题,我将其他的机器也同样装上k3s,那还是没有体验上的差别,差别只是节点不能跨机器部署,单节点故障会导致服务不可用,对于个人服务来说不是特别重要。
另外并没有放弃使用k8s集群来做一些学习研究的工作,所以我申请了鹏城生态 的安全可靠,免费公益服务器来搭建k8s集群,来继续进行研究。
后面会将我其他的服务都逐步迁移到k8s中来进行管理,并且挖掘k8s一些好用的有意思的功能来进行应用。
学习的路上没有止境,我一直认为学习是为了更好的工作和生活,自建的服务是,docker是,k8s也是,节省了很多的人力物力去处理各种各样复杂的现实问题。
]]>刚刚入手一台天翼云的服务器,配置8H16G,要不折腾点啥过不去,之前一直想整k8s,但是k8s比较复杂,而且需要的服务器配置比较高,我那么多1H2G的机器整不起来,然后公网IP通信也是个让人头疼的问题。
幸好看到了多云搭建 K3S 集群 这篇文章,然后就有了些许思路(给作者点赞),可以整一个k3s集群来承载我现在分布在各个服务器上的服务。
原来的六台服务器上,每个服务器都有不同的服务,每次都是ssh上去,然后docker-compose,除了大部分是自动调度的,手动维护还是挺费劲的,所以考虑着将部分服务搬到k3s集群上管理,然后通过api接口调度,是不是能节省了时间还学习到k8s的一些基础知识。
在做准备工作前先说几句废话:
腾讯云机器-227 公网IP: 123.123.123.227 配置: 1H2G 系统:centos7.9 内核版本:3.10.0-1160.76.1.el7.x86_64
天翼云机器-152 公网IP: 123.123.123.152 配置:8H16G 系统:centos7.9 内核版本:3.10.0-1160.76.1.el7.x86_64
注意:准备工作需要在所有的云服务器都要进行操作。
准备工作的目的:
我构建的k3s集群和版本:
1 | [root@tianyi-152 ~]# kubectl version --short |
使用MySQL作为存储,k3s支持PostgreSQL、MySQL 或 etcd作为外部存储,主要是支持k3s高可用。
使用WireGuard来构建虚拟内网,让各云的机器使用自建的内网IP能互相访问,用SSL通信。
因为我们构建虚拟内网需要使用软件WireGuard
,但是该软件需要内核5以上的版本,所以先升级系统内核。
从 linux内核列表 找到合适的内核及版本。
下载内核及安装
1 | #下载内核 |
修改默认内核版本
1 | # 查看当前实际启动顺序 |
在所有节点开启 IP 地址转发
1 | echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf |
所有节点开启修改主机名称
1 | # 腾讯云机器-227 |
添加 iptables 规则,允许本机的 NAT 转换
1 | iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT |
注意:
重启服务器
1 | # 重启服务器 |
WireGuard
,并且配置内网互联安装WireGuard
1 | #安装rpm依赖包 |
配置WireGuard
1 | #在各个云服务器上生成通信的秘钥,包括公钥和私钥 |
在腾讯云227的主机创建/etc/wireguard/wg0.conf
文件,输入以下内容
1 | [Interface] |
在天翼云152的主机创建/etc/wireguard/wg0.conf
文件,输入以下内容
1 | [Interface] |
启动WireGuard
使用wg-quick
工具来创建虚拟网卡
1 | #创建虚拟网卡,与配置文件名字对应,与iptables规则对应 |
观察内网互联情况,在两台主机同时执行
1 | [root@tianyi-152 ~]# wg |
注意查看是否有transfer,如果有,那说明已经正常通信了,或者互相用内网地址ping也可测通
1 | [root@tianyi-152 ~]# ping 192.168.1.1 |
配置WireGuard
开机自启
1 | #开启wg-quick@wg0 服务 |
如果后期需要增加节点,那么会修改配置文件,此时不能重新创建wgo,只需要修改配置热刷新即可。
1 | #用strip指令刷新 |
内网互联工作已经完成,剩下的就是折腾k3s集群了,值得注意的是,内网互联只需要配置一次就可以了,主要是保障主机能通过公网来构建内网虚拟网络。
安装K3s集群其实很简单,但是要先看文档:官方文档
有几个需要注意的点:
在天翼云152上安装k3s master节点:
1 | # 使用国内资源安装k3s |
注意:
--docker
容器运行时使用docker,如果不需要,那就去掉,否则先安装docker--datastore-endpoint
外部存储使用mysql,如果不需要,去掉即可,否则先准备好mysql等--disable traefik
禁用自带的traefik
,如果不需要,去掉即可,暂时没发现有啥用处--node-external-ip
、 --advertise-address
尽量指定外网IP或者能通信的内网IP--node-ip
指定上面使用wg分配的内网IP--flannel-iface wg0
指定网卡设备,如果是其他名字,请更换执行完命令后,查看k3s的服务状态是否正常启动
1 | #查看k3s 启动状态 |
正常running后,可以查看k3s的pod状态了,还可以看节点状态
1 | #查看所有的pod是不是completed 或者 running状态,如果是,那就是已正常启动 |
阅读了官方文档后,为保证高可用,因为天翼云的服务器有效期只有1年,后期续费基本不可能(价格差20倍),所以为了高可用,再创建一个主节点。
创建第二个主节点和创建第一个主节点基本一致,其他的就是多了个 --token
的参数
在天翼云152上获取token
1 | #获取token |
在腾讯云227上安装第二个master点
1 | #安装主节点 |
当然也可以选择将腾讯云227安装为agent节点 (master 和 agent要二选一,不要同时执行)
1 | #安装agent |
注意:
K3S_URL
是主节点的注册地址,如果是简单集群,那直接是ip:port即可,如果要高可用,尽量设置成域名,查看使用外部数据库实现高可用安装自行查看pods或者nodes的状态即可,如果有问题,先看官方文档,看看是不是配置不对,然后再去搜索引擎找答案。
集群安装完了,剩下的是实际部署服务啥的了,这时候用命令行或者配置文件来操作,对于k8s的新手用户来说还是比较费劲的,最好的方案是在k8s上部署一个kubesphere,用可视化界面来创建节点啊服务啊对外访问啥的,加深理解然后自己再去使用配置文件来配置。
正常还是看在 Kubernetes 上最小化安装 KubeSphere,据悉 kubesphere也是支持k3s的,但是不能保证完整可用性,毕竟k3s比k8s少了5个s。
我是先看了在linux上安装kubesphere的,需要提前安装一些依赖:
1 | yum install socat conntrack -y |
然后就可以安装kubesphere了,在k3s的其中一台master上安装即可,后续如果需要给k3s加节点,那么kubesphere会讲监控等的容器自动部署到新的节点上。
1 | #下载installer依赖 |
注意:
v3.2.1
是我实验成功的版本号,实际上它已经发布了v3.3.0
但是遗憾的是我没有安装成功,所以我把版本降级安装成功了kubesphere-installer.yaml
、cluster-configuration.yaml
可以先看看文件里写了啥,新手可以不改动kubesphere安装上了,还要看看它有没有安装完成,看看安装日志是否正常,如果正常安装,那么会给出地址和默认的账号密码
1 | #查看日志 |
使用 kubectl get pod -A
查看所有 Pod 是否在 KubeSphere 的相关命名空间中正常运行。如果是,请通过以下命令检查控制台的端口(默认为 30880):
1 | kubectl get svc/ks-console -n kubesphere-system |
注意:
看个成果界面:
凡花了很多时间和精力去做的事,尽量写个总结:
kubesphere新手入门使用k3s或者k8s创建服务,或者开通对外访问,我建议花一个小时看看视频,还是非常有用处的。
未完,待续……
接近一个多月没有更新了,忙于工作,忙于生活,忙于自我救赎。没有成功抵达乌兰察布看草原,但是坐在回家的高铁上领略了另外一番绿色的风景,人生无常,且行且珍惜吧。
说到caddy,我的上一篇文章就说到它的优点:比nginx配置简单,自动SSL,方便安装部署。并且已经在闲暇时间把我的所有服务器都从Nginx迁移到caddy了。
但是好景不长,突然发现caddy出现了两个严重的问题,导致我关停了一小段时间我的小站(防隐私泄露,防攻击)。
caddy在我这边出现的问题就基本上比较致命,出现了一次就会感觉损失巨大:
1、caddy自动续约证书成功,但是没有自动刷新网站的SSL证书,导致网站不可访问
2、caddy的forward_auth功能失效,导致网站没有经过我的authelia网关直接就能访问,导致我的个人信息网站被裸露访问(我访问网站时,查看caddy日志,发现直接失效,没有请求authelia进行验证是否有效)
我使用的是centos7系统,caddy版本是最新的2.5.2,然而这个翻车让我觉得重要的组件还是不能轻易更换,以免造成更大的损失。
我是新建了一个git仓库,置放我所有的docker-compose和相关配置文件文件,所以要更换caddy非常简单,直接到各个服务器上把caddy关闭并且关闭开机启动,然后把我的Nginx重新启动起来就可以了,非常的简单省事,20分钟我的6台服务器就回到了Nginx。
nginx相对于caddy实际上就是文档多一些,然后使用配置起来繁琐一些,但是配置只要做好了模板,就基本上不用修改,开一个新的网站我可能只要用到3分钟:copy一个Nginx的模板,改域名,改端口号,配置DNS,仅此而已(我的用的泛域名证书,全局用一个,省事)。
对于新火起来的caddy,确实也有不少优点,但是还是没有nginx稳定性这么高,所以选用,可以尝鲜,但是切记使用到常用环境还是要慎重慎重再慎重。
]]>caddy 是一款比较易用的web服务器,相对于nginx来说它的承载量没有nginx高,但是比nginx容易配置一些,另外自动支持ssl证书签发及续约。
目前我有7台服务器,二十多个各类服务,目前已经有3台服务器接近8个服务的访问已经迁移到caddy了,目前访问情况良好,没有使用泛域名证书,使用的是各自的单域名证书,主要是由于都分布在多个服务器上,单域名证书比较合适。
本文主要介绍一下我在试用caddy 遇到的一些问题和配置的详细步骤。
官方文档 看看官方对caddy的介绍,以及它的特性,安装方法和配置方法,把文档都看完一遍后,再继续安装caddy并且使用它。
这个时候可以搜搜博客,看看有没有写的比较好的,合适的博客,能帮助你进一步减少配置的难度,官方文档写的很碎片化,没有一个完整的配置项并且没有最佳实践,如果阅读各种云服务商的文档,很多都有最佳实践。
我调研的细节主要包括:
通过以上的细节,找了很多博客和官方文档,然后正式开始了安装和配置细节。
安装caddy 主要通过2两种方式:
/usr/local/bin/
文件夹中,然后 chmod +x /usr/local/bin/caddy
给执行权限,直接控制台输入 caddy
就可以看到caddy安装成功了。这里我使用的是第一种方式,因为我使用了模块化的管理,需要安装插件(安装插件需要重新编译)。
如果使用docker安装,需要重新用官方的Dockerfile进行重新编译打包,如果升级更新还是稍微有些麻烦,所以我选择了直接二进制文件安装。
安装很简单:
直接到官方网站:download-caddy选择你的系统,以及需要安装的插件,然后直接下载下来就可以。
之后就直接通过scp
把文件上传到云服务器,scp caddy_linux_amd64_custom host:/usr/local/bin/caddy
一步到位。
给caddy执行权限:chmod +x /usr/local/bin/caddy
这样就完成了caddy的安装
执行一下caddy version
看看你安装的版本。
配置文件主要分为两部分:
执行:vi /etc/systemd/system/caddy.service
然后将以下内容填充进去:
1 | [Unit] |
然后执行:
systemctl daemon-reload
刷新系统后台systemctl enable caddy
设置caddy开机启动systemctl status caddy
看看caddy的状态这里没有直接启动caddy,因为service中指定了caddy的配置文件--config /usr/local/bin/Caddyfile
,所以我需要先编辑好配置文件再启动。
先配置caddy的Caddyfile文件,caddy配置模式让我觉得配置比nginx要人性化点,简单省事。
执行vi /usr/local/bin/Caddyfile
1 | #支持直接#号写注释,这里主要使用了上文提到的caddyserver/transform-encoder插件 |
然后创建文件夹mkdir -p /data/caddy/domain/
进入文件夹创建一个域名对应的访问cd /data/caddy/domain/ && touch blog.bosong.online.caddy
修改对应的domain文件:vi blog.bosong.online.caddy
,如下:
1 | #直接写域名,自动给你支持了80->443端口,和证书等签发 |
到这一个简易的caddy 配置就完成了,可以启动caddy,然后先看看caddy是否启动正常,然后再访问网站看能不能访问,证书是不是刚签发的。
service caddy start
service caddy status -l
overwrite
会自动重写你的文件: caddy fmt -overwrite 你的文件
~/.local/share/caddy/certificates
,可以根据官方文档自行进行配置caddy的简单配置就是以上的内容,它的语法在官方文档中能看到,可以对照语法来看整个配置文件,虽然配置是Caddyfile,但是它实际上还是以json的形式来运行的,它内部有方法可以直接将caddy转化为Json,可以在官方文档去寻找和配置你想要的细节,等等。
查看了官方文档,然后看了很多博客之后,成功实现了从nginx转到caddy的任务,其中也有一些探索,包括CORS的配置等等,语法上使用是比nginx稍微简单点,但是它的报错信息不是很明显,需要转化成json去看,目前稳定运行了几天,还是比较简单。
caddy天然支持监控,可以使用Prometheus去采集数据,并在Grafana上进行展示,这些在官方文档中有,其中最重要的就是要注意安全问题,给caddy也配置上安全header等等配置,目前的caddy的文档不是特别的多,很多功能还是需要自己探索。
如果有相关问题,欢迎一起探索和交流。
]]>node_exporter是用来采集服务器的基本指标信息的,prometheus负责连接node_exporter来收集node_exporter获取到的数据,让grafana来负责展示prometheus采集到的数据。
简单看一下成果:
由于是给arm64的机器安装node_exporter来采集数据,所以本文中的例子皆以arm64机器为准:
下载node_exporter并且将二进制文件放到bin目录中
1 | #去github找到最新的版本 |
增加安全访问措施,主要分为两个主要步骤:
我这边主要是参考node_exporter增加密码和https验证,主要步骤如下:
创建ssl证书
1 | #存放证书的文件夹 |
创建node_exporter的配置文件
1 | #存放配置的文件夹,一下都以该文件夹为准 |
使用命令vi /etc/systemd/system/node_exporter.service
创建service文件,并填充如下内容:
1 | [Unit] |
考虑到实际情况,所以修改了具体的保存点和对应的端口,如果不需要可以修改或者移除--path.rootfs=/data/logs/exporter --web.listen-address=:1006
如果没有执行权限:chmod +x /etc/systemd/system/node_exporter.service
1 | # reload daemon |
1 | #假定prometheus已安装好并且已经在使用状态下 |
由于node_exporter的特殊性,一向喜欢用docker来进行管理的我这次选择了用源文件来安装对应的服务,实际上docker安装的效果是完全一致的。
本次的node_exporter主要遇到的坑点就是SSL一直提示握手失败,然后我各种搜文档,找资料。
最后一行代码解决:insecure_skip_verify: true
,还是要多看官方文档,查看有没有可用的选项让你避免出现错误什么的。
参考文档:
]]>简单来说,OIDC是一个OAuth2上层的简单身份层协议。它允许客户端验证用户的身份并获取基本的用户配置信息。OIDC使用JSON Web Token(JWT)作为信息返回,通过符合OAuth2的流程来获取对应的TOKEN信息。
它的作用是为多个不同的站点提供登录功能(和SSO类似)。每次需要使用OIDC登录网站时,都会被重定向到登录的OpenID网站,然后再回到该网站。例如,如果选择使用Github帐户登录Grafana,这就使用了OIDC。成功通过Github身份验证并授权Grafana访问您的信息后,Github会将有关用户和执行的身份验证的信息发送回Grafana。此信息在JWT中返回,包含ID Token或者Access Token。
这样就实现了简单的登录流程,OIDC主要有以下几个作用:
1、OIDC的协议简化了登录的流程开发工作,在支持OIDC的应用简单配置即可使用
2、OIDC的协议有组别概念,可以限制用户可访问的资源内容
3、一个账号根据不同的资源权限访问不同的站点内容
先看官方文档 ,官方文档写的还是比较详细的,创建一个OIDC应用,只需要在configuration.yml
的后面加上对应的配置即可,在本文中我以grafana配置为例,简单说明grafana使用Authelia来进行登录
1 | identity_providers: |
这样一个很简单的配置,就让Authelia实现了自身作为OIDC的身份提供商供 grafana 这个应用登录访问。
我们可以直接访问到你的authelia的地址来查看登录需要配置的端点信息:https://auth.example.com/.well-known/openid-configuration
将对应的auth.example.com
换成你自己的域名。
grafana 配置OIDC的登录官方也有完善的文档,但是我也遇到了一些小的坑点,所以我会在贴配置的同时,说明我遇到的坑点(其实是我菜)。
使用开源项目的对应功能,肯定第一步是看官方文档 ,官方文档还是写的比较详细,但是它是一个通用文档,我们需要根据实际情况做一下小的变更。
我的grafana是使用docker-compose启动的,它的配置很简单:
1 |
|
这时候需要复制grafana的默认配置文件 来写到grafana.ini
文件中了,数据库信息什么的配置。
注意我在这里碰到了一个坑点:当你需要启用对应的配置时候,需要将 ;
去掉,这样配置才能生效。(惯性思维是#
,突然来个;
号有点懵)。
grafana 的配置写的比较简单命令,其他配置忽略的情况下,以下几个配置就能支持到authelia的登录访问了。
1 |
|
配置完成后重启grafana之后,再次访问grafana就可以看到你配置的authelia登录框了,成果如下:
实际上我总共配置了三个client: outline、portainer 这个参考官方文档即可配置成功、grafana,除了grafana花费了些许时间之外(主要是我菜,配置没有去掉;
),其他两个配置都很简单。
现在authelia这个服务已经为我的数个网站提供登录保护支持,如果你有兴趣,可以与我一起交流探索更多的有趣的玩法,如果有遇到的一些问题欢迎一起探讨。
]]>对于程序员来说,有时候会有很多灵感爆发出来,然后这个时候就需要一个很灵活的笔记本能够记录自己的所思所想,快速的把想法沉淀到纸面上,而我也一直在寻找这样的一个好用的notebook。
我曾经用过好多款的notebook,但是或多或少的不是特别符合我的需求:
我对Notebook的要求也比较简单:
自从发现了outline以后,我还尝试着去注册,试用一下,然而在官网给了我致命打击,只支持组织类的账户注册,还都是google/slack等软件,然后发现开源,我就试着看对应的搭建文档,总体还是比较简单,它面向的客户主要是企业类客户,所以很多方面设计是偏向于企业化设计的,包括组件,刚好我有一些替代品:
一切就是那么的巧合,我迫不及待的创建好数据库和对应的账户,创建好cos的存储桶和单独的ak,配置基于authelia的OIDC,那么一切就开始了,就很简单,创建好.env
然后放入在github仓库中复制的模板,创建好docker-compose文件,一键启动。
数据迁移一直是一件比较难受的事情,我之前从standardnotes迁移到wikijs 在周末的深夜花了两三个小时,迁移我的接近100多篇的各种文档,然后第二天睡醒就感觉wikijs可能用不长久了,因为创建一个文档要点三次以上。
然而outline的迁移远比我想象的要简单,直接把wikijs的github上的备份仓库下载下来,然后直接把markdown里面的标题等信息全部手动移除,直接导入到outline就可以了,它支持直接导入文档,我只花了十几分钟来去掉markdown里面的多余信息,就完成了备份迁移过程。
使用开源软件最多的目的是为了减少数据泄密,还有方便自己的生活,列举一下我目前在使用的开源软件
这篇文章主要就是讲述一下我的网络版notebook的软件使用历史,一个好用的工具能让你节省很多的时间和精力,并且能让你的思绪能够快速的被记录下来。工欲善其事必先利其器,我算是一个喜欢折腾的人,平常会收集很多自己常用的软件,大部分是开源软件,对于我来说数据安全得到了保障,并且能增加我的阅历和生活,给无聊的生活带来一些乐趣,像OIDC这种东西,如果不是运维啊什么的,基本上很难去接触到,这也算是对自己技术能力的一个提升。
我对现代化软件最大的期望就是都能够在浏览器里直接运行,并且最好能在国内访问,这样速度和安全性都能得到保障,安装软件还算是一件比较痛苦的事情。
作为喜欢使用开源软件的程序员,也是深深的感谢开源文化,我日常也在积极参与开源,不局限于给常用的软件提PR,提升用户体验和自己的一些体验,自己也有一些开源的项目,比较简单,就主要是为了增加自己各种项目的自动化进程,减少人工干预。
]]>写这篇文章的初衷是昨天晚上记录一下我从gitee迁移到codeup的一系列过程,其中最后一步涉及到了github与codeup代码的双向同步,所以记录趁热记录一下我的github action如何使用。
我给这个github action起名叫做More Hub Mirror Action,代表它能在多个hub托管平台之上相互同步代码,主要用来做代码备份以及开源镜像同步。
我的介绍大概是这样写的:
一个用于在hub间(例如Github,Gitee、Coding,不局限,可以是所有)账户代码仓库同步的action,这个项目脱胎于Yikun/hub-mirror-action@master。
由于我是想要一个纯粹的不同的hub之间 同步的脚本,所以将该脚本进行了删减,不是作者做的不好,只是我仅仅需要简单的功能罢了
目前只支持,也只会支持两个仓库必须在两个hub之间存在的情况,不再创建新的仓库(由于创建仓库需要api支持,但是为了更通用,所以决定不支持对应的功能)
根据能量守恒定律,失去些什么,必然能得到些什么,这样就可以在不同的hub之间同步数据,不管是 从 github->gitee 还是 gitee-github 都可以支持到
src、dst 都需要写全路径了,例如:github.com/kunpengcompute
static_list 是必传参数,因为不会再动态获取对应的repos了
dst_key 也是必传参数,因为为了安全考虑,我决定全部使用ssh的方式进行同步,如果后期有需要,可以兼容https
同步过程主要分为两步:
创建好对应的github action,有两个,可以使用同一个action进行操作,我创建的仓库名是:github-sync
,下面我都以该仓库名作为github action的webhook进行请求。
先要做几个准备:
该仓库下的github action配置如下:
1 | # This is a basic workflow to help you get started with Actions |
简单说明:
codeup_push,这个是webhook和github约定好的event,填已有的即可
secrets.GIT_PRIVATE_KEY 这个是上面提到的ssh密钥,及时放在github的secrets中
src、dst使用除了https之外的个人路径全路径,src和dst可以随便填你想要同步的两个hub,甚至可以不是github(身在曹营心在汉的即视感)
github.event.client_payload.repo 这个是你在webhook中提到的你要同步的仓库
1 | curl -X POST -H 'Accept: application/vnd.github.v3+json' -H 'Authorization: token ${github-token}' https://api.github.com/repos/dislazy/github-sync/dispatches -d '{"event_type":"codeup_push","client_payload":{"repo":"${repos_name}","message":"github action sync"}}' |
简单说明:
,
分隔开即可我目前使用以上的脚本基本上分为两个大块:
开源的工具有很多,大多数都是为不同的需求不同的人群定制的,如果找不到合适的,如果有能力改一改也是极好的。
]]>gitee是目前国内做的比较好的公共git托管仓库和开源交流平台,codeup是阿里云的企业git托管,包括一整套devops的解决方案。
这篇文章主要分享一下我最近将代码从gitee迁移到codeup并且将几乎所有的devops都迁移到flow的过程。
主要还是想要一个简洁的git仓库管理平台和完善的devops生态系统,codeup早期时候使用过,但是没有这次的感觉这么惊艳,当一个产品让你产生了惊艳的感觉的时候,你可能已经想迫不及待的尝试它了,我也是这样,codeup恰好就是我想要的样子。
迁移过程总的来说分为三大步;
幸运的是,codeup支持一键同步很多平台的仓库,gitee恰好就被快速而便捷的同步到了codeup中,唯一出现的波澜就是:codeup是默认以代码组来创建仓库的,有点类似gitlab中project的概念,然而作为一个个人开发者,我不需要组别进行管理,这个时候在同步仓库的时候就把仓库的地址修改为不分组就可以了。
同步的过程很顺利,改好组别,一键全选,然后等待同步完成就可以。
flow是阿里云云效的一个组成部分,主要就是负责干devops这件事的。如果你不想迁移仓库,只是想单独使用flow作为你的devops工具也是完全可以的,它最多每个月送你5400分钟的构建打包时间,节点还可以使用国内和香港的节点,再也不用为node项目的编译而改一堆的仓库地址还没啥用而发愁了。
flow的配置过程也是相当简单,主要是阿里云提供了一大堆齐全的模板供你使用和查找,原生的文档也还是写的不错,说实话我在用xxx go的时候配置一步一个坑,构建速度还慢的感人。
拿一个最简单的docker镜像来说,我的打包到部署过程就只分为两个步骤:打包,部署。刚好我使用的也是阿里云的镜像仓库,然后直接选择个人仓库,填写一下你dockerfile的位置,其他的flow都给你搞定了,不需要你再写任何代码,效率之高谁用谁知道。
部署就更简单了,flow有全局的环境变量(真正的全局,配置好了,在对应的流水线引用一下,就so easy,在github等都是付费功能),在服务器安装agent,然后直接cd /aaa/ && docker-compose up -d
就部署完成了。不需要去配置服务器的密码什么的,地址都不需要填。
我有98个git仓库,21个流水线任务(多数是一样的,换个参数即可),在不到4小时的时间里,完全迁移完成,主要我的流水线都足够简单,打包,部署仅此而已。
再简单说一下,一个简单的node项目,原来在xxx go打包需要18+分钟,迁移完成后打包+部署耗时2分钟20s,主要是它的免费时长是5400分钟,效率可见一斑。
说双向同步其实有点牵强,真实情况是:大部分仓库从codeup同步到github(主要是私人项目),小部分仓库从github同步到github(主要是开源项目)。
这个过程还是稍微有点坎坷,但是没有让人失望,我之前就用过Yikun/hub-mirror-action来同步我的镜像仓库,但是看完源码发现,它好像不支持我从codeup同步到github,然后我就自己动手丰衣足食,根据他的源码修改了一个适合我自己使用场景的项目dislazy/hub-mirror-action,在此也非常感谢原作者,开源的力量很强大,值得我们有能力的人都尽一下自己的力量,我的action非常简单,可以以ssh的方式同步任何你想互相同步的代码,你可以从github同步到codeup,也可以从codeup同步到github。
我的同步action都放在github的同一个仓库中,新建了几个action,分别是:将github的全量仓库每天定时备份到gitee,同步codeup的单个仓库到github(近实时,通过api触发),同步github的单个仓库到codeup(近实时,通过api触发)。
说到同步,其实更多的是为了备份,发现codeup有一个很人性化的功能,能帮你备份你所有的仓库到阿里云的oss中,存储费用低廉(5年40G才45块钱,还是比较良心的),这样备份就有很多份,能防止任何一个仓库突然出现问题。
从决定迁移,到迁移完成,改一大堆东西,4个小时完成这个项目,有一方面是自己的能力问题,另外一方面我觉得和工具的易用性脱不开关系,就例如我配置xxx go的打包部署一样,一个项目我花了1小时配置,相当痛苦。
写这篇文章的目的纯粹是觉得工具好用,而我刚好用到,能节省我的时间和精力,所以想记录一下其中的过程,这篇文章没有任何代码,原因是因为flow的代码不直接存在仓库中,它是独立的,只是你需要关联仓库而已,如此简单。
其他的就从文档中找把,用之前看一遍文档,比尝试很多次都有用。
最近持续的居家办公生活,让我略感焦虑,说孤独也是很有感触,独立工作还是挺考验自己的自律性,以及工作和生活糅杂在一块的些许不便,然后该适应总是要适应,最近有很多的经历想变成文章记录下来,也因为情绪和工作的原因没有及时的记录下来,以后要多多记录,纯粹记录自己想记录的,给未来的自己看看。
加油吧,皮卡丘。
]]>前段时间对github同步到gitee并且实现自动化devops写了一篇简单版的文章,后期也遇到了很多问题,这篇文章主要解决遇到的痛点。
遇到问题是正常的,我们需要思考如何去解决问题,也需要针对具体的问题去解决问题,如果可以一劳永逸当然是最好的,然而大多数情况下不能,只能一步一步的探索。
先从问题3开始解决,只需要去查看对应的api文档,看看有没有对应参数,查看了文档之后发现有,然后去分析对应的github action的代码然后fork到自己的账户下面,去改动对应的代码即可,我这边已经改动完了,提交到PR但是因为理念原因目前没有被merge,可以直接上github查看我的fix。
多个仓库配置和单个仓库配置其实是冲突但是又不冲突的,可以分开来实现,创建一个新的github仓库,然后专门来做这件事,这样就不用一个一个去进行繁琐的配置了。
针对多个仓库的同步,这种同步实际上不需要实时,定时同步即可,这样可以用一个github action task去实现即可,以下是对应的解决方案代码
1 | # 定时同步多个仓库 |
针对单个仓库,因为需要进行及时进行后续的devops流程,所以针对它需要在push完之后进行同步。
我们去调研一下github的github action文档之后发现可以直接进行webhook触发,这个就可以直接帮助我们实现对应的实时同步过程。
可以先行查看对应的 文档。
此时分为两步走,在此之前先创建一个github的token,点击 申请一个 token,配置repos
的所有权限即可,后面会用到。
github.event.client_payload.repo
这个参数的对应的仓库,它由wenhook传递过来,见代码:1 | # This is a basic workflow to help you get started with Actions |
1 | # This is a basic workflow to help you get started with Actions |
其中,owner 是你的用户名,替换即可,repo 是你上面创建仓库的仓库名, githubToken 是上面申请的 Token 凭证,前面的token
单词要保留githubToken存到仓库的secrets中,然后将,event_type 是自定义的事件名字,client_payload是一个对象,它可以传递你需要传递的参数,我上面就传递了repo这个参数。
然后提交代码到对应仓库,查看webhook是否发送成功,再校验webhook触发的task是否执行成功即可。
通过以上方案解决了多个仓库配置不便和单个仓库繁琐配置的问题,还有隐私安全的问题,大大节省了配置的时间和你花费的精力,如果针对上面的方案有疑问,欢迎与我多多交流。
]]>文章的标题起的比较长,实际上这篇文章将以我的hugo-blog项目为例,讲述一下我将代码提交到github,然后自动同步到gitee,再根据gitee的webhook通过coding的持续集成部署的整个过程。
感谢github、gitee的给我们个人开发者提供足够的资源来完成这一系列的数据存储过程,也感谢coding提供的在我认为目前足够使用的持续集成功能,关键是这整个过程都是不需要付费的,需要的是灵快的小脑筋以及网上前人的经验罢了(文章中会用一些英文单词,避免敏感词汇,敬请原谅)。
事情的起因由俄乌战争引起,我认为没有战争是正义或者邪恶的,因为史诗是由胜利者书写的。
一直以来秉承一个原则:技术是自由的,它不能也不应该掺和到politics中去。
然而真实的情况是:技术必须与politics共存,它是在保证politics下才有的产物。
从这次俄乌战争中就可以看出来,以USA为首的西方国家彻底粉碎了技术是自由的谎言,甚至开源也不是自由的,由人主导的所谓的开源并非自由,从React到Github等一系列国外的开源软件的官网就能看出来很多现实:当我们的国家发生战争时,甚至是收复TW时,我们
将受到从金融、政治、外交、贸易、技术等一系列的和不能预知的威胁。
由此,为保障个人的权益,我决定将自己的代码库逐渐迁移到gitee中来,以预防未来可能发生的某些事情。
得益于github和gitee的用户群体都同样的大,绝大部分的坑都已经被前人趟过,我们只要稍加整理就好了。
从github迁移到gitee主要分为两步走:
以上的方案是不是很熟悉:完全就是数据库的数据热迁移步骤。下面我将详细说明以上两个步骤的具体情况:
感谢gitee提供的数据全量迁移功能,让我如此没有障碍的快速进行数据迁移,不得不说软件国产化做的越来越好,越来越贴近中国人的使用习惯。
全量迁移进行的非常顺利,接下来是对你需要经常写入的仓库进行数据的增量同步了,可以慢慢来,先将关键步骤记录下来,然后逐步逐个迁移,这样能将大量的工作分散开来。
迁移的技术方案:使用github的actions将当前仓库的提交记录同步到gitee中,个人免费版每个月有2000分钟的actions使用时间,相对来说还是比较富余的,大概1-2分钟可以同步一次commit,能同步一千来个commit,基本上够用。
迁移的步骤:
需要注意的点:
src_account_type
为user or org
,目标仓库(gitee)的参数是dst_account_type
,设置也同样如此。GITEE_PRIVATE_KEY
、GITEE_TOKEN
、GITEE_USER
都配置到github的Actions secrets中去,然后再编写如下所示的action。配置Actions secrets
创建github action 入口
对应的yml文件:
1 | # This is a basic workflow to help you get started with Actions |
直接按照以上配置进行修改即可,开箱即用,配置好了之后,可以提交一条commit 试试效果,job执行结果如下:
检查一下源仓库(github)和目标仓库(gitee)对应的提交记录是否对应,如果对应上了就没啥问题,不然就再看看actions的执行情况。
到这就完成了从github到gitee的迁移过程了,标准的数据库数据迁移做法:全量迁移+增量同步,如果有啥情况,随时可以无损迁移到gitee。
其实从github迁移到gitee不仅仅是代码数据库的迁移,还有后面的一系列的devops对应的地址改变,我这边主要就是在coding的持续集成,由于我的Jenkinsfile全部都是写在代码仓库里的,这时候切换就非常方便了,直接将对应的代码源从github切换成gitee的同名仓库即可,基本没有代价。
可能会有人问gitee也有对应的持续集成 gitee go 为啥不直接在gitee中生态圈使用,主要还是因为不能和coding一样我直接在自己的主机上执行任务,这样就不计算它的免费时间了,而且coding每个月会给1000分钟的免费时间,基本上也是用不完的。(主要是省钱和合理资源利用)。
直接将github的源代码仓库修改为gitee:
如果有自有云主机,可以配置在coding的资源池中使用,这样还不占用coding的免费时间,达到资源合理利用的目的
其实从github迁移到gitee 还有一层大的好处:不需要考虑你的国内云服务器拉不下来github代码的问题了,我的云主机十次有九次拉不下来github的代码,所以我一直使用coding自带的资源池。
另外一部分还有就是如何使用coding的持续集成功能部署hugo 项目,我会出一篇文章详细说明。
有些事想想觉得还挺费劲,但是一旦深入了解后做起来,发现还是挺简单,有时候就需要突破思维定势,你理解的难是建立在你固有的思维体系中的,如果要说难,先详细的去了解过整个过程后再去说难。
迁移和部署都出乎我想象的顺利,整个过程几个小时就完成了,支持重要的软件国产化,自有化,这样才能不被卡脖子。只要你足够强大,那么别人的制裁就只是个笑话了。
]]>在将自有云服务器导入到coding中作为持续集成的云主机时,提示git版本太老,所以无法继续进行安装,所以参考一篇文章对Centos 7上的Git进行了重新安装升级。
查看当前服务器的git版本
1 | git --version |
查看当前的系统版本
1 | cat /etc/redhat-release |
本次我们安装git使用编译源代码的方式安装,此前需要安装一些必要的依赖
1 | yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel asciidoc |
直接使用yum将git的旧版本remove掉
1 | yum remove git |
Git软件包可在此获取: https://mirrors.edge.kernel.org/pub/software/scm/git/
我发现源代码不区分你的CPU架构,直接找最新的版的下载即可
1 | git-2.9.5.tar.gz |
1 | cd /usr/local/src/ |
1 | git version |
如果是非root用户使用git,则需要配置下该用户下的环境变量。
1 | echo "export PATH=$PATH:/usr/local/git/bin" >> ~/.bashrc |