Java DevOps Pipeline: Automated Deployment with Gitee/GitLab, Jenkins & Docker

Technology Selection and Architecture Overview

The pipeline uses the following components:

Code Hosting: Gitee or GitLab (open-source friendly, flexible private deployment)

CI/CD: Jenkins

Image Build & Deployment: Docker

Trigger Mechanism: WebHooks

Optional Image Registry: Local Harbor or private Registry

Overall flow:

Developer pushes code → Gitee/GitLab → WebHooks → Jenkins → Build JAR → Create Docker image → Deploy to Docker host

Code Hosting and WebHooks Configuration

1. Gitee/GitLab Repository Setup

After creating a Java project repository, configure WebHooks:

Gitee: Project → Settings → WebHooks → Add WebHook

GitLab: Project → Settings → Webhooks

WebHook URL points to a Jenkins job trigger endpoint, e.g.:

http://<jenkins-server>/project/api-gateway-build

Enable "Push events" or custom trigger conditions. Set a Token/Secret for Jenkins to verify request origin and prevent unauthorized access.

2. Jenkins Job Configuration

Choose "Freestyle project" or Pipeline project.

Source Code Management: Enter Gitee/GitLab repository URL and credentials (read-only token or SSH key recommended).

Build Trigger: Select "Trigger remote build (e.g., from scripts)" or "Receive WebHooks".

Build Environment: Choose Shell script or custom Pipeline.

Jenkins Automation Script Breakdown

The following script serves as a Jenkins Shell build step:

# Parameter definitions
name=api-gateway
imageTag=${BUILD_NUMBER}
image=${name}:${imageTag}

# Locate JAR artifact
jar=$(ls target/*.jar | head -n 1)

# Generate Dockerfile
cat <<-EOS > target/Dockerfile
FROM openjdk:23
ADD ${jar} /app.jar
# Set timezone
RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
RUN echo 'Asia/Shanghai' >/etc/timezone
# Set system encoding
ENV LANG en_US.UTF-8
ENV LANGUAGE en_US:en
ENV LC_ALL en_US.UTF-8
EXPOSE 8080
CMD ["java", "-jar", "/app.jar"]
EOS

# Remove existing same-name container (avoid port conflict)
docker rm -f ${name}

# Build Docker image
docker build --force-rm -f target/Dockerfile -t ${image} .

# Run new container
docker run -d -p 8103:8103 --name ${name} --privileged=true --restart=always ${image}

# Clean old images (keep only current version)
docker images "${name}" --format "{{.Repository}}:{{.Tag}}" | grep -v ":${imageTag}" | xargs -r docker rmi

Key Points

imageTag=${BUILD_NUMBER}

: Each build increments automatically, ensuring image uniqueness and traceability.

After build, old containers and images are automatically removed to prevent disk bloat.

Verify running state and history with docker ps -a and docker images.

Advanced: Integrating a Private Image Registry

For multiple service nodes, push images to a private registry (e.g., Harbor) to enable elastic scaling and rollback. Add to the script:

# Push to private registry (e.g., Harbor)
registry=myharbor.local:5000
docker tag ${image} ${registry}/${image}
docker push ${registry}/${image}

During docker run, pull the specific versioned image directly.

Common Issues and Optimization Suggestions

1. Cross-Host Deployment and Port Conflicts

If multiple instances coexist, assign different ports per instance or use orchestration tools like Docker Compose or Kubernetes.

2. Build Speed and Security

Pre-warm Maven dependencies; plan Jenkins node resources in advance.

Control image layers: merge RUN commands to reduce intermediate layers.

Production environments should use minimal base images (e.g., distroless or openjdk-slim) for improved security.

3. Logging and Monitoring

Map Docker container logs to host directories or integrate with ELK/Prometheus monitoring platforms.

4. Multi-Environment Separation (Test/Staging/Production)

Use Jenkins parameterized builds to dynamically select environment and configuration files, enabling a single script to serve multiple environments.

Summary

This solution lets you build a low-barrier DevOps pipeline for Java services that supports continuous integration and automated deployment. Teams of any size can achieve:

Real-time triggering on code changes

Automatic compilation and packaging

Containerized delivery via Docker

One-click deployment with full history traceability

As the team grows, the pipeline can evolve toward Kubernetes, canary releases, and more advanced automation. The provided scripts and ideas are ready for self-hosted projects; remember to sanitize sensitive data and strengthen security, permissions, and backup measures in production.

Note: Scripts and concepts are for self-hosted practice; sanitize sensitive information per your environment. Production deployments should reinforce security, access control, and backup strategies.