I read some comments about the build of dropwizard applications: [1] "Dropwizard is designed to run as a JAR, not as a WAR file." and [2]"You can't do this. Dropwizard embeds Jetty. You should look into just using Jersey as a standard web application.", so, my questions are:
1 - How to deploy a jar file in a production environment?
2 - How will I manage the service? for example, is there a way to monitor the healthy of the application? if the application falls down how can I restart it again automatically?
[1] How to create a war from dropwizard app?
[2] Dropwizard in tomcat container
You can use tools like runit or systemd to manage your dropwizard app on Linux. They can do things like make sure it starts when the system starts up, and can help with detecting failures. There is a bit of scripting involved.
You can point a monitoring tool at the healthcheck URL of your app to send alerts when it's down.
For deployment, I prefer to package apps using the system packaging format, .deb (Debian-based systems, including Ubuntu), or .rpm (RedHat based systems). Use the fpm package builder to create it, and include your runit files (or whatever), and scripts to copy the jar file somewhere on the target system. If you have a private package repository, you can put builds of your app into it, and installation becomes a matter of "apt-get install myapp" or "yum install myapp". Otherwise, drop the package onto your target server and run "rpm -i myapp.rpm" or similar.
After running mvn package of your source directory, the said jar file is created in the target directory by maven.
Just upload this jar file to a directory of your liking on the server, say /opt/myapplication/.
The jar file can be executed on the server with java -jar JARFILE, make sure you have java installed there. That's it, basically.
Now when you run this in production, you want to have the process supervised (and restarted if it fails) and started automatically on bootup. For this, look into your servers startup-system (systemd was mentioned before for those linux distributions that support it, but on current debian/ubuntu versions you have ATM still other boot mechanisms, you probably need to write a start script for /etc/init.d/myapplication).
Health checks are - as mentioned before - integrated in the dropwizard app, you simply request the health check url on a regular base. In professional environments, you should have a tool like nagios that you could point to the URL.
If your server is unix, you can build fpm packages to install your service on server. Just build fpm, copy to server and install it.
Or use fabric (http://www.fabfile.org/).
Related
I'm new to deployment, I've jar file as a package how should I go ahead for deployment in my prod server?
My prod server is basically an EC2 machine running on AWS
Shall I just run java - jar "jar file"? is this the practiced way for prod servers?
Shall I package .jar file to ear/war and deploy in tomcat/jboss server?
Help appreciated!
Both of the approaches you described are valid.
For small web APIs that include their own application server (e.g. Spark, Javalin, Spring Boot) on Linux servers, I start a screen session and run java -jar. This allows me to exit the SSH session (disconnect from the server) without terminating the program.
For other Spring applications that don't include an application server, I package the code into a WAR and copy it to an application server's deployment directory. For Tomcat, that's webapps. The application server can then read the WAR and spin up a running instance (assuming hot-deploy is enabled).
Tomcat in particular also has a web page where you can upload your WAR file to deploy it.
If you would that the program is still held run after disconnecting from SSH or closing the terminal in Linux. You can use this command:
nohup java -jar file.jar &
This is basically up to your preference and usual standard at your place. We have services in Docker that basically have exec java -jar param param... at the end of entry-point.sh script. You can run whole Tomcat, etc.
If you're using Spring Boot (which is a good idea), then java -jar is perfectly fine - you can use embedded Tomcat and skip installing dedicated application server (or, to be precise, servlet container).
Second approach is preferred over first in Jboss servers as things can be easily done through console.
You can control the deployment of the application on the servers.
If say you don't want to deploy the jar on all the servers part of cluster ,that can be taken care.
I'm working on a brand new volume plugin and I'm required all of vol-test tests to be passed. And I have all tests successfully passed (on an environment with installed plugin) except the first one, which is docker plugin install. The thing is that there are three possible ways one can install a custom plugin:
.sock files are UNIX domain sockets.
.spec files are text files containing a URL, such as unix:///other.sock or tcp://localhost:8080.
.json files are text files containing a full json specification for
the plugin.
and we use json, which is simply a REST server implementing docker API (written in java, spring). The installation process for it straight forward: just copy the json file in /etc/docker/plugins and dockerd automatically discovers it.
The problem comes when I try to integrate the plugin into docker plugin install command. As it stated here:
Docker looks first for the plugin on your Docker host. If the plugin does not exist locally, then the plugin is pulled from the registry.
Our installation process doesn't assume a connection to a private or public registry, so we need first docker plugin create command in order to create the plugin locally. And this is where I'm having hard time to wrap my head around how to do that with json-based plugin. As per this doc, I need to specify a path to the plugin. If I use a directory name it expects config.json and rootfs to be present in the directory.
BUT
1. config.json - this is a config, that describes .sock format configs, and not the .json format (please correct me if I'm wrong)
2. how do I create the rootfs and why do I need it if my plugin is just a standalone REST service and it is not even in the container?
Appreciate any help.
config.json - this is a config, that describes .sock format configs, and not the .json format (please correct me if I'm wrong)
I've verified it working with .spec files, not very sure how it works with json files though. For .spec files, you don't mention .spec files in config.json. That is used only for unix socket plugins (option 1). Infact there is no need to have config.json for TCP socket plugins.
how do I create the rootfs and why do I need it if my plugin is just a standalone REST service and it is not even in the container?
In my understanding, rootfs is only for unix socket plugins. Plugin discovery works out of the box if .spec files exists in the right folder. In nutshell, you just create spec file and put it in the right discovery folder and try to bootstrap the container with that plugin name. You don't have to run commands like "docker plugin create/install/enable". You run the server, put the file in right folder and let new containers use that plugin.
I have a Java desktop application and now we distribute it as a jar in a installer of a main application (currently the Java application is only an importer/exporter). But as the jar is updated more often than the main application we are thinking of making it run through Java Web Start so it's updated independently when it start.
My question is how can I distribute it in the installer so if the user don't have internet it use the jar bundle in the installer (and copied in the main application folder) but when he launch and have internet, Java Web Start update it?
Edit: I have think in making two JNLP files one for local launch and one for online launch so it get updated, but then they need to share the cached jar so isn't installed two times, and I don't know if this is possible.
Edit, more explanations:
Maybe I haven't explain it very well. I have a native application and is distributed as an MSI, from download and through CD. With this application we distribute the Java application (a jar) that the main application used to exchange data to other formats. The MSI installs both the native app and copy the jar (not really install). Now if the user have internet and a new update is published, the complete MSI is downloaded and installed (updating the installation). Ok?
Well, we like to update only the jar in a more fashion approach, with Java Web Start, so it's updated when the jar is run independently of the main app. This have the problem that if we only deploy it as Java Web Start, if the user install the app in a computer without internet (for example carrying the MSI in a pen-drive or cd) he will not be able to use it, because as he don't have internet he can't download the jar.
And now is when my question come, can I deploy the jar in the MSI but execute through a Java Web Start so if the user have internet it get updated but if he doesn't have internet it still can use the bundle jar in the MSI?
..can I deploy the jar in the MSI but execute through a Java Web Start so if the user have internet it get updated but if he doesn't have internet it still can use the bundle jar in the MSI?
OK, I am formulating a plan here, this might be doable.
Let us presume that the MSI is capable of doing the following things.
Install a JRE if missing or too low a version available. The JRE needs to be included in the MSI (to avoid requiring the net).
Unpack the JWS launch file and Jar(s) (and native..) to the local file system as temporary files.
Invoke the javaws tool using 'IMPORT-OPTIONS' to set the code-base to the place in the local file-system they were unpacked.
At this point, desktop icons and shortcuts should be installed, and the program ready to launch. It is vital to specify a few extra options in the JNLP - specifically offline-allowed to ensure the app. can still be launched if the internet is not available.
Caveats: I don't have any experience with MSI, and my experience with using the import options is limited to calling them from build files (during development).
Are there any free tools using which I can package my war (java web app) and tomcat as exe
We distribute our web application Kunagi as a .war, a debian package and also as a windows .exe. The windows versiont works as follows:
The .exe is created by a tool which exists on all windows machines, called iexpress. It is just an archive which is executable. On execution it extracts itself into a temporary directory and then executes a predefined command in this direcotry.
So wie pack a minimal embedded Tomcat (just 5 jars) into it, together with Katokorbo.
Katokorbo is a simple Swing application which downloads a war from the web and starts it with the embedded Tomcat. It also checks for new versions of the webapp on startup, asks the user if he wants to upgrade, starts a browser with the webapp and provides a gui to the user to view log output and for stopping the whole thing.
Maven can do that (http://maven.apache.org/) and I think Ant can too.
I have CruiseControl.net setup on a machine which is currenly being used for Microsoft Projects.
I needed to add a java project to the same build server.
The java war files generated need to be copied to another server under Tomcat.
However, I face a lot of problems when it tries to copy to that network location, due to file access denied messages, as certain jar files are being used.
I tried to remotely stop tomcat before attempting to copy the files but wasnt successful doing that.
There are Ant tasks that allow you to admin Tomcat using build.xml. Maybe those can help.