kong

centos7下安装kong

由 ⅰ亾dé卋堺 提交于 2019-12-01 23:29:45
参考：https://www.cnblogs.com/duanxz/p/10364783.html 1、已经安装好postgresql，可以参考这个博客 https://www.cnblogs.com/stulzq/p/7766409.html 2、碰到的问题 2.1 如果报错错误: 函数 to_regclass(unknown) 不存在 (12) 参考 https://www.lijiaocn.com/%E9%97%AE%E9%A2%98/2018/09/29/kong-usage-problem-and-solution.html, postgresql版本升级就可以。sudo yum install https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-centos10-10-1.noarch.rpm#sudo yum install https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-7-x86_64/pgdg-centos96-9.6-3.noarch.rpmkong migrations bootstrap 2.2 kong migrations up -c /etc/kong/kong.conf

k8s运维记 - 如何让部署到k8s的kong网关托管自定义静态资源？

由 元气小坏坏 提交于 2019-12-01 09:40:22
目的 使用kong作为目录 /data/reports 的静态资源服务器，为了测试，已于目录 /data/reports 下创建文件 report.html ，如下： <html> <head></head> <body><h1>测试报告</h1></body> </html> 一、编写nginx自定义模板 获取kong自定义的nginx配置 [root@justmine ~]# kubectl -n [kong所在的命名空间] exec -it [kong pod完全限定名] sh [root@justmine ~]# cat /usr/local/kong/nginx.conf 将 nginx.conf 内容复制出来，新的 nginx 模板将在此内容上进行修改，避免修改后无法启动kong容器。 添加托管静态资源配置 worker_processes auto; daemon off; pid pids/nginx.pid; error_log /dev/stderr notice; worker_rlimit_nofile 65536; events { worker_connections 16384; multi_accept on; } http { include 'nginx-kong.conf'; # 上面为kong本身配置，下面为提供静态资源的配置。 server

Kong07-自定义 Kong 插件

由 可紊 提交于 2019-11-30 16:51:36
在进一步讨论之前，有必要简要说明 Kong 是如何构建的，特别是它是如何与 Nginx 集成的，以及 Lua 与它有什么关系。 在 Nginx 中，lua-nginx-module 模块支持 Lua 脚本功能。Kong 没有使用这个模块编译 Nginx，而是与 OpenResty 一起发布，OpenResty 已经包含了 lua-nginx-module 模块。OpenResty 不是Nginx的分支，而是扩展其功能的一组模块。 因此，Kong 是一个 Lua 应用程序，旨在加载和执行 Lua 模块(我们通常将其称为“插件”)，并为它们提供一个完整的开发环境，包括SDK、数据库抽象、迁移等等。 插件由Lua模块组成，这些模块通过插件开发工具包(或“PDK”)与请求/响应对象或流交互，以实现任意逻辑。PDK 是一组 Lua 函数，插件可以使用这些函数促进插件与 Kong 的核心(或其他组件)之间的交互。 本指南将详细探讨插件的结构、它们可以扩展什么以及如何分发和安装它们。有关 PDK 的完整参考资料是 Plugin Development Kit 。 来源： https://www.cnblogs.com/erdongx/p/11604874.html

Kong04- Kong 四大参考说明

由 让人想犯罪 __ 提交于 2019-11-30 16:51:02
Kong 四大参考说明 Kong 的官方有很多详细的参考说明，比如配置文件、命令行、Admin API、代理、负载均衡，接下来我们简单看一下，都提供什么内容。 本文主要基于 Kong 1.3 版本进行描述，如有更新，请查看最新文档。 配置文件 通过对配置文件的 深入理解，可以优化 Kong 集群、使用的数据库、配置 Nginx ， 官方的参考资料是 Configuration Reference Kong 在启动时，可以通过 -c 或者 --conf 参数来指定配置文件，比如： kong start -c /path/to/kong.conf 可以使用 check 命令来校验配置文件的语法正确性， $ kong check <path/to/kong.conf> configuration at <path/to/kong.conf> is valid Kong 的配置在加载的时候也会去找同名的环境变量，所有也可以通过环境变量来配置 Kong，而且环境变量的优先级高于配置文件。可以通过环境变量来配置 Kong 这样方便了基于容器的部署和运行。如果要使用环境变量，需要以 KONG_ 字段开头。 命令行参考 所提供的CLI(命令行接口)允许您启动、停止和管理 Kong 实例。CLI 可以管理本地节点(如在当前机器上)。可以参考官网文档 CLI Reference 主要由如下命令

Kong05-Kong 的健康检查和监控

由 狂风中的少年 提交于 2019-11-30 16:50:48
您可以让 Kong 代理的 API 使用 ring-balancer ， 通过添加包含一个或多个目标实体的upstream 实体来配置，每个目标指向不同的IP地址(或主机名)和端口。ring-balancer 将在不同的target之间平衡负载，并基于 uptream 配置对目标执行健康检查，使它们成为健康或不健康的，无论它们是否响应，ring-balancer 将只把流量路由到健康的target。 Kong 支持两种健康检查方式，可以单独使用，也可以组合使用。 active checks：其中定期请求目标中的特定 HTTP 或 HTTPS 端点，并根据其响应确定目标的健康状态; passive checks： Kong 分析正在代理的通信，并根据目标的行为响应请求来确定目标的健康状况。 健康和不健康的 target 健康检查功能的目标是为给定的 Kong 节点动态地将 target 标记为健康或不健康。没有集群范围内的健康信息同步，每个 Kong 节点分别确定其 target 的健康状况。这是可以取到的，因为在给定的点上，一个 Kong 节点可能能够成功地连接到一个目标，而另一个节点则无法到达。这样第一个节点将认为它是健康的，而第二个则会将其标记为不健康，并开始将流量路由到upstream 的其他 target。 无论是主动探测(针对主动健康检查)还是代理请求(针对被动健康检查)

Kong06-Kong 的集群怎么用

由 佐手、 提交于 2019-11-30 16:50:39
Kong 集群允许您通过添加更多的机器来处理更多的传入请求来横向扩展系统。它们将共享相同的配置，因为它们指向相同的数据库。指向相同数据存储的 Kong 节点将属于相同的 Kong 集群。 您需要在Kong集群前面安装一个负载平衡器，以便在可用节点之间分配流量。 Kong 集群可以做什么，不能做什么 拥有一个 Kong 集群并不意味着你的客户机流量将在您的 Kong 节点之间实现开箱即用的负载平衡。你仍然需要在Kong节点前安装一个负载平衡器来分配流量。相反，Kong集群意味着这些节点将共享相同的配置。 出于性能原因，Kong在代理请求时避免数据库连接，并将数据库的内容缓存到内存中。缓存的实体包括服务、路由、消费者、插件、凭证等……由于这些值都在内存中，因此通过其中一个节点的管理API所做的任何更改都需要传播到其他节点。 本文档描述了如何使这些缓存的实体失效，以及如何为用例配置Kong节点，该用例介于性能和一致性之间。 单节点集群 单个的 Kong 节点连到数据库创建一个单节点的 Kong 集群。通过该节点的管理 API 应用的任何更改都将立即生效。 考虑一个单独的 Kong 节点A。如果我们删除之前注册的服务: $ curl -X DELETE http://127.0.0.1:8001/services/test-service 然后，任何对节点 A 的后续请求都会立即返回

Kong01-Kong 介绍

