Platform-specific distributions: approaches

[brmeyer]

Recently, multiple individuals have commented on the large size of the Overlord project distribution sizes.  Up until now, the approach has been to utilize one single distribution, deployable to any supported platform.  Exploring ways to break it up into platform-specific distros could be valuable, especially as we start supporting concepts like Docker, as well as continue to add support for new platforms.  Ideas:

Overlay ZIP + Post-Installation Script

• Build one overlay ZIP per platform
• Require the use of a post-installation script for configuration, user setup, etc.
• Ant scripts stripped down to post-installation steps only
• PROs:
  • Most likely offers the smallest distro sizes and the tightest control
• CONs:
  • Substantial re-work

IzPack

• One IzPack per platform
• PROs
  • Simplest solution for end users
• CONs
  • Community only, as this implies shipping a pre-defined username, password, keystore, etc.
  • Substantial re-work
  • Ramp-up time (unless someone already has the expertise)

Maven Profiles

• One installation ZIP per platform
• Maven profiles isolate the Overlord modules and dependencies to their respective, targeted platform
• Would require either 1.) multiple assembly XML files or 2.) finding a way to make the assembly more dynamic, based on the Maven profile
• PROs:
  • less up-front work
• CONs:
  • Requires multiple builds to produce all distro zips
  • Still requires Ant for installation

Investigations to be performed:

[OVERLORD-149] PoC Suitability of IzPack to provide Overlord installer(s) - JBoss Issue Tracker

[OVERLORD-150] PoC Suitability of Embedded Ant for use in Overlord installer(s) - JBoss Issue Tracker

[objectiser]

IzPack wouldn't predefine the username and password - it would prompt user for the details (or take it from command line parameters).

Maven profiles - not sure why profiles would be necessary, unless at build time someone only wanted an individual platform distribution to be built. Otherwise I would have thought all platform distros should be built by default for release purposes.

I quite like the IzPack option as it is something that could be used inside a Dockerfile using silent install mode, with username/password potentially supplied from the docker build command line - but at the same time can be used standalone independent of docker. It combines the install and config steps, but can remove the dependency on ant.

Although we don't have izpack experience in the team, it is used within productisation, so could leverage their knowledge to get started.

[eric.wittmann]

Another way to solve the Ant problem is to implement a config tool in Java.  Here are the things it has to do:

1. Create a java keystore (the saml keystore *and* the vault)
2. Prompt for user credentials and configure the app server with the result - either by updating a file or by invoking another java tool (e.g. for eap and wildfly)
3. Use XSLT to inject changes into files like standalone.xml
4. Modify properties files

All of these are easily implemented in java.  I realize they are *more* easily implemented in Ant.  I have no idea how difficult it is to do in izpack.

I'd be happy also to see a POC installer done in izpack so we can get a sense for the difficulty in building and maintaining it.

[brmeyer]

The main point about the Maven profiles is that you'd need some way to isolate dependencies into the separate targets.  If that's done with separate assembly XML files, then you're correct.  But if we want the assembly XML files to somehow be dynamic, and let the Maven dependencies determine what goes into them, then profiles would be necessary separation.

[jorgemoralespou_2]

Hey,

The ant option is good, although it should require to strip down to leave only what is required for the target container, as like Eric says, it will simplify the install process. One thing that may be worth is to use embedded ant, so provide an script (platform dependant, bash or bat) to launch the embedded ant in the installation distrib. To embed ant is easy, and only few extra jars are required. More depending on the required features.

Also there are installers based on ant (http://antinstaller.sourceforge.net/ http://antigen.sourceforge.net/ )

The izPack option is also ok, but the graphical tools, even in silent mode sometimes require the servers to have X11 libraries (minor issue here). As they should also provide a text-only mode, which is not nice, but works.

The create your own installer is a very good option but might require some effort from your side, although I like it more.

The main problem with then installation, usually is modifying configuration already on the server, so to overlay another "feature" on top of an existing one, and to be platform independant, which leaves you with few options. There will always be requirements on something (java, ant, X11 libs, ...) so I would recommend then to explore a bit, an maybe come with the lightest and more maintainable of them. Which right now I think could be embedded-ant. If the ant scripts are properly configure to solve typical problems of the configurations, then great as you are almost there. With this problems I'm coming to respect values and information already in the configuration, or when configuring a database, checking if the schemas are already there, or for which version, as you do in newer DTGov with tje DTGovInit artifact.

I'll help you in whatever I can, although very bad coder :-(

[eric.wittmann]

I hadn't considered embedding Ant - that's an excellent option and I retract my suggestion to write our own java installer.

The biggest question I think is how to create stripped down distros for each platform without adding too much maintenance.

[jorgemoralespou_2]

For creating stripped down version of the installers per runtime, I would probably combine maven profiles and maven assemblies (maven-assembly-plugin), generating different .tar.gz, .zip,... with only the relevant bits required. This is very maintanable.

To make it more resiliant and easy you can introduce the automatic installation of the runtime in the CI build pipeline, starting a ,why not, docker container with the target runtime, to validate the installer process, and then delete the docker container. This is very easy with jenkins.

Also maybe deploying a sample application (quickstart) and validating that everything runs fine is a further step.