DEV Community: Om Patil

Step-by-Step Deployment Guide for Spring Boot Services on Ubuntu Server with CI/CD & Reverse Proxy

Om Patil — Thu, 19 Jun 2025 13:56:18 +0000

🧭 Overview
In this guide, I’ll walk you through a complete deployment pipeline for Spring Boot services using GitHub Actions, Ubuntu servers, and Nginx. We'll deploy two environments—Dev and Prod—on separate servers and configure:

✅ Systemd-based service management
✅ Auto-start on reboot
✅ Reverse proxy with Nginx
✅ CI/CD using GitHub Actions
✅ Branch-based deployment:
→ Push to dev → Deploys to Dev server
→ Push to main → Deploys to Prod server

      ┌────────────┐
      │ Static IP  │
      │ your-ip    │
      └────┬───────┘
           │
    ┌──────┴──────┐
    │  Reverse    │
    │   Proxy     │
    │   (Nginx)   │
    └────┬───────┘
  ┌──────┴───────┐
  │              │

┌─────▼─────┐ ┌────▼─────┐
│ Dev Server│ │ Prod Server│
│your-ip │ │ your-ip |
│ Port 8081 │ │ Port 8082 │
└───────────┘ └────────────┘

🔧 1. Initial Server Setup
✅ Install Java 21
sudo apt update && sudo apt upgrade -y
sudo apt install openjdk-21-jdk -y
java -version

📁 Create App Directory
mkdir ~/apps
cd ~/apps

📦 2. Deploy Spring Boot Applications
Upload your JARs to respective servers:

scp dev-app.jar ubuntu@your-ip:/home/ubuntu/apps/
scp prod-app.jar ubuntu@your-ip:/home/ubuntu/apps/

⚙️ 3. Create systemd Services
Use environment variables for better flexibility.

🔑 Create Environment Files
On Dev Server:
echo "SERVER_PORT=8081" > /home/ubuntu/apps/dev.env

On Prod Server:
echo "SERVER_PORT=8082" > /home/ubuntu/apps/prod.env

🧪 Dev Service: /etc/systemd/system/dev-app.service
[Unit]
Description=Spring Boot Dev Application
After=network.target

[Service]
User=ubuntu
WorkingDirectory=/home/ubuntu/apps
EnvironmentFile=/home/ubuntu/apps/dev.env
ExecStart=/usr/bin/java -jar /home/ubuntu/apps/dev-app.jar --server.port=${SERVER_PORT}
SuccessExitStatus=143
Restart=always
RestartSec=5
StandardOutput=file:/home/ubuntu/apps/dev-output.log
StandardError=file:/home/ubuntu/apps/dev-error.log

[Install]
WantedBy=multi-user.target
Repeat similarly for prod-app.service with prod.env.

▶️ 4. Enable and Start Services
sudo systemctl daemon-reload
sudo systemctl enable dev-app # On Dev Server
sudo systemctl enable prod-app # On Prod Server

sudo systemctl start dev-app
sudo systemctl start prod-app

✅ 5. Verify Deployment
Check status:
systemctl status dev-app
systemctl status prod-app

Test API:
curl http://:8081/endpoint
curl http://:8082/endpoint

🔄 6. CI/CD: Auto-Deploy with GitHub Actions
Create workflow files for each branch.

Example: .github/workflows/deploy-dev.yml
on:
push:
branches: [dev]

jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Copy JAR to Dev Server
uses: appleboy/scp-action@master
with:
host: ${{ secrets.DEV_HOST }}
username: ubuntu
key: ${{ secrets.SSH_KEY }}
source: target/dev-app.jar
target: /home/ubuntu/apps/dev-app.jar

  - name: Restart Dev App
    uses: appleboy/ssh-action@master
    with:
      host: ${{ secrets.DEV_HOST }}
      username: ubuntu
      key: ${{ secrets.SSH_KEY }}
      script: sudo systemctl restart dev-app

Repeat similarly for main branch → Prod server.

📜 7. Logging with Rotation
Logs are stored at:

/home/ubuntu/apps/dev-output.log

/home/ubuntu/apps/prod-output.log

📦 Add Log Rotation
Create /etc/logrotate.d/dev-app:

