Rebuild KoBo in a server (non-staging mode)

[dj_1]

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”):

(already running) python3 run.py

sudo docker exec -it kobofe_kpi_1 bash

cd /srv/src/kpi

rm -rf node_modules/ && npm install -g check-dependencies && npm install --quiet && npm cache clean --force

rm -rf jsapp/fonts/ && rm -rf jsapp/compiled/ && npm run copy-fonts && npm run build

python manage.py collectstatic --noinput

exit

cd kobo-install

sudo python3 run.py --stop

sudo python3 run.py

I would like to confirm this before I install KoBo in a server and non-staging mode.

Regards

[ks_1]

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

[dj_1]

Thanks for your reply @ks_1

I actually do git pull before entering the container, so that part should be fine.

I only need to verify that the steps I’ve listed above will be enough for applying updates on the live site.

Regards

[jnm]

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):

1. “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.
2. “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.
3. 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.

[dj_1]

Thank you very much for your reply @jnm, appreciated.

This solves my question. Unless @nolive says otherwise, I will then install KoBo in “staging” mode on the production server.

Best Regards

[nolive]

Hello @dj_1,

@jnm is right. Staging is the mode you want.

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.

You should run

source /etc/profile
rsync -aq --delete --chown=www-data "${KPI_SRC_DIR}/staticfiles/" "${NGINX_STATIC_DIR}/"` 

[dj_1]

Hello @nolive,

Thank you for confirming the above and for completing the steps for rebuilding. I have tried them and they are working as expected.

Thank you, appreciated!