I want to deploy a WAR to multiples tomcat servers (they may change) and do this from a java project.
I've searched and i find cargo, but in cargo i need to know all the servers were i want to deploy my WAR and create a config file with them. The thing is that those servers will change for sure in my enviroment (i may add some, remove some or modify some).
Is there any way i can do what i want?
i'll repeat what i want: From an java app deploy a WAR to a list of tomcat servers (running servers)
PS: sry for my english
EDIT:
this is an example of what i want to do:
Every tomcat its independent from the rest, its like ATM's and i want to "update" their "software" every time in a while, an ATM may be removed or added. so the number of ATM's to update may change
Why don't you publish your WAR file into a Maven repository and then use that as a platform for deployment? See the diagram in the following answer:
Should Artifactory NOT be used to capture the build artifacts that Jenkins produces?
This approach would neatly decouple the process that builds your software from the process(es) that deploy your software. Specifically you won't have to track your deployments in Maven anymore.
You can try with maven-deploy-plugin: http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ftp.html
You can configure where to put WAR file, there are possibilities to deploy using ssh or ftp protocol.
If you're running your Tomcats in a cluster, use the FarmWarDeployer.
Related
Recently, I have had to port an app from Tomcat to Wildfly and I'm currently working on setting up the modules directory for Wildfly.
It took a little bit of learning, but I figured out how to set up Spring, ActiveMQ RA, and several other libs as modules. This is working, but it has me worried about future maintenance of the modules directory. I have had to craft the entire directory by hand and I am worried about having to do this for every new dependency that every new app needs.
What are the best practices for maintaining JBoss Modules? Is the modules directory put into some version control system like SVN to detect and propagate changes?
Lets say I need a new framework in my app. From my understanding I would need to download the jars, create a modules directory for the jars, and then repeat this process for each environment in which I need Wildfly. What happens when needing to do this while other apps are running? This seems extremely time consuming in the long run.
I feel like there is a much better way to do this that I am either not realizing or too green with JBoss to understand.
With Maven and a pom, its so simple to hook up to a local or remote repo, and have the entire directory built out and available everywhere automatically. I feel like there must be something similar for JBoss Modules.
At the heart of my question: How are others using JBoss Modules and maintaining it within a production environment? What resources should I read or utilize?
Thanks for your time.
Kevin
I'm also looking for a solution for this.
I have previously been in projects where the JBoss CLI is being used. But I dont like that. It adds complexity as the JBoss CLI scripts are something new that developers need to understand. Changes in files are easier to understand.
I'm thinking of this:
Put a directory in a git-repo that has the exact directory structure as JBoss version used.
standalone-full.xml is put in git-repo/jboss-eap-6.4/standalone/configuration/standalone-full.xml
module.xml-files is put in git-repo/jboss-eap-6.4/modules/system/layers/.../module.xml
Also a setup.sh that will:
Copy the files from the git-repo to the installation directory of JBoss.
Download any jar-files, needed for the modules.xml, from a configured Nexus server. And put them into correct modules-directory.
The benefits are:
No binary files in git.
Changes to configuration of JBoss can be tracked.
The setup can be a part of a bigger scripted setup of for developers or docker images...
Is there a way to deploy apps without deploying it as a war file? At the moment I am repackaging and redeploying the war after every change. Is there a way to host it like IIS so changes can be done to an individual file without having to repackage and redeploy. Im using glassfish at the moment
Glassfish permits deploying applications and modules in an exploded directory format. It also supports automatic deployment and dynamic reloading.
You can hot deploy few things. By hot deploy I mean replacing the file not full app. Like hot deploying a jsp file, some static content there might be some more things. But then there are other things which may not work properly if you try to just replace a file.
Having said that it's not a recommended practice in most production environments. Most people would like to deploy a full war file.
But if you are simply looking for productivity in development environment you can use tools like JRebel. It works great. You don't have to keep deploying the war file again and again.
With Tomcat, you can configure the container to serve a webapp that is located in another directory (such as your build target directory) using a config file found under tomcat/conf/Catalina/localhost
But, you generally need to restart Tomcat if you make changes other than static content or JSP changes.
This sort of approach should be restricted to development environments only.
I agree with Laird Nelson that GlassFish can do that the reason is that Glassfish use Apache Felix which is an OSGI implementation (OSGi Framework and Service platform). Here you can find projects using felix. If you are using a simple Servlet Container like Tomcat there a lot of solutions.
I have a maven project which generate zip generated from ant scripts. Then this zip is deployed to specific application server again using ant script. this is very complex for maintenance. Now we move to use maven for building zip, so what is standard way to doing with respect to developer and client
How to handle application server specific deployment(e.g for weblogic and jboss) Do I need to create 2 zip for each server?
How to handle global configuration parameter like database, product specific settings. Where to put them, and how it use by developer and client?
The installation of application sever is need to integrate with build cycle or what is best practice for it?
I'll try to answer based on my experience:
I use maven profiles for this. Especially since there are beans (classes) that are specific to only one app server at a time. See http://maven.apache.org/guides/introduction/introduction-to-profiles.html
maven supports placeholders. One build for every single environment: dev/qa/prod,etc. All you need is the properties file. (this is similar to properties in ant)
You do not need (usually, unless you have integration tests that are tight to the app server - and if you do, it seems wrong) an app server for the build itself.
I have been working on 3 Java Spring and Hibernate projects at a time. Every time if I make any changes on any of these three project then I have to create build again and manually I upload three builds to three different servers.
Is there any mechanism to avoid this manual process? Is there a tool or script that can check if I make changes to my code in Eclipse and save the files which will then commit the code and automatically build and upload the war file to the appropriate server?
This would save me a lot of time.
You need continous integration. Maven is a build tool and won't deploy on change.
Whereas a CI tool such as jenkins will listen to your code reposiotry and every time a file is commited it will call then call whatver maven command you wish.
However re-reading your question, it looks like all you really need is a hot deploy development enivronment. Which is quite easy.
If the projects are on maven, there are plugins for all major application servers.
We package our application as a .war file, we advertise support for JBoss AS5 and instruct our clients to copy the .war into their JBoss 'deploy' directory, and start up their application server in order to deploy the .war.
We are introducing support for JBoss AS7, so our deployment instructions for AS7 will have to change to something like
-copy the application.war to $JBOSS_HOME/standalone/deployments
-touch $JBOSS_HOME/standalone/deployments/application.war.dodeploy
-start JBoss AS7
This deployent method seems awkward to me, and possibly fragile, as failure to successfully create the *.dodeploy file would cause the deploy to fail. Also JBoss startup problems may cause the deploy to fail, causing the *.dodeploy file to be renamed *.failed - so it would have to be renamed back to *.dodeploy before attempting to redeploy. We are thinking the process seems a little awkward for some of our clients, who may not be familiar with JBoss AS7.
Is there any way to automate this deployment process so that it is smoother for deployers who may not be comfortable with how things work with JBoss AS7? How are other people handling this type of situation? thanks for any suggestions.
There is a web interface that's fairly easy to use. You can access it after JBoss AS7 has been started by going to http://localhost:8080. There is a link on that page that takes you to the administration console.
You could also write scripts for deployments using the CLI interface. There is some information here https://docs.jboss.org/author/display/AS7/Management+Clients about how to use it.
Lastly you can always write your own Java client to deploy applications. I wrote a blog post a while back on how to write a custom deployment CLI interface.
If you're aware of the marker files then you might have made a conscious choice to disable the automatic deployment mode for the deployment folder, which ships enabled by default. Autodeploy is great for everything but exploded files, and removes the need to manually manage the marker files. With autodeploy enabled, you can use the "touch" command on the application itself, which will update the timstamp and trigger the application for deployment (or redeployment). So you can still script if need be, but focus on the file rather than the marker files.
Just for reference, there are five ways to deploy files, of which three will be common to the typical administration setup. These are the graphical Management Console, the Management Command Line Interface (CLI) and the deployment folder you mention. The other two are via an IDE (such as JBoss Developer Studio or Eclipse with JBoss Tools), and even via Maven.
For people that may not be comfortable with the scripting as you say, then you can't go past the Manage Deployments section in the Console GUI. The Console deployment does not move/copy the application to the deployment folder, so using both the Console and the Deployment folder can make for some effort in file management.
For bash-savvy users, the CLI is great, and is often recommended by the AS7 team as a preferred method of deploying and managing applications. The user guide section on the CLI is located here: https://docs.jboss.org/author/display/AS7/Admin+Guide#AdminGuide-RunningtheCLI.
An example of all deployment methods can be found on this YouTube video by one of the developers: "5 ways to deploy your application to JBoss AS 7". Hope that helps.
You only need .dodeploy for exploded deployments. If your deployment is a zipped war,ear,etc. then it will be picked up automatically.
Change your deployment mode from manual to auto which does this deployment automatically.
Steps :
1) Open your jboss configuration file : standalone.xml.
2) Look for deployment-scanner and add auto-deploy-zipped="true"
<deployment-scanner scan-interval="5000" relative-to="jboss.server.base.dir"
path="deployments" auto-deploy-zipped="true" auto-deploy-exploded="false"/>
3) Restart your Jboss.
Now it will automatically pick your zipped version of ear/war/jar/sar files for deployment.
You can still use your old scripts without using any markers.
This can be changed in the standalone.xml by changing the "auto-deploy" attributes on the deployment-scanner element in the standalone.xml configuration file.
More details can be found in the deployments folder README.