There’s a strong tendency to want to run everything in Docker these days,
especially if you’re trying to run something as an always-on service, since
passing --restart=always
to your run
invocation or Docker Compose
configuration ensures that running containers start back up after reboots or
failures, and seems to involve a little less “black magic” than actually
configuring software to run as services directly on a host.
The downside to this is the approach is that running a service in a container leads to significantly longer startup times, more memory and CPU overhead, lost logs, and in my opinion offer a false sense of security and isolation since most images are still configured to run as root, and more often than not large swathes of the host filesystem are mounted as volumes to achieve simple tasks.
There’s also a belief that your software will magically run anywhere - but if you’re writing Java (or any JVM language) code - that’s one of Java’s biggest selling points - it already has its own VM your code is running in, no most platforms!
Therefore, let’s see how easy it actually is to configure our software to run
as a standard system service, providing us with the ability to run it as a
separate restricted user, complete with standard logging configuration, and
give us control over via standard service myservice start|status|restart|stop
commands.