Posts

本文讲解如何使用 dns 授权方式申请 google cloud 证书，通过查阅官方文档可以得知可以使用 gcloud 和 Certificate Manager API 来申请证书，本文使用 gcloud 命令行工具来执行步骤。 创建 DNS 授权 第一步是创建 DNS 授权，使用以下命令来创建: gcloud certificate-manager dns-authorizations create AUTHORIZATION_NAME \ --domain="DOMAIN_NAME" gcloud certificate-manager dns-authorizations describe AUTHORIZATION_NAME 需要将 AUTHORIZATION_NAME 和 DOMAIN_NAME 分别替换为 dns 授权的名称和相应的域名。 先创建 dns 授权然后查看授权的详细信息 gcloud certificate-manager dns-authorizations create overstarry --domain="overstarry.vip" gcloud certificate-manager dns-authorizations describe overstarry 根据返回的 cname 信息，需要到相应的域名解析中添加 cname 记录. 创建引用 DNS 授权的 Google 管理的证书 接下来 创建引用 DNS 授权的 Google 管理的证书，使用以下命令创建: ...

最近在研究使用 google cloud 的 cdn 服务，本文就来讲解如何清除 cdn 的缓存。 本文介绍了几种清除cdn 缓存的方法。 google cloud console 清除 第一种也是最简单的，就是直接从 google cloud console 后台进行操作，我们打开 console 后台，选择网络服务， 点击负载均衡界面，选择我们要清除的cdn 缓存所使用的负载均衡器，点击缓存页面， 输入想要 cdn 节点清除的路径即可。过了一会，就可以看到操作成功，相应的文件已经失效。 Google Cloud CLI 命令 第二种方法是使用 Google Cloud CLI 使 cdn 缓存文件失效。 Google Cloud CLI 安装 该怎么安装 Google Cloud CLI 呢,有2个办法: 1) 直接下载安装二进制文件 2) 使用 Cloud Shell. 本文是使用 Cloud Shell 进行的操作。 使缓存内容失效 1 使用 gcloud compute url-maps list 列出目前所使用的负载均衡器 ...

今天我来讲讲如何备份 apisix 的数据,主要是路由、服务、上游等数据。本文中的 apisix 版本为 apisix 3.1.0版本。 接下来由我来介绍几种备份方法。 dashboard 导出备份 介绍的第一种方法是使用 apisix dashboard 进行数据导出，但这种方法有许多缺陷，只能导出 route 数据，其他服务、ssl数据都不能导出，而且新版本(3.0+)dashboard 导出的路由不包含上游服务的数据，不方便进行快速的路由迁移复制(我猜测可能是害怕上游服务信息不一致导致路由错误)。 接下来就来介绍如何进行导入导出。 1 我们打开 dashboard 2 选择要导出的路由，点击 export openapi 3 在新的 apisix dashboard 导入刚刚导出的 openapi 文件并填写相应的信息，导入成功后就可以看到导入的路由信息，相应路由的服务需要补充填写。 根据 admin api 编写相应的脚本 apisix 提供了各种route、service 的admin api 数据接口，我们可以根据官方提供的接口编写相应的脚本。 使用 etcd 备份方案 由于 apisix 默认采用 etcd 进行数据存储，我们可以备份 etcd 数据，到新的 apisix 集群导入备份的数据。 由于我对 etcd 的运维不太熟悉，想要了解 etcd 备份快照，可以查看这条链接。 小结 本文我介绍了3种将 apisix 数据导入导出的方法，3种方法各有各的优缺点，我们需要根据我们具体的情况来使用不同的方法。 ...

最近在研究 apisix 插件，想要研究插件的执行流程，为了了解插件的具体运行流程，查看了几种方法来调试:1. inspect plugin 2. 自定义插件调试 等等。 本文介绍了添加启用自定义插件。 简单修改插件 最近在研究 apisix 的 proxy-cache 插件，本文就以 proxy-cache 插件为例子来讲解 docker 环境下如何自定义插件。 我们先从 apisix 官方git库拷贝 proxy-cache 插件代码到本地文件夹。我们对插件的内容进行修改删除，并将插件名称修改为 proxy-cache2, 修改后的插件文件列表如下： 删除了内存缓存的相关内容，只保留了磁盘缓存的内容，并添加了一些日志记录好了解整个插件的整体流程。 apisix 添加自定义插件 接下来需要给 apisix 添加我们修改的 proxy-cache2 插件，通过查看容器的目录，我们需要将插件挂载到 /usr/local/apisix/apisix/plugins 目录下，我们修改 docker-compose 文件: version: "3" services: apisix: image: apache/apisix:${APISIX_IMAGE_TAG:-3.2.0-debian} restart: always volumes: - ./apisix_conf/config.yaml:/usr/local/apisix/conf/config.yaml:ro - ./apisix/plugins/proxy-cache2:/usr/local/apisix/apisix/plugins/proxy-cache2 - ./apisix_log://usr/local/apisix/logs depends_on: - etcd ##network_mode: host ports: - "9180:9180/tcp" - "9080:9080/tcp" - "9091:9091/tcp" - "9443:9443/tcp" - "9092:9092/tcp" networks: apisix: 我们添加 ./apisix/plugins/proxy-cache2:/usr/local/apisix/apisix/plugins/proxy-cache2 将本地的插件目录挂载进行容器中，重启 apisix。 ...

