Containerize a Spring Boot application with Podman Desktop

FONT: https://developers.redhat.com/articles/2023/10/19/containerize-spring-boot-application-podman-desktop#running_the_containerized_application

You are here

Containerize a Spring Boot application with Podman Desktop

October 19, 2023

Cedric Clyburn Related topics: ContainersJavaKubernetesSpring Boot Related products: Podman DesktopRed Hat Enterprise Linux

Share:

Spring and Spring Boot are developer favorites for building Java applications that run in the cloud. Spring is known for being production-ready, complimenting containerization very well. According to the State of Spring 2022 report, Kubernetes has become the dominant platform for running Spring apps. So, how can we take a Spring application, containerize it, and run it locally? Let’s explore this by using Podman Desktop, an open-source tool to seamlessly work with containers and Kubernetes from your local environment.

Prerequisites

  • Spring Boot Application: For this article, we’ll use the popular Spring PetClinic sample application on GitHub (Figure 1). Feel free to also use your own project or start from the Spring Initializr.
A screenshot of the Spring Pet clinic Repository on Github
Figure 1: The Spring Petclinic repository on Github.
  • Podman Desktop: Let’s use Podman Desktop, the powerful GUI-based tool for deploying and managing containers using the Podman container engine. Once installed, you’ll be ready to start containerizing your Spring application (Figure 2).
A screenshot of the Podman Desktop dashboard.
Figure 2: The Podman Desktop dashboard.

Containerizing the Spring Boot application

Let’s get started by cloning the application’s source code if using the PetClinic repository.

git clone https://github.com/spring-projects/spring-petclinic.git
cd spring-petclinic

While we can use Maven to build a jar file and run it, let’s jump straight into creating a Containerfile in the project’s root directory, which will serve as the blueprint for the container image we’ll create later (analogous to Docker’s Dockerfile). You can create the file with the command touch Containerfile or simply create it from your IDE. Let’s see what the Containerfile will look like for this sample Spring Boot application:

# Start with a base image that has Java 17 installed.
FROM eclipse-temurin:17-jdk-jammy

# Set a default directory inside the container to work from.
WORKDIR /app

# Copy the special Maven files that help us download dependencies.
COPY .mvn/.mvn

# Copy only essential Maven files required to download dependencies.
COPY mvnw pom.xml./

# Download all the required project dependencies.
RUN ./mvnw dependency:resolve

# Copy our actual project files (code, resources, etc.) into the container.
COPY src./src

# When the container starts, run the Spring Boot app using Maven.
CMD ["./mvnw", "spring-boot:run"]

Let’s take a deeper look at the components that make up this Containerfile:

  • FROM eclipse-temurin:17-jdk-jammy:
    • Purpose: This line sets the foundation for our container.
    • Deep Dive: It tells Podman to use a pre-existing image that already has Java 17 installed. Think of it as choosing a base flavor for a cake before adding more ingredients. We use the eclipse-temurin image because it’s a trusted source for Java installations.
  • WORKDIR /app:
    • Purpose: Designates a working space in our container.
    • Deep Dive: Containers have their own file system. Here, we’re telling Podman to set up a folder named ‘app’ and make it the default location for any subsequent operations.
  • COPY commands:
    • Purpose: They transfer files from our local system into the container.
    • Deep Dive: The first COPY grabs Maven’s configuration, a tool Java developers use to manage app dependencies. The second copies over the main files of our app: the Maven wrapper (mvnw) and the project’s details (pom.xml).
  • RUN ./mvnw dependency:resolve:
    • Purpose: Downloads necessary libraries and tools for the app.
    • Deep Dive: This command activates Maven to fetch everything our app needs to run. By doing this in the Containerfile, we ensure the container has everything packaged neatly.
  • COPY src./src:
    • Purpose: Add our actual application code.
    • Deep Dive: Our app’s logic, features, and resources reside in the src directory. We’re moving it into the container so that when the container runs, it has our complete app.
  • CMD [“./mvnw”, “spring-boot:run”]:
    • Purpose: Start our application!
    • Deep Dive: This command is the final step. This line tells Podman to run our Spring Boot application using Maven when our container launches.

This Containerfile is ready to be used with Podman Desktop to create a container image of our Spring Boot application (Figure 3). Before building the image for this application, let’s double check the directory structure and Containerfile in our IDE of choice.

A screenshot of the Containerfile in VSCode.
Figure 3: The Containerfile in VSCode.

Building the container image with Podman Desktop

We can now build our container image with Podman Desktop by first heading to the Images section of Podman Desktop and selecting the Build an Image button in the top-right corner (Figure 4).

A screenshot of the Podman Desktop with the build image button highlighted.
Figure 4: The Podman Desktop Build Image is highlighted.

This will open a menu where you can select the path to our previously created Containerfile, which should be in the root directory of the spring-petclinic folder. With the Containerfile selected, we can also give our container image a name, for example, petclinic. Now, click on Build, and you’ll see each of the layers of the image being created. You can find this in your local image registry (the Image section in Figure 5).

A screenshot of the Podman Desktop build image menu.
Figure 5: The Podman Desktop Build Image menu.

Running the containerized application

Fantastic! Let’s return to the Images section to see the containerized Spring Boot application, now built and tagged as an image, as well as the eclipse-temurin base image that was downloaded to build our petclinic image. We can easily run this image as a container on our system using the Run icon to the right of our container image (Figure 6).

A screenshot of the Podman Desktop run container.
Figure 6: The Podman Desktop showing where to run the container.

Under Port Mapping, make sure to assign port 8080 of the container to port 8080 of the host. Feel free to leave all other settings as default. Click Start Container to launch the containerized instance of your Spring Boot application (Figure 7).

A screenshot showing the start container button in the Podman Desktop menu.
Figure 7: Click the start container button in the Podman Desktop menu.

Now, with the container up and running, let’s open the container’s URL in the browser using the handy open browser button within the Podman Desktop user interface (Figure 8).

A screenshot of the Podman Desktop highlighting the open browser button.
Figure 8: The Podman Desktop highlighting the open browser button.

Perfect, looks like our Spring Boot application is running, thanks to the startup command in our Containerfile, as well as the port mapping we configured in Podman Desktop (Figure 9).

A screenshot showing the Spring Boot application is running in Chrome.
Figure 9: The Spring Boot application is running in Chrome.

Now we can see this PetClinic application running in our browser, but that’s not all. For more features that may involve bringing out the terminal, we can now use Podman Desktop instead (Figure 10). This may include, SSH’ing into a container for debugging and modifying settings, maybe viewing the logs of a container, or inspecting environment variables. This can all be done under the Container Details section that opens automatically after starting the container.

A screenshot of the Podman Desktop terminal.
Figure 10: The Podman Desktop terminal.

Wrapping up

We have gone from local Spring Boot code to containerizing the application and running it with Podman Desktop! Now, as a container, we can share this application across environments using registries like Quay.io and Docker Hub and deploy it using Kubernetes and OpenShift to a variety of different cloud providers.Last updated: January 15, 2025

Related Posts

Recent Posts

What’s up next?

Read Podman in Action for easy-to-follow examples to help you learn Podman quickly, including steps to deploy a complete containerized web service. LinkedInYouTubeTwitterFacebook

RED HAT DEVELOPER

Build here. Go anywhere.

We serve the builders. The problem solvers who create careers with code.

Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

Sign me up

© 2025 Red Hat

https://www.google.com/recaptcha/api2/bframe?hl=en&v=Lu6n5xwy2ghvnPNo3IxkhcCb&k=6LfI4RApAAAAAF0FZDNh0WxeTb5vW26PPphSO9CR&bft=0dAFcWeA4cWuzQUGkfsrWOK2bL2tgkxlHUWBM7aegdByjKYGUp9Bscf1mdedF5sLmoYL8ru6xp1vPOFU6FF0l_bIY8xaZM4xN2sg

