APISIX

最近使用 Apisix 网关时，需要开启 gzip 功能，通过查阅资料学习，了解了几种开启 gzip 的方式，本文记录 2 种 Apisix 开启 gzip 的方式。 gzip 插件 我们可以使用 gzip 插件 针对某些路由开启 gzip，只需对路由使用 gzip 插件并配置一些插件属性即可。 接下来使用一个例子来演示 gzip 插件，使用 apisix admin api 创建一条路由，要注意的是本文的例子是使用 apisix 3.7 版本： curl -i http://127.0.0.1:9180/apisix/admin/routes \ -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X POST -d ' { "uri": "/get", "plugins": { "gzip": { "buffers": { "number": 8 }, "comp_level": 6, "disable": false, "types": "*" } }, "upstream": { "nodes": [ { "host": "httpbin.org", "port": 443, "weight": 1 } ], "timeout": { "connect": 6, "send": 6, "read": 6 }, "type": "roundrobin", "scheme": "https", "pass_host": "pass", "keepalive_pool": { "idle_timeout": 60, "requests": 1000, "size": 320 } }, "status": 1 }' ...

最近需要使用 apisix 来代理 gRPC 服务，本文记录一下 apisix 代理 gRPC 服务以及实践过程中遇到的一些问题。 准备 在接下来的步骤前，我们需要准备一个 gRPC 服务，我们使用 kratos 简单启动一个 gRPC 服务： $ kratos new hellowrold $ cd helloworld $ kratos run 一个简单的 gRPC 服务就启动了，我们先直接请求 gRPC 服务看看，通过 postman 请求接口后，接口顺利返回相应的值。 接下来我们开始本篇的主要内容：apisix 代理服务。 apisix 代理 gRPC 服务 我们使用 apisix admin 接口创建 Route: upstream 的 scheme 指定为 grpc 或 grpcs,nodes 指定需要代理的服务地址。 curl http://127.0.0.1:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "methods": ["POST", "GET"], "uri": "/helloworld.v1.Greeter/SayHello", "upstream": { "scheme": "grpc", "type": "roundrobin", "nodes": { "127.0.0.1:9001": 1 } } }' ...

前言 最近需要忽略请求 uri 大小写，即不管 uri 的大小写都返回小写 uri 所请求的响应内容，例如请求 xx.vip/A 实际请求 xx.vip/a, 本文主要以 apisix 来讲解如何实现这个功能。 解决 遇到这个需求，首先肯定采用 apisix 的插件来实现，根据前面多次的经验，这个功能应该可以使用 serverless 插件中的 serverless-pre-function 插件来实现，具体的流程如下： 1 获取请求的 uri 2 将 uri 转为小写 3 修改请求的 uri 具体的插件内容如下： "serverless-pre-function": { "_meta": { "disable": false }, "functions": [ "return function(conf, ctx) local uri = ctx.var.uri;ctx.var.uri= string.lower(uri);ngx.log(ngx.ERR, \"match uri \", ctx.var.uri ); end" ], "phase": "rewrite" } 添加插件后，再次请求路径，发现请求结果还是没有变，查看日志发现 uri 修改成功了，不知为何还是没有修改成功。 后面又仔细研究了 proxy-rewrite 插件中修改 uri 的代码，发现它是使用了 nginx 标准的函数 ngx.req.set_uri 来赋值新的 uri。 ...

