Late to the party, as always.
Anyway, I'll write up in general how we manage things. It's not ideal,
but it seems to answer most everyone's questions.
See at the end of this message.
On 6/30/2023 12:13 PM, Christopher Schultz wrote:
Alan,
On 6/30/23 06:35, Alan F wrote:
This is great thankyou Thomas. Just wondering how secure this is,
prefer to be able to deploy with a non 'admin' account does this
support a deploy only profile there?
So... you are concerned about security but would like a non-admin
account to be able to deploy web applications on your server?
Hmm...
-chris
-----Original Message-----
From: Thomas Hoffmann (Speed4Trade GmbH)
<thomas.hoffm...@speed4trade.com.INVALID>
Sent: 29 June 2023 09:08
To: Tomcat Users List <users@tomcat.apache.org>
Subject: AW: Tomcat Deployment scripts
Hello Alan,
Von: Alan F <shiva...@hotmail.com>
Gesendet: Mittwoch, 28. Juni 2023 18:24
An: users@tomcat.apache.org
Betreff: Tomcat Deployment scripts
Anyone have an example deployment script or method used to deploy a
simple war and context root, also with rollback preferably.
Thanks
you could use tomcat-manager.
A war file can be deployed using curl for example:
https://stackoverflow.com/questions/4432684/tomcat-manager-remote-deploy-script
Greetings, Thomas
At $work we do the following:
1. Jenkins Maven job for Tomcat deployment
We use the Tomcat Maven plugin. Since we only use the manager-script
access, the rest of the functionality is not important.
2. We use serially named WAR files (##nnnnnn)
This allows us to do the following:
a. The mgr-script username and password are "hidden" in Jenkins'
settings.xml
b. Jenkins uses global environment variables to specify the target server
c. A nice GUI front end done with a Jenkins plugin allows a person to
select:
1. artifact (from Nexus)
2. artifact version (from Nexus)
3. target server
d. The Jenkins jobs send email upon completion
This allows us to control who deploys to which server, prevent SNAPSHOT
versions from being deployed to production (via groovy scripts), and
most importantly provide a record of what was deployed to what server
when, and by whom.
We can use this to roll back versions of the application, since the
serial number on the WAR file is based on the Jenkins' build numbers and
increases with each run. All that has to be done is to select the
appropriate artifact version from Nexus. The artifact and version lists
are built dynamically by groovy scripts when the build (deploy) job is run.
It's clunky, and I need to polish up the groovy scripts, and sometimes
you need to change database targets or content-security-policy (testing
versus production), but it seems to work.
At least the developers / admins who use it don't complain (too much),
and Jenkins is the place of record for all application deployments.
. . . just my two cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
