标签归档:Lua

Kong 2.0 正式发布!

从上一次主要开源版本发布以来,经过整整一年的发展,我们很荣幸地宣布旗舰开源API网关的下一个章节 – Kong Gateway 2.0全面上市!

混合模式部署(Hybrid Mode Deployment)

混合模式也称为Control Plane/Data Plane分离(CP / DP),它可以将Kong的代理有效,安全地部署在任何地方,然后可以从单个点(Control Plane)控制整个群集。在这种模式下,Data Plane节点不连接到数据库。而是根据需要由控制平面管理和推送其配置。此功能可显着提高大型Kong群集的安全性和性能,同时降低运营成本。要开始混合模式部署,请参考混合模式文档

支持 golang的PDK

Lua是用于编写Kong插件的实际使用的语言。虽然Lua的性能良好且非常易于嵌入,但它在开发人员体验,第三方库和普遍欢迎方面都达不到要求。在2019年Kong Summit峰会期间,我们透露了对Go的Go插件支持,从而使开发人员可以使用Go完全开发其插件。

为了帮助开发人员入门,我们还准备了Go Plugin Development GuideGo Plugin Development Kit(PDK)文档。我们迫不及待想看看开发人员将与他们一起做什么!

ACME (Let’s Encrypt) 加密支持

在过去的几年中,我们看到了行业中端到端加密的强劲推动。如今,由于服务具有自动配置和管理TLS证书的功能,因此服务的HTTPS加密已被视为一种商品,而不是一种奢侈。我们很自豪地宣布,由于新的自动证书管理环境(ACME)v2协议支持和Let’s Encrypt集成,在Kong Gateway 2.0中,端到端HTTPS比以往更加容易。只需启用插​​件,Kong便会负责整个证书管理生命周期。有兴趣尝试可以查看ACME插件文档

其他改进

请注意,以上列表仅涉及此版本中的部分功能/修复!有关更改的完整列表,我们建议您也阅读2.0.0更改日志

Prometheus 插件性能

由于我们的工程团队一直在进行一些巧妙的调整,因此Prometheus插件现在可以以几乎两倍的速度(按每秒请求数)运行。

扩展支持 NGINX Directive 注入

httpstream子系统添加了新的注入上下文,从而减少了编写自定义NGINX模板的需要,并为用户提供了更好的升级兼容性。

Kubernetes 兼容性

最新的Kong for Kubernetes 0.7版本与开箱即用的Kong Gateway 2.0兼容。立即开始使用Kong for Kubernetes!

升级路径

随着2.0的发布,我们还发布了Kong Gateway 1.5,它充当了较旧版本的Kong Gateway和带有API实体到服务/路由迁移工具的新2.x系列之间的桥梁。

不支持从0.x版本的Kong Gateway直接升级到2.x。而是,这些用户应先从0.x升级到1.5,然后再升级到2.0.0。

从现在开始,我们正式放弃对0.x版本的支持。

下一步

不用说,Kong 员工和我们出色的社区贡献者为此发布付出了多少工作。 Kong Gateway 2.0.0现已开始下载,我们鼓励所有人尝试一下。与往常一样,请通过Kong与我们分享有关Kong Nation的反馈,并查看我们将来的社区活动以与我们建立联系。

Happy Kong!





Kong 1.4 发布!自动检测Cassandra Topology 更改,自定义Host Header以及更多功能!

原文地址:https://konghq.com/blog/kong-gateway-1-4-released-auto-detect-cassandra-topology-changes-custom-host-header-much/

我们很高兴地宣布1.4系列的第一个版本已经发布! 我们的工程团队和出色的社区成员在此版本中添加了许多新功能,改进和修复。

请阅读以下内容,了解Kong Gateway 1.4中最相关的更改以及如何充分利用这些新增功能。 有关完整的详细信息,请参阅更改日志;有关如何从以前的Kong版本进行升级的说明,请参阅升级路径

自动检测Cassandra Topology 更改

从Kong Gateway 1.4开始,将自动检测对Apache Cassandra群集拓扑所做的任何更改,从而避免Kong重新启动。

如何利用此新功能:

新的配置cassandra_refresh_frequency设置在检查Cassandra集群拓扑结构更改之前,Kong必须等待多长时间。默认频率是每60秒检查一次,但是可以根据需要增加、减少甚至禁用这个值。

上游的Hostname属性

Kong中定义的任何上游现在都可以使用一个名为hostname的可选属性,该属性定义在通过Kong服务器代理连接时将使用的Host header。

主要优点:

服务器通常会监听与解析名称不同的服务器名称,并且此新属性可以保证Kong在代理连接和积极检查主机的运行状况时将使用正确的名称。

DAO属性的新变更

新的属性转换已添加到DAO模式中,使开发人员能够添加在插入或更新数据库条目时运行的函数

新的状态接口

通过新的状态接口,插件可以将端点添加到已经存在的/status端点,从而公开不敏感的健康数据,从而避免公开Kong的管理API。

主要优点

  • 用户可以同时公开Kong的健康数据并保护Kong的Admin API。
  • 对于使用禁用的管理界面运行的Kong节点,执行基于HTTP的运行状况检查更加容易。

Kong Gateway 1.4中的其他新功能

新的Admin API响应headerX-Kong-Admin-Latency

  • 这个新的响应header报告了对Kong的Admin API的每个请求处理了多长时间。

新的配置选项router_update_frequency

  • 这个新的配置选项允许设置检查路由器和插件更改的频率。
  • 这样可以避免在频繁更改Kong路由或插件时性能下降。
  • 此选项使管理员可以选择延迟路由器和插件配置更改的可用性,还是增加数据库负载。

限速插件中的Service-level 支持

  • 除了使用者,凭证和IP级别外,限速插件现在还具有服务级别的支持。

Kong Gateway 1.4中的其他改进和错误修复

