KoboToolBox Without Docker

[chlarsen]

Dear All,
I am running FreeBSD and OpenBSD in a highly secured, dedicated server environment with separate jails for PostgreSQL, Redis, MongoDB, etc. pp.
As you can imagine, a docker-based installation of the KoboTooloBox software (excluding the required support services, such as PostgreSQL, Redis, Nginx, etc.) is the only reasonable way to get going and to take advantage of the already optimised configurations of the latter. Plus, FreeBSD does not really love Docker so much; OpenBSD does not like it at all!
Where can I get "de-Docker-ed" version of the core software, plus instructions for the required services. Reverse-engineering the Docker files is an option, but error-prone and no fun. Is there a way to touch base with the folks that developed and deployed KoboToolBox in the first place, and then wrapped it all up for Docker?
Thank you so much!
Chris

[fititnt]

Hi Chris, I'm also about to use Kobo for testing, so I'm anwser here based on some previous experience (and also to give you some tips that could works fine than full reverse engineering of dockerized files. TL;DR: use container just for part of the stack.

One way to do it is host both the frontend (the nginx/apache/traefik etc, choose one, for sure this is not a problem on BSD) and the software that really store data (databases, filesystem) on your BSD, and the rest still use docker inside a virtual machine (that could be hosted on any *BSD or a different VM or bare metal, them choose one that would play fine with docker). Then leave only the "core" on the docker-compose.yml file and replace the link lines with hardcoded port lines (docker allows map one internal port to a different external (on the host, aka the VM who run the docker), and then map that port to the *BSD port.

This is not the only way, but is one way that would work and makes much more easy to keep up to date with new releases. Also, some people, even the ones who uses docker a lot, in production still use the databases on the host or complete different bare metal or virtual machines, and not inside a docker container, in special for stacks that still run from years ago when docker could had some nasty bugs with storage, but still very good for developers test the full stack and was getting pretty popular.

With this approach, I think the docker-compose.local.yml could still be used to test new releases, but the edited version of docker-compose.server.yml would be your real one used on servers. It could be not just be easier to setup, but to maintain.

I'm not proficient with kobo or BSD, but maybe I could help you with this if you already do not done this work since you posted here with the Docker part.

[chlarsen]

Dear Emerson, Thank you so much for your kind advice; I will definitely take it to heart, and, yes, it makes a lot of sense! I will keep you updated! Warmest regards from Kenya, Chris On Sunday, September 02, 2018 07:57 +07, Emerson Rocha Luiz <[email protected]> wrote:   Hi Chris, I'm also about to use Kobo for testing, so I'm anwser here based on some previous experience (and also to give you some tips that could works fine than full reverse engineering of dockerized files. TL;DR: use container just for part of the stack. One way to do it is host both the frontend (the nginx/apache/traefik etc, choose one, for sure this is not a problem on BSD) and the software that really store data (databases, filesystem) on your BSD, and the rest still use docker inside a virtual machine (that could be hosted on any *BSD or a different VM or bare metal, them choose one that would play fine with docker). Then leave only the "core" on the docker-compose.yml file and replace the link lines with hardcoded port lines (docker allows map one internal port to a different external (on the host, aka the VM who run the docker), and then map that port to the *BSD port. This is not the only way, but is one way that would work and makes much more easy to keep up to date with new releases. Also, some people, even the ones who uses docker a lot, in production still use the databases on the host or complete different bare metal or virtual machines, and not inside a docker container, in special for stacks that still run from years ago when docker could had some nasty bugs with storage, but still very good for developers test the full stack and was getting pretty popular. With this approach, I think the docker-compose.local.yml could still be used to test new releases, but the edited version of docker-compose.server.yml would be your real one used on servers. It could be not just be easier to setup, but to maintain. I'm not proficient with kobo or BSD, but maybe I could help you with this if you already do not done this work since you posted here with the Docker part. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[gessel]

@chlarsen
It has been a few years, any success in de-dockerizing koboToolBox? The same issue with ODK now that Central has been, alas, also dockerized. For now, the only usable solution seems to be the now not actively maintained ODK aggregate.

[chlarsen]

Thank you for your comment and concern. There is, of course, OnaData, which is well documented and seems to be lead in one or two aspects Kobo Toolbox's development. However, it is a bit rough around the edges at times, and the Kobo Toolbox biotope seems to be a bit more usable. I do think that server platform should come back to simplicity, transparency and granularity, and docker is just the opposite, as it needs reverse engineering, as soon as the highly opinionated setup is diverged from. Anyway, this is just food for thought.

[noliveleger]

@chlarsen, @gessel
You should open a discussion on the community forum. I think you would get more help/guidance than GitHub. We only use GH to track bugs/issues.

However, You run from native packages such as NGINX, uWSGI, PostgreSQL, MongoDB, Redis (and nodejs to compile front-end code).
You will have to pass environment variables to KPI and KoBoCAT Django apps though. (through uWSGi configuration files).