search

fititnt / uwazi-docker

Dockerized version of Uwazi (“openness" in Swahili). HURIDOCS designed Uwazi to make human rights information more open and accessible to the defenders who need it.
The Unlicense
11 stars 4 forks source link

Very basic (and generic) instructions on how to upgrade from older to new versions of Uwazi #39

Closed fititnt closed 1 year ago

fititnt commented 5 years ago

See

At this moment, we do not have some automated way to upgrade without the user need to run commands inside the uwazi container the first time after one upgrade. This PR is a very first attempt to explicit document how to do it.

vasyugan commented 5 years ago

I am still somewhat confused about how to upgrade and partly because I still don't really understand how yarn works and what it does. However, I suppose the goal would be to have prebuilt docker images for each release so that the user could simply run the docker-compose command, the uwazi-docker image is pulled from hub.docker.com and the app is set up.

I wonder whether there is some mechanism in uwazi, through which one could detect the need for data migration and do it as needed. Or does it do any harm to just run yarn migrate and yarn reindex whenever a new image is pulled? Would there be a mechanism in docker to detect that the image has been upgraded and therefore these commands should be run? Or would it be possible to pass a parameter to docker-compose which triggers running of these commands?

fititnt commented 5 years ago

@vasyugan yes, in theory, is possible to do this. Maybe one software that use both Node and MongoDB that do something like this is the RocketChat. They have a base image here https://github.com/RocketChat/Docker.Official.Image. But note that this software I cited as example have 1) huge user base, 2) much more developers inside the company and 3) does not have one additional container like Elastic Search.

But before archive something like this with Uwazi, it will take some time and smaller steps. I think even in the best possible scenario, even if they already have more people inside their developer team like other open sources like RocketChat, we would still need at least two released versions like 1.5 and 1.6 to start doing full automation.

By "full-automation" I mean run the uwazi container that via docker-compose-yml connect to one mongodb and elastic search and, if empty, populate as if is a new installation, if have data and is same version, run normaly, and if have data, but is a older version, runs the migration).

Note that have a image on docker hub would not means full automation, just would save some building time. It would make it faster, not do the right thing without some human intervention.

This PR, for now, is just for we start to document what are the steps to update from 1.3 to 1.4 (and, since their are generic, would work for 1.4 to 1.5). But, for do some more automation (or at least the https://github.com/fititnt/uwazi-docker/blob/master/docker-entrypoint.sh give some hint that the databases version are outdaded) we would need some yarn commands or make some hardcoded checks (like access the mongodb from command line and return true or false).

The problem with do some hardcoded check here on the docker-entrypoint.sh is that it would make it a problem on next updates. But some additional yarn scripts to do this check if a migration is need would allow do some automation.