/home/ubuntu/apps/dev-output.log {
daily
rotate 7
compress
missingok
notifempty
copytruncate
}
Repeat for prod-output.log.

🛡️ 8. Security Best Practices
Enable UFW firewall:

sudo ufw allow 22
sudo ufw allow 80
sudo ufw allow 8081
sudo ufw allow 8082
sudo ufw enable
Disable root SSH login

Keep servers updated regularly

Use GitHub Secrets for all sensitive credentials

🌐 9. Optional: Reverse Proxy with Nginx
Install Nginx on your reverse proxy server:

sudo apt install nginx -y

Create config: /etc/nginx/sites-available/reverse-proxy
server {
listen 80;
server_name your-ip;

location /dev/ {
    proxy_pass http://your-ip:8081/;
    proxy_set_header Host $host;
}

location /prod/ {
    proxy_pass http://your-ip:8082/;
    proxy_set_header Host $host;
}

}

Enable and restart:
sudo ln -s /etc/nginx/sites-available/reverse-proxy /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

Test:
http://your-ip/dev/hello → Dev
http://your-ip/prod/hello → Prod

🧠 Pro Tips for Production
Health Check : Use /actuator/health endpoint and restart if it fails
Monitoring : Use htop, glances, or Prometheus + Grafana
Docker (Optional) : Containerize apps to simplify deployment
Secrets : Always use .env files or GitHub Secrets
Recovery : Keep previous .jar backups or use versioned deployment folders

🏁 Conclusion
With this setup, you’ve built a complete, secure, and automated deployment pipeline for Spring Boot services:

Branch-based CI/CD deployment

Nginx reverse proxy with clean routing

Auto-restarting apps

Centralized logging with rotation

Optional Docker support for scaling later

📢 If this helped you, give a ❤️ or comment below!
Follow me for more hands-on guides in DevOps, Linux, and Java 🚀

Dockerizing a Spring Boot Microservice on WSL: My Learning Journey

Om Patil — Wed, 18 Jun 2025 12:36:16 +0000

Recently, I Dockerized my Spring Boot microservice and ran it successfully using WSL (Windows Subsystem for Linux). I also connected it to a PostgreSQL database running on my Windows host. It wasn't all smooth sailing—but I learned a ton, and I'm sharing it here to help fellow developers!

🛠️ My Environment

OS: Windows 10 with WSL (Ubuntu)
App: Spring Boot Microservice
Database: PostgreSQL on Windows
Tools: Docker, Maven

📦 Step-by-Step Journey

1️⃣ Create a Dockerfile

Here's the Dockerfile I used to containerize my app:


Dockerfile
FROM openjdk:23-jdk-slim
WORKDIR /app
COPY target/myservice.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]
✅ Tip: I used openjdk:23-jdk-slim because my app runs on Java 23.

2️⃣ Build the JAR
I packaged my Spring Boot app using:
mvn clean package -DskipTests

I initially tried ./mvnw but switched to mvn since I already had Maven installed on WSL.

3️⃣ Build the Docker Image
docker build -t jwt-service .

This built my custom image containing the application JAR.

4️⃣ Database Connectivity Challenge
Initially, I used this in application.properties:

spring.datasource.url=jdbc:postgresql://host.docker.internal:5432/myservice_db
But it failed inside WSL.

✅ Fix: I got my actual local IP using ipconfig on Windows and updated it:

spring.datasource.url=jdbc:postgresql://my_ip:5432/myservice_db
5️⃣ PostgreSQL Access Errors
I ran into these issues:

❌ Connection timed out

❌ no pg_hba.conf entry for host...

Fixes:

Edited pg_hba.conf to allow my IP.

Set listen_addresses = '*' in postgresql.conf.

Restarted PostgreSQL on Windows.

Tested it using a temporary PostgreSQL container:

docker run --rm -it postgres:16 psql -h my_ip -U postgres -d myservice_db
Worked perfectly!

6️⃣ Running the App in Docker
docker run -p 8080:8080 --name myservice-container myservice-service
Accessed the API at:
http://localhost:8080/myservice/service

7️⃣ Keep Container Running After Closing WSL
I used -d to run the container in the background:

docker run -d -p 8080:8080 --name jwt-container jwt-service

