Apigateway-kong (vii) configuration instructions

This part should be introduced at the very beginning, but I think it will be more profound to look back on the configuration after I have some knowledge of Kong. Next, make a detailed explanation of the parameters in this configuration file to facilitate better use or optimization of the Kong Gateway.

Directory

• I. Configuration loading
• Two. Verifying the configuration
• Three. Environment variables
• Four. Custom Nginx configuration & Embedded Kong configuration
• 1. Custom Nginx Configuration
• 2. Embedding Kong in Openresty
• 3. Providing the Web and API for Kong

• Five. Property configuration
  
  • 1. Common Parts
  • 2.nginx part
  • 3. Data Storage Section
  • 4. Data Caching section
  • 5.DNS parsing section
  • 6. Development & Miscellaneous

Configuration load

Kong provides a default configuration file that can be found in/etc/kong/kong.conf.default if a Kong is installed through one of the official packages. To start configuring Kong, you can copy this file:

CP /etc/kong/kong.conf.default/etc/kong/kong.conf

If all of the values in your configuration are commented out, Kong will run with the default settings. At the beginning, the Kong lookup may contain several default locations for the configuration file:

/etc/kong/kong.conf/etc/kong.conf

You can override this behavior by specifying a custom path to the configuration file by using the-c/--conf parameter at the command line:

$ Kong Start--conf/path/to/kong.conf