Kong Gateway 1.4还改善了限速插件内存的使用,使用共享字典的TTL终止了其local策略计数器,以避免在内存中保留不必要的计数器。

此版本中存在一些重要的错误修复,例如服务网格弃用的开始,它将被替换为Kuma(kuma.io)向前发展。 已知服务网格会导致向上游的HTTPS请求忽略proxy_ssl *指令,因此在Kong Gateway的下一个主要版本中将停止使用该服务网格。 在此版本中,默认情况下禁用此功能,以避免出现此问题,并且仍可以使用新的配置选项service_mesh启用它。

另一个相关的修复与使用日志插件记录NGINX产生的错误有关,该错误过去曾错误地将某些请求属性报告为请求方法,并且现在可以正常工作。

我们还解决了一个问题,即在删除所有Kong workers时,目标不能在所有Kong员工中正确更新的情况下,在频繁使用情况下,将流量与这些被删除目标进行了平衡。

与往常一样,此处提供Kong Gateway 1.4的文档。 此外,我们将在后续帖子和社区电话中讨论1.4中的关键功能,敬请期待!

感谢我们的用户,贡献者和核心维护者社区,感谢您对Kong开源平台的持续支持。

请尝试一下Kong Gateway 1.4,并确保让我们知道您的想法

Kong社区

像往常一样,随时在我们的社区论坛Kong Nation上提问。 从您的反馈中吸取教训,将使我们能够更好地了解关键任务用例并不断改进Kong。

Happy Konging!

在 CentOS 安装 Kong

安装包

首先下载配置的相应软件包:

企业试用用户应从其欢迎电子邮件中下载其包,并在步骤1之后将其许可保存到/etc/kong/license.json

YUM Repositories

你也可以通过YUM安装Kong;按照下面“Set Me Up”部分中的说明进行操作。

注意:确保生成的.repo文件的baseurl字段包含您的CentOS版本;例如:

baseurl=https://kong.bintray.com/kong-rpm/centos/6

或者

baseurl=https://kong.bintray.com/kong-rpm/centos/7

安装

  1. 安装Kong 如果要下载程序包,请执行:
     $ sudo yum install epel-release
     $ sudo yum install kong-1.3.0.*.noarch.rpm --nogpgcheck
    

    如果您正在使用存储库,请执行:

      $ sudo yum update -y
      $ sudo yum install -y wget
      $ wget https://bintray.com/kong/kong-rpm/rpm -O bintray-kong-kong-rpm.repo
      $ export major_version=`grep -oE '[0-9]+\.[0-9]+' /etc/redhat-release | cut -d "." -f1`
      $ sed -i -e 's/baseurl.*/&\/centos\/'$major_version''/ bintray-kong-kong-rpm.repo
      $ sudo mv bintray-kong-kong-rpm.repo /etc/yum.repos.d/
      $ sudo yum update -y
      $ sudo yum install -y kong
    
  2. 准备数据库或声明性配置文件 无论是否有数据库,Kong都可以运行。使用数据库时,您将使用 kong.conf 配置文件在启动时设置Kong的配置属性,并将数据库用作所有已配置实体的存储,例如Kong代理所在的 Routes 和 Services 。

    不使用数据库时,您将使用kong.conf的配置属性和kong.yml文件来将实体指定为声明性配置。

    使用数据库

    配置Kong以便它可以连接到您的数据库。Kong支持PostgreSQL 9.5+Cassandra 3.x.x作为其数据存储。

    如果您使用Postgres,请在开始Kong之前配置数据库和用户,即:

     CREATE USER kong; CREATE DATABASE kong OWNER kong;
    
    然后执行Kong的数据迁移:
    
      $ kong migrations bootstrap [-c /path/to/kong.conf]
    

    对于Kong 小于0.15的注意事项:如果Kong版本低于0.15(最高0.14),请使用up子命令而不是bootstrap。另请注意,如果Kong 小于0.15,则不应同时进行迁移;只有一个Kong节点应该一次执行迁移。对于0.15,1.0及以上的Kong,此限制被取消。

    不使用数据库

    如果要在无DB模式下运行Kong,则应首先生成声明性配置文件。以下命令将在当前文件夹中生成kong.yml文件。它包含有关如何填写它的说明。

     $ kong config init
    

    填写kong.yml文件后,编辑您的kong.conf文件。将数据库选项设置为off,将declarative_config选项设置为kong.yml文件的路径:

     database = off
      declarative_config = /path/to/kong.yml
    
  3. 启动Kong
     $ kong start [-c /path/to/kong.conf]
    
  4. 使用Kong Kong正在运行
      $ curl -i http://localhost:8001/

微服务 API 网关 Kong 插件 AWS Lambda 中文文档

从Kong调用 AWS Lambda函数。它可以与其他请求插件结合使用以保护,管理或扩展功能。

注意:此插件与0.14.0之前的Kong版本和0.34之前的Kong Enterprise捆绑在一起的功能与此处记录的功能不同。 有关详细信息,请参阅CHANGELOG

术语

  • plugin: 在请求被代理到上游API之前或之后,在Kong内部执行操作的插件。
  • Service: 表示外部 upstream API或微服务的Kong实体。
  • Route: 表示将下游请求映射到上游服务的方法的Kong实体。
  • Consumer: 代表使用API的开发人员或机器的Kong实体。当使用Kong时,Consumer 仅与Kong通信,其代理对所述上游API的每次调用。
  • Credential: 与Consumer关联的唯一字符串,也称为API密钥。
  • upstream service: 这是指位于Kong后面的您自己的 API/service,转发客户端请求。

配置

此插件与具有以下协议的请求兼容:

  • http
  • https

此插件与无DB模式兼容。

在 Service 上启用插件

使用数据库:

通过发出以下请求在Service上配置此插件:

$ curl -X POST http://kong:8001/services/{service}/plugins \
    --data "name=aws-lambda"  \
    --data-urlencode "config.aws_key=AWS_KEY" \
    --data-urlencode "config.aws_secret=AWS_SECRET" \
    --data "config.aws_region=AWS_REGION" \
    --data "config.function_name=LAMBDA_FUNCTION_NAME"