Or detached from a live container with:

Ctrl + P then Ctrl + Q

🚪 This keeps the container running while exiting the terminal.

🔍 What I Learned
✅ How to Dockerize a Spring Boot app
✅ How to connect from WSL Docker to host PostgreSQL
✅ How to configure pg_hba.conf and postgresql.conf
✅ Using psql inside a container to test connectivity
✅ Running containers in detached mode

🧠 What’s Next?
I plan to fully Dockerize the database as well, and eventually use Docker Compose to orchestrate the full microservice stack.

🙌 Final Thoughts
This wasn't just about Docker commands—it was about solving real-world issues like network configs, file access, and container persistence. I hope this helps someone else facing similar issues.

Feel free to drop your feedback or ask any questions in the comments!

Learning Linux Commands: A Game-Changer for DevOps on Windows Using WSL

Om Patil — Tue, 17 Jun 2025 12:48:41 +0000

As someone working in a DevOps environment, I recently started diving into the world of Linux commands—and wow, it’s been a revelation! Whether you’re setting up CI/CD pipelines, configuring servers, or managing Docker containers, Linux is at the heart of everything DevOps.

But here's the twist: I work on a Windows machine. So how did I manage to get hands-on with Linux? The answer is: WSL (Windows Subsystem for Linux).

🐧 Why WSL is a Blessing for DevOps Engineers on Windows
WSL allows you to run a full Linux distribution right inside Windows without needing to dual boot or spin up a virtual machine. You get the power and flexibility of Linux while keeping your existing Windows setup.

Benefits:

Run Linux CLI tools natively

Use bash scripts, SSH, Git, Docker, etc.

Access both Linux and Windows files

Faster and lighter than a VM

If you're a DevOps engineer using Windows, WSL is your best friend!

🧠 Linux Commands I Learned (and Why They Matter)
Here are some fundamental Linux commands I learned, along with how they help in day-to-day DevOps tasks:

cd – Change Directory
cd /path/to/directory
📌 Why it's useful:
Navigate between project folders, configuration directories, or log file locations. Knowing your way around the filesystem is essential.
ls – List Files and Directories
ls -l
📌 Why it's useful:
Check what's inside a directory, view permissions, timestamps, and file sizes—especially useful when debugging deployment folders.
grep – Search Text in Files
grep "ERROR" logs.txt
📌 Why it's useful:
Find errors in huge log files quickly. Combine with tail or cat for log analysis during debugging or monitoring.
tail – View the End of a File
tail -n 50 app.log
📌 Why it's useful:
Quickly view the latest logs. Perfect for checking what just went wrong in a running application or pipeline.
chmod and chown – Manage Permissions
chmod +x script.sh
chown user:group file.txt
📌 Why it's useful:
Control who can execute scripts or access sensitive config files. Crucial for script execution and security in servers or CI/CD workflows.
ps and kill – Manage Processes
ps aux | grep java
kill -9 1234
📌 Why it's useful:
Check which processes are consuming resources and kill any stuck or zombie processes—especially handy while managing apps or services.
df and du – Check Disk Space
df -h
du -sh /var/log
📌 Why it's useful:
Monitor disk usage to prevent your server from going down due to lack of space—a common issue in cloud-hosted environments.
scp and ssh – Secure Copy and Remote Access
scp file.txt user@server:/path
ssh user@server
📌 Why it's useful:
Transfer files to/from servers and log into remote machines to troubleshoot or deploy applications.
docker – Container Management
docker ps
docker exec -it container_name bash
📌 Why it's useful:
Interact with running containers, debug issues, and manage containerized services—a core part of DevOps.

⚡ Pro Tip: Combine Commands for Superpowers
You can chain commands using pipes (|) or logical operators (&&, ||) to build powerful one-liners:

ps aux | grep nginx | awk '{print $2}' | xargs kill -9
The above command finds and kills all nginx-related processes.
DevOps magic!

✨ Final Thoughts
Linux commands are not just something to memorize—they are tools that give you control, speed, and flexibility as a DevOps engineer. And if you're on Windows, don't let that stop you: install WSL, and start practicing today.

The more you use it, the more natural it becomes—and the more effective you’ll be in managing infrastructure, automating tasks, and solving real-world problems.