简单介绍

caddy 是一款比较易用的web服务器，相对于nginx来说它的承载量没有nginx高，但是比nginx容易配置一些，另外自动支持ssl证书签发及续约。

目前我有7台服务器，二十多个各类服务，目前已经有3台服务器接近8个服务的访问已经迁移到caddy了，目前访问情况良好，没有使用泛域名证书，使用的是各自的单域名证书，主要是由于都分布在多个服务器上，单域名证书比较合适。

本文主要介绍一下我在试用caddy 遇到的一些问题和配置的详细步骤。

简单介绍

node_exporter是用来采集服务器的基本指标信息的，prometheus负责连接node_exporter来收集node_exporter获取到的数据，让grafana来负责展示prometheus采集到的数据。

简单看一下成果：

安装node_exporter

由于是给arm64的机器安装node_exporter来采集数据，所以本文中的例子皆以arm64机器为准：

下载node_exporter并且将二进制文件放到bin目录中

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#去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.3.1.linux-arm64.tar.gz

#将可执行文件复制到/usr/local/bin中
cp node_exporter-1.3.1.linux-arm64/node_exporter /usr/local/bin/

#给执行权限，不然有可能因为权限问题无法执行
chmod +x  /usr/local/bin/node_exporter

简单说说什么是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、一个账号根据不同的资源权限访问不同的站点内容

说说过去

对于程序员来说，有时候会有很多灵感爆发出来，然后这个时候就需要一个很灵活的笔记本能够记录自己的所思所想，快速的把想法沉淀到纸面上，而我也一直在寻找这样的一个好用的notebook。

我曾经用过好多款的notebook，但是或多或少的不是特别符合我的需求：

• notion 笔记应用中的神器了，因为是商业化的有一些限制的，或者有一些个人隐私的内容不方便记录，试用了一段时间后放弃
• trilium 也算是一个非常好用的笔记本了，优点就是无线层级，并且能快速记录每日的一个笔记，缺点可能就是颜值过低，然后数据存储是Sqlite,使用了很长一段时间后放弃
• 语雀 国产的笔记软件，它的定位是类似于wiki这样的模式，创建一个文档还是比较繁琐，至少需要连续点3击三次以上，我要的是点击一次就能创建一个文档，给提了需求无果以后放弃。
• 蚂蚁笔记 蚂蚁笔记实际上是国内各种社区上推文比较多的一款了，文档也很详实，但是因为开源不再更新，所以不考虑使用
• standardnotes 这个是用截止到目前用的时间最长的笔记软件，够简洁，但是毕竟作为一个开源的商业化软件，自建的文档写的不是特别详细，很多功能都能设置，但是不生效，备份措施很多，但是只局限于付费会员（也不提供开源的方法配置），所以我一直在寻找替代品
• dailynotes dailynotes是一款小众的开源笔记本，它的作用主要是以日期为标题记录一些工作内容，当天的todo啥的，非常好用，一开始只支持了Sqlite，但是我看完源码之后，发现非常简单，进行了一些自定义的改造和自动化部署，一直把它当做每日todo在使用，现在还用着，非常好用
• wikijs wikijs是一款我用来替代standard notes的笔记本，部署简单，操作简单，但是它的作用还是wiki类，创建一个文档，至少要点三次，所以找到替代品以后无奈放弃
• outline 这个我发现的最晚，但是发现是最好用的笔记本，部署比较简单，但是需要的组件比较繁琐，需要PostgreSQL、自建的oidc登录、aws s3或者兼容的tencent cos等,主要是有层级结构，颜值还行，操作简单，我创建文档点一下就可以，备份也很简单，会帮我直接存储到tencent cos上，不用担心数据丢失。

我对Notebook的要求也比较简单:

• 支持web页面访问，我有几个电脑，用软件的话一个一个下载怕是要疯
• 创建文档或者笔记简单，最好是点一下就可以，并且支持markdown编辑器
• 备份简单，最好能直接备份我的原始markdown文档，不给markdown重命名或者添加一个特别的标签
• 数据安全 数据安全最合适的方法就是开源笔记，数据都在自己手上，不用担心泄密

说说当前

自从发现了outline以后，我还尝试着去注册，试用一下，然而在官网给了我致命打击，只支持组织类的账户注册，还都是google/slack等软件，然后发现开源，我就试着看对应的搭建文档，总体还是比较简单，它面向的客户主要是企业类客户，所以很多方面设计是偏向于企业化设计的，包括组件，刚好我有一些替代品：