Install Podman Desktop on Debian (without flatpak) March 27, 2024

FONT: https://aliefee.page/blog/post/install-podman-desktop-on-debian-without-flatpak#install-podman-desktop-on-debian-without-flatpak-

Install Podman Desktop on Debian (without flatpak)

Since there is no official Debian package for Podman Desktop, we need to download the official binary archive and install it manually, in case you don’t want to use Flatpak.

This tutorial assumes:

  • You have a working Debian installation (or a Debian based distro like Ubuntu, Linux Mint, Kali, MX Linux etc.)
  • You are comfortable with using terminal and have sudo access
  • You have the latest stable podman installed on your machine. If not just run: sudo apt install podman

1.Download Podman Desktop

First, head over to Podman Desktop Download page and download the latest version archive.

Podman Desktop Download Page

2.Move the downloaded file to /opt

We will install Podman Desktop inside /opt directory. Open your terminal and move the downloaded file to /opt.
Now open terminal and run the command below.
Change <download-directory> and <version> with the path to directory where you downloaded the file and the version you downloaded.

sudo mv <download-directory>/podman-desktop-<version>.tar.gz /opt

3.Extract the archive

cd /opt
sudo tar -xvf podman-desktop-<version>.tar.gz
sudo rm podman-desktop-<version>.tar.gz

sudo mv podman-desktop-<version> podman-desktop

On the question of why we put binaries into /opt:
It is recommended to install software from official repositories whenever possible to avoid clashes of different packaging of the same software. But in our case, since there is no official Debian package for Podman Desktop as of the date i composed this tutorial (March 2024), we installed it into /opt as a convention.
You can read further about the Filesystem Hierarchy Standard https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html

I recommend you to check if there is an official package available in apt repositories before going ahead:

apt search podman-desktop

If you find an official package, you can install it using apt. And you can easily retract the process at this step easily:

sudo rm -rf /opt/podman-desktop-*

Ensuring podman-desktop can be executed

sudo chmod +x /opt/podman-desktop/podman-desktop

At this step, we will put a symbolic link in /usr/local/bin directory.
So that it can be executed in your terminal

sudo ln -s /opt/podman-desktop/podman-desktop /usr/local/bin/podman-desktop

You can check if you can run podman-desktop from your terminal:

which podman-desktop
# /usr/local/bin/podman-desktop
# if you see this output, you are able to run podman-desktop from your terminal

5.Put a Desktop Entry

You can now run podman-desktop from your terminal.
But you will want to run it from your desktop environement’s menu too right?
To achieve that we need to create a .desktop file in /usr/local/share/applications

/usr/local/share/applications/podman-desktop.desktop

[Desktop Entry]
Name=Podman Desktop
Exec=podman-desktop
Terminal=false
Type=Application
Icon=podman-desktop
StartupWMClass=Podman Desktop
Categories=Development;

let’s do it with a few commands:

cd /tmp
echo -e "[Desktop Entry]\nName=Podman Desktop\nExec=podman-desktop\nTerminal=false\nType=Application\nIcon=podman-desktop\nStartupWMClass=Podman Desktop\nCategories=Development;" > podman-desktop.desktop
sudo desktop-file-install --dir=/usr/local/share/applications ./podman-desktop.desktop
rm podman-desktop.desktop

6.[Optional] Install icon file

You can copy and run all the commands at once

cd /tmp
wget https://aliefee.page/podman-desktop-icons.tar # download
tar -xvf podman-desktop-icons.tar # extract
mv podman-desktop-icons icons # rename
sudo cp -r ./icons /usr/local/share # copy
rm -rf icons podman-desktop-icons.tar # clean up

Congrats! You have now Podman Desktop set and up perfectly!

