Christopher, Stephan, On Tue, Jul 5, 2022 at 11:18 PM Christopher Schultz <ch...@christopherschultz.net> wrote: > > 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
Logging to stdout and stderr is a sure way to get oneself into a serious bottleneck. > 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) They don't go to files. They get sent to a logging router instead (e.g., Fluentd), which send them to logging aggregators (e.g., Graylog) > > -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
