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

Update production-instructions.md (style, typos) #47

Closed mayeulk closed 12 months ago

mayeulk commented 1 year ago

Feel free to include answers to some of the followings in this PR:

production-instructions.md says: "you would need to use docker exec to do it once after restoring a backup." Should the specific command be: docker compose run -e RUN_YARN_MIGRATE_REINDEX=true --rm uwazi ? If not, which one?

production-instructions.md says: To see the names of the docker volumes, use this command: docker volume ls | grep 'mongodb_data1\|uploaded_documents'

$ docker volume ls | grep 'mongodb_data1|uploaded_documents' local uwazi-docker_mongodb_data1 local uwazi-docker_uploaded_documents

Since the production-instructions.md mentions the elasticsearch cache, maybe we could have:

$ docker volume ls | grep uwazi
local     uwazi-docker_elasticsearch_data1
local     uwazi-docker_mongodb_data1
local     uwazi-docker_uploaded_documents

Thank you.

fititnt commented 1 year ago

Thank you!

I was about to merge, because the typos really make sense (and don't need to test).

Q1

production-instructions.md says: "you would need to use docker exec to do it once after restoring a backup." Should the specific command be: docker compose run -e RUN_YARN_MIGRATE_REINDEX=true --rm uwazi ? If not, which one?

Ok. I will explain a bit more the logic. At installation time, with the IS_FIRST_RUN=true, the database would be erased. This is supposed to be used only one time ever.

The RUN_YARN_MIGRATE_REINDEX=true start the container with 

yarn migrate
yarn reindex

So it should be safe, even if executed without need, however it could at minimum be a slower start. Very likely the only reason to need this again is if the container is rebuild with a newer Uwazi version, but if reusing the same container again and again, the code already expect the data be the expected schema.

So, let's say you don't want to update the Uwazi code very often (like if want give a few months to stop, do backup, and upgrade) then this RUN_YARN_MIGRATE_REINDEX=true migth be necessary only when upgrade the Container (which now uses the production tag, so means also update the code base).

The reason for ask to please make backup first, is because if someone is upgrading Uwazi, since now it's using the very production tag, which is granted that at least after some years will need to upgrade the ElasticSearch, Mongo, etc, in the best case scenario, even with skilled people able to debug how to upgrade these dependencies, you could stay hours with the app offline. But if we document to just please backup first (e.g. don't do it with production data without backup) then the person would be in a hurry to upgrade the other dependencies.

Q2

The part

Since the production-instructions.md mentions the elasticsearch cache, maybe we could have:

$ docker volume ls | grep uwazi
local     uwazi-docker_elasticsearch_data1
local     uwazi-docker_mongodb_data1
local     uwazi-docker_uploaded_documents

Yes, this make sense. Feel free do add the output

mayeulk commented 1 year ago

Yes, this make sense. Feel free do add the output

Done, plus added link to the admin guide in 6 other languages. Feel free to merge the PR; thank you.

fititnt commented 12 months ago

Thank you, @mayeulk. I will merge immediately now. Normally I would look faster on the other issues, but this week got unexpected bureaucratic actions I still need to do with a community-related thing I'm doing since last year., but I will try to rush a bit what is on this repo.

Other PRs related to documentation are easier to merge too, unless they have something to discuss.