André: See comments inline.
On 7/16/2019 4:37 PM, André Warnier (tomcat) wrote: > On 16.07.2019 19:54, Martynas Jusevičius wrote: >> Grigor, >> >> I think this is a use case that Docker containers at least partially >> address. >> >> I find deploying containers way easier to share/deploy and more >> platform-independent than WAR files. >> >> I’ve created a Tomcat-based image that accepts ENV variables and modifies >> server.xml using their values: >> https://github.com/AtomGraph/letsencrypt-tomcat >> >> I think you should be able to do the same with web.xml. > > I have not seen your solution. But a question comes to mind : does this > not just move the problem, from tomcat to the Docker container then ? > > Why not provide a (shell ? perl ?) installer/updater script, along with > the application WAR, which modifies the application's web.xml (or the > server's web.xml) in function of some site-specific parameter file, > which is located somewhere outside the tomcat directories and remains > there ? What I've done depends on how complex the target environment is. For simple environments, I do the following: 1. Create a maven deploy job for Jenkins 2. The maven job: a. has the base WAR as a dependency b. stuff that needs replacing is in the maven job 3. Jenkins supplies environment variables used for replacing a. environment variables are set based on target characteristics b. all values are recorded in the Jenkins job log Like I said, this works for simple changes, and obviously not for Tomcat-related changes. I currently don't keep a copy of the WAR file, which may lead to some challenges when trying to reproduce a deployment. However, I've not run into any issues yet. For more complex environments (where I have to change Tomcat), then I think a Docker solution is reasonable. I'm currently looking at this with using Redis as a session manager, and log4j2 for logging. I can take a standard Tomcat Docker image, and use a Docker file to make all the alterations. If I drive this from Maven, I can manage the WAR and other dependencies as well. Finally, I can take the resulting Docker image (altered Tomcat, environment-specific WAR file), and push it to a private repository with some suitable label. Now I have a good / reproducible way to regenerate my environment - for example, disaster recovery. Run this entire mess from Jenkins (or your CI/CD tool of choice), and you get a simple way to deploy applications. It all depends on the requirements, I guess. . . . just my two cents. /mde/ >> >> Martynas >> >> On Fri, 12 Jul 2019 at 21.44, Grigor Aleksanyan >> <grigor.aleksan...@onetick.com.invalid> wrote: >> >>> Hi Everyone, >>> >>> We have been shipping web application with war packaging in our >>> production >>> builds which contains a web.xml with few security sections. >>> This web.xml defines security constraints that are in most cases not >>> what >>> the final deployment uses. This means that to update the war we need to >>> save new web.xml somewhere, copy the new war, run the server so that it >>> extracts the war, then shut down the server and copy web.xml back. >>> This is >>> a headache for our cloud based web services upgrade as well as in all >>> other >>> deployment scenarios, including tests. >>> >>> To facilitate deployment we've added a new packaging of another war >>> file, >>> which is the same as our original war but its web.xml doesn't contain >>> any >>> security sections. >>> With an empty web.xml (in terms of security), the security can be >>> defined >>> via server's conf/web.xml, where it belongs, since the security is in >>> reality defined by the server rather than the war application. >>> It would be great if we could just replace our default web.xml but if >>> some >>> user uses our default web.xml, they would become unsecured after an >>> upgrade, so we opted for a separate war. >>> >>> Do you guys see any other way of achieving what we aim to achieve >>> with the >>> new war file with default web.xml (backwards compatibility is a >>> constraint >>> in our case)? >>> Maybe there is a way of ignoring security sections in the war or we can >>> make it configurable in the code based on some config/env variable? >>> >>> Please let me know if you have any considerations about this, any help >>> would be appreciated. >>> >>> Thank you, >>> -Grigor >>> >>> -- >>> >>> >>> * >>> * >>> *CONFIDENTIALITY NOTE:* THIS E-MAIL MESSAGE AND ANY ATTACHMENTS MAY >>> CONTAIN CONFIDENTIAL AND PRIVILEGED INFORMATION OF ONEMARKETDATA, >>> LLC. IT >>> IS FOR THE SOLE USE OF THE INTENDED RECIPIENT(S) AND ANY UNAUTHORIZED >>> REVIEW, USE, COPYING OR DISCLOSURE IS PROHIBITED. IF YOU ARE NOT THE >>> INTENDED RECIPIENT, PLEASE CONTACT THE SENDER IMMEDIATELY BY REPLY >>> E-MAIL >>> OR BY TELEPHONE AT +1 201 710 5977, AND DESTROY ALL COPIES OF THIS >>> MESSAGE >>> FROM YOUR SYSTEM. >>> >>> E-SIGNATURE NOTICE: Unless specifically set forth >>> herein, the transmission of this communication is not intended to be a >>> legally binding electronic signature, and no offer, commitment or assent >>> on >>> behalf of OneMarketData, LLC is expressed or implied by the sending of >>> this >>> email, or any attachments hereto.
signature.asc
Description: OpenPGP digital signature
