Re: Tomcat in distroless image
Christopher, Stephan, On Tue, Jul 5, 2022 at 11:18 PM Christopher Schultz 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
Re: Tomcat in distroless image
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
AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
Hallo Mark, > -Ursprüngliche Nachricht- > Von: Mark Thomas > Gesendet: Montag, 4. Juli 2022 19:37 > An: users@tomcat.apache.org > Betreff: Re: AW: Tomcat 10 with Http2 and compression sometimes closes > connection with Firefox > > On 30/06/2022 07:40, Mark Thomas wrote: > > > > > I think I'm going to need the sample app to investigate this. > > I have received the sample application and can recreate the issue. > > Going back to your original summary: > > > 1) Main page was requested by Firefox from Tomcat (GET ...) > 2) Tomcat sends the first compressed chunks of data to the browser > 3) Firefox reads the first packages and notices, that additional resources are > needed (CSS, JS ...) > 4) While Tomcat is still sending the main page in chunks, the browser is > already requesting additional resources on other channels > 5) Firefox is sending a RST_STREAM and closes that last requested > stream(s) (dunno why it does request first and then closes the channel) > 6) Tomcat is sending a GoAway message to the browser > 7) Tomcat stops also sending the main page (on a different channel) > > > I tested with 10.0.x. > > I don't see the above sequence. > > I ran the test 4 times, closing the browser between each test > > When things go wrong it appears that FireFox is re-using the main page > (ticket.jsp) from a cache. > > I see the additional resources being requested and then cancelled. > > I do not see any GOAWAY messages from Tomcat. > > I do see a single GOAWAY message from the browser to Tomcat when I close > the browser window (as expected). > > I don't see anything going wrong on the Tomcat side. > > At the moment, this looks to me like an issue with Firefox rather than with > Tomcat. > > If you can narrow the test case to something that shows Tomcat doing > something wrong, then I'd be happy to look at this again. > > Mark > > - Thank you very much for taking a look at it! I could also see that the browser cache is used sometimes. Sometimes the jsp is requested from the server, sometimes not. I did several tests again and the behaviour is not very consistent, thus it's hard to get a handle on the problem. I was also thinking about the possibility of a Firefox bug but this wouldn’t explain that: 1) It only happens with Tomcat 10.x and doesn’t show up with Tomcat 9.x 2) Users don’t report any problems with other internet websites (using Firefox) The GoAway seems to be sent from time to time by Tomcat, but not always. I recorded one session which matches my last description: https://privfile.com/download.php?fid=62c3ec1170199-MTM2OTM= I set up another PC for testing, thus the IP addresses (source/target) differ and can be interpreted more easily. Maybe the last Capture was not readable without the keyfile, thus I exported it differently and it should be readable now. a) Is the behaviour according to the linked network trace an expected behaviour? (sending a GoAway after a rst_stream message) b) Have you been able to reproduce the error with Tomcat 9.x? If you have any hints or suggestions, how I could narrow it down, please drop a line. I don’t have any big or great ideas at the moment. Thank you very much! Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