不使用数据库:

通过添加此部分在服务上配置此插件执行声明性配置文件:

plugins:
- name: aws-lambda
  service: {service}
  config: 
    aws_key: AWS_KEY
    aws_secret: AWS_SECRET
    aws_region: AWS_REGION
    function_name: LAMBDA_FUNCTION_NAME

在这两种情况下,{service}是此插件配置将定位的RouteID或名称。

在 Route 上启用插件

使用数据库:

通过发出以下请求在 Route 上配置此插件:

$ curl -X POST http://kong:8001/routes/{route}/plugins \
    --data "name=aws-lambda"  \
    --data-urlencode "config.aws_key=AWS_KEY" \
    --data-urlencode "config.aws_secret=AWS_SECRET" \
    --data "config.aws_region=AWS_REGION" \
    --data "config.function_name=LAMBDA_FUNCTION_NAME"

不使用数据库:

通过添加此部分在 Route 上配置此插件执行声明性配置文件:

plugins:
- name: aws-lambda
  route: {route}
  config: 
    aws_key: AWS_KEY
    aws_secret: AWS_SECRET
    aws_region: AWS_REGION
    function_name: LAMBDA_FUNCTION_NAME

在这两种情况下,,{route}是此插件配置将定位的 route 的idname

在 Consumer 上启用插件

使用数据库:

您可以使用http://localhost:8001/plugins在特定的Consumers上启用此插件:

$ curl -X POST http://kong:8001/consumers/{consumer}/plugins \
    --data "name=aws-lambda" \
     \
    --data-urlencode "config.aws_key=AWS_KEY" \
    --data-urlencode "config.aws_secret=AWS_SECRET" \
    --data "config.aws_region=AWS_REGION" \
    --data "config.function_name=LAMBDA_FUNCTION_NAME"

不使用数据库:

通过添加此部分在Consumer上配置此插件执行声明性配置文件:

plugins:
- name: aws-lambda
  consumer: {consumer}
  config: 
    aws_key: AWS_KEY
    aws_secret: AWS_SECRET
    aws_region: AWS_REGION
    function_name: LAMBDA_FUNCTION_NAME

在这两种情况下,{consumer}都是此插件配置将定位的Consumeridusername
您可以组合consumer_idservice_id 。 在同一个请求中,进一步缩小插件的范围。

全局插件

  • 使用数据库:可以使用http://kong:8001/plugins/配置所有插件。
  • 不使用数据库:可以通过plugins:配置所有插件:声明性配置文件中的条目。

与任何 Service ,Route 或 Consumer (或API,如果您使用旧版本的Kong)无关的插件被视为“全局”,并将在每个请求上运行。有关更多信息,请阅读插件参考插件优先级部分。

参数

以下是可在此插件配置中使用的所有参数的列表:

