postanalyticsモジュールのアップグレード¶
本手順では、別サーバーにインストールされているpostanalyticsモジュールを最新の6.xバージョンへアップグレードする手順を説明します。postanalyticsモジュールは、Wallarm NGINXモジュールのアップグレードより前にアップグレードする必要があります。
all-in-oneインストーラーでのアップグレード
バージョン4.10以降は、個別のLinuxパッケージが非推奨になったため、Wallarmのall-in-oneインストーラーを使用してアップグレードします。この方法は、従来のアプローチと比べて、アップグレード手順と継続的なデプロイの保守を簡素化します。
インストーラーは次の処理を自動で実行します。
- OSとNGINXのバージョンを確認します。
- 検出したOSとNGINXのバージョンに対応するWallarmリポジトリを追加します。
- これらのリポジトリからWallarmパッケージをインストールします。
- インストールしたWallarmモジュールをNGINXに接続します。
- 提供されたトークンを使用してフィルタリングノードをWallarm Cloudに接続します。
サポート終了のモジュール(3.6以下)をアップグレードするには、別の手順を使用してください。
要件¶
-
Access to the account with the Administrator role in Wallarm Console for the US Cloud or EU Cloud.
-
Access to
https://meganode.wallarm.com
to download all-in-one Wallarm installer. Ensure the access is not blocked by a firewall. -
Access to
https://us1.api.wallarm.com
for working with US Wallarm Cloud or tohttps://api.wallarm.com
for working with EU Wallarm Cloud. If access can be configured only via the proxy server, then use the instructions. -
Executing all commands as a superuser (e.g.
root
). -
Access to the IP addresses and their corresponding hostnames (if any) listed below. This is needed for downloading updates to attack detection rules and API specifications, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers.
手順1: クリーンなマシンを準備します¶
When upgrading modules with all-in-one installer, you cannot upgrade an old package installation - instead you need to use a clean machine. Thus, as step 1, prepare a machine with one of the supported OS:
-
Debian 10, 11 and 12.x
-
Ubuntu LTS 18.04, 20.04, 22.04
-
CentOS 7, 8 Stream, 9 Stream
-
Alma/Rocky Linux 9
-
RHEL 8.x
-
RHEL 9.x
-
Oracle Linux 8.x
-
Oracle Linux 9.x
-
Redox
-
SuSe Linux
-
Others (the list is constantly widening, contact Wallarm support team to check if your OS is in the list)
Using new clean machine will lead to that at some moment you will have both old and new node, which is good: you can test the new one working properly without stopping the old one.
手順2: Wallarmトークンを準備します¶
To install node, you will need a Wallarm token of the appropriate type. To prepare a token:
手順3: Wallarmのall-in-oneインストーラーをダウンロードします¶
Wallarm suggests all-in-one installations for the following processors:
-
x86_64
-
ARM64 (beta)
To download all-in-one Wallarm installation script, execute the command:
手順4: Wallarmのall-in-oneインストーラーを実行してpostanalyticsをインストールします¶
To install postanalytics separately with all-in-one installer, use:
# If using the x86_64 version:
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.6.1.x86_64-glibc.sh postanalytics
# If using the ARM64 version:
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.6.1.aarch64-glibc.sh postanalytics
The WALLARM_LABELS
variable sets group into which the node will be added (used for logical grouping of nodes in the Wallarm Console UI).
手順5: 別サーバー上のNGINX‑Wallarmモジュールをアップグレードします¶
別サーバーにpostanalyticsモジュールをインストールした後は、別のサーバーで動作している関連するNGINX‑Wallarmモジュールをアップグレードします。
手順6: NGINX‑Wallarmモジュールをpostanalyticsモジュールに再接続します¶
On the machine with the NGINX-Wallarm module, in the NGINX configuration file (typically located at /etc/nginx/nginx.conf
), specify the postanalytics module server address:
http {
# omitted
upstream wallarm_wstore {
server <ip1>:3313 max_fails=0 fail_timeout=0 max_conns=1;
server <ip2>:3313 max_fails=0 fail_timeout=0 max_conns=1;
keepalive 2;
}
wallarm_wstore_upstream wallarm_wstore;
# omitted
}
-
max_conns
value must be specified for each of the upstream wstore servers to prevent the creation of excessive connections. -
keepalive
value must not be lower than the number of the wstore servers. -
The
# wallarm_wstore_upstream wallarm_wstore;
string is commented by default - please delete#
.
Once the configuration file changed, restart NGINX/NGINX Plus on the NGINX-Wallarm module server:
手順7: NGINX‑Wallarmと別サーバーのpostanalyticsモジュールの連携を確認します¶
To check the NGINX‑Wallarm and separate postanalytics modules interaction, you can send the request with test attack to the address of the protected application:
If the NGINX‑Wallarm and separate postanalytics modules are configured properly, the attack will be uploaded to the Wallarm Cloud and displayed in the Attacks section of Wallarm Console:
If the attack was not uploaded to the Cloud, please check that there are no errors in the services operation:
-
Analyze the postanalytics module logs
If there is the record like
SystemError binary: failed to bind: Cannot assign requested address
, make sure that the server accepts connection on specified address and port. -
On the server with the NGINX‑Wallarm module, analyze the NGINX logs:
If there is the record like
[error] wallarm: <address> connect() failed
, make sure that the address of separate postanalytics module is specified correctly in the NGINX‑Wallarm module configuration files and separate postanalytics server accepts connection on specified address and port. -
On the server with the NGINX‑Wallarm module, get the statistics on processed requests using the command below and make sure that the value of
tnt_errors
is 0Description of all parameters returned by the statistics service →
手順8: 古いpostanalyticsモジュールを削除します¶
-
Delete old postanalytics module in Wallarm Console → Nodes by selecting your postanalytics module node and clicking Delete.
-
Confirm the action.
When the postanalytics module node is deleted from Cloud, it will stop participation in filtration of requests to your applications. Deleting cannot be undone. The postanalytics module node will be deleted from the list of nodes permanently.
-
Delete machine with the old postanalytics module or just clean it from Wallarm postanalytics module components: