• 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

• Getting Started
• Commands, Files, and Folders Inside a Container
• Cleanup

In this post, I decided to share some of the basic commands you might need to get started with Docker. This is neither an extensive list of the commands available, nor all of the commands you might need. This is merely me sharing a prettified list of my cheat sheet for Docker basics with you.

Getting Started

Before we get started, it might be a good idea to note that all of the commands below are written without sudo. If your installation is not running without sudo (assuming that you are running Linux), you might want to check out the post-installation guide for Linux in the Docker docs.

1. Check if Everything Works

First things first, you can use this simple command to check that your installation is fine. Note: Make sure you have right CPU architecture for your images. Raspberry Pi (ARM) things will not run on x86 architecture, and vice versa.

For x86:

$ docker run docker/whalesay cowsay Hello World!

For Raspberry Pi / AMD:

$ docker run -d -p 80:80 hypriot/rpi-busybox-httpd

2. List Containers

After creating containers, first thing you might want to do is to see what containers you have up and running. To list all running containers you can use:

$ docker ps

This command will give you a list similar to this:

CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS                    PORTS                NAMES
e85753d57a67        easypi/dokuwiki-arm         "/bin/sh -c 'php-f..."   1 days ago          Up 23 hours               0.0.0.0:80->80/tcp   mywiki

However, it will not show you any stopped containers. To list all local containers use the -a option:

$ docker ps -a

The output will be more like this (note that is shows also stopped, or even failed containers):

CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS                    PORTS                NAMES
573193cf1d5e        hypriot/rpi-busybox-httpd   "/bin/busybox http..."   2 days ago          Exited (0) 5 hours ago                         mytest
e85753d57a67        easypi/dokuwiki-arm         "/bin/sh -c 'php-f..."   1 days ago          Up 23 hours               0.0.0.0:80->80/tcp   mywiki

More on docker ps in the Docker docs.

3. List Images

To list all the images available on your system, simply do this:

$ docker images

4. Containers vs. Images?

What is the difference between containers and images, you might wonder? Well, I have a link for you. This will hopefully help you to understand how Docker manages the data within your images and containers.

5. Starting and Stopping Containers

Another two basic commands – starting and stopping containers:

$ docker start <container_id>
$ docker stop <container_id>

Note: The docker run command first creates a writeable container layer over the specified image, and then starts it using the specified command. That is, docker run is equivalent to the API’s /containers/create, and then /containers/<id>/start.

Commands, Files, and Folders Inside a Container

6. Run Any Command from a Container

You can run any command in a running container just knowing its ID (or name):

$ docker exec -it <container_id_or_name> echo "Hello from container!"

7. Getting Into Containers

Since you can run any command, then you can (obviously) also run a shell from a container; if you have any. This will be a bit similar to running an ssh command to connect remotely to a regular Linux box (given you have bash or sh in the container):

$ docker exec -it <container_id_or_name> bash
$ # or:
$ docker exec -it <container_id_or_name> sh

8. Copy Files From and To Containers

Another useful trick you might need is to copy some files to and from a container. Your friend here is the docker cp command (link to the docs):

$ # To container:
$ docker cp foo.txt <container_name>:/foo.txt
$ # From container:
$ docker cp <container_name>:/foo.txt foo.txt

Cleanup

After playing round with all the images and containers, you might realize that you have quite a collection of these on your drive, just taking up space.

9. Remove Containers

To remove the unused or unwanted containers, you can run the docker rm command with the IDs of those images. The IDs can be retrieved with the docker ps -a command, mentioned above.

$ docker rm <container_id>

10. Remove Images

The docker rmi command followed by the IDs of images will help you to remove the unused or unwanted images. The abovementioned docker images command will help you finding the correct IDs for the images in question.

$ docker rmi <container_id>

Have fun!

• Introduction
• Create the Service File
• Activate the Service

Introduction

After your Docker containers are set up and running, you might need to be able to start some of them automatically on a reboot or a crash. There are several ways of getting this done.

One of them is to use restart policies provided by Docker. They can be set to control whether your containers start automatically when they exit, or when Docker restarts.

Alternatively, you can use a process manager such as upstart, systemd, or supervisor instead. In this post, I want to show you how it is done with systemd.

Create the Service File

To create a service file that will be used by systemd (systemctl command), we will first need to get your container name. This can be done by running the following command in your shell:

$ docker ps -a

The output will look something like this. Select the right container from the list, and note its name in the last column. In this example, we will be using mywiki container.

CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS                    PORTS                NAMES
573193cf1d5e        hypriot/rpi-busybox-httpd   "/bin/busybox http..."   2 days ago          Exited (0) 5 hours ago                         mytest
e85753d57a67        easypi/dokuwiki-arm         "/bin/sh -c 'php-f..."   1 days ago          Up 23 hours               0.0.0.0:80->80/tcp   mywiki

Now, we will need to create a file (choose an appropriate file name for the service):

$ sudo nano /etc/systemd/system/docker-dokuwiki.service

Paste the following into the file. Set a proper Description, and make sure to update the container name in ExecStart and ExecStop:

[Unit]
Description=DokuWiki Container
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker start -a mywiki
ExecStop=/usr/bin/docker stop -t 2 mywiki

[Install]
WantedBy=local.target

A couple of notes about the script above:

1. This file is called a unit file for systemd.
2. Make sure you don’t have any extra line brakes within the sections, like Unit, or Service.
3. The -a option in the Docker command for ExecStart makes sure it is running in attached mode, i.e., attaching STDOUT/STDERR and forwarding signals.
4. The -t option in the Docker command for ExecStop specifies seconds to wait for it to stop before killing the container.

Activate the Service

Before we can activate the service we have created, we need to reload the unit file. You will also need to run this command anytime you do any modifications to the unit files:

$ sudo systemctl daemon-reload

To activate the service run the following commands (remember to change the service name):

$ sudo systemctl start docker-dokuwiki.service
$ sudo systemctl enable docker-dokuwiki.service

To disable the service run the following commands (remember to change the service name):

$ sudo systemctl stop docker-dokuwiki.service
$ sudo systemctl disable docker-dokuwiki.service

Changes will come to effect on a reboot:

$ sudo reboot

Now you should have a container that will start on a server reboot, Docker restart, or a crash. Congratulations!

As a next step, you might want to look at (external documentation links):

• Adding some more parameters to the unit file.
• Available docker start options.
• Available docker start options.