Docker Compose: Custom Commands to Keep your Container up

Sometimes you just want to keep up your container without running the intended process, for example to diagnose an unexpected shutdown during starting up the container’s process. To achieve that, we make use of the option in docker and docker-compose to overwrite the container’s innate command that is usually executed during your container’s runtime.

Preparing our experiment

First of all we gotta pull the docker image for our experiments. For illustration purposes we use an image that is completely unrelated to any command we’re going to use later:

docker pull maven:3.9.9-eclipse-temurin-8-alpine

That’s all. Now let’s head into our experiments.

docker container run COMMAND – parameter

When executing docker run we can not only set an image name but also add a custom command that overrides the image’s default command. Let me illustrate that by showing you the date of today as of writing this post – using maven’s docker image.

>docker run maven:3.9.9-eclipse-temurin-8-alpine date
Sat Mar 8 14:21:43 UTC 2025

where maven:3.9.9-eclipse-temurin-8-alpine is the docker image and date the custom command that replaces the default mvn execution.

docker compose directive – command:

Being a decorator on top of docker’s base CLI docker compose can do anything that plain docker run can do. Thus we can do custom command executions here as well. In fact, it’s much more fun than using the default CLI. But thats just me. Now without further ado:

And there is our today’s date.

What commands can we use in docker?

In this section I present my favorite commands to keep my docker containers open. The most intuitive is probably:

sleep infinity

That one is pretty self-explanatory. We just sleep for an infinite amount of time or until we manually cancel the process. The constant infinity is defined in the GNU world and serves us as a representation of positive infinity.

The next one is:

top

We just let your container dispay it’s realtime ressource usage thus keeping your container up and running. Time to docker exec into it and do our thing. Little caveat: Some images may strike top out to reduce the container’s size and to focus on it’s core business. If that’s the case, we should try my top-most favorite. This one should be available quite often and looks so cool:

tail -f /dev/null

That one waits on a neverending file and tries to spit out whatever it finds at the end of it – in this case dark and pure nothingness.

Final thoughts

This post was a personal matter of heart to me having had the use case several times. But since im getting old *sigh* I tended to forget what commands I can use. Now that’s finally a thing of the past. Give it a bookmark and it will keep reminding you as well. Do you have a favorite command to keep things up? Feel free to drop me a line in the comments down below. And if you still can’t get enough of Docker or Maven here are some recommendations just for you: My most recent star is this post about configuring TLS for HTTPS-secured Maven repos. And finally for the more docker-inclined people out there this post about docker ps – formatting might make your daily life a little simpler.

Have a sunny day!

Share it with:

docker ps formatting – Cheat Sheet

Checking the status of Docker containers is an important starting point, when it comes to debugging container clusters. docker ps is an ideal tool to get you started. Unfortunately, the output can sometimes be quite verbose and overwhelming.

The --format parameter is supposed to ease the pain here, but Go templates can be quite tedious to write every time, too. To counter that a little, I reveal my favorite ready-to-alias docker ps calls in today’s post. I hope they make your everyday Docker life a little easier.

# Are my expected containers up?
docker ps --format "table {{.Names}}\t{{.Status}}"

# What ports do my containers expose?
docker ps --format "table {{.Names}}\t{{.Ports}}"

# What networks are my containers assigned to?
docker ps --format "table {{.Names}}\t{{.Networks}}"

All of them can be extended with more docker ps command line parameters, even when aliased later on.

As you may have noticed, my first column is always the container name followed by the property I’d like to analyse. This is my personal way to keep the output compact and focused on the problem at hand, but of course you can query any property you like. Check out the official documentation for a comprehensive list of available properties and pick what you need for the task.

Do you have a favourite formatting? Or do you want to talk about any other question? Feel free to let me know in the comments below. I plan to publish more cheat sheet-style posts in the future. This helps me out to share recent learnings in a focused way and provides you with quick help and valuable insights. You can find another example here, where I demonstrate how to set up Linux users with low maintenance work afterwards. Or if you are into Rust like I am, the Rust modules cheatsheet might be a valuable companion, when it comes to structuring your code with Rust Modules.

Until next time!

Home » docker
Share it with:

Zalenium in a minimal Docker Compose – Setup

What is Zalenium?

Zalenium, brought to us by German online fashion retailer Zalando, is a feature-enriched Selenium test platform based on the popular Selenium Grid. Besides the core features like scaling Selenium test execution nodes, it provides nice things like video recording, a video player directly in the management UI and integrations with popular browser test tools like Sauce Labs. For a more detailed overview, please check out the project page. As far as we are concerned here, we have all the good arguments we need to fire up a small test setup. 🙂

What are we going to do?

In the following miniworkshop, we temporarily slip into the shoes of a devops engineer and set up a minimal Zalenium Grid – environment in order to execute remote Selenium tests there. The goal is that we use no more than 2 files (of resonable size):

  • the docker-compose-file to build and start the Zalenium-container provided by Zalenium
  • a sample selenium-webdriver-test to be executed inside Zalenium, kindly provided by Felipe Almeida, thank you very much.

For our experiment, I modified the latter to enable remote driver execution instead of starting a local firefox. Therefore, I prepared everything in a small bitbucket-repo.

Prereqs for the Zalenium Setup

  • a recent version of Docker (should already include docker-compose)
  • Ruby > 2.3.1 (I recommend using RVM)
  • a recent Chrome-browser
    • Unfortunately, my Firefox (v67.0.4) does not support the video format of the test execution recordings. 🙁

Steps

  1. Open a terminal and clone the repo.
  2. cd inside the new directory and fire up the containers: $ docker-compose up -d
  3. Start the test: $ ruby selenium_minimal.rb
  4. After the test execution, open a Chromeand head to the Dashboard: http://localhost:4444/dashboard/
  5. You should see one test execution in the list on the left side. Click it.
  6. Play the video and enjoy the action of your test.

Conclusion

Now that you have the power to quickly fire up Zalenium and its grid nodes, you can go further. Host it on a remote machine serving your needs as a Test Automaton Engine, move it to the cloud and go to town. This should step up your Quality Assurance Game in a scalable and easily maintainable way. Have fun!

Home » docker
Share it with:
Florianrein's Blog
Datenschutz-Übersicht

Diese Website verwendet Cookies, damit wir dir die bestmögliche Benutzererfahrung bieten können. Cookie-Informationen werden in deinem Browser gespeichert und führen Funktionen aus, wie das Wiedererkennen von dir, wenn du auf unsere Website zurückkehrst, und hilft unserem Team zu verstehen, welche Abschnitte der Website für dich am interessantesten und nützlichsten sind.