This enterprise-grade deployment approach for CentOS 7, CentOS 8, and Rocky Linux covers server initialization, production configuration for MySQL and Nginx, systemd-based service management, and log governance. It solves three common production issues: disk exhaustion caused by nohup, unstable default settings, and releases without rollback paths. Keywords: Linux deployment, Java operations, systemd.
Technical Specifications Snapshot
| Parameter | Description |
|---|---|
| Operating System | CentOS 7 / CentOS 8 / Rocky Linux |
| Language | Java, Shell, SQL, Nginx Config |
| Frontend Type | Static assets built from Vue / React |
| Web Service | Nginx |
| Database | MySQL 8.0 |
| Process Management | systemd |
| Logging Stack | journalctl + logrotate |
| Protocols | HTTP / TCP |
| Stars | Not provided in the source content |
| Core Dependencies | JDK 1.8, nginx, mysql-server, chrony |
This deployment approach targets real production environments, not just a setup that “happens to run”
The value of the original material is that it is not a one-off installation tutorial. Instead, it provides a complete path from system initialization to production release and rollback. The core idea is straightforward: standardize the system first, deploy the application second, and finally close the loop with logging, release management, and operations.
For Java frontend-backend separated projects, the real risk usually is not “startup failure” but “losing control after running for a few weeks.” Examples include logs filling up the disk, untraceable configuration changes, services that cannot self-heal after a crash, and databases still running with default parameters. This deployment plan addresses those issues systematically.
Server initialization is the first line of defense for stability
During initialization, install common tools in one pass, enable time synchronization, raise file descriptor and process limits, and configure the firewall according to the principle of minimum exposure. The most important outcome here is not the commands themselves, but the creation of a consistent server baseline.
yum install -y wget curl vim net-tools lrzsz tree zip unzip tar chrony
systemctl start chronyd && systemctl enable chronyd # Enable time synchronization to prevent drift in logs and scheduled jobs
cat >> /etc/security/limits.conf <<'EOF'
* soft nofile 65535 # Increase the file descriptor limit to avoid exhaustion under high concurrency
* hard nofile 65535
* soft nproc 65535 # Increase the process limit to avoid restricting Java services
* hard nproc 65535
EOF
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --permanent --add-port=8080/tcp
firewall-cmd --permanent --add-port=3306/tcp
firewall-cmd --reload # Open only the required portsThis configuration establishes the system baseline, time consistency, and network boundary controls.
A standardized directory layout significantly reduces operational complexity
In enterprise environments, one of the biggest problems is inconsistent directory structures across servers. Separate software, project files, frontend assets, logs, and backups. Doing so makes future releases, troubleshooting, backups, and automation scripts much easier.
mkdir -p /usr/local/soft # Software installation directory
mkdir -p /data/project # Java project directory
mkdir -p /data/frontend # Frontend static assets directory
mkdir -p /data/logs # Centralized log directory
mkdir -p /data/backup # Release backup directoryThis directory convention creates fixed anchor points for deployment, rollback, and log governance.
JDK and MySQL should be installed through controlled production methods
The JDK 1.8 section emphasizes avoiding the system default package because the version is harder to control, the upgrade strategy is often inconsistent, and environment variables vary across environments. In production, it is better to upload a specific archive and configure JAVA_HOME explicitly.
cd /usr/local/soft
tar -zxvf jdk-8u*.tar.gz
mv jdk1.8* jdk1.8 # Standardize the directory name for scripts and operations
cat >> /etc/profile <<'EOF'
export JAVA_HOME=/usr/local/soft/jdk1.8
export JRE_HOME=$JAVA_HOME/jre
export CLASSPATH=.:$JAVA_HOME/lib:$JRE_HOME/lib
export PATH=$PATH:$JAVA_HOME/bin
EOF
source /etc/profile
java -version # Verify that the JDK is activeThis script installs a fixed JDK version and standardizes global environment variables.
The focus of production MySQL installation is account isolation and parameter tuning
The original content highlights two key principles. First, do not let business applications connect with root over the long term. Second, enable utf8mb4, slow query logging, and connection-related tuning as early as possible. This improves both security and observability.
ALTER USER 'root'@'localhost' IDENTIFIED BY 'Mx@123456'; -- Change the root password
CREATE USER 'biz'@'%' IDENTIFIED BY 'Biz@123456'; -- Create a dedicated business account
CREATE DATABASE biz_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
GRANT ALL ON biz_db.* TO 'biz'@'%'; -- Grant the business account access to the business database
FLUSH PRIVILEGES;This SQL completes the most basic and most critical layer of database permission isolation.
[mysqld]
character-set-server=utf8mb4
max_connections=500 # Increase the maximum number of connections for concurrent access
wait_timeout=600
interactive_timeout=600
innodb_buffer_pool_size=512M # Allocate core cache space for InnoDB
innodb_log_file_size=256M
slow_query_log=1 # Enable slow query logging for performance troubleshooting
slow_query_log_file=/data/logs/mysql-slow.log
long_query_time=2These key my.cnf settings address character encoding, connection capacity, and slow SQL monitoring.
Nginx should serve both static assets and reverse proxy traffic
For frontend-backend separated projects, Nginx acts as both the static file server and the unified entry point for backend APIs. The frontend uses try_files to handle SPA routing, while the backend proxies /api/ requests to the local Java service.
server {
listen 80;
server_name _;
location / {
root /data/frontend;
index index.html;
try_files $uri $uri/ /index.html; # Support Vue/React History mode routing
}
location /api/ {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 60s; # Control proxy connection timeout
proxy_read_timeout 60s;
}
}This configuration creates a unified traffic entry point for frontend paths and backend API proxying.
Java services should be managed by systemd instead of running directly with nohup
This is the most production-critical part of the entire deployment plan. systemd does not just provide another startup method. It adds real service governance: automatic restarts, queryable service state, centralized logs, and explicit startup dependencies.
[Unit]
Description=Java Project Service
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/soft/jdk1.8/bin/java -Xms512m -Xmx1024m -XX:+HeapDumpOnOutOfMemoryError -jar /data/project/demo.jar
SuccessExitStatus=143
Restart=always # Restart automatically after abnormal exit
RestartSec=5 # Wait 5 seconds before restarting after failure
[Install]
WantedBy=multi-user.targetThis service file enables Java process management, self-recovery, and basic JVM protection.
Together with systemctl status java-project and journalctl -u java-project -f, it replaces the scattered nohup.out approach and avoids uncontrolled logging and the issue where deleted log files still occupy disk space.
Frontend releases and log governance must become part of the standard workflow
The frontend process is relatively simple: build locally, upload the contents of dist to /data/frontend, fix permissions, and restart Nginx. However, the real reliability gain comes from log rotation and a rollback strategy.
/data/logs/*.log {
daily
rotate 7
missingok
compress
delaycompress
notifempty
copytruncate # Rotate logs without interrupting processes that are still writing
}This logrotate rule rotates logs daily, retains seven days of history, and compresses old files.
cp /data/project/demo.jar /data/backup/demo-$(date +%Y%m%d).jar # Back up the old version first
systemctl stop java-project # Stop the current service
# Upload the new jar and overwrite the old file
systemctl start java-project # Start the new version
systemctl status java-project # Check the runtime status
journalctl -u java-project -f # Watch startup logs in real timeThis release procedure creates a minimal but practical rollback loop that small and medium-sized teams can execute consistently.
The core benefits of this approach are standardization, recoverability, and operational readiness
From an architectural perspective, this is not a complex platform. It is a cost-effective production delivery template. By combining a Linux baseline, MySQL parameter governance, a unified Nginx entry point, systemd-based process management, and log rotation, it builds a stable deployment model for single-server or lightweight production environments.
If your project still relies on nohup java -jar, default MySQL settings, and manual frontend file copies, this approach can significantly reduce incident rates over time. It is especially valuable for small and medium-sized applications, private deployments, and teams moving from training or demo environments into production.
FAQ
1. Why is nohup not recommended for starting Java in production?
Because nohup only solves background execution. It does not solve automatic restarts, state management, log aggregation, or failure recovery. systemd provides process supervision, centralized logging, and boot-time startup, which makes it a much better fit for production.
2. Why should MySQL use a dedicated business account instead of root?
The root account has excessive privileges, carries higher risk if exposed, and makes permission auditing harder. A dedicated business account can be granted access at the database level and aligns with the principle of least privilege.
3. What is the purpose of try_files $uri $uri/ /index.html in frontend configuration?
It supports Vue and React applications that use History mode routing. When a user directly opens a deep route, Nginx falls back to index.html and lets the frontend router take over, preventing a 404 response.
Summary
This article restructures scattered deployment steps into a practical enterprise-grade Linux deployment approach. It covers server initialization, JDK 1.8, MySQL 8.0, Nginx, systemd-based Java service management, frontend static asset release, log rotation, and release rollback. Its primary goal is to eliminate common production issues such as disk exhaustion from nohup, unstable default configuration, and weak security boundaries.