1 Introduction

In daily use, we often come across excellent software managed via configuration files, such as HAProxy, Nginx, Apache, and Keepalived. These software programs are famous for their high performance and flexibility, but their configuration files usually need to be modified directly using a text editor. For technical personnel who are familiar with the configuration file formats of these software programs, directly editing configuration files with a text editor is an efficient and habitual way of operating.

However, for users who are more accustomed to graphical user interfaces, this plain-text operation method may seem complex or even daunting. To make up for this, many projects offering graphical user interface (GUI) management functions have emerged in the community. These tools greatly lower the barrier to entry, enabling more people to easily use these powerful tools. For example, in a previous article, I introduced a project that provides graphical management functions for Nginx:nginxWebUI(See article:Docker Series: Using Docker to Build a Graphical Nginx Based on nginxWebUI), which is specifically designed for Nginx graphical management.

And today, I want to introduce to you a more comprehensive and widely popular graphical management tool—Roxy-WIThis project not only supports HAProxy, but is also compatible with the graphical configuration management of Nginx and Apache (perhaps its other name is more familiar:HAProxy-WI). As a long-developed project, with its comprehensive features and user-friendly interface, it has become the first choice for many users in configuration management.

Note: Actually, there used to be more than just this GUI project supporting HAProxy, but many of them are now 404~.

2 Introduction to Roxy-WI

Roxy-WI is an open-source, powerful graphical management tool, mainly used to configure and manage load balancers and related Web server software, including HAProxy、Nginx 和 ApacheIts original design intention is to provide administrators with a convenient Web interface, simplifying the process of configuration file management while enhancing the efficiency of monitoring and operation. The following are some core functions and features of Roxy-WI:

Core Functions

1. Graphical Configuration Management

• Supports editing and managing configuration files of HAProxy, Nginx, and Apache with an intuitive graphical interface, without the need to directly modify text files.

• Provides version control functions to track configuration change history, making rollback easy.

2. Monitoring and Statistics

• Built-in real-time monitoring function to view performance data of load balancers and servers (such as traffic, connections, latency, etc.).

• Supports integration with tools like Prometheus and Grafana for extended monitoring.

3. Log Management

• Provides log viewing functionality, enabling centralized display of HAProxy, Nginx, or Apache log information.

• Supports rapid filtering and analysis of logs through a Web interface.

4. Cluster Management

• Supports managing multiple nodes or instances, easily syncing configurations to other servers via the interface.

• Provides distributed deployment capabilities, suitable for cluster architectures in complex network environments.

5. User Management

• Provides a multi-user access mechanism, allowing different user permissions to be set (read-only, edit, administrator, etc.).

• Supports LDAP or local account authentication methods.

6. Advanced Features

• Supports scheduled tasks, such as scheduled service restarts or configuration file backups.

• Provides SSL certificate management functions, including generating and deploying certificates.

• Enables alert notifications via Telegram or email.

Applicable Scenarios

• Small and Medium-sized Enterprises: Helps enterprises without professional O&M teams easily achieve efficient load balancing management.

• Development Environment: Developers can quickly deploy and test load balancing solutions via the GUI without needing a deep understanding of configuration file syntax.

• Complex Network Environments: Suitable for users who need to manage multiple load balancers and Web servers simultaneously, especially in scenarios with cluster requirements.

Technical Architecture

Roxy-WI's backend is primarily written in Python, combining SQLite or other databases (MySQL, MariaDB) to store configuration information. Its frontend is built on modern Web technologies, providing a clean and intuitive user interface. Roxy-WI supports Docker deployment and can also run directly on most Linux systems. Common installation methods include:

• Quick deployment using the official installation script.

• Manually installing required dependencies and configuring the service environment.

Advantages

• Lowers the O&M barrier, suitable for users who do not have a deep grasp of HAProxy/Nginx/Apache configuration file formats.

• Comprehensive features, suitable for both production and experimental environments.

• Open-source with an active community, providing continuous updates and documentation support.

3 Deploying Roxy-WI

1 Preparation: Understanding Roxy-WI Configuration Files

This step is mainly to understand Roxy-WI's configuration file ”roxy-wi.cfg” in advance, because whether deploying Roxy-WI using Docker or source code, this configuration file will ultimately be involved (the GitHub address of the configuration file is as follows:https://github.com/roxy-wi/roxy-wi/blob/master/roxy-wi.cfg). Taking the default configuration provided officially as an example for a basic explanation:

[main] {main:lib_path}/configs/hap_config/{main:lib_path}/configs/kp_config/ {main:lib_path}/configs/nginx_config/{main:lib_path}/configs/apache_config/

From the end of the above content[mysql]section, it can be seen that the default configuration uses the SQLite database (enable = 0 means disabling MySQL-compatible databases). If you want to use a MySQL or MariaDB database, please refer to the detailed configuration steps later in the article.

And if you choose to use the default SQLite database, you also need to add the following configuration in roxy-wi.cfg:

# ----------------------------
# 数据库配置（SQLite）
# ----------------------------
[database]
# 使用 SQLite 数据库
db_type = sqlite
# SQLite 数据库文件的存储路径
db_path = /var/lib/roxy-wi/roxy-wi.db  # 根据你的需求修改路径

The following content is a sample configuration of roxy-wi using the SQLite database to manage HAProxy:

# Roxy-Wi 配置文件

# ----------------------------
# 数据库配置（SQLite）
# ----------------------------
[database]
# 使用 SQLite 数据库
db_type = sqlite
# SQLite 数据库文件的存储路径
db_path = /var/lib/roxy-wi/roxy-wi.db  # 根据你的需求修改路径

# ----------------------------
# HAProxy 配置
# ----------------------------
[haproxy]
# HAProxy 配置文件的路径
haproxy_cfg_file = /etc/haproxy/haproxy.cfg
# HAProxy 的状态页面和其他运行时信息的路径
haproxy_status_url = http://haproxy宿主机IP:8085  # 如果你需要 HAProxy 状态页面

# ----------------------------
# Web 界面配置
# ----------------------------
[web]
# 设置 Roxy-Wi Web 界面监听的 IP 和端口
listen_ip = 0.0.0.0  # 监听所有 IP 地址
listen_port = 443   # 可以根据需要更改端口

# ----------------------------
# 用户管理
# ----------------------------
[users]
# 管理员账号配置
admin_user = admin
admin_pass = your_secure_password  # 请设置一个强密码
# 你可以根据需要添加其他用户
# user1 = password1
# user2 = password2

# ----------------------------
# 日志配置
# ----------------------------
[logging]
# 启用日志记录
log_enabled = true
# 设置日志文件路径
log_file = /var/log/roxy-wi/roxy-wi.log
# 日志级别（可选值：info, debug, warning, error）
log_level = info

# ----------------------------
# 其他设置（如API访问、自动备份等）
# ----------------------------
[api]
# 是否启用 API（如果你需要通过 API 来管理 HAProxy）
api_enabled = false  # 如果不使用 API，可以设置为 false

[backup]
# 配置是否自动备份 HAProxy 配置
backup_enabled = false  # 如果你不需要自动备份，可以关闭
# 备份文件存储路径
backup_dir = /var/backups/haproxy/

# ----------------------------
# 监控设置（可选）
# ----------------------------
[monitoring]
# 启用 HAProxy 监控
monitoring_enabled = true
# 配置 HAProxy 监控的频率（秒）
monitoring_interval = 60  # 每60秒监控一次

Explanation:

1. Database Configuration：

• db_type = sqlite: Specifies using SQLite as the database. You can also use MariaDB, but since I only manage one HAProxy, there's really no need for MariaDB.

• db_path = /var/lib/roxywi/roxy-wi.db: Sets the path for the SQLite database file. Usually, you can choose a secure path.

2. HAProxy Configuration：

• haproxy_cfg_file = /etc/haproxy/haproxy.cfg: Specifies the path to the HAProxy configuration file.

• haproxy_status_url = http://127.0.0.1:8000: Specifies the HAProxy status page URL, which is typically used for health checks and monitoring.

3. Web Configuration：

• listen_ip = 0.0.0.0: The Web interface will listen on all IP addresses. You can restrict it to a specific IP address to ensure security.

• listen_port = 8000: The access port for the Web interface. Ensure this port is not occupied by other applications.

4. User Configuration：

• admin_user = admin and admin_pass = your_secure_password: Configures the username and password for the administrator account. Please be sure to set a strong password.

• You can add other users as needed.

5. Logging Configuration：

• log_enabled = true: Enables logging.

• log_file = /var/log/roxy-wi/roxy-wi.log: Specifies the storage path for the log file.

• log_level = info: The log level. You can choose different levels as needed, such as debug, warning, error.

6. API Configuration：

• api_enabled = false: If you do not use the API to manage HAProxy, keep it as false. If you need the API, you can set it to true and perform additional configuration.

7. Automatic Backup Configuration：

• backup_enabled = false: If you do not need to automatically back up HAProxy configuration files, you can disable this feature. If backup is needed, you can enable it and set the backup directory.

8. Monitoring Settings：

• monitoring_enabled = true: Enable HAProxy monitoring.

• monitoring_interval = 60: Collect HAProxy monitoring data every 60 seconds.

2 Docker Deployment

2.1 Roxy-WI's Official Attitude Towards Docker Deployment

The official recommendation actually does not advise deploying Roxy-WI via Docker:

Why does the official Roxy-WI not recommend using Docker for production deployments?

The official Roxy-WI team explicitly states that the Docker deployment method is mainly suitable for development, testing, or learning environments, and is not suitable for production environments. The reasons behind this mainly include the following aspects:

Security Issues

• Insufficient Isolation: Docker provides a containerized environment, but its isolation is not as strong as that of virtual machines (VMs). If containers are misconfigured or have security vulnerabilities, they may pose risks to the host system, especially when running critical services in production environments.

• Updates and Patches Issues: The official team may not provide timely security updates or patches for Docker images, especially for security vulnerabilities in containerized environments. However, production environments require higher security and reliability.

Performance Issues

• Resource Isolation Overhead: Although Docker provides resource isolation features, in high-performance demand scenarios, the overhead brought by containerization may reduce system efficiency. For example, when Roxy-WI needs to process complex configuration files and high-traffic services, the containerized environment may become a bottleneck.

• Optimization Difficulty: Compared to running directly on the operating system, containerized system resource allocation and performance optimization may not be as efficient as source code deployment, especially when handling a large number of concurrent tasks.

Long-term Stability and Compatibility Issues

• Image Instability: Docker images may not have undergone long-term rigorous testing. When the Docker engine version is updated or the image changes, certain features may fail or compatibility issues may arise, affecting the stability of the production environment.

• Insufficient Containerization Support: Roxy-WI is not fully optimized for container environments. The various services it manages (such as HAProxy, Nginx, and Apache) involve complex configurations and hardware access requirements, and containerization may increase compatibility issues.

Lack of Persistent Storage

• Data Persistence Challenges: Docker containers default to ephemeral storage, and data may be lost after a restart. Although data can be persisted by mounting volumes, improper configuration may lead to the loss of critical configuration files in the production environment.

• File System Limitations: Roxy-WI needs to frequently modify configuration files or use persistent data. The file system characteristics of containers may lead to additional complexity, which is unfavorable for long-term maintenance.

Debugging and Maintenance Complexity

• Debugging Difficulties: Troubleshooting issues in containerized environments is usually more complex than deploying directly on physical machines or virtual machines. Although Docker provides some debugging tools, troubleshooting in production environments is highly difficult.

• Log Management Issues: Containerized log management is different from traditional environments and may require additional configuration to ensure that logs can be correctly collected and persisted, especially when containers are frequently restarted or migrated.

Source Code Deployment is More Convenient for Managing Multiple Applications

The core function of Roxy-WI is to manage multiple reverse proxy and load balancing tools, including HAProxy、Nginx 和 ApacheThe source code deployment method can:

• Directly access all configuration files and services on the host machine, without complex mounting or mapping.

• Manage service restart and update operations more efficiently, reducing permission management and interaction issues introduced by containerization.

• Provide greater flexibility to adapt to complex deployment requirements in production environments.

Officially Recommended Deployment Method

Roxy-WI officially recommends deploying via source code or traditional operating system installation. Compared to containerization, this method has undergone more rigorous long-term testing and validation, offering higher stability and reliability, while also being easier to debug and maintain.

Conclusion

Docker deployment is suitable for development, testing, or learning environments because it simplifies the installation and deployment process. However, in production environments, due to limitations in security, performance, compatibility, debugging, and maintenance, the official recommendation is to use source code or operating system-level deployment. Especially in scenarios where Roxy-WI needs to manage multiple services such as HAProxy, Nginx, and Apache, source code deployment provides higher flexibility and reliability.

Note: When I was writing this article, I didn't plan to follow the official recommendation and intended to just use Docker deployment + SQLite database to get it done. However, I encountered some strange issues (some pages worked fine while others kept loading despite being configured correctly, etc.), which ultimately led me to just go with source code deployment + MariaDB database~.

2.2 Deploying Using the docker run Format

Create working directory

mkdir -p /docker/roxy-wi/data
mkdir -p /docker/roxy-wi/config

Deploy using the docker run command:

docker run --name roxy-wi -d --privileged --restart=always --net=public-net \
-v /docker/roxy-wi/data:/var/roxy-wi/lib \
-v /docker/roxy-wi/config:/etc/roxy-wi \
-p 8443:443 \
registry.roxy-wi.org/roxy-wi

2.3 Deploying Using docker-compose

Create working directory

mkdir -p /docker/roxy-wi/

Create docker-compose.yml

vim /docker/roxy-wi/docker-compose.yml

Then paste the following content and save it:

version: '3.8'

services:
  roxy-wi:
    image: registry.roxy-wi.org/roxy-wi
    container_name: roxy-wi
    restart: always
    privileged: true
    networks:
      - public-net
    ports:
      - "8443:443"
    volumes:
      - /docker/roxy-wi/data:/var/roxy-wi/lib
      - /docker/roxy-wi/config:/etc/roxy-wi

networks:
  public-net:
    external: true

Start the Roxy-WI container

cd /docker/roxy-wi
docker-compose up -d

Note: Since Docker is not the recommended deployment method for Roxy-WI, I'll be a bit lazy and won't explain the parameters in detail. As for those adventurous friends who ”know there are tigers in the mountains but still go there,” please research it yourselves; it is also very simple.

3 APT Source Code Deployment

3.1 Foreword

Regarding source code deployment, it is recommended to use Ubuntu's LTS (Long-Term Support version, such as 22.04). Following my previous habit, I used Debian's LXC on PVE to deploy it (the Debian system is not within the scope of official direct support):

As a result, a bunch of problems occurred, which really frustrated me. So I simply switched to the Ubuntu 22.04 version of LXC, and then it was completed successfully.