• PostgreSQL 刚好我有自建的,没有成本直接使用
• Redis 刚好我有自建的，没有成本直接使用
• Mail 刚好我有自己的邮箱服务器，也是可以直接使用
• OIDC 刚好我自己一直在使用的web层sso软件: authelia 支持OIDC,简单配置一番即可使用
• AWS S3 我是长期使用tencent cos 它是兼容s3协议的，虽然稍微有些不完美，但是还是可以使用，这个备份的文件直接存储到cos上

一切就是那么的巧合，我迫不及待的创建好数据库和对应的账户，创建好cos的存储桶和单独的ak,配置基于authelia的OIDC，那么一切就开始了，就很简单，创建好.env 然后放入在github仓库中复制的模板，创建好docker-compose文件，一键启动。

前言

写这篇文章的初衷是昨天晚上记录一下我从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。

1. 由于我是想要一个纯粹的不同的hub之间 同步的脚本，所以将该脚本进行了删减，不是作者做的不好，只是我仅仅需要简单的功能罢了

2. 目前只支持，也只会支持两个仓库必须在两个hub之间存在的情况，不再创建新的仓库（由于创建仓库需要api支持，但是为了更通用，所以决定不支持对应的功能）

3. 根据能量守恒定律，失去些什么，必然能得到些什么，这样就可以在不同的hub之间同步数据，不管是 从 github->gitee 还是 gitee-github 都可以支持到

4. src、dst 都需要写全路径了，例如：github.com/kunpengcompute

5. static_list 是必传参数，因为不会再动态获取对应的repos了

6. dst_key 也是必传参数，因为为了安全考虑，我决定全部使用ssh的方式进行同步，如果后期有需要，可以兼容https

前言

gitee是目前国内做的比较好的公共git托管仓库和开源交流平台，codeup是阿里云的企业git托管，包括一整套devops的解决方案。

这篇文章主要分享一下我最近将代码从gitee迁移到codeup并且将几乎所有的devops都迁移到flow的过程。

为什么？

主要还是想要一个简洁的git仓库管理平台和完善的devops生态系统，codeup早期时候使用过，但是没有这次的感觉这么惊艳，当一个产品让你产生了惊艳的感觉的时候，你可能已经想迫不及待的尝试它了，我也是这样，codeup恰好就是我想要的样子。

痛点

1. 仓库数量多的情况下每个都需要配置，十分繁琐。
2. 如果统一配置在一个github action中时单个仓库提交无法被感知。
3. github的私有仓库如果gitee没有则会被原来的github action创建为公有仓库，隐私信息容易被泄露。

前言

文章的标题起的比较长，实际上这篇文章将以我的hugo-blog项目为例，讲述一下我将代码提交到github，然后自动同步到gitee，再根据gitee的webhook通过coding的持续集成部署的整个过程。

感谢github、gitee的给我们个人开发者提供足够的资源来完成这一系列的数据存储过程，也感谢coding提供的在我认为目前足够使用的持续集成功能，关键是这整个过程都是不需要付费的，需要的是灵快的小脑筋以及网上前人的经验罢了（文章中会用一些英文单词，避免敏感词汇，敬请原谅）。

为什么迁移

事情的起因由俄乌战争引起，我认为没有战争是正义或者邪恶的，因为史诗是由胜利者书写的。

一直以来秉承一个原则：技术是自由的，它不能也不应该掺和到politics中去。

然而真实的情况是：技术必须与politics共存，它是在保证politics下才有的产物。

从这次俄乌战争中就可以看出来，以USA为首的西方国家彻底粉碎了技术是自由的谎言，甚至开源也不是自由的，由人主导的所谓的开源并非自由，从React到Github等一系列国外的开源软件的官网就能看出来很多现实：当我们的国家发生战争时，甚至是收复TW时，我们
将受到从金融、政治、外交、贸易、技术等一系列的和不能预知的威胁。

由此，为保障个人的权益，我决定将自己的代码库逐渐迁移到gitee中来，以预防未来可能发生的某些事情。

前言

在将自有云服务器导入到coding中作为持续集成的云主机时，提示git版本太老，所以无法继续进行安装，所以参考一篇文章对Centos 7上的Git进行了重新安装升级。

查看当前服务器的git版本

1
2

[root@ce-88 ~]# git --version
git version 1.8.3.1

查看当前的系统版本

1
2

[root@ce-88 ~]# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

安装依赖

本次我们安装git使用编译源代码的方式安装，此前需要安装一些必要的依赖

1
2

[root@ce-88 ~]# yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel asciidoc
[root@ce-88 ~]# yum install  gcc perl-ExtUtils-MakeMaker