由 ▼魔方 西西 提交于 2019-11-30 16:50:04
概述 Kong 是在客户端和（微）服务间转发API通信的API网关，通过插件扩展功能。 Kong 的官方网站， https://konghq.com/kong Kong 的官方 Github 站点： https://github.com/kong/kong Kong 有两个主要组件： Kong Server ：基于 nginx 的服务器，用来接收 API 请求。 Apache Cassandra ：用来存储操作数据。 Kong 的数据存储支持两个组件，Cassandra 和 PostgreSQL 。 Kong 官方推荐的 GUI 工具叫 Kong-Dashboard，但是友好度不太好。 Kong 还有一个 GUI 的工具叫做 KongA，GitHub 地址是 https://github.com/pantsel/konga 。 你可以通过增加更多 Kong Server 机器对 Kong 服务进行水平扩展，通过前置的负载均衡器向这些机器分发请求。根据文档描述，两个Cassandra节点就足以支撑绝大多数情况，但如果网络非常拥挤，可以考虑适当增加更多节点。 对于开源社区来说，Kong 中最诱人的一个特性是可以通过插件扩展已有功能，这些插件在 API 请求响应循环的生命周期中被执行。插件使用 Lua 编写，而且 Kong 还有如下几个基础功能：HTTP 基本认证、密钥认证、CORS（

Kong02-KongA 介绍

由 半世苍凉 提交于 2019-11-30 16:49:36
KongA 是 Kong 的一个 GUI 工具。GitHub 地址是 https://github.com/pantsel/konga 。 KongA 概述 KongA 带来的一个最大的便利就是可以很好地通过UI观察到现在 Kong 的所有的配置，并且可以对于管理 Kong 节点情况进行查看、监控和预警，KongA 主要特性如下： 多用户管理 管理多个 Kong 节点 电子邮件异常信息通知 管理所有Kong Admin API 使用快照备份，还原和迁移Kong节点 使用运行状况检查监控节点和API状态 轻松的数据库集成（MySQL，postgresSQL，MongoDB） KongA 当前最新版本是 v0.14.1（update：2019.01.28），KongA 从 v0.14.0 开始，只支持 Kong 大于 v1.0.0 的版本。如果 Kong 的版本低于 v1.0.0 ，需要使用 konga:legacy 分支去构建发布版本。 KongA 的使用依赖如下内容： 一个安装好，处于运行状态的 Kong Nodejs >= 8 （推荐使用 8.11.3 LTS 版本） Npm KongA 的安装参考它在 GitHub 上的 Installation 即可。 如果使用 Docker 进行安装的话，使用 Kong 创建的 Docker 网络，启动命令如下： docker run -p

Kong/Konga - Docker容器化安装

由 本秂侑毒 提交于 2019-11-30 08:02:44
1.0 安装kong + postgresDB docker network create kong-net docker pull postgres:latest docker run -d --name kong-database \ --network=kong-net \ -p 5432:5432 \ -e "POSTGRES_USER=kong" \ -e "POSTGRES_DB=kong" \ postgres:latest 压缩版： docker run -d --name kong-database --network=kong-net -p 5432:5432 -e "POSTGRES_USER=kong" -e "POSTGRES_DB=kong" postgres:latest docker pull kong:latest docker run --rm \ --network=kong-net \ -e "KONG_DATABASE=postgres" \ -e "KONG_PG_HOST=kong-database" \ kong:latest kong migrations bootstrap 压缩版： docker run --rm --network=kong-net -e "KONG_DATABASE=postgres" -e "KONG_PG

通过Kong实现金丝雀发布

由 会有一股神秘感。 提交于 2019-11-28 16:12:13
金丝雀发布（Canary Releases）的由来 17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。 Kong的金丝雀发布简述 金丝雀发布又称灰度发布，是指在我们的生产环境中划分出一部分节点为灰度节点，当上新版本的时候，先上灰度环境并且会切换一部分流量过来，当灰度环境的流量都没有问题的时候，就会在整个生产环境上新版本。 我理解的可能有问题，请留言或者进群讨论一下 Kong的金丝雀发布的实现 假设生产环境的状况如下： 创建upstream upstreams/ POST { "name":"xjj.tv.com" } 创建target #灰度版本的target /upstreams/b7208664-4c0b-4c64-98a2-683594bb1bfd/targets POST { "target":"172.16.0.92:8899", "weight": 0 } #生产版本 /upstreams/b7208664-4c0b-4c64-98a2-683594bb1bfd/targets POST { "target":"172.16.0.92
订阅 kong