Virtual Desktop Infrastructure (VDI) — how it works and a step by step guide to create a VDI Linux server on cloud using RDP protocol

Idan Friedman

Idan Friedman

10 min read

FONT:

https://medium.com/@idan441/virtual-desktop-infrastructure-vdi-how-it-works-and-a-step-by-step-guide-to-create-a-vdi-linux-2afa9ee02171

Aug 1, 2022

Virtual Desktop Infrastructure or VDI in short, is the ability to connect remotely to another machines with a fully supported GUI and I/O devices.

Probably you have heard long and complicated explanations about this before. In this 3 parts series of articles I’ll discuss about VDI in simple words, give examples of VDI use in cloud and will show how to build VDI servers in an automated process with Packer.

In this article I will discuss about concept of VDI and will guide you through a step-by-step guide to create you own VDI machine in AWS cloud using Ubuntu Linux and RDP remote desktop protocol.

In the 2nd article I will talk machine images and Packer, a tool used to automate machine images. I will give an example for using Packer to automate creation of VDI machine images.

In the last article I will show you an example for a real VDI project done by me while working in Develeap for one of its largest customers, showing the challenges which we faced and how we solved them. I w

Virtual desktop as infrastructure (VDI) in simple words

Virtual desktop as infrastructure (VDI) is having the ability to login and graphically use a remote server as if it was a desktop machine. That is, to seamlessly use a remote server with a desktop GUI connected to your local keyboard, mouse and screen connected to your local computer. In other words, VDI is a remote server which is doing calculations using its own CPU and RAM, while the input and output devices shared and connected to it are from your local machine.

In this configuration the remote server feels like a local machine — you can install on it any application you need, including things like a web browser or a graphical game. The server can include any modern technology such as JAVA JVM, Python interpreter or C++ libraries — which gives an endless variety of options. As the server includes a GUI, you can also run graphical applications too.

An example for virtual desktop as infrastructure (VDI) — a remote server is accessed from a local machine. In this session, a shell terminal is running from within the remote server’s GUI

The basic requirements to share of your input and output devices from your local machine with the remote server is done using a remote desktop solution client application. The remote desktop solution allows sharing the computer input and output devices with the server. You can share “classic” I/O device like a screen, a keyboard or a mouse but also other devices such as a printer, a video camera, volume speakers and even a smart card reader!

The server is required to run an operating system which is capable of handling remote sessions, and a server application/daemon process to actually accept client’s sessions requests, authenticate and handle them.

Both client application on you local machine and server application/daemon must support same remote desktop protocol.

Data flow demonstrating a user accessing a remote server using VDI. Note that no physical I/O devices are connected directly to the remote server, and instead the server is sharing the client’s machine I/O devices.

Advantages of VDI:

Basically you can run almost any application on-premise, but using a VDI remote server can be a considerable choice in some use-cases. Running your application remotely in cloud can have extra benefits such as high internet speed, pay-on-need for resources and high-security and reliability.

Below are two lists covering some of the advantages of running an application remotely, as well as running the remote server on cloud.

Advantages of using VDI as a solution for hosting your application –

  • Accessibility — you can connect to the server from any location — as long as you have network connectivity.
  • No dependency between physical local machine and the remote server — your server can run a different environment regardless of your local machine.
  • No need to maintain physical devices to connect to your server — the server can stay anywhere you want — no need to have a dedicated desk, mouse, keyboard and screen for it.

I want to sharp the difference between running the application locally and remotely using VDI:

When running the application locally — it runs on your OS with the local configurations and machine resources. With VDI a remote server can run your application with a different CPU architecture regardless of the user’s desktop machine. The application will use resources from the server itself and and not from your local machine. Only resource taken from your local machine are for running the remote desktop client.

Advantages of using VDI on cloud platform –

  • Fast access to cloud provider services — as the server is located within the cloud computing center, the physical distances are short, so any communication from your server to other application or Cloud fully-managed services will benefit from a high network speed.
  • Pay as you go, scale-up as needed —you can change the server’s capabilities according to your need and pay-as-you-go. Just to compare, in reality if you need to replace your desktop machine — you will have to replace the whole machine which is very expensive.
  • High-connection internet speed — the server is located in a servers farm with a high internet connection –much faster than the user’s house. This is quite useful in case you want to traffic big amounts of data to your application.
  • Advanced back-ups — cloud provider offers advanced back-up systems which can allow efficient, chip and real-time back-up.
  • High availability— computing centers have advanced power backups and disaster recovery technologies.
  • Better data security — all data is processed on the server itself, without leaving it. Also the server can enjoy the enhanced network security features available on cloud platforms.
A speed test result of a remote VDI server. The remote server is located in a server farm with high-speed internet connection. ( In this case in AWS Frankfurt region )

Importance of good and stable internet connection –

The main disadvantage of VDI is the need for a stable and fast internet connection from the user’s house/office to the server. Generally a remote connection will require a minimum of 2–5Mbps connection speed and up to 10–15 Mbps, depending on usage and remote desktop protocol being used.

VDI — Behind the scenes:

Generally VDI can be done with all major operating systems (Windows and Linux family) — but for this example I will choose Ubuntu Linux as a model.

For the server to serve remote desktop sessions, it requires to have some sort of desktop GUI installed (Gnome, KDE… ) and a remote desktop solution daemon running which allows to share I/O devices between client’s machine and the server. Once you have that, the remote server is able to serve users clients requests and to manage remote sessions.

Which existing solutions are in market?

There are many remote desktop solutions in the market such as VNC, RDP , NICE DCV, VMware and the list continue. There are many clients which support the various solutions.

It is to note that there are already made out the box VDI solutions which are more easy to manage, to scale and to provision multiple servers for multiple users.

What is a desktop GUI?

Before watering our hands, let’s start with answering these two basic most questions –

  1. What is the difference between the large varieties of Ubuntu desktop versions — Ubuntu, Lubuntu, Xubuntu, Kubuntu etc.. ?
  2. What is the difference between Ubuntu server and Ubuntu desktop versions?

The answer for both questions is the installed packages included in each version.

An Ubuntu desktop machine includes the Linux kernel along with many other packages and installations including and not only — a terminal shell, a firewall, drivers, a GUI desktop, and some applications to be used by the user such as a web browser.

Now let’s answer on the 1st question — Ubuntu can support multiple types of GUI desktop solutions — each one has different requirements, applications installed, style and performances. There are multiple versions of Ubuntu each one using a different desktop solution — XFCE desktop is used by Xubuntu, LXQt desktop by Lubuntu, GNOME desktop by Ubuntu “default” popular version.

As for the 2nd question — Ubuntu server is like a light-weight version of the desktop version with no GUI desktop installed — it includes only what needed to run on a server. That is —on a server you don’t need a GUI, you don’t need Firefox or OpenLibre, a media player and many other things which mostly you would like on your personal computer. In vice-versa — you can think about Ubuntu desktop as an extended version of Ubuntu server with more installations which gives the user a better experience and more functionality.

Creating a VDI Ubuntu Linux server in AWS cloud using Ubuntu server and RDP:

After explaining the concepts — let’s try to create a VDI machine.

We will create a remote desktop server in AWS cloud using Ubuntu server 20.04 . We will install GNOME desktop which is the desktop install on Ubuntu “default” desktop distribution.

For this example, I chose working with “remote desktop protocol”, or RDP in shorts. ( In its Linux adaptation it is known as xRDP ) I chose it because it is easy to install and has a wide range of clients. There are many available users’ clients available for free — for Windows, Mac and Linux.

To note, the concept and instructions should be almost the same for any cloud provider (or on-premise server) and other Linux distributions. Also, managing a VDI server with a remote desktop solution other than RDP will work in a similar way to the one I’ll show below.

