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 (@OlivierL, please correct me if I’m wrong):
- “Developer mode”: use local source code files, and use Django’s
runserver_plusto 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.
