Docker updates

[ghost]

This is a follow-on PR to #3839 and can be handled two ways; review this PR in place of #3839 or maintain commits of branched PR by not squash merging.

VIVO GitHub issue: #3822 and #3786

Also related to #3698 as the docker deployment supports specifying the Tomcat webapp context path.

What does this pull request do?

• Improves docker image
  • not running tomcat as root
  • affords specifying webapp context path
  • supports loading sample data on reset of home
  • provides a subset of runtime properties to be defined on startup via environment variables
• Affords substitution of context.xml variables
  • vitro/rootUserAddress
  • vitro/defaultNamespace

What's new?

Updates to the Dockerfile, docker-compose.yml, and start.sh script among other deployment related configuration files.

How should this be tested?

See README.md

Interested parties

@chenejac

[chenejac]

@wwelling please check my comments here, I suggest to review this PR instead of previous one (#3839), and of course we need to review Vitro PR as well (vivo-project/Vitro#370)

[ghost]

Dragan Ivanovic
3 days ago
Only bin, rdf and config files are copied into VIVO_HOME, right? I suppose some changes might happened into config and rdf in customized VIVO instances. I see the next scenarios:

1. An institution is installing VIVO for the first time, there is only empty VIVO_HOME directory.
2. An institution is upgrading VIVO, but didn't customized VIVO_HOME, meaning didn't change any single file in rdf and config.
3. An institution is upgrading VIVO to some future VIVO which is not changing any file which should be copied to config or rdf subdirectories of VIVO_HOME, but institution customized its previous VIVO version by changing something in VIVO_HOME/config or VIVO_HOME/rdf.
4. An institution is upgrading VIVO to some future VIVO which is changing some files which should be copied to config or rdf subdirectories of VIVO_HOME (introducing new property in default.runtime.properties, adding new n3 file in rdf, etc.), and institution also customized its previous VIVO version by changing something in VIVO_HOME/config or VIVO_HOME/rdf.

I suppose the first two scenarios are not a problem.
@William Welling
is manual creation of digest only solution for 3rd scenario (in the case when docker is not used), or it is also working for 4th scenario? Do you see any other scenario? We can add instructions for upgrading VIVO somewhere in wiki documentation. If it is just one command, I hope it wouldn't be a problem.

[ghost]

1. An institution is installing VIVO for the first time, there is only empty VIVO_HOME directory.

 There is always a VIVO home directory now and not defined at build time but rather runtime. Previously, the maven process could have created the home directory if not exist.

2. An institution is upgrading VIVO, but didn't customized VIVO_HOME, meaning didn't change any single file in rdf and config.

 Upgrade will handle the rest now knowing there is a digest provided of the VIVO home directory.

3. An institution is upgrading VIVO to some future VIVO which is not changing any file which should be copied to config or rdf subdirectories of VIVO_HOME, but institution customized its previous VIVO version by changing something in VIVO_HOME/config or VIVO_HOME/rdf.

 Are there any home bin, config or rdf file changes on upgrade?

 Has the instance of VIVO been tampered with? i.e. has the system administrator, developers, or other personnel that have access to the terminal changed them? We have a known use case in which they are mutated but versioned in a fork. If implementer continues to build from source the VIVO application, they continue to do so but have to provide there VIVO home digest on restart or it may be in an uncertain state. Is a useful thing to know when restarting to avoid having graph dumped into your production triplestore.

4. An institution is upgrading VIVO to some future VIVO which is changing some files which should be copied to config or rdf subdirectories of VIVO_HOME (introducing new property in default.runtime.properties, adding new n3 file in rdf, etc.), and institution also customized its previous VIVO version by changing something in VIVO_HOME/config or VIVO_HOME/rdf.

 The customizations described here are most likely made in a repository fork and applied before build. Which means everything would work as expected.

[wwtamu]

Merge conflicts with #3940.