Skip to content

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 to wallarm_wstore_upstream.

      Backward compatibility preserved with a deprecation warning:

      2025/03/04 20:43:04 [warn] 3719#3719: "wallarm_tarantool_upstream" directive is deprecated, use "wallarm_wstore_upstream" instead in /etc/nginx/nginx.conf:19
      
    • 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 now wstore. Backward compatibility preserved with a deprecation warning.
  • Docker image:

    • 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_GBSLAB_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.
    • 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.tarantoolcontroller.wallarm.postanalytics.
  • Kubernetes Sidecar Controller:

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.

  • 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

  1. Review recommendations for the module upgrade.

  2. Upgrade installed modules following the instructions for your Wallarm node deployment option:


Other updates in Wallarm products and components →