In addition, if you insist on using Debian, it is also fine. You can directly use the code on the Roxy-WI homepage on GitHub, clone it locally using the git command, and then install it manually (GitHub link address:https://github.com/roxy-wi/roxy-wi), but you need to deploy Apache or Nginx yourself. I felt it was too much trouble, so I gave up.

Note 1: Some online tutorials that also use git for deployment require usingroxy-wi.pyto start the service, and some require usingsetup.pyto install. The key point is that these two files cannot be found at all on the Roxy-WI homepage on GitHub, which left me completely confused.

Note 2: Actually, using the APT method is just deploying Apache and the Roxy-WI source code together, which saves time and worry.

Note 3: For those who do not know how to use PVE to create LXC, you can refer to one of my previous articles:Docker Series: Using LXC based on Turnkey-gameserver to set up a Minecraft Bedrock Edition server。

3.2 Preparation (Optional)

Install and upgrade the pip version

Ubuntu 22.04 installs Python 3 by default but does not install pip. When using the apt command to install Roxy-WI related components, although pip will also be installed, because the pip version is low (22.02), it does not support the ”--break-system-packages” option (at least version 23.3 is required). Therefore, the following output will appear when using the default installation:

Therefore, it is recommended to use the following commands to install pip and confirm the default installed pip version before formally installing Roxy-WI:

apt update
apt install python3-pip
pip3 --version

Then use the following command to upgrade the pip version:

python3 -m pip install --upgrade pip

Confirm the upgrade is successful:

Fix the distro-info package

After upgrading the pip version, the following error will also appear:

This is because the version number format 1.1build1 in the distro-info package does not comply with the standard PEP 440 version specification, and pip follows this specification more strictly in the new version, so parsing this version will fail. Therefore, you can run the following command to fix it:

apt install --reinstall python3-distro-info

Create the roxy log directory in advance

After installation, although the ”/var/log/roxy-wi“ directory will eventually be created, this prompt will frequently appear during the installation process

Obsessive-compulsive disorder (OCD) makes it very annoying to look at, so it is recommended to create it in advance:

mkdir -p /var/log/roxy-wi

Note 1: Directly using Ubuntu 24.04 may not have these problems, but since I have a ready-made 22.04 version LXC template, I was too lazy to mess with 24.04. Besides, the new version may not be as stable as the old version.

Note 2: It is best to have a proxy/VPN environment.

3.3 Installing Roxy-WI Using the apt Command

Add the Roxy-WI repository address

echo \
  "deb [arch=amd64, trusted=yes] https://repo.roxy-wi.org/ubuntu \
  $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/roxy-wi.list > /dev/null

Update the repository

apt update

Install Roxy-WI

apt-get install roxy-wi roxy-wi-checker roxy-wi-metrics roxy-wi-smon roxy-wi-portscanner roxy-wi-keep-alive roxy-wi-socket

Confirm the Roxy-WI default configuration file:

cat /etc/roxy-wi/roxy-wi.cfg

3.4 Configuring Roxy-WI to Use MariaDB Database (Optional)

Earlier in the article, when introducing the Roxy-WI configuration file, it was mentioned that Roxy-WI uses the SQLite database by default. This performance is sufficient when only using Roxy-WI to manage one instance. However, once managing multiple instances at the same time, it becomes quite strained. In this case, an external database is needed: MySQL or MariaDB. The following is a demonstration of the MariaDB configuration process:

Create a new Roxy-WI database and user on the database

Here, you can choose your preferred database: if you want to use MariaDB or MySQL, you need to change ”enable = 0” to "enable = 1". At the same time, in the locally or remotely deployed database (log in to the database using the mysqldump command), use the following commands to initialize the database:

CREATE DATABASE roxy-wi;
CREATE USER 'roxy-wi'@'%' IDENTIFIED BY 'your_password';
GRANT ALL PRIVILEGES ON roxy-wi.* TO 'roxy-wi'@'%';
FLUSH PRIVILEGES;

Note: If the locally or remotely deployed database supports remote management, you can also use a client like DBeaver for initialization. For specific steps, please refer to my previous article:Tips and Tricks Series - Manually Initializing a Database: Creating a New Empty Database and Granting Permissions to the Corresponding User。

Install the MariaDB client on the device where Roxy-WI is deployed:

apt-get install mariadb-client libmariadb-dev

Modify the ”roxy-wi.cfg” configuration file on the device where Roxy-WI is deployed to point to the MariaDB database:

[mysql]
# By default Sqlite DB is used
enable = 1
mysql_user = roxy-wi # 需要和第一部分创建的用户名一致
mysql_password = your_password # 需要和第一部分创建的密码一致
mysql_db = roxy-wi # 需要和第一部分创建的库名一致
mysql_host = 127.0.0.1 #如果roxy-wi和数据库在同一台设备上，则可以使用127.0.0.1；如果不是同一台设备，则这里填写数据库设备的IP地址
mysql_port = 3306 # 填写mariadb数据库的实际对外服务端口

Initialize the MariaDB database using the official script

Run the create_db.py script on the device where Roxy-WI is deployed. The script is located in the ”/var/www/haproxy-wi” folder:

python3 /var/www/haproxy-wi/create_db.py

If the initialization is normal, the following output will appear:

And you can see that a large number of tables have appeared in the Roxy-WI database in the MariaDB database, which was originally empty, indicating that the initialization was successful:

Create a service corresponding to Roxy-WI for easier management in the future (optional)

The essence of installing Roxy-WI via APT is to directly use Apache to provide services for Roxy-WI (which is actually a convenient manual installation. The path of Roxy-WI in the Apache configuration file is/etc/apache2/sites-enabled/roxy-wi.conf), which is different from the systemd-type services we are used to (it cannot be directly managed using commands like systemctl reload, restart, etc. (though you can usesystemctl restart apache2orsystemctl reload apache2to achieve this, but people with OCD say they really dislike it).

Therefore, you can manually create a Roxy-WI.service as a shortcut to manage Roxy-WI separately to fit our habits. Follow the steps below.
Create a new Roxy-WI.service file:

vim /etc/systemd/system/roxy-wi.service

Then paste the following content and save it:

[Unit]
Description=Roxy-WI (via Apache)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/systemctl restart apache2
ExecReload=/bin/systemctl reload apache2
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Reload the Systemd configuration, set the newly created Roxy-WI service to start automatically on boot, and start the service immediately:

systemctl daemon-reload
systemctl enable roxy-wi
systemctl start roxy-wi

After that, you can usesystemctl reload roxy-wi和systemctl restart roxy-wito manage Roxy-WI separately.

4 Initializing Roxy-WI

1 Logging into Roxy-WI

Use ”https://roxy-wi宿主机IP“ to log in to the Roxy-WI web interface:

Enter the username and password to log in (the default username and password are both admin):

Click ”admin” in the upper right corner to change the password yourself:

---

If you want to access Roxy-WI using a custom domain name, redirect local port 80 to port 443 (if a CDN is used, this needs to be configured on the CDN provider's side), or use a custom SSL certificate, you need to modify the corresponding Apache configuration file for Roxy-WI:

vim /etc/httpd/conf.d/roxy-wi.conf

To access using a custom domain name, find the following line and replace “roxy-wi.example.com" with your domain name:

<VirtualHost *:443>
    ...
    ServerName my_domain.local
    ...
</VirtualHost>

To enable redirection from port 80 to port 443, please add the following lines to the configuration file:

<VirtualHost *:80>
        ServerName my_domain.local
        Redirect permanent "/" "https://my_domain.local/"
</VirtualHost>

To use a custom certificate, please edit the following lines:

<VirtualHost *:443>
    ...
    SSLEngine on
    SSLCertificateFile /var/www/haproxy-wi/app/certs/haproxy-wi.crt
    SSLCertificateKeyFile /var/www/haproxy-wi/app/certs/haproxy-wi.key
    ...
</VirtualHost>

2 Adding Target Servers Where Services to Be Managed Are Located

2.1 Adding SSH Credentials for the Device Where Roxy-WI Is Located

type = s3ssh-keygencommand to generate a key pair (optional):

ssh-keygen -t rsa -b 4096 -f /var/lib/roxy-wi/keys/roxywi_id_rsa

After that, in the path/var/lib/roxy-wi/keys/, the private key file ”roxywi_id_rsa” and the public key file ”roxywi_id_rsa.pub” will be generated.”

Copy the public key file of the Roxy-WI device to the target server where haproxy is located (assuming the server IP is 192.168.1.100):

ssh-copy-id -i /var/lib/roxy-wi/keys/roxywi_id_rsa.pub [email protected]

---

If the device where Roxy-WI is located and the target server are the same device, you can also copy it manually directly:

mkdir -p /root/.ssh # 可选步骤，如果没有/root/.ssh目录才需要创建
cat /var/lib/roxy-wi/keys/roxywi_id_rsa.pub >> /root/.ssh/authorized_keys

---

In ”Admin area” - “SSH credentials” - “Add”, add an SSH credential for the device where Roxy-WI is located (used to log in via SSH to other devices with HAproxy, Nginx, or Apache installed for management):

Added successfully:

Then upload the content of the previously generated private key file (/var/lib/roxy-wi/keys/roxywi_id_rsa):

Note: A prerequisite for using Roxy-WI to manage haproxy based on the ”SSH key” method is that the target server where haproxy is located must support SSH public key login: that is, in the ”/etc/ssh/sshd_config” file, the ”PubkeyAuthentication yes” setting must be effective (friends who are interested in the detailed operations of configuring SSH public key login can refer to the article:Debian Series: Configuring SSH Public Key Login)。

---

Using ”SSH key” is the officially recommended default (for security), but it is not mandatory. If you do not want to use public key-based login for SSH, you can also use the traditional username and password method to log in to SSH. You only need to uncheck ”Enable SSH key” when adding SSH credentials, and the password input box will appear:

---

2.2 Adding Target Servers Where Applications to Be Managed Are Located (Taking HAProxy Server as an Example)

In ”Admin area” - “Servers” - “Add”, add the host machine where haproxy is located:

Successfully added:

After adding, you can directly test whether Roxy-WI and the device where haproxy is located can successfully connect using SSH:

5 Adding Services to Be Managed on Roxy-WI

1 Installing Services to Be Managed by Roxy-WI (Taking HAProxy as an Example)

Click ”Installation” - “Proxy service”, and select the corresponding server to install HAproxy:

After successful installation, you can see the content in the HAproxy section:

Note 1: For those who plan to use Roxy-WI to manage HAproxy from the very beginning, if HAproxy is a brand new deployment, you can install HAproxy directly in Roxy-WI (the same goes for Nginx, Apache, and Keepalived), which can save a lot of trouble.

Note 2: For ”Available versions”, you can choose any version of the software you wish to install, such as the latest version of haproxy 3.1.1-1. However, whether it can be installed depends on the latest version in the apt repository on the target server. For example, the latest version in the apt repository of my target server Ubuntu 22.04 is 2.4.24, so even if you wish to install 3.1.1-1, the final actual version can only be 2.4.24.

Note 3: If you are using Roxy-WI to install Nginx or Apache, the process is the same, so I won't introduce them one by one.

2 Adding Existing HAProxy Services on Target Servers (Optional)

If it is an HAproxy that was already in use before, and now you just want to use Roxy-WI to manage it (ensure that the HAproxy service is managed through standard service management tools, such as systemd; ensure the status of HAProxy,statistics page 和 Logging Configuration must be set correctly), it is not troublesome either. Follow the normal steps above to add SSH credentials, add the server, and then add the existing service in the Services of the server, taking HAproxy as an example again:

However, if you have some custom configurations when installing HAproxy yourself (for example, not using the default path), you will also need to configure it in the ”Admin area” - “Settings” - “HAproxy” section at the end:

If the service to be managed is not HAproxy, but Nginx or Apache, the process is similar.

6 Using Roxy-WI to Manage Applications (Taking HAProxy as an Example)

1 Overview

---

This part of the content is about how to use Roxy-WI to manage applications. However, I will only briefly introduce it from the perspective of using Roxy-WI, because if we also discuss it from the application perspective (such as HAproxy, Nginx, Apache), not only will the focus of this article be lost, but it might also make things less clear. Furthermore, friends who have already started researching Roxy-WI to manage applications must already know what they need to know, and if I talk about trivial things, I might even be looked down upon~.

---

Roxy-WI's HAProxy feature provides a user-friendly interface for managing and monitoring the configuration and status of HAProxy. It simplifies the deployment and management process of HAProxy, allowing users to easily edit configuration files, view real-time traffic statistics, check health status, and optimize load balancing rules. Through this interface, users can effectively manage multiple HAProxy instances, create and delete frontend and backend services, adjust load balancing strategies, and ensure high availability and flexibility in traffic distribution.

The figure below shows the functional modules provided when using Roxy-WI to manage HAproxy:

Next, I will briefly go over some of the more important features.

2 Overview

“The ”Overview" feature provides an intuitive interface to help users monitor and manage HAProxy instances in real time. It displays key performance data of HAProxy instances, including traffic statistics (such as Bytes In and Bytes Out), current and total sessions, and other information. In addition, users can directly perform management operations through this interface, such as starting, reloading, restarting, or stopping HAProxy instances:

This feature helps users quickly understand the overall operation of HAProxy, identify potential performance bottlenecks or configuration issues, thereby providing a basis for further optimization and management.

3 Config

“The ”Config" feature is mainly used to configure and manage various settings of HAProxy. Through this feature, users can edit HAProxy configuration files and configure load balancing strategies, listening ports, backend servers, etc. It provides a friendly graphical interface that simplifies the HAProxy configuration process, avoiding direct manual editing of complex configuration files, making it suitable for users who want to manage HAProxy configurations intuitively.

Then you can see the content of haproxy.cfg corresponding to the selected haproxy instance:

For example, if I want to see the content of the ”frontend http_front” configuration section, I just need to click to expand it:

After clicking Edit on the right side of the image above, you can directly enter the edit mode:

As you can see, even for those who are not familiar with the content of the haproxy.cfg configuration file, they can directly use Roxy-WI's Config feature to manage the content of haproxy.cfg, and for those who are familiar with the configuration file content, it is even more powerful.

Note: For those who are not familiar with HAProxy configuration, you can refer to my previous article:HAProxy Practical Tutorial: Multi-Scenario Deployment and Common Feature Configuration Analysis。

4 Stats

“The ”Stats" feature is used to monitor and view real-time statistics of HAProxy. Through this feature, users can intuitively view key metrics such as connection status, request count, error rate, and traffic of the frontend, backend, and individual servers. This helps to quickly diagnose the health of load balancing, identify abnormal traffic, and optimize service performance. In addition, Roxy-WI integrates HAProxy's built-in statistics page through the Web interface, allowing O&M personnel to easily obtain relevant data without manually configuring HAProxy's stats listening items:

5 Logs

“The ”Logs“ feature is used to view real-time logs of HAProxy, helping users monitor traffic, troubleshoot faults, and analyze request processing. This feature provides a visual interface for logs, allowing users to view and filter log content directly on the Web interface without logging into the server or manually searching for log files. Through the ”Logs" option, users can quickly discover connection errors, backend server status changes, or abnormal requests, improving O&M efficiency and facilitating the debugging of HAProxy configurations.

However, although the path for reading HAProxy logs is set in Roxy-WI's ”Admin area” - “Settings”:

However, by default, logs are not actually visible in ”Logs”. This is because HAProxy does not write logs directly, but is only responsible for sending logs to rsyslog, which then writes them to the /var/log/haproxy/ directory. Therefore, if you want ”Logs” to display HAProxy logs normally, you need to first modify haproxy.cfg and add the following configuration in the global section:

global
    log /dev/log local0 info
    log /dev/log local1 notice

log /dev/log local0 infolog /dev/log local1 noticeConfirm whether the following path exists:

mkdir -p /var/log/haproxy/

If not, create it yourself:

vim /etc/rsyslog.d/haproxy.conf

Create the HAProxy configuration file in rsyslog:

$ModLoad imudp
$UDPServerRun 514
local0.*    /var/log/haproxy/haproxy.log
local1.*    /var/log/haproxy/haproxy.notice.log

Then paste and save the following content:

systemctl reload haproxy
systemctl restart rsyslog

$UDPServerRun 514

6 Add proxy

“local0.* /var/log/haproxy/haproxy.log

local1.* /var/log/haproxy/haproxy.notice.log

Create Backend:

SSL Offloading:

I won't take screenshots of the other interfaces one by one. Overall, for friends who are not used to the CLI interface, it is really very friendly.

7 Summary

For HAProxy, Roxy-WI should be considered the best graphical management tool at present. As for the graphical management of Nginx and Apache, although Roxy-WI also performs very well, there are still many other choices after all, which is why I chose HAProxy for demonstration in this article.

However, as the saying goes, Roxy-WI is not a must. If you are really familiar with the configuration files of HAProxy (Nginx, Apache, etc.), a single vim is enough~, plus the built-in statistics interface (actually, Roxy-WI basically just references this directly~):

It is absolutely sufficient for daily use.

Note 1: Actually, I regretted it by the time I wrote the second half of the article. HAProxy is so convenient to manage through configuration files. After making changes, just use the commandsystemctl reload haproxyto reload the content, and the current connections won't be interrupted. What more could you ask for (doing the same operation with Roxy-WI requires visiting Roxy-WI in a browser and clicking the mouse several times~). Moreover, the statistics provided by Roxy-WI are actually just calling HAProxy's own statistics directly, with no extra advantages. In contrast, messing around with Roxy-WI itself took me a lot of time, which seems very unworthy now. But I was already on the hook back then, and more than half of the article was written, so I had to persist in finishing it. Of course, this is not to say Roxy-WI is bad, but from my original intention of researching Roxy-WI just to easily manage HAProxy, it was simply ”penny wise and pound foolish”. The key to the problem actually lies in: does HAProxy even need graphical management? Finally, I just hope this article can be helpful to those friends who need to use Roxy-WI to manage software like HAProxy, Nginx, Apache, etc. For myself, it has been confirmed to be completely useless~~~~.

Note 2: Roxy-WI also provides an official demo site. Interested friends can experience it directly:Roxy-WI demo site, username/password: admin/admin.