Docker Tip #95: Check If Your App Is Running in Docker or Kubernetes
This could be handy as you transition into using containers or want to configure something slightly different in Kubernetes.
Prefer video? Here’s a recorded version of this tip on YouTube which covers this topic.
In rare cases you might control an application being run but maybe you’re using a tech stack that doesn’t make it easy to have different config files for different run-time environments, but you can run custom code when your app starts where you can perform custom logic to detect if your app is running in a container and then do something different.
Likewise for detecting Docker vs Kubernetes (as opposed to Docker vs non-Docker) we can have custom logic in a Docker entrypoint script which we’ll cover shortly.
Docker vs non-Docker
Docker will place a /.dockerenv file in the root of the file system. Although back in 2016 Docker mentioned it’s not recommended to depend on this. If you’re checking to see if your app is running in a container but not with Docker such as Podman you’ll also need to do something different because that file won’t exist.
In my opinion the easiest and most dependable way is to use environment variables. You can set DOCKER_RUNTIME=1 only when your container starts and now your app can check to see if that environment variable is set when it boots up. You can name it anything you want. When your app doesn’t run in Docker it’s expected you wouldn’t see this env var.
You could have an if condition that checks for this env var in whatever programming language you’re using. Where it goes will depend on which web framework you’re using. It would be in a spot that gets executed only early on before your app fully boots.
Kubernetes vs Docker
Let’s say you have your app running with Docker Compose on a server but you also have the same app running in Kubernetes. Maybe you’re in the process of switching over and your app’s web server needs slightly different local IP ranges configured or there’s something else that’s a bit different.
Ideally there would be no differences at the app or web server level but sometimes in the real world you just need a solution to your problem, not someone saying you should refactor your application or change your tech stack.
Kubernetes will set the KUBERNETES_SERVICE_HOST environment variable by default so we can use that to detect the presence of Kubernetes at run-time. You could choose to make your own env variable too, but I’ve used the built-in one from Kubernetes for quite some time now for a specific client’s project and it works.
An entrypoint script gets run every time you start your container. If you’re setting a specific config value before your web server starts you can have custom logic like:
if [ -n "${KUBERNETES_SERVICE_HOST}" ]; then
# TODO: Add your custom logic here or use sed to replace something in a file.
echo "This is running in Kubernetes!"
fi
Using -n will check if the env var is defined and set. You can use -z to do the opposite to check if it’s empty. You can also add an else to handle both cases.
That might be enough because now you can perform all of your custom logic here. If not you can check for the presence of this environment variable being set when your app boots up and avoid the entrypoint script all together since Kubernetes will define the environment variable and it will be available in your container and accessible by your application.