Steps:

  1. Spin an EC2 virtual server with Ubuntu server version 20.04 .
  2. When creating the EC2 instance make sure to assign it a security group which is open for port 22 (to SSH to the instance) and port 3389 which is used by RDP protocol for contacting the remote server.

3. Wait for the server to be up and running — and connect to it using SSH.

4. Update the apt package manager so we can install a GUI and RDP package

$ sudo apt update

5. Install a GUI solution along with necessary dependencies. For this example the following command will install GNOME desktop GUI which is the default Ubuntu desktop. Note the command below installs a minimal version of GNOME desktop with almost nothing, you can install other GUIs which include all pre-installed applications which generally come with Ubuntu.

# Option 1 - will install a minimal version of GNOME desktop$ sudo apt install gnome-session gdm3
# Option 2 - will install the ubuntu GNOME dekskop with all default applications. Bear in mind that it will require more volume!$ sudo apt-get install ubuntu-desktop

6. Install xRDP server application. When installed, xRDP has automatically created a user named “xrdp” in the operating system called which will run the RDP server application in the background.

$ sudo apt install xrdp -y

7. xRDP uses the SSL-cert manager for securing the authentication between the servers and clients connecting to it. You need to grant the “xrdp” user permissions to access the SSL-cert manager.

$ sudo usermod -a -G ssl-cert xrdp

8. Now restart the xRDP service and make sure it is running.

$ sudo systemctl restart xrdp
$ sudo systemctl status xrdp
xRDP service is running. This indicates you can remotely access the machine using any RDP client

9. Open the OS firewall to port 3389 which is used by xRDP protocol.

$ sudo ufw allow 3389
$ sudo ufw reload

10. At this point we have a GUI and RDP installed – all we need is a user with a password in order to login. we can use default created “ubuntu” user by setting it a password but it has sudo permissions and we should prefer a new user with less permissions. Create a new user in the OS and assign it a password.

$ sudo useradd -m <username>
$ sudo passwd <username>

That’s it! You can now login form your machine to the remote server using any remote control client which support RDP protocol.

Compatible RDP clients are available on all major OS — for example: In Windows you can just search for “remote control” on the start-up menu , in Mac you can download the remote desktop application from the App Store and in Linux you can use Remmina client.

Open your RDP client, on server address fill in the EC2 instance public IP address and later insert the username and password you just set.

I want to note that sometimes you can have troubles connecting because of graphical drivers – an over-pass for this issue is to try and reduce the screen resolution or color-depth in your RDP client configurations.

An example of using Remmina application for Linux OS to login to a remote server using RDP protocol. Here I set a custom resolution and a lower color depth.

Test and play:

Check your physical location from within the remote session — you will be shown the server’s location and not your local machine’s location.

A remote session with Remmina client used to connect to a remote server using RDP protocol. The remote server is running Firefox web browser. The EC2 instance is located in Frankfurt Germany, therefore the location is shown to be Germany. Also note the time differences between my client machine (Israel) and the remote machine.

Now let’s try to do a network speed test on our local machine and on the VDI server — see the high speed and low latency!

A VDI EC2 instance server in AWS Frankfurt region, showing a speed test with 891/1509 Mbps and 1ms latency result.

Now for the gist of it let’s install firefox and try to watch YouTube via the remote server.

$ sudo apt install firefox

How can we go far from here?

So that is a basic proof of concept on how to create a VDI remote Linux server. It is to note that we can use other OS or distributions such as Debian Linux or Windows to act as a remote server with other remote desktop solutions.

So how can we go far from here?

  • We can and should make it more secure — like limiting access through VPN only.
  • We can do some nice DevOps work here — making a whole automated CI/CD pipeline which can create a VDI remote server with needed applications and configurations already pre-installed.
  • We can scale the amount of servers — having hundreds of servers running in parallel — serving hundreds of different users.