前言 最近有一个需求，需要配置一个路由，这个路由是子域名形式的，域名类似 xx.apps.overstarry.vip，我们需要根据子域名中的 xx 内容来请求同一个对象存储中不同的文件。 这个需求之前处理过，那时采用了 nginx 来处理主要路径的逻辑，apisix 直接请求 nginx 服务， 也就是大概这样的一种结构: apisix -> nginx -> oss。这次同样的需求，我决定采用2层结构，去除中间的 nginx 层，由 apisix 直接访问 oss 服务。 接下来我就来讲述处理的过程。 过程 使用 proxy-rewrite 处理这个需求，我第一反应是使用 proxy-rewrite 插件来处理，我使用 regex_uri 字段来进行正则替换匹配，添加的插件内容如下: "proxy-rewrite": { "regex_uri": [ "^(.*).apps0.overstarry.vip(.*)$", "/$1/production$2" ] } 配置完后，请求了几次，发现没有请求成功，通过查看日志发现请求到了奇怪的地址。又仔细的研究了一会，发现是我理解错误了，proxy_rewrite 是根据 uri 进行正则匹配的，没有根据 host 匹配的选项，前面填写的那些是根本不会匹配成功的。 serverless proxy-rewrite 插件不能实现我们的需求，我又查看了 issue列表，发现了一个issue(#7739),里面提到了可以使用插件 serverless 来实现我们的需求。 serverless 介绍 APISIX 有两个 serverless 插件：serverless-pre-function 和 serverless-post-function。 serverless-pre-function 插件会在指定阶段开始时运行，serverless-post-function 插件会在指定阶段结束时运行。这两个插件使用相同的属性。 实现 我们的需求应该是采用 serverless-pre-function 来实现，具体过程描述如下：获得请求的 host, 对 host 进行相应的文本正则替换，将替换的文本和uri 进行组合拼接，得到真正的uri. ...

前言 最近在给 APISIX 配置自动更新 SSL 证书的时候，发现了一些问题，本文记录以下发现问题的过程和解决方案。 步骤 我们先来看下原始的配置方法吧: 1 安装相应脚本 $ curl --output /root/.acme.sh/renew-hook-update-APISIX.sh --silent https://gist.githubusercontent.com/anjia0532/9ebf8011322f43e3f5037bc2af3aeaa6/raw/65b359a4eed0ae990f9188c2afa22bacd8471652/renew-hook-update-APISIX.sh $ chmod +x /root/.acme.sh/renew-hook-update-APISIX.sh $ /root/.acme.sh/renew-hook-update-APISIX.sh Usage : /root/.acme.sh/renew-hook-update-APISIX.sh -h <APISIX admin host> -p <certificate pem file> -k <certificate private key file> -a <admin api key> -t <print debug info switch off/on,default off> 2 安装 acme.sh curl https://get.acme.sh | sh -s [email protected] 3 申请证书,并添加renew-hook 这里我采用的是 dns api的方式申请证书的 ~/.acme.sh/acme.sh --issue --dns dns_ali -d *.xx.com --renew-hook '~/.acme.sh/renew-hook-update-APISIX.sh -h http://127.0.0.1:9280 -p ~/.acme.sh/"*.xx.com_ecc"/"fullchain.cer" -k ~/.acme.sh/"*.xx.com_ecc"/"*.xx.com.key" -a {admin-key}' --log --debug 这里的 http://127.0.0.1:9280 是你的 APISIX 的 admin 接口地址，admin-key 是你的 key。 ...

最近在学习常用的容器运行时 containerd, 本篇我就来介绍如何本地构建 containerd 进行调试开发，主要介绍2种 常规方式和使用容器构建，由于本地环境限制，我主要是使用 docker 搭建本地调试环境。 非容器 build 这里先开始介绍常规直接从源码本地构建的方式。 构建环境要求 1 go1.19.x及以上版本 2 Protoc 3.x+ 3 适用于您的发行版的 Btrfs 标头和库。请注意，可以通过构建标签禁用构建 btrfs 驱动程序no_btrfs，从而删除此依赖项。 前面2点相信大家都很清楚，第三点的 Btrfs 是什么呢？Btrfs是一种现代的Linux写时复制（COW）文件系统，旨在实现先进的功能，同时也注重容错、修复和简易管理。 build 1 拉取containerd 源代码至本地 2 构建 进入源代码根目录，执行一下命令: cd containerd make 执行后，会在 ./bin/ 目录下生成所有项目的二进制文件。 如果你需要修改 gRPC API ,修改后需要使用 protoc 编译生成新的代码: make generate docker 容器构建 接下来讲解怎么通过 docker 构建本地 containerd 调试环境。 构建要求 1 go1.19.x及以上版本 2 Protoc 3.x+ 3 docker 构建 进入源代码根目录 cd containerd， 执行以下命令: docker run -it -v ${PWD}/containerd:/go/src/github.com/containerd/containerd -e GOPATH=/go -w /go/src/github.com/containerd/containerd golang:1.19 make && make install 这将会进行 containerd 的构建，过了一会发现构建失败,错误信息如下: ...

介绍 containerd 是一个用于管理容器生命周期的开源容器守护程序，是 Docker 引擎中的核心组件之一。它负责容器的创建、启动、停止、销毁等操作，并提供了对容器的基本管理功能，如镜像管理、网络管理、存储管理等。与 Docker 引擎相比，containerd 更加轻量级，同时也支持多种容器运行时，如 runc、gVisor、Kata Containers 等。由于其简单、可扩展和可移植等优点，containerd 也成为了许多容器平台和工具的基础组件之一。 安装 本文只介绍 Linux 系统下的安装方式。 Linux 下的 deb 和 rpm 包 containerd.io 由 docker 官方进行分发，通过查阅官方文档，具体的安装步骤如下： 1 更新 apt 软件包索引并安装必要的软件包，以便 apt 能够使用 HTTPS 仓库。 sudo apt-get update sudo apt-get install \ ca-certificates \ curl \ gnupg \ lsb-release 2 添加 Docker’s 官方 GPG key: sudo mkdir -m 0755 -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg 3 设置存储库 ...

今天我来简单介绍 kubernetes 生态中一个重要一环-包管理工具 Helm。 介绍 Helm 是 Kubernetes 的开源包管理器。它提供了提供、共享和使用为 Kubernetes 构建的软件的能力。 Helm 于 2015 年在 Deis 创建，后来被微软收购。现在称为 Helm Classic 的是在当年 11 月的首届 KubeCon 上推出的。2016 年 1 月，Helm Classic 与谷歌的 Kubernetes 部署管理器合并到现在是 Helm 主要项目的存储库中。 该项目目前拥有超过 30,000 个 GitHub stars，每月从全球获得超过 200 万次下载。2020 年 4 月，Helm 在 CNCF 中获得毕业。 安装 Helm 二进制安装 1 打开 https://github.com/helm/helm/releases , 下载你需要的版本 2 解压安装包 3 将文件夹中的 helm 二进制文件移动到相应的位置 脚本安装 helm 官方提供了一个安装的脚本: $ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 $ chmod 700 get_helm.sh $ ./get_helm.sh 除了以上2种安装方式，你还可以通过各个操作系统的包管理工具安装和编译源码安装，这里就不过多赘述了。 ...

最近一台 Ubuntu 出现了网络问题，ping baidu.com 出现了 temporary failure in name resolution 报错，根据我的经验这是服务器的 DNS 出现了问题，特此在本文记录一下如何设置 DNS 的过程. 修改 netplan 配置文件 我先尝试修改 netplan 的配置文件，编辑相应的配置文件，我这里的路径是 /etc/netplan/00-installer-config.yaml, 修改后的内容如下: network: ethernets: ens160: addresses: - 192.168.1.51/24 gateway4: 192.168.1.1 nameservers: addresses: - 114.114.114.114 search: [] version: 2 修改后执行 netplan apply, 重新 ping 后发现没有效果，未能解决问题。 修改 /etc/resolv.conf 我们还可以通过修改 /etc/resolv.conf 文件来设置 dns, 虽然通过修改此文件可以解决我们的问题，但编辑 /etc/resolv.conf 文件时，发现了一行注释 This file is managed by man:systemd-resolved(8). Do not edit. 可以得知这个文件是由man:systemd-resolved(8) 管理，/etc/resolv.conf 是一个动态生成的文件， 下次重启服务器时此文件还会恢复到默认的内容，所以此方案只适合临时解决，不能一次性解决问题。 接下来我来介绍如何永久的修改 /etc/resolv.conf 修改 /etc/systemd/resolved.conf 文件 # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # # Entries in this file show the compile time defaults. # You can change settings by editing this file. # Defaults can be restored by simply deleting this file. # # See resolved.conf(5) for details [Resolve] DNS=114.114.114.114 8.8.8.8 #FallbackDNS= #Domains= #LLMNR=no #MulticastDNS=no #DNSSEC=no #DNSOverTLS=no #Cache=no-negative #DNSStubListener=yes #ReadEtcHosts=yes ~ ~ ~ ~ ~ ~ ~ 添加要修改的 dns 信息。 ...