前言 前段时间在使用 apisix 添加路由时，需要将 http 转为 https, 在配置 http_to_https 后，访问相应网址时发现 https 的端口不是我们所配置的默认端口 443，而是 9443 端口。 可以看到访问 http://localhost 会跳转至错误的地址：https://localhost:9443/ ,正确的地址应该是 https://localhost，这是怎么回事呢？ 分析 接下来我来简单对问题进行简单分析。 我是采用 docker 的方式部署的 apisix，这是我们的配置文件： version: "3" services: apisix-dashboard: image: apache/apisix-dashboard:3.0.0-alpine restart: always volumes: - ./dashboard_conf/conf.yaml:/usr/local/apisix-dashboard/conf/conf.yaml ports: - "9000:9000" networks: apisix: 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 depends_on: - etcd ##network_mode: host ports: - "9180:9180/tcp" - "80:9080/tcp" - "9091:9091/tcp" - "443:9443/tcp" - "9092:9092/tcp" networks: apisix: etcd: image: bitnami/etcd:3.4.15 restart: always volumes: - etcd_data:/bitnami/etcd environment: ETCD_ENABLE_V2: "true" ALLOW_NONE_AUTHENTICATION: "yes" ETCD_ADVERTISE_CLIENT_URLS: "http://etcd:2379" ETCD_LISTEN_CLIENT_URLS: "http://0.0.0.0:2379" ports: - "2379:2379/tcp" networks: apisix: web1: image: nginx:1.19.0-alpine restart: always volumes: - ./upstream/web1.conf:/etc/nginx/nginx.conf ports: - "9081:80/tcp" environment: - NGINX_PORT=80 networks: apisix: networks: apisix: driver: bridge volumes: etcd_data: driver: local 可以看到我们将 apisix 容器的 http 端口和 https 端口映射为 80 和 443，按照常理来说，http_to_https 后的端口应该也是 443 端口才对。我猜测重定向时，apisix 还是采用配置文件中设定的 https 端口才导致跳转的 url 端口错误。 ...

今天我来讲讲如何备份 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 备份快照，可以查看这条链接。 ...

最近在研究 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。 ...

本文我来讲解如何使用 APISIX 来代理 PostgreSQL 数据库服务。 初试 最开始我以为很简单，我采用了直接在 APISIX DashBoard 上配置了一条路由，配置好后，连接发现无法成功连接，提示连接失败。 经过仔细的思考，发现 PostgreSQL 是使用 TCP 协议的数据库，不能通过简单的 route 进行配置，必须使用 stream-proxy 进行代理，接下来我们来看看怎么样来进行配置。 stream-proxy TCP 是许多流行应用程序和服务的协议，例如 LDAP、MySQL 和 RTMP。UDP（用户数据报协议）是许多流行的非事务性应用程序的协议，例如 DNS、系统日志和 RADIUS。 APISIX 可以动态负载平衡 TCP/UDP 代理。在 Nginx 的世界里，我们把 TCP/UDP proxy 称为 stream proxy，APISIX 就遵循了这个说法。 启用 stream-proxy 要开启 APISIX 流代理需要在 APISIX 配置中开启，APISIX 默认是关闭的。 apisix: stream_proxy: # TCP/UDP proxy tcp: # TCP proxy address list - 9100 - "127.0.0.1:9101" udp: # UDP proxy address list - 9200 - "127.0.0.1:9211" 如果 apisix.enable_admin 为 true，则 HTTP 和流代理都启用了上述配置。 ...

前言 最近需要使用 apisix 反向代理 oss, 实现通过域名访问相应的资源 (由于条件的限制，不能在 oss 绑定自定义域名)，我直接在 apisix dashboard 配置了路由，创建成功后，我通过浏览器访问时，发现资源不能预览会直接下载。 这样的现象让我很奇怪，通过查阅相关资料，发现使用 OSS 默认域名通过文件 URL 从浏览器访问图片或者网页文件时，Response Header 中会自动加上 Content-Disposition:attachment。即从浏览器访问这些文件时，会以附件形式进行下载。 解决 通过询问同事，得知他是通过 nginx 的 proxy_hide_header 忽略 Content-Disposition 解决的。那 apisix 该怎么实现呢，我通过自己的不断尝试和提 issue 询问官方人员，得知可以使用 response-rewrite 插件实现这个功能。 接下来我就来介绍下我尝试的过程吧，我最开始是使用 proxy-rewrite 将 Content-Disposition 设置为 inline，具体配置如下： { "uri": "/*", "name": "xx", "host": "xixi.xx.work", "plugins": { "proxy-rewrite": { "headers": { "Content-Disposition": "inline" }, "host": "xx", "regex_uri": [ "/(.*)$", "/xx/${1}" ] } }, "upstream": { "nodes": [ { "host": "xxx.com", "port": 80, "weight": 1 } ], "timeout": { "connect": 6, "send": 6, "read": 6 }, "type": "roundrobin", "scheme": "http", "pass_host": "pass", "keepalive_pool": { "idle_timeout": 60, "requests": 1000, "size": 320 } }, "status": 1 } curl 结果： ...