参数 默认值 描述
name 要使用的插件的名称,在本例中为aws-lambda
service_id 此插件将定位的 Service 的ID。
route_id 此插件将定位的 Route 的ID。
enabled true 是否将应用此插件。
consumer_id 此插件将定位的Consumer的id
config.aws_key 调用功能时要使用的AWS密钥凭证。
config.aws_secret 调用功能时要使用的AWS秘密凭证
config.aws_region Lambda函数所在的AWS区域。支持的区域是:us-east-1,us-east-2, ap-northeast-1,ap-northeast-2, ap-southeast-1, ap-southeast-2, eu-central-1, eu-west-1
config.function_name 要调用的AWS Lambda函数名称
config.qualifier 
optional
调用功能时要使用的 Qualifier 
config.invocation_type 
optional
RequestResponse 调用函数时要使用的 InvocationType。可用类型为RequestResponseEventDryRun
config.log_type 
optional
Tail 调用函数时要使用的LogType。默认情况下,不支持noneTail
config.timeout 
optional
60000 调用该函数时的可选超时(以毫秒为单位)
config.keepalive 
optional
60000 可选值(以毫秒为单位),用于定义空闲连接在关闭之前将存活多长时间
config.unhandled_status 
optional
200,202  204 Unhandled Function Error时使用的响应状态代码(而不是默认的200202204
config.forward_request_body 
optional
false 一个可选值,用于定义是否在JSON编码请求的request_body字段中发送请求正文。如果可以解析正文参数,则将在请求的单独的request_body_args字段中发送它们。正文参数可以针对application/jsonapplication/x-www-form-urlencodedmultipart/form-data内容类型进行解析。
config.forward_request_headers
optional
false 一个可选值,用于定义是否将原始HTTP请求标头作为映射发送到JSON编码请求的request_headers字段中。
config.forward_request_method
optional
false 一个可选值,用于定义是否在JSON编码请求的request_method字段中发送原始HTTP请求方法动词。
config.forward_request_uri 
optional
false 一个可选值,用于定义是否在JSON编码请求的request_uri字段中发送原始HTTP请求URI。请求URI参数(如果有)将在JSON主体的单独的request_uri_args字段中发送。
config.is_proxy_integration 
optional
false 一个可选值,它定义是否将从Lambda接收的响应格式转换为此格式。请注意,未实现参数isBase64Encoded

提醒: 默认情况下,curl将发送带有application/x-www-form-urlencoded MIME类型的有效负载,该负载自然会由Kong进行URL解码。 为确保正确解码可能出现在您的AWS密钥或机密中的特殊字符(如+),您必须对其进行URL编码,因此如果使用curl,请使用--data-urlencode。 这种方法的替代方法是使用其他MIME类型(例如application/json)发送有效负载,或使用其他HTTP客户端。

发送参数

与请求一起发送的任何表单参数也将作为参数发送到AWS Lambda函数。

已知的问题

使用伪造的上游服务

使用AWS Lambda插件时,响应将由插件本身返回,而无需将请求代理到任何上游服务。 这意味着服务的host, port, path属性将被忽略,但仍必须为由Kong验证的实体指定。 主机属性尤其必须是IP地址,或者是由名称服务器解析的主机名。

响应插件

系统中存在一个已知限制,该限制会阻止执行某些响应插件。 我们计划将来删除此限制。

分步指南

步骤

  1. 以允许用户使用lambda函数操作以及创建用户和角色的用户身份访问AWS Console。
  2. 在AWS中创建执行角色
  3. 创建一个将通过Kong调用该功能的用户,对其进行测试。
  4. 在Kong中创建一个Service&Route,添加链接到我们的aws函数的aws-lambda插件并执行它。

配置

  1. 首先,让我们为lambda函数创建一个称为LambdaExecutor的执行角色。在IAM控制台中创建一个选择AWS Lambda服务的新角色,将没有任何策略,因为本示例中的函数将简单地执行自身,从而返回硬编码JSON作为响应,而无需访问其他AWS资源
  2. 现在,我们创建一个名为KongInvoker的用户,由我们的Kong API网关用来调用该函数。在IAM控制台中,创建一个新用户,必须通过访问和秘密密钥向其提供编程访问权限;然后将直接附加现有策略,尤其是预定义的AWSLambdaRole。确认用户创建后,将访问密钥和秘密密钥存储在安全的地方。
  3. 现在我们需要创建lambda函数本身,将在弗吉尼亚北部地区(代码us-east-1)进行。在Lambda Management中,创建一个新函数Mylambda,将没有蓝图,因为我们将在下面粘贴代码。对于执行角色,我们选择一个以前专门创建的LambdaExecutor角色使用下面的内联代码来返回简单的JSON响应,请注意,这是Python 3.6解释器的代码。
      import json
    def lambda_handler(event, context):
      """
        If is_proxy_integration is set to true :
        jsonbody='''{"statusCode": 200, "body": {"response": "yes"}}'''
      """
      jsonbody='''{"response": "yes"}'''
      return json.loads(jsonbody)
    

    从AWS控制台测试lambda函数,并确保执行成功。

  4. 最后,我们在Kong中设置了Service&Route,并将其链接到刚刚创建的功能。

使用数据库

curl -i -X POST http://{kong_hostname}:8001/services \
--data 'name=lambda1' \
--data 'url=http://localhost:8000' \

该Service并不需要真正的URL,因为我们不会对上游进行HTTP调用,而需要由函数生成的响应。

还要为 Service 创建一条 Route :

curl -i -X POST http://{kong_hostname}:8001/services/lambda1/routes \
--data 'paths[1]=/lambda1'

添加插件

curl -i -X POST http://{kong_hostname}:8001/services/lambda1/plugins \
--data 'name=aws-lambda' \
--data-urlencode 'config.aws_key={KongInvoker user key}' \
--data-urlencode 'config.aws_secret={KongInvoker user secret}' \
--data 'config.aws_region=us-east-1' \
--data 'config.function_name=MyLambda'

不使用数据库

将 Service, Route and Plugin 添加到声明性配置文件中:

services:
- name: lambda1
  url: http://localhost:8000

routes:
- service: lambda1
  paths: [ "/lambda1" ]

plugins:
- service: lambda1
  name: aws-lambda
  config:
    aws_key: {KongInvoker user key}
    aws_secret: {KongInvoker user secret}
    aws_region: us-east-1
    function_name: MyLambda

创建所有内容后,请调用服务并验证正确的调用,执行和响应:

curl http://{kong_hostname}:8000/lambda1

附加标题:

x-amzn-Remapped-Content-Length, X-Amzn-Trace-Id, x-amzn-RequestId

JSON响应:

{"response": "yes"}

充分利用AWS Lambda在Kong的强大功能,尽享乐趣!

使用源码安装 Kong

无论是否有数据库,Kong都可以运行。

使用数据库时,您将使用kong.conf配置文件在启动时设置Kong的配置属性,并将数据库用作所有已配置实体的存储,例如Kong代理所在的 Routes 和 Services 。

不使用数据库时,您将使用kong.conf的配置属性和kong.yml文件来将实体指定为声明性配置。

使用数据库

  1. 安装依赖项OpenResty 1.15.8.1。作为一个OpenResty应用程序,您必须遵循OpenResty安装说明。您将需要OpenSSL和PCRE来编译OpenResty,并至少使用以下编译选项:
      $ ./configure \
        --with-pcre-jit \
        --with-http_ssl_module \
        --with-http_realip_module \
        --with-http_stub_status_module \
        --with-http_v2_module
    

    您可能必须指定--with-openssl,并且可以添加任何其他您想要的选项,例如其他Nginx模块或自定义--prefix目录。

    OpenResty可以方便地捆绑LuaJITresty-cli,它们对于Kong来说是必不可少的。将nginx和resty可执行文件添加到$ PATH

      $ export PATH="$PATH:/usr/local/openresty/bin"
    

    Luarocks 3.1.3,使用与OpenResty捆绑的LuaJIT版本编译(请参阅--with-lua--with-lua-include配置选项)。例:

      ./configure \
        --lua-suffix=jit \
        --with-lua=/usr/local/openresty/luajit \
        --with-lua-include=/usr/local/openresty/luajit/include/luajit-2.1
    
  2. 安装 Kong现在已经安装了OpenResty,我们可以使用Luarocks来安装Kong的Lua源:
      $ luarocks install kong 1.3.0-0
    

    或者

      $ git clone git@github.com:Kong/kong.git
      $ cd kong
      $ [sudo] make install # this simply runs the `luarocks make kong-*.rockspec` command
    
  3. 添加kong.conf

    注意:如果您使用的是Cassandra,则需要执行此步骤;它是Postgres用户的可选项。

    默认情况下,Kong配置为与本地Postgres实例通信。 如果您使用的是Cassandra,或者需要修改任何设置,请下载kong.conf.default文件并根据需要进行调整。 然后,以root身份将其添加到/etc

      $ sudo mkdir -p /etc/kong
       $ sudo cp kong.conf.default /etc/kong/kong.conf
    
  4. 准备数据库配置Kong以便它可以连接到您的数据库。Kong支持PostgreSQL 9.5+Cassandra 3.x.x作为其数据存储。如果您使用的是Postgres,请在启动Kong之前配置数据库和用户:
     CREATE USER kong; CREATE DATABASE kong OWNER kong;
    

    接下来,运行Kong迁移:

      $ kong migrations bootstrap [-c /path/to/kong.conf]
    

    对于Kong < 0.15的注意事项:如果Kong版本低于0.15(最高0.14),请使用up子命令而不是bootstrap。另请注意,如果Kong < 0.15,则不应同时进行迁移;只有一个Kong节点应该一次执行迁移。对于0.15,1.0及以上的Kong,此限制被取消。

  5. 启动Kong
     $ kong start [-c /path/to/kong.conf]
    
  6. 使用KongKong正在运行
      $ curl -i http://localhost:8001/
    

不使用数据库

  1. 按照上面的列表中的步骤1和2(安装依赖项,安装Kong)。
  2. 写声明性配置文件以下命令将在当前文件夹中生成kong.yml文件。它包含有关如何填写它的说明。执行此操作时,请遵循[声明配置格式]:/1.3.x/db-less-and-declarative-config/#the-declarative-configuration-format说明。
      $ kong config init
    

    我们假设该文件名为kong.yml

  3. 添加kong.conf下载kong.conf.default文件并根据需要进行调整。特别是,确保将database配置选项设置为off,并将declarative_config选项设置为kong.yml的绝对路径
      database = off
      ...
      declarative_config = /path/to/kong.yml
    
  4. 启动Kong
     $ kong start [-c /path/to/kong.conf]
    
  5. 使用KongKong正在运行
      $ curl -i http://localhost:8001/

如何在 Kong 和 OpenResty 中使用环境变量 os.getenv()

在项目中有时会遇到使用系统环境变量的问题,但是直接使用 os.getenv() 是不可行的,不仅是在 Kong 中,在 OpenResty 也都是不可以的,原因是 Kong 是基于 OpenResty ,OpenResty 是基于 Nginx 的,而Nginx在启动的时候,会把环境中所有的环境变量都清除掉,我们可以从Nginx的官方文档中看到这段描述:http://nginx.org/en/docs/ngx_core_module.html#env 

By default, nginx removes all environment variables inherited from its parent process except the TZ variable.

具体可以参考春哥在这个issue下的回复:https://github.com/openresty/lua-nginx-module/issues/601

所以需要在你的nginx.conf文件中把你需要的环境变量声明一下:

events{
  ...
}

env PATH;
env USERNAME;

然后重启一下Nginx,就可以直接在你的 Lua 代码中使用 os.getenv("USERNAME") 获取环境变量。

在 Kong 中使用 os.getenv()

那如果我想在kong的插件中是使用os.getenv()要怎么操作呢?

在 Kong 里面,我们看到Kong生成的 Nginx配置文件是不可修改的,即使你修改了,Kong 还是会生成恢复成修改前,那么这个时候就要用到 Kong 的一个自定义 Nginx 配置文件功能。详情可以看这俩issue:

那么实际操作起来就很简单了,新建一个custom-nginx.conf文件,里面和上文一样,把你需要使用到的环境变量写到这个配置文件中。

events{
  ...
}

env PATH;
env USERNAME;

接着重启 Kong 即可。不过这里要注意的是,重启的时候,需要带上一个参数--nginx-conf。不过不要搞错的是-c参数是kong的配置文件参数,--nginx-conf 是自定义Nginx模板配置参数

 kong restart -c kong.conf --nginx-conf custom-nginx.conf

重启成功之后,就可以在 Kong 的插件中使用代码中使用 os.getenv("USERNAME") 来获取环境变量了。

在 Ubuntu 上安装 Kong

安装包

首先下载配置的相应软件包:

企业试用用户应从其欢迎电子邮件中下载其包,并在步骤1之后将其许可保存到/etc/kong/license.json

APT存储库

您也可以通过APT安装Kong; 按照下面页面上“Set Me Up”部分的说明,将分布设置为适当的值(lsb_release -sc)(例如,precise)和组件到main

安装

  1. 安装Kong 如果要下载程序包,请执行:
      $ sudo apt-get update
      $ sudo apt-get install openssl libpcre3 procps perl
      $ sudo dpkg -i kong-1.3.0.*.deb
    

    如果您正在使用apt存储库执行:

      $ sudo apt-get update
      $ sudo apt-get install -y apt-transport-https curl lsb-core
      $ echo "deb https://kong.bintray.com/kong-deb `lsb_release -sc` main" | sudo tee -a /etc/apt/sources.list
      $ curl -o bintray.key https://bintray.com/user/downloadSubjectPublicKey?username=bintray
      $ sudo apt-key add bintray.key
      $ sudo apt-get update
      $ sudo apt-get install -y kong
    
  2. 准备数据库或声明性配置文件无论是否有数据库,Kong都可以运行。

    使用数据库时,您将使用 kong.conf 配置文件在启动时设置Kong的配置属性,并将数据库用作所有已配置实体的存储,例如Kong代理所在的 Routes 和 Services 。

    不使用数据库时,您将使用kong.conf的配置属性和kong.yml文件来将实体指定为声明性配置。

    使用数据库

    配置Kong以便它可以连接到您的数据库。Kong支持PostgreSQL 9.5+Cassandra 3.x.x作为其数据存储。

    如果您使用Postgres,请在开始Kong之前配置数据库和用户,即:

     CREATE USER kong; CREATE DATABASE kong OWNER kong;
    
    然后执行Kong的数据迁移:
    
      $ kong migrations bootstrap [-c /path/to/kong.conf]
    

    对于Kong 小于0.15的注意事项:如果Kong版本低于0.15(最高0.14),请使用up子命令而不是bootstrap。另请注意,如果Kong 小于0.15,则不应同时进行迁移;只有一个Kong节点应该一次执行迁移。对于0.15,1.0及以上的Kong,此限制被取消。

    不使用数据库

    如果要在无DB模式下运行Kong,则应首先生成声明性配置文件。以下命令将在当前文件夹中生成kong.yml文件。它包含有关如何填写它的说明。

     $ kong config init
    

    填写kong.yml文件后,编辑您的kong.conf文件。将数据库选项设置为off,将declarative_config选项设置为kong.yml文件的路径:

     database = off
      declarative_config = /path/to/kong.yml
    
  3. 启动Kong
     $ kong start [-c /path/to/kong.conf]
    
  4. 使用KongKong正在运行
      $ curl -i http://localhost:8001/

Kong 1.3发布!支持原生gRPC代理,上游双向TLS认证,以及更多功能

原文地址:https://konghq.com/blog/kong-1-3-released/

今天,我们很高兴地宣布推出Kong 1.3!我们的工程团队和出色的社区为此版本提供了许多功能和改进。基于1.2版本的成功,Kong 1.3是Kong的第一个版本,它本身支持gRPC代理,上游相互TLS身份验证,以及一系列新功能和性能改进。

请阅读以下内容,了解有关Kong 1.3的新功能,改进和修复的更多信息,以及如何利用这些令人兴奋的变化。 请花几分钟时间阅读我们的更新日志以及升级路径以获取更多详细信息。

原生gRPC代理

我们观察到越来越多的用户转向微服务架构,并听到用户表达他们对本机gRPC代理支持的兴趣。Kong 1.3通过支持gRPC本地代理来解决这个问题,为支持gRPC的基础架构带来更多控制和可见性。

主要优点:

  • 简化运营流程。
  • 为gRPC服务添加A / B测试,自动重试和断路,以提高可靠性和正常运行时间。
  • 更多的可观测性
  • 针对gRPC服务的日志记录,分析或Prometheus集成?Kong让你满意。

主要功能:

  • 新协议:Route和Service实体的protocol属性现在可以设置为grpcgrpcs,这对应于通过明文HTTP/2(h2c)的gRPC和通过TLS HTTP/ 2(h2)的gRPC。

上游双向TLS认证

Kong长期以来一直支持与上游服务的TLS连接。 在1.3中,我们添加了对Kong的支持,以提供特定证书,同时与上游握手以提高安全性。

主要优点:

  • 能够使用证书与上游服务握手使得Kong在需要强大的身份验证保证的行业中更加出色,例如金融和医疗保健服务。
  • 安全性更好
  • 通过提供可信证书,上游服务将确定传入请求是由Kong转发的,而不是恶意客户端。
  • 对开发人员更友好
  • 您可以使用Kong将需要相互TLS身份验证的服务转换为与开发人员无关的方法(例如OAuth)。

主要功能:

  • 新配置属性:Service实体具有新字段client_certificate。如果设置,当Kong尝试与服务握手时将使用相应的证书。

Sessions 插件

在Kong 1.3中,我们开放了Sessions插件(之前仅在Kong Enterprise中提供)供所有用户使用。 结合其他身份验证插件,它允许Kong记住之前已经过身份验证的浏览器用户。 您可以在此处阅读详细的文档

NGINX CVE修复

Kong 1.3附带NGINX HTTP/2模块(CVE-2019-9511CVE-2019-9513CVE-2019-9516)的修复程序。 我们还发布了Kong 1.0.4,1.1.3,1.2.2来修补旧版Kong中的漏洞,以防不能立即升级到1.3。

OpenResty Version Bump

OpenResty的版本已经发布到最新的OpenResty版本 - 1.15.8.1,该版本基于Nginx 1.15.8。 此版本的OpenResty在关闭上游keepalive连接,ARM64架构支持和LuaJIT GC64模式时带来了更好的性能。 最引人注目的变化是,由于LuaJIT编译器生成更多本机代码,OpenResty更有效地存储请求上下文数据,因此使用密钥身份验证在基线代理基准测试中,Kong现在运行速度提高约10%。 

Kong 1.3的其他新功能

按任何请求 header 路由

  • Kong的路由器现在能够通过任何请求头(不仅是Host)匹配路由。
  • 这允许对服务之间路由传入流量的方式进行精细控制。
  • 参阅此处的文档

最少连接负载平衡

  • Kong现在可以将流量发送到连接数最少的上游服务。
  • 在某些用例中改善上游负载分配。
  • 参阅此处的文档

数据库导出

  • 新添加的kong config db_export CLI命令可用于创建数据库内容转储到YAML文件中,该文件适用于声明性配置或稍后导回数据库。
  • 这样可以更轻松地创建声明性配置文件。
  • 这使得Kong配置的备份和版本控制变得更加容易
  • 参阅此处的文档

主动关闭上游keepalive连接

  • 在旧版本的Kong中,上游连接永远不会被Kong关闭。这可能导致竞争条件,因为Kong可能会尝试重新使用keepalived连接,而上游尝试关闭它。
  • 如果您在Kong error.log中看到“upstream prematurely closed connection”错误,则此版本应显着减少甚至消除部署中的此错误。
  • 添加了新的配置指令来控制此行为,请阅读完整的更新日志以了解更多信息。

更多的监听标志支持

  • 特别是reuseport标志,如果Kong worker数量很大,可用于改善负载分配和延迟抖动。
  • 还添加了deferredbind标志支持。您可以查看NGINX listen指令文档以了解使用它们的效果。

其他改进和错误修复

Kong 1.3还包含有关存储CA证书(没有私钥的证书),Admin API接口和更多PDK功能的新实体的改进。 我们还修复了很多错误。由于此版本中有大量新功能,因此我们无法在此博客文章中介绍所有这些内容,而是鼓励您在此处阅读完整的更新日志

我们还在kong.conf模板中添加了一个新的部分,以更好地解释注入NGINX指令的功能。 对于具有仅添加几个NGINX指令的自定义模板的用户,我们建议切换使用注入的NGINX指令,以获得更好的可升级性。

与往常一样,Kong 1.3的文档可在此处获得。 此外,如上所述,我们将在后续帖子和社区电话中讨论1.3中的主要功能,敬请期待!

感谢我们的用户,贡献者和核心维护者社区,感谢您对Kong的开源平台的持续支持。 请试试Kong 1.3,一定要告诉我们您的想法

Kong社区

像往常一样,随时可以就我们的社区论坛Kong Nation提出任何问题。 从您的反馈中学习将使我们能够更好地理解任务关键用例并不断改进Kong。

微服务 API 网关 Kong 插件 Kubernetes Sidecar 注入插件中文文档

Kubernetes Sidecar 注入插件

该插件将注入Kong数据平面节点并在Kubernetes之上形成服务网格

介绍

Kong 0.15.0 / 1.0.0增加了代理和路由原始tcptls流的能力,并使用服务网格Sidecar模式和Kong节点之间的相互tls来部署Kong。本教程将引导您使用我们的 Kubernetes Sidecar 注入插件在Kubernetes上设置Kong服务网格。

准备条件

您需要在Kubernetes上运行Kong 1.0.0或更高版本,包括存储为可用于Kong控制平面的机密的SSL证书。来自Kong Kubernetes Repository的Make任务run_cassandrarun_postgres将完全配置必备数据存储,Kong控制平面,Kong数据平面和SSL机密。

或者,按照Kong Kubernetes Install Instructions页面中的任何设置说明进行操作,然后设置SSL证书/密码:

cd $(mktemp -d)

### Create a key+certificate for the control plane
cat <<EOF | kubectl create -f -
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: kong-control-plane.kong.svc
spec:
  request: $(openssl req -new -nodes -batch -keyout privkey.pem -subj /CN=kong-control-plane.kong.svc | base64 | tr -d '\n')
  usages:
  - digital signature
  - key encipherment
  - server auth
EOF
kubectl certificate approve kong-control-plane.kong.svc
kubectl -n kong create secret tls kong-control-plane.kong.svc --key=privkey.pem --cert=<(kubectl get csr kong-control-plane.kong.svc -o jsonpath='{.status.certificate}' | base64 --decode)
kubectl delete csr kong-control-plane.kong.svc
rm privkey.pem

或使用以下简便脚本:

curl -fsSL https://raw.githubusercontent.com/Kong/kong-dist-kubernetes/master/setup_certificate.sh | bash

安装步骤

导出一些变量以访问Kong Admin API和Proxy:

$ export HOST=$(kubectl get nodes --namespace default -o jsonpath='{.items[0].status.addresses[0].address}')
$ export ADMIN_PORT=$(kubectl get svc --namespace kong kong-control-plane  -o jsonpath='{.spec.ports[0].nodePort}')

通过Kong Admin API启用Sidecar Injector插件:

curl $HOST:$ADMIN_PORT/plugins -d name=kubernetes-sidecar-injector -d config.image=kong

打开Kubernets Sidecar Injection:

cat <<EOF | kubectl create -f -
apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  name: kong-sidecar-injector
webhooks:
- name: kong.sidecar.injector
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations: [ "CREATE" ]
  failurePolicy: Fail
  namespaceSelector:
    matchExpressions:
    - key: kong-sidecar-injection
      operator: NotIn
      values:
      - disabled
  clientConfig:
    service:
      namespace: kong
      name: kong-control-plane
      path: /kubernetes-sidecar-injector
    caBundle: $(kubectl config view --raw --minify --flatten -o jsonpath='{.clusters[].cluster.certificate-authority-data}')
EOF

或使用以下简便脚本:

curl -fsSL https://raw.githubusercontent.com/Kong/kong-dist-kubernetes/master/setup_sidecar_injector.sh | bash

使用

接下来,任何开始使用Kong Sidecar的pods都会自动注入,而来自该pods容器的所有数据都将通过Kong Sidecar。 例如,如果我们使用Istio中的bookinfo.yaml示例:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.1/samples/bookinfo/platform/kube/bookinfo.yaml

我们看到所有pods都收到了Kong Sidecar:

kubectl get all
NAME                 READY   STATUS
pod/details-v1       2/2     Running
pod/productpage      2/2     Running
pod/ratings-v1       2/2     Running
pod/reviews-v1       2/2     Running
pod/reviews-v2       2/2     Running
pod/reviews-v3       2/2     Running

继续配置服务。

基于OpenResty 的 WEB 框架 Lor 安装初探

  • 项目介绍:
    • Lor是一个运行在OpenResty上的基于Lua编写的Web框架.
    • 路由采用Sinatra风格,Sinatra是Ruby小而精的web框架.
    • API基本采用了Express的思路和设计,Node.js跨界开发者可以很快上手.
    • 支持插件(middleware),路由可分组,路由匹配支持string/正则模式.
    • lor以后会保持核心足够精简,扩展功能依赖middleware来实现. lor本身也是基于middleware构建的.
    • 推荐使用lor作为HTTP API Server,lor也已支持session/cookie/html template等功能.
    • 框架简单示例项目lor-example
    • 框架全站示例项目openresty-china
  • 项目地址: https://github.com/sumory/lor
  • 文档地址: http://lor.sumory.com

安装lor框架

git clone https://github.com/sumory/lor
cd lor 
make install

此时可能会有报错如下:

/usr/bin/env: "resty": 没有那个文件或目录

原因为lor没有找到resty的执行目录,这个时候只需要找到resty的执行目录并软链过去即可:

sudo ln -s /usr/local/openresty/bin/resty /usr/bin/resty

框架自带一个示例项目,运行一下代码

lord new lor_demo

启动

然后就能在框架中看到lor_demo文件夹,执行如下命令

cd lor_demo
lord start

打开浏览器,输入http://localhost:8888/正常访问,即正常安装。

使用 konga 来管理微服务 API 网关 kong

微服务网关kong有比较多个后台管理面板,比如比较简单的kong-dashboard,还有konga,之前在初探kong的时候,使用的就是比较简单的kong-dashboard,很多功能都没有,而且最近由于kong官方更新比较频繁,1.0之后的kong-dashboard就已经不兼容了,频繁报错,所有今天我就来使用一下另一款kong的后台管理面板:konga

安装konga

在开始安装之前,需要准备的有:

  • 一个已经安装好的kong环境
  • Nodejs >= 8 (推荐8.11.3 LTS)
  • npm

关于这三者的安装,我这里就不赘述了,kong的安装可以在博客的相关文章查看。在做好准备工作之后,就开始安装:

安装npm依赖

$ git clone https://github.com/pantsel/konga.git
$ cd konga
$ npm i

在执行npm i之后,由于会引入很多的npm包,所以可能会有报错,比如我这里就遇到了一些权限问题,比如:

Unable to save binary /home/qianyugang/soft/konga/node_modules/node-sass/vendor/linux-x64-64 : { Error: EACCES: permission denied, mkdir '/home/thinkpad/soft/konga/node_modules/node-sass/vendor'

如果出现了如上错误,可以把最后一个命令修改为

sudo npm i --unsafe-perm=true --allow-root

执行之后,可能会提示:

bower bootstrap-switch extra-resolution Unnecessary resolution: bootstrap-switch#~3.3.4
added 69 packages from 77 contributors and audited 3120 packages in 4.654s
found 275 vulnerabilities (125 low, 24 moderate, 126 high)
  run `npm audit fix` to fix them, or `npm audit` for details

意思是有一些包没有执行好,那么我们就按照它的提示执行一下:

sudo npm audit fix --unsafe-perm=true --allow-root

基本就可以解决npm依赖包的问题了。总之这里是有可能出现各种各样的npm问题,依次解决即可。

初始化数据库

npm的依赖都安装完成之后,就需要复制一下konga目录下的.env_example文件

cp .env_example env

然后把其中的一些配置项目都填写上去。具体的配置项可以查看 https://github.com/pantsel/konga#environment-variables 。这里就主要把以下三项配置好:

DB_ADAPTER=postgres
PORT=1337
DB_URI=postgresql://kong_user:kong_pass@localhost:5432/konga

注意这个DB_URI一定要填写完整,这里的数据库我用的是postgres,konga其实还支持mysql,mongo等多种数据库,这里就不赘述了。配置完成之后,需要登上你自己的postgres数据库,然后执行如下命令新建数据库:

CREATE DATABASE "konga" WITH ENCODING='UTF8';

新建了数据库之后,,执行如下命令,来初始化数据库:

node ./bin/konga.js prepare --adapter postgres --uri postgresql://kong_user:kong_pass@localhost:5432/konga

出现如下提示之后,数据库这一块就完成:

Preparing database...
debug: Hook:api_health_checks:process() called
debug: Hook:health_checks:process() called
debug: Hook:start-scheduled-snapshots:process() called
debug: Hook:upstream_health_checks:process() called
debug: Hook:user_events_hook:process() called
debug: Seeding User...
debug: User seed planted
debug: Seeding Kongnode...
debug: Kongnode seed planted
debug: Seeding Emailtransport...
debug: Emailtransport seed planted
debug: Database migrations completed!

启动konga

执行如下命令:

npm start

看到如下小帆船的图,成功启动


   Sails              <|    .-..-.
   v0.12.14            |\
                      /|.\
                     / || \
                   ,'  |'  \
                .-'.-==|/_--'
                `--'-------' 
   __---___--___---___--___---___--___
 ____---___--___---___--___---___--___-__

最后,打开浏览器输入http://localhost:1337/,就可以进入konga的管理界面了。会出现一个让你注册的界面,注册登录一下,然后配置一下kong的admin-api链接,大功告成,打完收工。

微服务 API 网关 Kong 中文文档发布

由于项目的原因,最近的几个月一直在学习微服务的API网关 Kong ,在这里做一个简单介绍,是一个云原生,高效,可扩展的分布式 API 网关。 自 2015 年在 github 开源后,广泛受到关注,目前已收获 1.68w+ 的 star,其核心价值在于高性能和可扩展性。由于对项目的积极维护,Kong被广泛用于从初创公司到全球5000强以及政府机构的生产中。从技术角度来说,Kong是基于Openresty的一个莹莹,Openresty是基于Nginx的,使用的语言是Lua。

所以在学习过程中,首要是需要看官方文档,由于项目比较新,所以暂时没有中文文档,我就想着,反正文档总是要全部看一遍的,不如自己翻译一份好了,于是乎就有了这个项目:Kong的文档中文版。欢迎大家star&fork。

由于自己不是英语专业,而且主要目的是学习Kong,所以采用的是人工+机翻结合的方式,如果有遇到翻译的不够通顺,或者对于翻译的语句有歧义的地方,麻烦一定点击官网英文文档https://docs.konghq.com/ 查看,并且欢迎提 PR 提修改意见。另,由于kong的文档本身也在不断增加和完善当中,如果有遇到没有即使更新翻译的状况欢迎提issue,我会不断补充的。

todo:

  • 目前文档中的超链接都是链接的英文原文,后续会慢慢改成中文内链。
  • 会在每一页文档里面附上单独的英文原文链接,以便做对照。
  • 会添加kong自带的插件文档。

本文档是基于 https://docs.konghq.com/1.1.x/ 1.1.x 版本,目前官网已经更新至 1.2.x 版本,如果使用的最新版本,请查看 https://docs.konghq.com 并注意差别。