Stefan,
On 7/2/22 09:45, Stefan Mayr wrote:
Hi,
Am 01.07.2022 um 17:10 schrieb Christopher Schultz:
Thomas,
On 6/30/22 13:52, Thomas Meyer wrote:
Sadly currently Tomcat startup relies on shell script to bootstrap
JVM process.
In the light of distroless images (e.g.
https://blog.chainguard.dev/introducing-apko-bringing-distroless-nirvana-to-alpine-linux/)
What are you thoughts on packaging tomcat in distroless base OCI
images that doesn't even contain any shell anymore?
Would it be possible to provide an alternative start mechanism which
directly starts JVM process which setup/prepare env like the current
catalina.sh shell script does?
What are your thoughts on above topic?
Speaking for myself, here, of course.
The Tomcat team doesn't package anything other than the "standard
distributions" such as the source and the pre-built Java binaries, plus
the Windows binaries for various things. We don't package anything
specific like Docker base containers, etc. and I don't think we want to
get into that business.
If someone in the community wants to do something like that: go for it.
But we have enough to do already and don't want to play favorites.
The only reason catalina.sh exists is to figure out what's going on with
the hosting environment. If you want to build a launch-process that is
integrated into a specific environment, then you don't need all that
tooling to figure out what is what: you can just write one big command
line and launch the JVM with all the necessary arguments.
I agree with that. In my opinion this part of environment detection is
not necessary in a container because a container is immutable. So it
should be enough to run Tomcat the way you want to have it and copy &
paste the java command line into our container image generation manifest
(e.g. Dockerfile).
To use Tomcat in a more container friendly way you should consider also
some other things too:
- because containers are static there is no need to explode WAR files or
scan the directory for changes. The extracted application can be copied
into the image and server.xml can be tuned to disable those features.
- you should avoid logging into files and tune the logging configuration
to log everything to stdout and stderr
This is something that I really don't understand about containerized
applications running like this. Maybe I'm too old-skool and think that
application logs go into application-log files and access-logs go into
access-log files.
Assuming an ideal case, where should all of these things go if your
choices are "stdout" or "stderr"?
1. HTTP Access logs
2. HTTP access logs from multiple virtual hosts (or is the idea that one
container ~= 1 virtual host)
3. Server logs (e.g. DEBUG/INFO/WARN coming from the app server)
4. Application logs (e.g. DEBUG/INFO/WARN coming from the application)
5. Application logs for applications other than the primary (e.g. Tomcat
Manager)
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
