• Introduction
• Setup
• Conclusion

Introduction

The built-in development mode for Quarkus is a great functionality that lets you update the application code, resources, and configurations. Setting it up is a great way to develop your applications locally, as you can immediately see the changes reflected in your application.

Furthermore, we have a remote development mode, which lets you make changes to local files immediately available in a containerized environment. Remote development mode works excellently if the container runs in a local Docker or remote containerized environment.

However, running several simultaneous containers with the remote development mode on, mapped to the same domain, may result in warnings and erratic behavior from the client side.

Setup

Imagine a setup where you are running a set of containers, for example, using docker-compose and mapping them all to my.cluster.host.com (or even localhost)through several ports:

First, you will need to update quarkus.live-reload.url in the properties for all the apps (see docs on where and how to do this). Update the settings to the correct domain and port (in our case, it is 8080, 8081, or 8082):

quarkus.live-reload.url=http://localhost:8081

Next, try starting your containers with the remote development mode enabled and connect to the application from a terminal or an IDE. For the second and the consecutive applications, the attempts to establish a connection you will see the following message in the logs:

$> ./mvnw quarkus:remote-dev -Dquarkus.profile=dev

< ... >

[WARNING] Changed debug port to 57409 because of a port conflict
Listening for transport dt_socket at address: 57409

< ... >

Note: Fallback ports will be random and may vary from the one above.

This setup will break the remote reloading from the terminal on the client side (i.e., your IDE). Two or more of your client applications now see that the default port 50005 for a remote debug is in use and start with a new, random port.

The simple fix is to update the debug ports for all other applications to something other than 5005, such as 6006 and 6007. Custom debug ports can be set in the pom.xml files, under quarkus-maven-plugin, for each of the applications that require this update:

<build>
  <plugins>
    <plugin>
      <groupId>io.quarkus.platform</groupId>
      <artifactId>quarkus-maven-plugin</artifactId>
      <version>${quarkus.platform.version}</version>
      <!-- ADD THE CONFIGURATION MENTIONED BELOW THIS LINE -->
      <configuration>
        <debug>6006</debug>
      </configuration>
...

You can choose whether to update the debug ports for all applications in the cluster or for all applications except one, which will get the default port.

Now, you will need to rebuild your apps and re-initiate the remote development mode for each container. And, voilà, everything works!

One last note: Please ensure you do not use the remote development functionality in the production environment.

Conclusion

A tiny config update brings back the development joy of using remote development mode for more than one container simultaneously.

Happy coding!

Containers are something that we use to run our applications and, normally, we dispose of the whole container when we build a new version of the application or need to upgrade something in the setup. This means that containers are generally having a short lifespan.

However, in this case, I want to show you how to build something that exists for an even shorter period of time and that can be used as an alternative to a local setup for building and testing applications locally before pushing it to test, staging, production, etc.

This is a simplified example of what is being done on a much bigger scale with moving your CI/CD pipelines to such disposable containers, and with libraries like Testcontainers.

In this case, I would like to show you how to setup Jekyll applications, but this can be easily applied to any kind of applications written in any of your favorite languages, like Java or Python. Until recently, I have been running a Jekyll installation locally with all dependencies installed on my machine. However, it has been a bit challenging when moving between machines and reinstalling operating systems. To simplify the process, I decided to containerize the local build and test processes.

I wanted the following:

• To build my code from and to the local folder on my (host) machine
• Run the application (in this case this blog) from a local folder on my (host) machine
• Avoid setting up the environment, or have a minimal and portable setup
• Avoid environment clean-up – I didn’t want to hold on to the unnecessary containers and container images

TL;DR: The solution

(see next section for the explanation)

$ export JEKYLL_VERSION=3.8
$ docker run --rm --volume="$PWD:/srv/jekyll" \
       -it jekyll/jekyll:$JEKYLL_VERSION jekyll build
$ docker run --name newblog --volume="$PWD:/srv/jekyll" -p 4000:4000 \
       -it jekyll/jekyll:$JEKYLL_VERSION jekyll serve --watch --drafts

Explanation – line by line

So, let’s take a closer look at each of the lines:

1: export JEKYLL_VERSION=3.8

Just setting up versions that will be used later – a bit of housekeeping. Nothing exciting here.

2: docker run --rm --volume="$PWD:/srv/jekyll" \
        -it jekyll/jekyll:$JEKYLL_VERSION jekyll build

Here, we build the code and output it to the same disk volume as the source code, i.e. the volume that is shared with my host machine. Now I have the built version on my machine without the hassle of setting up the local build environment. In addition to that, I will be doing some clean-up, by deleting the build container after the build job is finished.

• --rm – just execute the command and clean-up (remove the container, file system, etc.)
• --volume – mapping the current directory to /srv/jekyll in the container
• -it instructs Docker to allocate a pseudo-TTY connected to the container’s stdin; creating an interactive shell in the container
  • -i – attach container’s STDIN
  • -t – allocate a pseudo-TTY
• jekyll/jekyll:$JEKYLL_VERSION – Docker image to use and the tag
• jekyll build – command to run

3. docker run --name newblog --volume="$PWD:/srv/jekyll" -p 4000:4000 \
        -it jekyll/jekyll:$JEKYLL_VERSION jekyll serve --watch --drafts

This will create another container that will be running our application. Here we will need to add a few other parameters – like mapping the container ports to the ports on the local machine and giving the container a name.

• --name newblog – give your container a name
• --volume – mapping the current directory to /srv/jekyll in the container
• -p – bind port 4000 of the container to TCP port 4000 (-p host_machine:container)
• -it instructs Docker to allocate a pseudo-TTY connected to the container’s stdin; creating an interactive shell in the container
  • -i – attach container’s STDIN
  • -t – allocate a pseudo-TTY
• jekyll/jekyll:$JEKYLL_VERSION – Docker image to use and the tag
• jekyll serve --watch --drafts – command to run

Now you can stop the container with CTRL+c, and restart it again with:

$ docker start newblog -i

If you don’t want the container being persistent on your system, you can simply add --rm as in the previous command:

$ docker run --rm --name newblog --volume="$PWD:/srv/jekyll" -p 4000:4000 \
       -it jekyll/jekyll:$JEKYLL_VERSION jekyll serve --watch --drafts