The configuration format is simple: simply uncomment any property (the comment is defined by the # character) and modify it to the value you want. For convenience, Boolean values can be specified as on/off or True/false

Verifying the configuration

You can use the Check command to verify the integrity of the settings:

$ kong Check <path/to/kong.conf><path/to/kong.conf> is valid

This command will take into account the environment variables you are currently setting, and will fail if your settings are not valid. In addition, you can use the CLI in debug mode to gain a deeper understanding of the properties that Kong is starting:

$ KONG Start-c <kong.conf>--VV ./ ,/ One  -: -: $[Verbose] no configfileFound at/etc/kong.conf ./ ,/ One  -: -: $[Verbose] no configfileFound at/etc/kong/kong.conf ./ ,/ One  -: -: $[Debug] Admin_listen ="0.0.0.0:8001" ./ ,/ One  -: -: $[Debug] Database ="Postgres" ./ ,/ One  -: -: $[Debug] Log_level ="Notice"[...]

Environment variables

When loading properties from a configuration file, Kong also looks for environment variables with the same name, which allows you to fully configure Kong with environment variables, for example, which is very handy for container-based infrastructure.

All environment variables prefixed with Kong_, capitalized and with the same name as the settings, overwrite the original configuration.

inch kong.conf can be rewritten as: $ export kong_log_level=error

Custom Nginx Configuration & Embedding Kong configuration

Adjusting Nginx configuration is an important part of setting up a Kong instance, which allows you to optimize the performance of its infrastructure or to embed Kong into an already running openresty instance.

1. Custom Nginx Configuration

Kong can use the--nginx-conf parameter to perform a start, reload, and restart operation, which must specify the Nginx configuration template. This template uses the Penlight engine, which compiles with the specified Kong configuration and dumps it into your Kong prefix directory before starting nginx.

The default template file is: Https://github.com/Mashape/kong/tree/master/kong/templates. It is divided into two nginx configuration files:Nginx.lua and Nginx_kong.lua. The Nginx_kong.lua contains all the configurations for the Kong startup, and the Nginx.lua contains all the configurations, including the Nginx_kong.lua. Before you start Nginx, copy the two files to the root of Kong, similar to this:

/usr/local/Kong├──nginx-kong.conf├──nginx.conf

If you want to include additional server modules in Nginx configuration, or you must adjust the global settings that are not exposed by Kong, refer to the following code:

# ---------------------# custom_nginx.template#---------------------worker_processes ${{nginx_worker_processes}}; # can is set by Kong.confdaemon ${{nginx_daemon}}; # can is set by Kong.confpid PIDs/Nginx.pid; # This setting is Mandatoryerror_log logs/Error.log ${{log_level}}; # can is set by kong.confevents {with epoll; # custom setting multi_accept on;} HTTP {# include default Kong Nginx config include'nginx-kong.conf'; # Custom Server server {Listen8888;        server_name custom_server; Location/{.... # etc}}}

You can then use the following command to start the Kong:

$ kong Start-c kong.conf--nginx-conf custom_nginx.template

If you want to customize the Kong Nginx child configuration file and eventually add other LUA handlers or custom Lua_ * directives, you can embed Nginx_kong.lua configuration in this custom_nginx.template sample file:

#------------------------------------------worker_processes ${{nginx_worker_processes}}; # can be set by Kong.confdaemon ${{nginx_daemon}};                     # can is set by Kong.confpid PIDs/nginx.pid;                      # This setting was Mandatoryerror_log logs/Error.log ${{log_level}}; # can be set by kong.confevents {}http {  Resolver ${{dns_resolver}} ipv6=off;  CharSet UTF-8;  Error_log logs/Error.log ${{log_level}};  Access_log logs/access.log;  .... # etc}

2. Embedding Kong in Openresty

If you are running your own openresty server, you can also easily embed Kong by adding a child configuration file for the Kong Nginx by using the include directive (similar to the previous section example). If you have an effective, top-level nginx configuration that contains only the Kong-specific configuration:

# my_nginx.confhttp {    'nginx-kong.conf';}

You can start your instance as follows:

$ nginx-p/usr/local/openresty-c my_nginx.conf

Kong will run in this instance (as configured in nginx-kong.conf).

3. Providing the Web and API for Kong

A common use case for API providers is to let Kong serve websites and APIs through proxy ports-server port 80 or 443. For example, https://my-api.com (Web site) and HTTPS://MY-API.COM/API/V1 (API).

To achieve this, we cannot simply declare a new virtual server module, as we did in the previous section. A good solution is to use a custom Nginx configuration template, the template inline Nginx_kong.lua, and add a new location block to serve the site as well as the Kong proxy location block:

# ---------------------# custom_nginx.template#---------------------worker_processes ${{nginx_worker_processes}}; # can is set by Kong.confdaemon ${{nginx_daemon}}; # can is set by Kong.confpid PIDs/Nginx.pid; # This setting is Mandatoryerror_log logs/Error.log ${{log_level}}; # can is set by kong.confevents {}http {# here, we inline the contents of Nginx_kong.lua CharSet UTF-8; # any contentsuntilKong'S Proxy Server block... # Kong'S Proxy Server blockserver {server_name Kong; # any contentsuntilThe location/Block ... # here, we declare our custom location serving our website # (or API portal)whichWe can optimize forserving static Assets location/{root/var/www/my-api.com;      Index index.htm index.html;    ...    } # Kong's Proxy location/has been changed to/api/v1location/api/v1 {set $upstream _host nil;      Set $upstream _scheme nil;      Set $upstream _uri nil; # Any remaining configuration forThe Proxy location ...} } # Kong'S Admin server block goes below}

View CodeProperty configuration 1. General section

Prefix (default/usr/local/kong)

Working directory. The prefix path equivalent to Nginx, including temporary files and logs. Each Kong process must have a separate working directory.

Log_level (Default notice)

The log level of the Nginx server. Logs can be found at < prefix >/logs/error.log
For a list of acceptable values, see Http://nginx.org/en/docs/ngx_core_module.html#error_log.

Proxy_access_log (Default Logs/access.log)

The path of the proxy port request access log. Set this value to off to disable logging agent requests. If this value is a relative path, it will be placed under the prefix position.

Proxy_error_log (Default Logs/error.log)

The path of the proxy port request error log. The granularity of these logs is adjusted by the Log_level directive

Admin_access_log (Default Logs/admin_access.log)

Manages the path of the API request access log. Set this value to off to disable the records Management API request. If this value is a relative path, it will be placed under the prefix position.

Admin_error_log (Default Logs/error.log)

Manages the path of the API request error log. The granularity of these logs is adjusted by the Log_level directive.

Custom_plugins (Default None, Example: my-plugin,hello-world,custom-rate-limiting)

A comma-delimited list of other plug-ins should be loaded for this node. Use this property to load a custom plug-in that is not bundled with Kong. Plug-ins will be from Kong.plugins. {Load in name}.* namespace

Anonymous_reports (Default on)

Send anonymous usage data (such as an error stack trace) to help improve Kong.

2.nginx part

Proxy_listen (default 0.0.0.0:8000, 0.0.0.0:8443 SSL Example: 0.0.0.0:80, 0.0.0.0:81 HTTP2, 0.0.0.0:443 SSL, 0.0.0.0:444 HTTP2 SSL)

What should the proxy server listen to?? Comma-separated list of addresses and ports. The proxy server is the public entry point for Kong, which proxies consumer traffic to back-end services. This value accepts Ipv4,ipv6 and host names.

You can specify some suffixes for each pair:

• SSL will require that all connections made through a particular address/port be made with TLS enabled.
• HTTP2 will allow the client to open the HTTP/2 connection to the Kong proxy server.
• Finally, Proxy_protocol will enable the use of the proxy protocol for a given address/port.

The proxy port of the node, enabling the "Control-plane" mode (no traffic agent feature) that can be configured to connect to the node cluster of the same database.
See Http://nginx.org/en/docs/http/ngx_http_core_module.html#listen for a description of the acceptable format for this and other * _listen values.

Admin_listen (default 127.0.0.1:8001, 127.0.0.1:8444 SSL example 127.0.0.1:8444 HTTP2 SSL)

The management interface should listen for a comma-separated list of addresses and ports. The admin interface is an API that allows you to configure and manage Kong. Only a Kong administrator can access this interface. This value accepts Ipv4,ipv6 and host names. You can specify some suffixes for each pair:

• SSL will require that all connections made through a specific address/port be made with TLS enabled.
• HTTP2 will allow the client to open the HTTP/2 connection to the Kong proxy server.
• Finally, Proxy_protocol will enable the use of the proxy protocol for the given address/port.

You can set this value to off to disable the admin interface for this node, and enable the "Data-plane" mode (no configuration feature) to extract its configuration changes from the database.

Nginx_user (Default Nobody nobody example Nginx www)

Defines the user and group credentials used by the worker process. If the group is omitted, a group with a name equal to the user name is used.

Nginx_worker_processes (Default Auto)

Determine the number of work processes generated by Nginx. See http://nginx.org/en/docs/ngx_core_module.html#worker_processes for detailed usage of the directive and a description of acceptable values.

Nginx_daemon (Default on)

Determine if Nginx is running as a background process or as a foreground process. Used primarily for development or when running Kong in a Docker environment. See Http://nginx.org/en/docs/ngx_core_module.html#daemon.

Mem_cache_size (Default 128M)

The memory cache size of the database entity. The units accepted are K and M, and the minimum recommended value is a few megabytes.

Ssl_cipher_suite (default modern)

Defines the TLS password provided by Nginx. The accepted values are modern, intermediate, old, or custom. For a detailed description of each cipher suite, see Https://wiki.mozilla.org/Security/Server_Side_TLS.

Ssl_ciphers (Default None)

Defines a custom list of TLS passwords provided by Nginx. The list must conform to the pattern defined by OpenSSL ciphers. If the ssl_cipher_suite is not custom, the value is ignored.

Ssl_cert (Default None)

An absolute path to an SSL certificate (certificate) with SSL Proxy_listen value enabled.

Ssl_cert_key (Default None)

The absolute path of the SSL key (key) for the SSL-Proxy_listen value is enabled.

Client_ssl (default off)

Determines if Nginx should send a client SSL certificate when proxy requests are made.

Client_ssl_cert (Default None)

If CLIENT_SSL is enabled, the absolute path to the client SSL certificate for the proxy_ssl_certificate directive. Note that this value is statically defined on the node and cannot currently be configured on a per-API basis.

Client_ssl_cert_key (default None)

If CLIENT_SSL is enabled, the absolute path of the client SSL key for the Proxy_ssl_certificate_key address. Note that this value is statically defined on the node and is currently not configurable on a per-API basis.

Admin_ssl_cert (Default None)

The absolute path of the SSL certificate that has the SSL Admin_listen value enabled.

Admin_ssl_cert_key (Default None)

The absolute path of the SSL key for the SSL Admin_listen value is enabled.

Upstream_keepalive (default 60)

Sets the maximum number of idle keepalive connections for the upstream server that is retained in each worker process cache. When this number is exceeded, the least recently used connection is closed.

Server_tokens (Default on)

Enables or disables the issuance of a Kong version in the error page and server or via (if requested by proxy) Response Header (response header) field.

Latency_tokens (Default on)

Enables or disables the publication of Kong delay information in the X-kong-proxy-latency and x-kong-upstream-latency response header domains.

Trusted_ips (Default None)

Defines a trusted IP address block that is known to send the correct x-forwarded-* header. Requests from trusted IPs allow Kong to forward their x-forwarded-* header upstream. An untrusted request allows Kong to insert its own x-forwarded-* header.

This property can also set the SET_REAL_IP_FROM directive in the Nginx configuration. It accepts values of the same type (CIDR blocks), but is a comma-delimited list.

To trust all/\IP, set this value to 0.0.0.0/0,::/0.
If you specify a special value UNIX:, all UNIX domain sockets will be trusted.

For more details on the set_real_ip_from directive, please see the nginx documentation.

Real_ip_header (Default X-real-ip)

Defines the request header field whose value will be used to replace the client address. This value sets the Ngx_http_realip_module directive with the same name in the Nginx configuration.
If this value receives Proxy_protocol, the Proxy_protocol parameter is appended to the listen Directive of the Nginx template.

Please refer to the Nginx documentation for instructions on this directive.

Real_ip_recursive (default off)

This value sets the Ngx_http_realip_module directive with the same name in the Nginx configuration.

Please refer to the Nginx documentation for instructions on this directive.

Client_max_body_size (default 0)

Defines the maximum requested principal size allowed by the request of the Kong agent, as specified in the Content-length request header. If the request exceeds this limit, Kong will reply 413 (the request entity is too large). Setting this value to 0 disables checking the request body size.

Note: Please refer to the Nginx documentation for further instructions on this parameter. The numeric value can be either K or m as the suffix, in kilobytes or megabytes, to indicate the limit.

Client_body_buffer_size (Default 8k)

Defines the buffer size of the read request body. If the client request body is larger than this value, the principal is buffered to disk. Note that the Kong plug-in that accesses or operates the request body when the principal is cached to disk may not work, so it is recommended that this value be set to as high as possible (for example, set it to be as high as client_max_body_size to force the request body to remain in memory). Note that a high concurrency environment will require a large amount of memory allocation to handle many concurrent large request bodies.

Note: Please refer to the Nginx documentation for further instructions on this parameter. The numeric value can be either K or m as the suffix, in kilobytes or megabytes, to indicate the limit.

Error_default_type (Default Text/plain)

The default MIME type used when requesting the accept header is missing and Nginx is returning an error for the request. The accepted values are Text/plain,text/html,application/json and application/xml.

3. Data Storage Section

Kong will store all the data (such as APIs, consumers, and plugins) in Cassandra or PostgreSQL.
All Kong nodes that belong to the same cluster must connect themselves to the same database.

Support from Kong v0.129. 4 should be considered deprecated. Upgrade to 9 is recommended. 5+2. 1 support should be considered deprecated. Upgrade to 2 is recommended. 2+

Determine which PostgreSQL or Cassandra the Kong node will use as its data store. The acceptable values are postgres and Cassandra.

Default: Postgres

Postgres settings

Name	Describe
Pg_host	Host address of the Postgres server
Pg_port	Port of the Postgres server
Pg_user	Postgres User Name
Pg_password	User password for Postgres
Pg_database	The name of the database instance to connect to must exist
Pg_ssl	Whether to enable SSL connection to the server
Pg_ssl_verify	If PG_SSL is enabled, switch server certificate validation. See Lua_ssl_trusted_certificate settings

Cassandra Settings

Name	Describe
Cassandra_contact_points	List of cluster names, separated by commas
Cassandra_port	Port on which the node is listening
Cassandra_keyspace	The key space used in the cluster will be automatically created if it does not exist
Cassandra_consistency	Set the consistency of read and write operations
Cassandra_timeout	Time-out setting for read and write operations in milliseconds MS
Cassandra_ssl	Configure Enable SSL connection
Cassandra_ssl_verify	If CASSANDRA_SSL is enabled, switch server certificate validation. See Lua_ssl_trusted_certificate settings
Cassandra_username	User name when using the Passwordauthenticator scenario
Cassandra_password	User password when using the Passwordauthenticator scenario
Cassandra_consistency	Consistency settings used when reading/writing Cassandra clusters
Cassandra_lb_policy	The load balancing policy used when distributing queries in the Cassandra Cluster. The accepted values are Roundrobin and dcawareroundrobin. When and only if you are using a multi-datacenter cluster, configure the Cassandra_local_datacenter option at the same time
Cassandra_local_datacenter	When using the Dcawareroundrobin policy, you must specify the name of the local cluster in the Kong node
Cassandra_repl_strategy	If you are creating a key space for the first time, specify a replication policy
Cassandra_repl_factor	Specify replication criteria for Simplestrategy
Cassandra_data_centers	Specifying the NETWORKTOPOLOGYSTRATEGY data center
Cassandra_schema_consensus_timeout	Defines the timeout (in milliseconds) for each pattern consensus waiting period between Cassandra nodes. This value is used only during the migration process.

4. Data Caching section

To avoid unnecessary communication with the data store, Kong caches entities (such as APIs, consumers, certificates, and so on) for a configurable amount of time. If the entity is updated, it also handles invalidation.

This section allows you to configure the behavior of Kong about caching these configuration entities.

5.DNS parsing section

kong resolves the hostname to an SRV or a record (in this order, the CNAME record is dereferenced in the procedure). If a name is resolved to an SRV record, it will also overwrite any given port number by the contents of the Port field received from the DNS server.

The DNS options search and Ndots (from the/etc/resolv.conf file) will be used to extend the short name to a fully qualified name. So it will first try the SRV type in the entire search list, and if it fails, it will try the search a record list and so on.

Within the duration of the TTL, the internal DNS resolver loads each request that it obtains through entries in the DNS record. For an SRV record, the weight (weight) field is respected, but it uses only the field entries in the lowest priority (lowest priorities) in the record.

6. Development & Miscellaneous

Other settings inherited from the Lua-nginx module allow for more flexibility and advanced usage.

For more information, see Lua-nginx-module Documentation: Https://github.com/openresty/lua-nginx-module.

Apigateway-kong (vii) configuration instructions