Re: Tomcat in distroless image
Hi Chris, Am 07.07.2022 um 00:59 schrieb Christopher Schultz: Stefan, On 7/6/22 18:50, Stefan Mayr wrote: Am 05.07.2022 um 23:36 schrieb Pawel Veselov: 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. Maybe, but this is the convention most have agreed on for stateless (container) applications. It is factor #11 of the 12 factor app principles (https://12factor.net/logs). As always, your choices depend on the infrastructure you have. Runnning on a single docker host with an image customized for your needs? Then you can always mount the local filesystem into your container to write your logs on. Is this an image you deliver to your customers or that will run in kubernetes? So don't log into files and stick to the defaults: log 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) 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) And because it is very hard to parse those logs in a sensible way it is becoming increasingly popular for container apps to use a json based log format. This is "ugly" but still somewhat readable for human users and almost all central logging solutions have a built-in json parser. No regex-vodoo to parse multiline output required (e.g. Stacktraces). Switching from raw text to a structed log format also improves the posibilities for your search queries a lot. Addressing questions 2 and 5: it is best practice to have only one application in your container and remove everything also. So having multiple applications would usually result in multiple different containers. They might share the same (Java+Tomcat) baseimage but include different apps. A container image is an immutable artefact. As such they should have a bit of "hardening" and I would not expect something like the manager app in a container. Changes should result in new images. We use JMX extensively for our applications,
Re: Tomcat in distroless image
Stefan, On 7/6/22 18:50, Stefan Mayr wrote: Am 05.07.2022 um 23:36 schrieb Pawel Veselov: 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. Maybe, but this is the convention most have agreed on for stateless (container) applications. It is factor #11 of the 12 factor app principles (https://12factor.net/logs). As always, your choices depend on the infrastructure you have. Runnning on a single docker host with an image customized for your needs? Then you can always mount the local filesystem into your container to write your logs on. Is this an image you deliver to your customers or that will run in kubernetes? So don't log into files and stick to the defaults: log 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) 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) And because it is very hard to parse those logs in a sensible way it is becoming increasingly popular for container apps to use a json based log format. This is "ugly" but still somewhat readable for human users and almost all central logging solutions have a built-in json parser. No regex-vodoo to parse multiline output required (e.g. Stacktraces). Switching from raw text to a structed log format also improves the posibilities for your search queries a lot. Addressing questions 2 and 5: it is best practice to have only one application in your container and remove everything also. So having multiple applications would usually result in multiple different containers. They might share the same (Java+Tomcat) baseimage but include different apps. A container image is an immutable artefact. As such they should have a bit of "hardening" and I would not expect something like the manager app in a container. Changes should result in new images. We use JMX extensively for our applications, including for monitoring and management. We use the Tomcat Manager
Re: Tomcat in distroless image
Am 05.07.2022 um 23:36 schrieb Pawel Veselov: 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. Maybe, but this is the convention most have agreed on for stateless (container) applications. It is factor #11 of the 12 factor app principles (https://12factor.net/logs). As always, your choices depend on the infrastructure you have. Runnning on a single docker host with an image customized for your needs? Then you can always mount the local filesystem into your container to write your logs on. Is this an image you deliver to your customers or that will run in kubernetes? So don't log into files and stick to the defaults: log 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) 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) And because it is very hard to parse those logs in a sensible way it is becoming increasingly popular for container apps to use a json based log format. This is "ugly" but still somewhat readable for human users and almost all central logging solutions have a built-in json parser. No regex-vodoo to parse multiline output required (e.g. Stacktraces). Switching from raw text to a structed log format also improves the posibilities for your search queries a lot. Addressing questions 2 and 5: it is best practice to have only one application in your container and remove everything also. So having multiple applications would usually result in multiple different containers. They might share the same (Java+Tomcat) baseimage but include different apps. A container image is an immutable artefact. As such they should have a bit of "hardening" and I would not expect something like the manager app in a container. Changes should result in new images. There are many different scenarios how containers can be used. So your milage may vary. Regards, Stefan - To
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
Re: Tomcat in distroless image
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 Regards, Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat in distroless image
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. -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
On Thu, 30 Jun 2022 19:52:46 +0200 Thomas Meyer wrote: > Hi, > > 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? Distroless and all other "small" images are quite hard to debug, no ps, no curl, no other tools for debugging, therefore I'm personally against it because such tools will always be helpfully. I'm quite happy that tomcat relies on shell scripts this requires some more tools which helps to debug some issues. Jm2c. > Mfg > Thomas Regards Alex - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat in distroless image
CONFIDENTIAL & RESTRICTED Just my 2 cents... Tomcat is based on Java. AFAIK java itself needs a wide range of 'OS services'. Is there some distributionless java image around? Hiran -Original Message- From: Thomas Meyer Sent: Thursday, June 30, 2022 19:53 To: users@tomcat.apache.org Subject: Tomcat in distroless image CAUTION: External mail. Be careful with links and attachments. Hi, Sadly currently Tomcat startup relies on shell script to bootstrap JVM process. In the light of distroless images (e.g. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.chainguard.dev%2Fintroducing-apko-bringing-distroless-nirvana-to-alpine-linux%2Fdata=05%7C01%7C%7Ca362b5381ee24ff6446608da5ac15ec7%7Cb3f4f7c272ce4192aba4d6c7719b5766%7C0%7C0%7C637922083809078548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Rf8VAfyRfwsCXQaiVsdgefafatLAJYuqBE%2FR6sYoxOk%3Dreserved=0) 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? Mfg Thomas IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees . It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws . If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system. Amadeus Data Processing GmbH Geschaftsfuhrer: Sven Fuhrmeister Sitz der Gesellschaft: Erding HR Munchen 212770 Berghamer Strasse 6 85435 Erding Germany. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat in distroless image
Hi, 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? Mfg Thomas
