Hi, I need to install KoboToolbox in a server, in non-staging mode:
What kind of installation do you need?
1) On your workstation
2) On a server
[2]: 2
…
Use staging mode?
1) Yes
2) No
[2]: 2
Let’s assume the platform has been installed with the above settings and runs successfully, and that I’m using Git to synchronize the code between my localhost and the above server.
Now, I make some changes on the KPI code from my localhost, and I want to reflect those changes in the server. I go to the server and do a git pull under the KPI repository.
After that, could someone confirm that the steps from below are the correct ones for rebuilding in the server? (they are the steps I currently apply in a server that has KoBo in “staging mode”):
I’m no expert, but I feel like you need to git pull the new code into the container if you’re not changing the docker image. Here’s what worked for me:
docker exec -it kobofe_kpi_1 /bin/bash
git pull origin master (you would need to git init etc. first)
npm install
npm run copy-fonts
npm run build
python manage.py collectstatic
It would be better to use kobo-install’s staging mode than to pull code into running containers. Running containers can easily be recreated by upgrades or any kind of configuration changes, and when this happens in production or staging mode, all changes you made inside the container are lost. Only developer mode, which actually connects the source code directories (aka mounts them / maps volumes) from your host to the filesystem inside the container will preserve some changes. It’s still almost always a bad idea, even in developer mode, to make your changes inside the container.
Staging mode should work well for you, because it uses a production-ready configuration but builds the Docker images from local source code instead of pulling our pre-built images from Docker Hub.
For reference (@nolive, please correct me if I’m wrong):
“Developer mode”: use local source code files, and use Django’s runserver_plus to serve HTTP requests. This is great for editing code, because it automatically reloads when Python source files change, but it’s totally unsuitable for production. The Django maintainers themselves demand that you not use this in production.
“Staging mode”: use local source code files, and uWSGI to serve requests. uWSGI does not automatically reload when source code changes, so it’s less convenient for developers, but it is production-ready.
Neither of those two, i.e. production mode: download KPI and KoBoCAT Docker images from https://hub.docker.com/r/kobotoolbox/ and use uWSGI. No local KPI or KoBoCAT source files are considered.
Note: at this time, developer and staging modes do not affect Enketo at all. Enketo always uses a pre-built image from Docker Hub unless you manually edit the Docker Compose configuration to do something else.
FYI. You do not have to run ./run.py --stop before ./run.py because ./run.py does stop all the containers if they are already running before starting them.
If you make some changes in the front-end code or/and front-end assets, you may want to add another command after python manage.py collectstatic --noinput.