A Comprehensive CI/CD Guide: Deploying a Spring Boot Application on Choreo — Crafting a Dockerfile for Seamless Deployment

Welcome back to our Spring Boot and Choreo deployment series! In our last blog, we covered the ins and outs of building and versioning your Spring Boot app. Now, in Part 2, we’re diving into Dockerfile creation — the key to seamless deployment with Choreo.

In this blog, we’ll guide you through the essentials of crafting a Dockerfile, from defining the base image to optimizing performance. By the end, you’ll be ready to transform your Spring Boot app into a deployable container, perfectly suited for Choreo’s deployment orchestration.

Let’s get started on this containerization journey — your ticket to streamlined and efficient deployment!

Base Image

FROM openjdk:17-alpine

Starting your Dockerfile with the FROM instruction is a crucial step, as it defines the base image for your container. In your case, you’ve chosen the Alpine variant of OpenJDK 17, a lightweight Linux distribution. But why does it have to be lightweight,

Choosing a lightweight base image, such as Alpine Linux, for your Docker containers offers several advantages in the context of microservices, cloud-native applications, and containerized environments. Here are a few reasons why a lightweight base image is often preferred:

Security

Minimalistic images often have a reduced attack surface because they include only essential components. This can contribute to a more secure environment by minimizing potential vulnerabilities.

Reduced Image Size

Lightweight base images typically have a smaller footprint compared to their full-fledged counterparts. This is crucial for faster image downloads, quicker container startup times, and more efficient use of storage

WORKDIR /app

The WORKDIR command in Docker is used to set the working directory for any subsequent RUN, CMD, ENTRYPOINT, COPY, and ADD instructions in the Dockerfile.

In this case, the /app directory is being set as the working directory. This means that any subsequent commands or file operations will be relative to this directory unless an absolute path is specified.

ARG USER=buddhima

ARG USER_GROUP=buddhima

ARG USER_ID=10001

ARG USER_GROUP_ID=10001

Running processes as a non-root user in a container enhances security. If a container runs as the root user and gets compromised, it might have more privileges on the host system, potentially leading to security vulnerabilities. By running the container as a non-root user, you limit the potential impact of security breaches.

RUN addgroup -g ${USER_GROUP_ID} -S ory; \

adduser -u ${USER_ID} -S ory -G ory -D -h /app -s /bin/nologin; \

chown -R ${USER_ID}:${USER_GROUP_ID} /app

addgroup -g ${USER_GROUP_ID} -S ory;: This command creates a group named “ory” with the specified group ID (USER_GROUP_ID). The -S flag indicates that this is a system group.

adduser -u ${USER_ID} -S ory -G ory -D -h /app -s /bin/nologin;: This command creates a user named “ory” with the specified user ID (USER_ID). The user is added to the “ory” group (-G ory). The -S flag indicates that this is a system user. The -D flag instructs adduser to create a home directory (-h /app). The shell for this user is set to /bin/nologin to restrict login access.

chown -R ${USER_ID}:${USER_GROUP_ID} /app: This command changes the ownership of the “/app” directory and its contents recursively to the user and group created earlier.

By setting the shell to /bin/nologin, you ensure that the user cannot log in interactively. This is beneficial for security because if an attacker gains access to the container or system, they won’t be able to log in using the compromised user account.

ADD — chown=10001:10001 https://github.com/Buddhimah/demo-vehicle-service/releases/download/v0.0.34/employee-0.0.34.jar /app/

— chown=10001:10001: This option sets the ownership of the copied file or directory to the specified user and group IDs. In this case, it’s setting the ownership to the user ID 10001 and the group ID 10001.

https://github.com/Buddhimah/demo-vehicle-service/releases/download/v0.0.34/employee-0.0.34.jar: This is the source URL from which the file is downloaded. In this case, it’s a JAR file hosted on GitHub.

/app/: This is the destination directory inside the Docker image where the file will be copied.

So, this ADD instruction fetches the JAR file from the specified URL and copies it into the /app/ directory in the Docker image, setting the ownership to the user with ID 10001 and group with ID 10001. This is a common practice to ensure that the file is owned by a specific non-root user within the container, adhering to the principle of least privilege for security reasons.

The finalised docker file can be found https://github.com/Buddhimah/demo-vehicle-service/blob/main/Dockerfile