The modernization of network monitoring has transitioned from monolithic bare-metal installations to the agile, encapsulated environment of containerization. Cacti, a powerhouse in the realm of network graphing and monitoring, has been reimagined through Docker to provide administrators with an isolated, scalable, and portable infrastructure. By abstracting the complex dependencies of PHP, Apache, and MySQL/MariaDB into immutable images, Docker eliminates the "dependency hell" typically associated with manual Cacti installations. This shift allows for rapid deployment, consistent environment mirroring across development and production stages, and a streamlined path to disaster recovery through volume mapping and automated backup scripts. Whether deploying a lightweight instance for a small LAN or architecting a distributed system with remote pollers for global datacenters, the containerized approach ensures that the underlying host operating system remains pristine while the monitoring stack stays updated and isolated.
Analysis of All-in-One Container Architectures
One of the most efficient methods for deploying Cacti is the "All-in-One" (AIO) approach, exemplified by the chestersgarage/cacti image. This architectural pattern bundles the web server, the database engine, the PHP runtime, and the poller into a single unit.
The AIO implementation is built upon Alpine Linux, a security-oriented, lightweight Linux distribution. The choice of Alpine is critical because it significantly reduces the image footprint, leading to faster pull times and a reduced attack surface. Within this image, the Spine poller is integrated and pre-configured, ensuring that the high-performance polling mechanism is operational immediately upon container start.
For users on specialized platforms like unRAID, the AIO approach is particularly potent. It allows the administrator to map specific host directories to container paths to ensure that critical data survives container recreation. The technical requirement for this involves utilizing the -v flag to bind-mount host paths to the internal container filesystem.
The following table details the specific volume mappings required for a persistent chestersgarage/cacti installation:
| Host Path (unRAID Example) | Container Path | Purpose | Access Mode |
|---|---|---|---|
/mnt/cache/appdata/Cacti/backups |
/var/backups |
Storage for manual and scheduled backups | Read-Write (rw) |
/mnt/cache/appdata/Cacti/mysql-data |
/var/lib/mysql |
MySQL/MariaDB raw database files | Read-Write (rw) |
/mnt/cache/appdata/Cacti/mysql-conf |
/etc/mysql |
Database configuration files | Read-Write (rw) |
/mnt/cache/appdata/Cacti/cacti-data |
/var/lib/cacti/rra |
RRD files (Round Robin Database) | Read-Write (rw) |
/mnt/cache/appdata/ Collaborate/apache-conf |
/etc/apache2 |
Apache web server configurations | Read-Write (rw) |
/mnt/cache/appdata/Cacti/php-conf |
/etc/php7 |
PHP runtime configurations | Read-Write (rw) |
/mnt/cache/appdata/Cacti/logs |
/var/log |
System and application logs | Read-Write (rw) |
This granular mapping ensures that the "stateless" nature of Docker does not result in the loss of historical network data. If the container is deleted, the RRD files—which contain the actual graphed data—and the MySQL database remain safely on the host's persistent storage.
Decoupled Database Deployments and Multi-Container Strategies
For enterprise environments, a decoupled architecture is preferred, where the Cacti application and the database reside in separate containers. This approach allows for independent scaling and specialized tuning of the database engine.
Using a combination of images like polinux/cacti and million12/mariadb allows for a professional-grade separation of concerns. In this scenario, the database container acts as a dedicated data store, while the Cacti container acts as the application layer. This requires a network bridge or a specific IP address to facilitate communication between the two entities.
To initiate a decoupled database instance, the following command is utilized:
docker run -d --name cacti-db -p 3306:3306 --env="MARIADB_USER=cactiuser" --env="MARIADB_PASS=my_password" million12/mariadb
Once the database is operational, the Cacti application is launched and pointed toward the database IP:
docker run -d --name cacti -p 80:80 -p 443:443 --env="DB_ADDRESS=192.168.99.100" --env="DB_USER=cactiuser" --env="DB_PASS=my_password" polinux/cacti
This separation introduces a critical administrative requirement: firewall management. Because the containers communicate over specific ports, the host firewall (such as firewalld on CentOS/RHEL 7) must be configured to allow traffic for MySQL (3306), HTTP (80), and HTTPS (443).
The necessary firewall commands are as follows:
firewall-cmd --permanent --zone=public --add-service=mysql
firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --reload
The impact of this configuration is a more resilient system where the database can be backed up, migrated, or upgraded without affecting the availability of the Cacti web interface.
Advanced Deployment with oems/cacti and Custom Configurations
The oems/cacti image provides a versatile middle ground, offering both internal and external database options. By default, this image includes an internal database using MySQL 5.5, which is suitable for rapid prototyping and small LAN installations.
The default credentials for the internal database are:
- Database name: cacti
- Default user: cactiuser
- Default password: cactiuser
It is imperative to remember that the Web interface itself uses a separate set of credentials, with the default user and password being admin.
For users who require persistent data when using the oems/cacti image, volume mounting is mandatory. Without it, deleting the container results in the total loss of the database. To implement persistence, the following command is used:
docker run -d -p 80:80 -v $PWD/mysql:/var/lib/mysql oems/cacti
Further customization is possible by mounting the config.php file directly from the host, allowing administrators to change database connections or system settings without entering the container shell:
docker run -d -p 80:80 -v $PWD/mysql:/var/lib/mysql -v $PWD/config.php:/var/www/html/cacti/include/config.php oems/cacti
For a complete production-ready deployment using this image, including the RRD (Round Robin Database) files, the command expands to:
docker run -d -p 80:80 -v $PWD/mysql:/var/lib/mysql -v $PWD/config.php:/var/www/html/cacti/include/config.php -v $PWD/rra:/var/www/html/cacti/rra oems/cacti
An advanced technique provided by oems/cacti is the ability to extract the default database for use in other environments, such as a docker-compose setup. This is achieved by running:
docker run --rm -it -v $PWD/mysql_org:/var/lib/mysql cacti sh -c "tar -xvf /mysql_basic.tar"
This extracts the database files into the mysql_org directory on the host, which can then be mapped to a standard MariaDB image in a YAML configuration:
yaml
services:
db:
image: mariadb
volumes:
- $PWD/mysql_org:/var/lib/mysql
Scaling and Distributed Polling Architectures
Cacti version 1+ introduced a paradigm shift in how data is collected through the implementation of remote polling servers. In a traditional setup, the Cacti master server handles both the User Interface (UI) and the actual polling of devices via SNMP. As the network grows, this becomes a bottleneck.
The remote poller architecture allows the UI and the information system to remain centrally located while scaling the polling load across multiple datacenters or geographic locations. This creates a distributed monitoring web where each remote poller is a separate entity.
The technical requirements for this distributed model are:
- Each instance (Master or Remote Poller) must possess its own MySQL-based database.
- Remote pollers must have read/write access to the Cacti master's database to sync configurations and report data.
This architecture is typically deployed using docker-compose, where the Cacti service and a MySQL database are defined as separate services. During the initial installation, the Cacti service is configured to automatically set up a new database, ensuring that the environment is bootstrapped without manual SQL execution.
Plugin Management and System Customization
Extending the functionality of Cacti is achieved through plugins. In a containerized environment, managing these plugins requires a strategic approach to volume mounting to ensure that updates to the container image do not wipe out installed extensions.
The startup script in these images is designed to automatically install necessary components to the appropriate directories upon build or run. However, the installation of a plugin is only the first step; the administrator must manually enable the plugin via the Cacti GUI to make it active.
To add new plugins to a running container fetched from Docker Hub, the /cacti/plugins directory must be mounted as a volume. This allows the user to drop plugin folders into the host directory, making them immediately available to the container.
Furthermore, the system allows for the injection of custom settings during the initial installation. This is handled by placing .sql files within the settings folder. The start.sh script is programmed to automatically merge all files ending in .sql during the installation phase, allowing for the programmatic definition of users, database schemas, or system tweaks.
Backup, Recovery, and Migration Workflows
Given that Cacti stores critical historical network data in RRD files and a MySQL database, a robust backup strategy is non-negotiable. In a Docker environment, this involves both filesystem-level backups and application-level database dumps.
The chestersgarage/cacti image provides built-in tools to facilitate this. While scheduled backups are handled internally, a user can trigger an immediate full backup using the following command:
docker exec cacti /backup
This process writes a backup file to the /var/backups directory inside the container. These files are timestamped using a w-hh-mm format, ensuring that multiple versions can be stored without overwriting each other.
To restore a system from a backup, the administrator must perform the following steps:
1. Place the backup file into the host folder mounted as /var/backups.
2. Execute the restore command using the filename as the argument:
docker exec cacti /restore <file-name>
- Terminate the Cacti container.
- Re-run the container to apply the restored state.
A critical post-restore step is to ensure that the MySQL root password is set correctly to maintain security and connectivity.
For users migrating from a non-Docker Cacti installation or a different image, the process involves a partial migration. Instead of attempting to migrate the entire OS, the user should:
- Dump only the Cacti database from the old installation.
- Package the RRD files (the .rrd files containing the graph data).
- Inject these files into the new container's respective volumes (/var/lib/mysql and /var/lib/cacti/rra).
Technical Operations and Troubleshooting
Maintaining a Cacti Docker instance requires familiarity with the container's internal shell and log management. When the system does not behave as expected, the primary tool for diagnosis is the logs command:
docker logs cacti
For deeper inspection, such as modifying the spine.conf file located at /usr/local/spine/etc/spine.conf, the administrator must enter the container's interactive shell:
docker exec -it cacti /bin/bash
This allows for the manual verification of configuration files and the testing of connectivity between the Cacti application and the database engine.
Conclusion
The deployment of Cacti via Docker transforms a complex, dependency-heavy application into a streamlined, manageable service. By leveraging All-in-One images like chestersgarage/cacti for simplicity, or decoupled architectures using polinux/cacti and million12/mariadb for scalability, network administrators can achieve a high level of operational flexibility. The integration of Alpine Linux ensures a lightweight footprint, while the use of volume mapping for MySQL and RRD files protects against the inherent volatility of container lifecycles. The ability to scale via remote pollers in version 1+ further extends Cacti's utility from simple LAN monitoring to complex, multi-datacenter oversight. Ultimately, the success of a Cacti Docker implementation relies on the strict adherence to persistence strategies—specifically the mapping of configuration and data folders—and the implementation of a rigorous backup and restore cadence using the provided internal scripts.