Chris, On 5/19/2017 7:33 AM, Christopher Schultz wrote: > Israel, > > On 5/18/17 10:52 AM, Israel Timoteo wrote: >> Any comments from the community for ... > >> 1) What tools is the community using for simultaneous applications >> deployment on several servers, let’s say more than 20? > > I am using neither of these strategies, but... > > a. FarmWebDeployer [1]
Doesn't this require a cluster (and therefore multicast)? That becomes challenging in a cloud environment where there's no multicast easily available. > b. Auto-deploy + scp This would be nice with a little scripting. > > Why in the world are you deploying a web application to 20+ > macos-based servers? Or do you have a Macos client and 20+ > non-macos-based servers? > >> 4) Is JAVA_OPTS required? > > JAVA_OPTS is only required if you require any java opts. Do you > require such options? Usually, when people set JAVA_OPTS they really > want to set CATALINA_OPTS instead. > > Hope that helps, > -chris > > [1] http://tomcat.apache.org/tomcat-8.0-doc/config/cluster-deployer.html What I do is use Jenkins, Maven, Nexus, and a little Groovy scripting. 1. Maven with the Tomcat Maven Plugin [1] The WAR file is customized (context.xml) based on the target environment. 2. Jenkins The build is run by Jenkins, and the build number (with a little 0 padding via a Groovy script) is tacked onto the WAR name as app##0000nn.war. This allows the parallel deploy feature to be used [2]. 3. Nexus This is where all of the base artifacts are stored. Nexus 2 is used currently since Nexus 3 doesn't have the REST API needed to cleanly interact with the Jenkins job via a Groovy script. Maybe I should learn how to write a Nexus plugin to get lists of artifact versions via REST . . . 4. Groovy scripting Groovy is used in Jenkins to do the following: a. Query Nexus to get a list of artifact versions b. Prevent non-production artifacts from landing on production platforms c. Create the final number for parallel deployment To expand this to multiple machines, a set of pipeline jobs could be created. a. Build the customized WAR for the target environment b. Multiple jobs deploy to the servers in the target environment c. Multiple jobs validate the deployment d. Final job sends mail to interested parties with success / failure I know that's a lot of infrastructure. There are certainly things that could be done differently. Ant (with Ivy), or gradle could be used for the builds. A different repository manager could be used (other than Nexus). A different CI / CD system could be used (other than Jenkins). Anything that meets at least the following requirements could be strung together. a. Reliable place to get the WAR file you need to deploy b. Reliable build system that can be automated c. Build system that can deploy to Tomcat d. Testing that the deployment actually worked e. Notification The end result is that some authorized person can log into Jenkins, select a version of an application to deploy, deploy it to the target environment, know that it's been successful (or not), and have notifications automatically sent out. [1] http://tomcat.apache.org/maven-plugin.html [2] https://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Parallel_deployment . . . just my (rather lengthy) 2 cents /mde/
signature.asc
Description: OpenPGP digital signature
