Uploaded image for project: 'Dev - Nexus Repo'
  1. Dev - Nexus Repo
  2. NEXUS-25518

Instance cannot be easily deployed from a pipeline (immutable infrastructure)



    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.0
    • Fix Version/s: None
    • Component/s: Bootstrap
    • Labels:
    • Environment:
      Docker, Kubernetes, VM's using pre-built VM images. Generally, any environment using the "Immutable Infrastructure" paradigm.


      When I deploy Nexus3, I need to reserve three locations for possible changes:

      1. The "nexus/etc" directory for configuration changes/additions.
      2. The "nexus/deploy" directory for plugins. ("kar" archives)
      3. The "nexus-work" directory for Nexus3's state.

      For a simple example, take a deployment that wants to use GitHub Authentication, which is not uncommon. In the "etc" directory I need to add "githubauth.properties", in the "deploy" directory I need to put the "nexus3-github-oauth-plugin.kar" plugin, and the working directory will be the long-term persistent state.

      The way Nexus3 is currently structured, this is very difficult to automate, as the first two are part of the software's distribution. The working directory contains an "etc" directory, but this is apparently not monitored for configuration files such as those belonging to plugins. The result is that for an upgrade scenario I need to extract files from the current installation and copy them into the new one. Only the work directory is fully independent. This approach is institutionalized in the installation and upgrade instructions, which assume you have a server that you can log on to, and manually change.

      From maintainability and disaster recovery perspectives, this is unwanted. In order to be able to use one-button, fully automated deploys, we need to separate the static and variable content.


      Suggested change is to monitor the "etc" sub-directory in the working directory for configuration files as well as the original, or allow a fully separate directory, so files in there override anything in the distribution. For the plugin deploy directory, a similar approach can be used, although it could more simply be moved outside of the distribution tree, since there are no plugins distributed.


      As a working example, that is an admitted dirty hack, I can run Nexus3 in docker as follows:

      docker run -d -p 8081:8081 --name nexus -v $(pwd)/etc:/opt/sonatype/nexus/etc -v $(pwd)/deploy:/opt/sonatype/nexus/deploy -v $(pwd)/nexus-data:/nexus-data sonatype/nexus3

      This is not a recommended approach, however, as it depends on knowledge of the structure of the distribution instead of pre-defined volume mount locations. A comparable solution will also allow cleaner deployments on Kubernetes.

      NOTE This is filed as a bug, as the current approach makes deployments to Docker (and direct derivates), Kubernetes, but also VMs (using e.g. packer) dependent on not having changes in the contents of the "/opt/sonatype/nexus/etc" directory during upgrades, and thus not automatable.




            bert.laverman@axoniq.io Bert Laverman
            Last Updated By:
            Joe Tom
            0 Vote for this issue
            4 Start watching this issue


              Date of First Response: