What is New in Wallarm Node 6.x and 0.14.x¶
This changelog covers updates for NGINX Node 6.x and Native Node 0.14.x+. If upgrading from an older version, refer to this document.
For the detailed changelog on minor versions of the Wallarm Node, refer to the NGINX Node artifact inventory or Native Node artifact inventory.
This release introduces key architectural improvements aimed at enhancing performance and maintainability of the Wallarm Node. These updates also lay the groundwork for upcoming features.
Replacing Tarantool with wstore for postanalytics¶
Wallarm Node now uses wstore, a Wallarm-developed service, instead of Tarantool for local postanalytics processing.
As a result, the following changes have been introduced to NGINX Node:
-
All-in-one installer, AWS/GCP images:
-
The NGINX directive
wallarm_tarantool_upstream
, which defines the postanalytics module server address when deployed separately from other NGINX services, has been renamed towallarm_wstore_upstream
.Backward compatibility preserved with a deprecation warning:
-
Log file renamed:
/opt/wallarm/var/log/wallarm/tarantool-out.log
→/opt/wallarm/var/log/wallarm/wstore-out.log
. - The new wstore configuration file
/opt/wallarm/wstore/wstore.yaml
replaces obsolete Tarantool configuration files such as/etc/default/wallarm-tarantool
or/etc/sysconfig/wallarm-tarantool
. - The
tarantool
section in/opt/wallarm/etc/wallarm/node.yaml
is nowwstore
. Backward compatibility preserved with a deprecation warning.
-
-
- All the above changes are applied within the container.
- Previously, memory for Tarantool was allocated via the
TARANTOOL_MEMORY_GB
environment variable. Now, memory allocation follows the same principle but uses a new variable:TARANTOOL_MEMORY_GB
→SLAB_ALLOC_ARENA
. -
Adjusted the container's directory structure to align with Alpine Linux conventions. Specifically:
- Content from
/etc/nginx/modules-available
and/etc/nginx/modules-enabled
has been moved to/etc/nginx/modules
. - Content from
/etc/nginx/sites-available
and/etc/nginx/sites-enabled
has been moved to/etc/nginx/http.d
.
- Content from
-
The default
allow
value, specifying permitted IP addresses for the/wallarm-status
service, is now 127.0.0.0/8 instead of 127.0.0.8/8.
-
Kubernetes Ingress Controller:
- Tarantool is no longer a separate pod, wstore runs within the main
<CHART_NAME>-wallarm-ingress-controller-xxx
pod. - Helm values renamed:
controller.wallarm.tarantool
→controller.wallarm.postanalytics
.
- Tarantool is no longer a separate pod, wstore runs within the main
-
Kubernetes Sidecar Controller:
- Helm values renamed:
postanalytics.tarantool.*
→postanalytics.wstore.*
. -
The following Docker images have been removed from the Helm chart for Sidecar deployment:
These images have been replaced by the wallarm/node-helpers image, which now runs the relevant services.
- Helm values renamed:
The described changes are incorporated into the Node upgrade instructions provided below.
Removal of collectd¶
The collectd service, previously installed on all filtering nodes, has been removed along with its related plugins. Metrics are now collected and sent using Wallarm's built-in mechanisms, reducing dependencies on external tools.
Use the /wallarm-status
endpoint, which replaces collectd by providing the same metrics in Prometheus and JSON formats.
As a result of this change, also the following changed in the configuration rules:
-
The
/opt/wallarm/etc/collectd/wallarm-collectd.conf.d/wallarm-tarantool.conf
collectd configuration file is no longer used. -
If you previously used collectd to forward metrics via a network plugin, such as:
LoadPlugin network <Plugin "network"> Server "<Server IPv4/v6 address or FQDN>" "<Server port>" </Plugin>
you should now switch to scraping
/wallarm-status
via Prometheus.
Which Wallarm nodes are recommended to be upgraded?¶
-
Client and multi-tenant Wallarm NGINX Nodes of version 4.10 and 5.x to stay up to date with Wallarm releases and prevent installed module deprecation.
-
Client and multi-tenant Wallarm nodes of the unsupported versions (4.8 and lower).
If upgrading from the version 3.6 or lower, learn all changes from the separate list.
Upgrade process¶
-
Upgrade installed modules following the instructions for your Wallarm node deployment option: