search

vivo-project / VIVO

VIVO is an extensible semantic web application for research discovery and showcasing scholarly work
http://vivoweb.org
BSD 3-Clause "New" or "Revised" License
205 stars 127 forks source link

Docker updates #3844

Closed ghost closed 1 day ago

ghost commented 1 year ago

This is a follow-on PR to https://github.com/vivo-project/VIVO/pull/3839 and can be handled two ways; review this PR in place of https://github.com/vivo-project/VIVO/pull/3839 or maintain commits of branched PR by not squash merging.

VIVO GitHub issue: https://github.com/vivo-project/VIVO/issues/3822 and https://github.com/vivo-project/VIVO/issues/3786

Also related to https://github.com/vivo-project/VIVO/issues/3698 as the docker deployment supports specifying the Tomcat webapp context path.

What does this pull request do?

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

ghost commented 1 year ago

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 commented 1 year ago

_1. An institution is installing VIVO for the first time, there is only empty VIVOHOME 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 VIVOHOME, 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 VIVOHOME/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 VIVOHOME/rdf.

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

Merge conflicts with https://github.com/vivo-project/VIVO/pull/3940.