介绍

通常情况下Kong需要连接数据库，数据库可以是postgres或Cassandra，数据库用来存储其配置的实体，如路由、服务和插件。Kong使用它的配置文件，kong.conf，以指定Postgres和Cassandra的用法及其各种设置。
kong1.1增加了在没有数据库的情况下运行Kong的功能，只使用内存存储：我们称之为无数据库模式. 当运行无数据库模式时，相关配置信息是在另外的一份YAML或JSON格式配置文件中，使用声明性配置 .
无数据库模式和声明性配置的结合有许多好处：

  • 减少依赖项的数量：如果用例的整个设置适合内存，则无需管理数据库安装
  • 它非常适合于CI/CD场景中的自动化：配置forentity可以保存在通过gitpository管理的单一真实源中
  • 它为Kong提供了更多部署选项

    什么是声明性配置

    如果您已经熟悉声明性配置的概念，可以跳过这一节。
    声明性配置的关键思想，顾名思义，就是这样的概念声明的，而不是命令配置风格。“命令式”意味着一个配置是以一系列顺序给出的：“先做这个，然后做那个”。“声明性”意味着一次给出配置：“我声明这是世界的状态”。
    Kong管理API是一个命令式配置工具的例子。配置的最终状态是通过一系列API调用获得的：一个调用创建服务，另一个调用创建路由，另一个调用添加插件，等等。
    像这样以增量方式执行配置会产生不希望看到的副作用中间状态发生。在上面的例子中，在创建一个路由和添加一个插件之间有一个时间窗口，在这个窗口中路由没有应用插件。
    另一方面，声明性配置文件将在单个文件中包含所有所需实体的设置，一旦该文件加载到kong中，它将替换整个配置。当需要增量更改时，将对声明性配置文件进行更改，然后重新加载整个配置文件。在任何时候，加载到Kong的文件中描述的配置都是系统的配置状态。

    在无DB模式下设置Kong

    要在无DB模式下使用Kong，请设置kong.conf文件的database=off. 与往常一样，您可以通过编辑来完成此操作kong.conf和设置database=off或环境变量。然后您可以正常启动Kong：
    1. $ export KONG_DATABASE=off
    2. $ kong start -c kong.conf

    一旦kong开始运行，进入/在没有运行管理器的情况下验证该数据库的API。它将返回整个Kong配置；验证数据库设置为off :
    1. $ http :8001/
    2. HTTP/1.1 200 OK
    3. Access-Control-Allow-Origin: *
    4. Connection: keep-alive
    5. Content-Length: 6342
    6. Content-Type: application/json; charset=utf-8
    7. Date: Wed, 27 Mar 2019 15:24:58 GMT
    8. Server: kong/2.1.0
    9. {
    10.   "configuration:" {
    11.      ...
    12.      "database": "off",
    13.      ...
    14.   },
    15.   ...
    16.   "version": "2.1.0"
    17. }

    Kong正在运行，但尚未加载声明性配置。这意味着此节点的配置为空。不存在任何类型的路线、服务或实体：
    1. $ http :8001/routes
    2. HTTP/1.1 200 OK
    3. Access-Control-Allow-Origin: *
    4. Connection: keep-alive
    5. Content-Length: 23
    6. Content-Type: application/json; charset=utf-8
    7. Date: Wed, 27 Mar 2019 15:30:02 GMT
    8. Server: kong/2.1.0
    9. {
    10.   "data": [],
    11.   "next": null
    12. }

创建声明性配置文件

为了将实体加载到无数据库的Kong中，我们需要一个声明性的配置文件。以下命令将创建一个骨架文件，以便您开始使用：

  1. $ kong config -c kong.conf init


创建一个命令kong.yml文件，包含声明实体及其关系的语法示例。默认情况下，生成的文件中的所有示例都被注释掉了。您可以通过取消注释示例（删除#标记）并修改其值

声明性配置格式

Kong声明性配置格式由实体及其属性的列表组成。这是一个小而复杂的示例，它演示了许多功能：

  1. _format_version: "2.1"
  2. _transform: true
  3. services:
  4. - name: my-service
  5.   url: https://example.com
  6.   plugins:
  7.   - name: key-auth
  8.   routes:
  9.   - name: my-route
  10.     paths:
  11.     - /
  12. consumers:
  13. - username: my-user
  14.   keyauth_credentials:
  15.   - key: my-key


唯一必须的元数据是_format_version: "2.1"，它指定声明性配置语法格式的版本号。这还与解析文件所需的最低版本Kong相匹配。
这个_transform元数据是可选的布尔值（默认为是的)，它控制导入时是否发生架构转换。如果你想输入密码的话，你很可能想要输入密码true，以便Kong在将它们存储到数据库之前对它们进行加密/散列。如果您要导入已经散列/加密凭据，设置_transform到假这样加密就不会发生两次了。
在顶层，您可以指定任何kong实体，无论是核心实体，例如services和消费者在上面的示例中，或者由插件创建的自定义实体，例如keyauth_credentials. 这使得declarativeconfiguration格式具有内在的可扩展性，这就是为什么kongconfig处理声明性配置所需的命令kong.conf有空，这样插件指令被考虑在内
当实体具有关系时，例如指向服务的路由，可以通过嵌套来指定此关系。
嵌套只能指定一对一的关系：应用于服务的插件可以通过嵌套描述其关系，如上面的示例所示。涉及两个以上实体的关系，例如应用于服务和使用者的aPlugin必须通过顶层条目来完成，其中实体可以通过它们的主键或标识名称（可以在管理API中用于引用它们的相同标识符）进行标识。以下是应用于服务和消费者的插件示例：

  1. plugins:
  2. - name: syslog
  3.   consumer: my-user
  4.   service: my-service

校验声明性配置文件

编辑完文件后，可以在尝试将其加载到Kong之前检查syntax是否有任何错误：

  1. $ kong config -c kong.conf parse kong.yml
  2. parse successful

加载声明性配置文件

有两种方法可以将声明性配置加载到Kong中：viakong.conf通过管理API
要在Kong启动时加载声明性配置，请使用declarative_config指令kong.cnf（或者，像往常一样对所有人kong.conf条目，相当于KONG_声明性配置环境变量）

  1. $ export KONG_DATABASE=off
  2. $ export KONG_DECLARATIVE_CONFIG=kong.yml
  3. $ kong start -c kong.conf


或者，可以使用/config终结点。装载以下示例kong.ymlusing HTTPie:

  1. $ http :8001/config config=@kong.yml


这个/configendpoint用给定文件中指定的实体替换内存中的整个实体集。

在无db模式下使用Kong

在DB lessmode中使用Kong时有许多事情需要注意。

内存缓存要求

实体的整个配置必须适合Kongcache。确保内存缓存配置正确：请参阅mem_cache_size指令kong.cnf .

无中央数据库协调

由于没有中央数据库，多个Kong节点没有中心协调点，没有数据的集群传播：节点之间完全独立。
这意味着声明性配置应该独立地加载到每个节点中。使用/config端点不影响其他Kong节点，因为它们彼此不了解。

只读管理API

由于配置实体的唯一方法是通过声明性配置，因此在无数据库模式下运行Kong时，实体上CRUD操作的端点在管理API中有效地只读。GET用于检查实体的操作正常工作，但尝试岗位 ,PATCH``把或DELETE在端点中，例如/服务或/plugins会回来的不允许HTTP 405 .
此限制仅限于其他情况下的数据库操作。尤其是使用POST设置目标的运行状况状态仍处于启用状态，因为这是特定于节点的内存操作。

插件兼容性

并非所有的Kong插件都与无数据库模式兼容，因为一些主题化的设计需要中央数据库协调和/或实体的动态创建。

完全兼容

以下插件仅从数据库中读取（大多数插件只是为了读取其初始配置），因此它们与DB less完全兼容：

  • aws-lambda
  • azure-functions
  • bot-detection
  • correlation-id
  • cors
  • datadog
  • file-log
  • http-log
  • tcp-log
  • udp-log
  • syslog
  • ip-restriction
  • prometheus
  • zipkin
  • request-transformer
  • response-transformer
  • request-termination

  • kubernetes-sidecar-injector

    部分相兼容

    只要使用的凭据集是静态的并指定为声明性配置的一部分，则可以使用身份验证插件。动态创建、更新或删除凭据的管理API终结点在无数据库模式下不可用。属于以下类别的插件：

  • acl

  • basic-auth
  • hmac-auth
  • jwt
  • key-auth

与Kong捆绑的速率限制插件为存储和协调计数器提供了不同的策略：本地存储策略存储计数器节点内存，以每个节点的方式应用限制；redis存储策略将Redis用作跨节点协调计数器的外部键值存储的策略；以及cluster使用Kong数据库作为群集范围限制的中心协调点的策略。在无DB模式下本地和redis策略可用，并且集群无法使用。属于这一类的插件包括：

  • rate-limiting
  • response-ratelimiting

这个pre-function和岗位职能serverless的插件可以在无数据库模式下使用，但需要注意的是，如果任何配置的函数试图写入数据库，则写入操作将失败。

不兼容
  • oauth2-为了正常工作，插件需要生成和删除令牌，并将这些更改提交到数据库中，这与数据库less不兼容。

参考

https://docs.konghq.com/2.2.x/db-less-and-declarative-config/#