使用github-api来同步docker镜像
前言docker诞生至今，不过短短九年时间，已经风靡世界，引起了科技世界一场巨大的革命。 然而因为国内外网络不通，所以导致我们部署开源镜像的时候，经常无法拉取镜像，这个问题曾经也苦恼了我不短的时间。 在一开始的时候解决这个问题就是自己使用国外的服务器来拉取镜像，然后push到国内的仓库，但是一段时间过后发现做的都是重复的工作，从工程师的角度来说，重复的工作会浪费大量不必要的时间，最好可以引入自动化工作来替代它，解放双手，何乐而不为呢。 过程我的镜像仓库主要是使用的是阿里云的镜像仓库，基本上免费，在国内速度还快，我提前配置好了阿里云的镜像仓库和命名空间，账号密码到github的secrets中，在此就不多做赘述。 自动化的过程分为了两个阶段，第一个阶段是人工智能半自动化，我使劲研究了github的action文档，发现可以使用矩阵的方式来同步多个镜像，如下： 12345678910111213141516171819202122232425262728293031323334353637383940414243# This is a basic workflow to help y...
公有云安装k3s集群实践（三）
前言最近也是没有中断过折腾，最近主要解决了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集群实践（二）
前言前段时间搭建了跨公有云厂商的k3s集群，部署了几个比较小的服务来测试一些稳定性。 结果还是有些让人失望的，跨越地域传输数据的网络的稳定性还是比较差，经常出现服务无法访问的情况，在网上也找了很多用其他软件构建虚拟内网的文档，试着搭建了一下，发现稳定性还是很脆弱。 奈何暂时放弃了使用公有云集群作为自己的生产k8s集群的方案，比较生产集群稳定性还是有一定要求，我自己自建了很多的服务，包括 spug 云上ssh工具，可以管理云主机，在必要的时候连接到云主机 bitwarden 非常好用而且开源的密码管理器，我现在的各种网站的密码都是使用的随机密码，大大降低了数据泄露的风险 outline 文档管理工具，自建的wiki，这篇文章就是使用outline写的 linkace 书签管理器 这篇文章叫《公有云安装k3s集群实践（二）》，实际上应该是《k3s公有云集群从入门到放弃》。 基于多方面考虑，直接搭建单节点k3s，把原来的k3s卸载，然后直接重新安装k3s，就能直接使用了。 12345678#卸载k3s-server/usr/local/bin/k3s-uninstall.sh#...
公有云安装k3s集群实践（一）
前言刚刚入手一台天翼云的服务器，配置8H16G，要不折腾点啥过不去，之前一直想整k8s，但是k8s比较复杂，而且需要的服务器配置比较高，我那么多1H2G的机器整不起来，然后公网IP通信也是个让人头疼的问题。 幸好看到了多云搭建 K3S 集群 这篇文章，然后就有了些许思路（给作者点赞），可以整一个k3s集群来承载我现在分布在各个服务器上的服务。 原来的六台服务器上，每个服务器都有不同的服务，每次都是ssh上去，然后docker-compose，除了大部分是自动调度的，手动维护还是挺费劲的，所以考虑着将部分服务搬到k3s集群上管理，然后通过api接口调度，是不是能节省了时间还学习到k8s的一些基础知识。 在做准备工作前先说几句废话： k3s集群搭建本身很简单，稍稍有些麻烦的是环境准备还有内网互联问题 作为新手，k3s仍属于k8s，了解各种概念非常繁琐，不如使用现成的可视化工具：kubesphere 来进行操作，能迅速的帮助理解概念，从各种陌生的词汇中暂时挣脱出来 集群不是搭好初始版本就能用的，需要你不断的看官方文档，不断的对集群进行改进，甚至包括重新安装 我是在重新安装k3s集群4...
从caddy 重回 Nginx
前言接近一个多月没有更新了，忙于工作，忙于生活，忙于自我救赎。没有成功抵达乌兰察布看草原，但是坐在回家的高铁上领略了另外一番绿色的风景，人生无常，且行且珍惜吧。 说到caddy,我的上一篇文章就说到它的优点：比nginx配置简单，自动SSL，方便安装部署。并且已经在闲暇时间把我的所有服务器都从Nginx迁移到caddy了。 但是好景不长，突然发现caddy出现了两个严重的问题，导致我关停了一小段时间我的小站（防隐私泄露，防攻击）。 过程caddy在我这边出现的问题就基本上比较致命，出现了一次就会感觉损失巨大： 1、caddy自动续约证书成功，但是没有自动刷新网站的SSL证书，导致网站不可访问 2、caddy的forward_auth功能失效，导致网站没有经过我的authelia网关直接就能访问，导致我的个人信息网站被裸露访问（我访问网站时，查看caddy日志，发现直接失效，没有请求authelia进行验证是否有效） 我使用的是centos7系统，caddy版本是最新的2.5.2，然而这个翻车让我觉得重要的组件还是不能轻易更换，以免造成更大的损失。 结果我是新建了一个git仓库，置...
centOS7配置caddy的最佳实践
简单介绍caddy 是一款比较易用的web服务器，相对于nginx来说它的承载量没有nginx高，但是比nginx容易配置一些，另外自动支持ssl证书签发及续约。 目前我有7台服务器，二十多个各类服务，目前已经有3台服务器接近8个服务的访问已经迁移到caddy了，目前访问情况良好，没有使用泛域名证书，使用的是各自的单域名证书，主要是由于都分布在多个服务器上，单域名证书比较合适。 本文主要介绍一下我在试用caddy 遇到的一些问题和配置的详细步骤。 配置过程step 1：阅读官方文档官方文档 看看官方对caddy的介绍，以及它的特性，安装方法和配置方法，把文档都看完一遍后，再继续安装caddy并且使用它。 step2：细节调研这个时候可以搜搜博客，看看有没有写的比较好的，合适的博客，能帮助你进一步减少配置的难度，官方文档写的很碎片化，没有一个完整的配置项并且没有最佳实践，如果阅读各种云服务商的文档，很多都有最佳实践。 我调研的细节主要包括： SSL证书签发的验证方式，一般是文件验证或者是DNS验证，我一般用DNS的验证，并且我用的是ali的DNS服务器解析，然后找对应的文档就可...
centos7安装node_exporter并配置安全访问
简单介绍node_exporter是用来采集服务器的基本指标信息的，prometheus负责连接node_exporter来收集node_exporter获取到的数据，让grafana来负责展示prometheus采集到的数据。 简单看一下成果： 安装node_exporter由于是给arm64的机器安装node_exporter来采集数据，所以本文中的例子皆以arm64机器为准： 下载node_exporter并且将二进制文件放到bin目录中 1234567891011121314#去github找到最新的版本https://github.com/prometheus/node_exporter/releases#下载最新的版本文件（如果云服务器下载过长，可以先本地下载，然后上传到服务器）wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-arm64.tar.gz#解压下载的文件tar -zxvf node_exporter-1....
使用Authelia来实现多站的OIDC登录
简单说说什么是OIDC简单来说，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、一个账号根据不同的资源权限访问不同的站点内容 如何配置Authelia来支持grafana通过OIDC登录先看...
Notebook软件的自我进化历程
说说过去对于程序员来说，有时候会有很多灵感爆发出来，然后这个时候就需要一个很灵活的笔记本能够记录自己的所思所想，快速的把想法沉淀到纸面上，而我也一直在寻找这样的一个好用的notebook。 我曾经用过好多款的notebook，但是或多或少的不是特别符合我的需求： notion 笔记应用中的神器了，因为是商业化的有一些限制的，或者有一些个人隐私的内容不方便记录，试用了一段时间后放弃 trilium 也算是一个非常好用的笔记本了，优点就是无线层级，并且能快速记录每日的一个笔记，缺点可能就是颜值过低，然后数据存储是Sqlite,使用了很长一段时间后放弃 语雀 国产的笔记软件，它的定位是类似于wiki这样的模式，创建一个文档还是比较繁琐，至少需要连续点3击三次以上，我要的是点击一次就能创建一个文档，给提了需求无果以后放弃。 蚂蚁笔记 蚂蚁笔记实际上是国内各种社区上推文比较多的一款了，文档也很详实，但是因为开源不再更新，所以不考虑使用 standardnotes 这个是用截止到目前用的时间最长的笔记软件，够简洁，但是毕竟作为一个开源的商业化软件，自建的文档写的不是特别详细，很多功能都能...
使用简单脚本实现github与其他所有git仓库的双向同步
前言写这篇文章的初衷是昨天晚上记录一下我从gitee迁移到codeup的一系列过程，其中最后一步涉及到了github与codeup代码的双向同步，所以记录趁热记录一下我的github action如何使用。 More Hub Mirror Action我给这个github action起名叫做More Hub Mirror Action,代表它能在多个hub托管平台之上相互同步代码，主要用来做代码备份以及开源镜像同步。 我的介绍大概是这样写的： 一个用于在hub间（例如Github，Gitee、Coding，不局限，可以是所有）账户代码仓库同步的action，这个项目脱胎于Yikun/hub-mirror-action@master。 由于我是想要一个纯粹的不同的hub之间 同步的脚本，所以将该脚本进行了删减，不是作者做的不好，只是我仅仅需要简单的功能罢了 目前只支持，也只会支持两个仓库必须在两个hub之间存在的情况，不再创建新的仓库（由于创建仓库需要api支持，但是为了更通用，所以决定不支持对应的功能） 根据能量守恒定律，失去些什么，必然能得到些什么，这样就可以...