Modernize application deployment

[NiccoMlt]

How does it work now

The application was designed in the "zip distro era" of Java deployments, when the primary deliverable was a ZIP archive that contained the whole self-contained application directory. This is, in fact, the existing layout of a Carapace ZIP for deployment:

• bin/ directory containing:
  • the systemd service
  • utility scripts like java-utils.sh and setenv.sh
• lib/ directory containing all the dependencies JARs
• conf/ directory containing the properties files like:
  • cluster.properties for services like ZooKeeper, BookKeeper and HerdDB
  • logging.properties for java.util.logging, later replaced by Logback configuration in the top-level directory
  • server.properties for Carapace own configuration
  • user.properties for Carapace user realm configuration
  • zoo.cfg for the ZooKeeper configuration
• logback.xml in recent versions of Carapace
• web/ directory containing:
  • META-INF/MANIFEST.MF file
  • META-INF/maven/org.carapaceproxy/carapace-ui/pom.properties with information on the artifact itself
  • ui/ with the whole Vue.js subproject

This structure is described in the Apache Maven Assembly Plugin configuration file zip-assembly.xml. It is usually installed under /opt/<app> or /data/<app>.

When running, additional files like server.java.pid and the logs are created somewhere inside that directory.

Clustering

In this codebase ZooKeeper is used as the cluster coordination layer. In contrast with HerdDB, which is embedded into the Carapace process, ZooKeeper is an external dependency and should be installed separately in a clustered deployment.

Preferable approach

This deployment is very non-ergonomic, especially for lightweight deployments like on the developer machine.
It would be cool to have, on release:

• a containerized installation (i.e. Docker, OCI);
• a self-contained JAR (i.e. a shadow JAR);
• the "legacy" ZIP installation;
• (bonus) a standard packaged installation like RPM and DEB (i.e. with jpackage).

On development environments, the developer should be able to just use the "run" button of the IDE to execute the application in place, without polluting the system or the Git-tracked root directory with runtime files.

Additional files should be generated by Maven during build when possible.

Clustering

Clustering should be easily deployable without complex manual installations, and/or very well documented in the README or the wiki. This is another issue, though.

Self-contained runtime

It could be interesting to use tools link jlink/jpackage to ship a JRE along with the package. This is another issue, though.