Docker "Philosophy"

[uberbrady]

When I first wrote the Docker implementation, I took the "one process per container" philosophy pretty literally. (Yes, Apache does fork multiple processes, but I didn't want to get too literal).

But, especially since lots of new users of Snipe-IT are also not fully conversant with Docker, they often run into all kinds of hitches with getting all the appropriate containers set up and running.

So maybe I was too literal? Maybe the real line of thinking should be "one application" per container? And so, the MySQL as well as the webserver/PHP combo should all run on one container, with some kind of storage volume(s) that hold the MySQL data, as well as any uploaded data.

The opposite problem, however, is that we have a lot of users who like to mix-and-match different things together. We have some users who want to use standalone non-docker databases, and some who like to use non-standard databases (like PostgreSQL, or others). I don't know that I would want to prevent that, per se. We have some people who take Snipe-IT and repackage it - which is absolutely permitted by license (so long as they also release their source code).

My current thinking is that the Snipe-IT repo is a sort of 'developer tool' - users can absolutely run stuff we have on there, and we do our best to try and document it for you. But it's a tool and you can combine it and use it however you like, and run it wherever you can get it to run. We give you the tools, and do our best to document everything - and then you build it yourself. Like buying a Lego kit, I guess.

Anyways, I'm not necessarily convinced that changing how we do Docker is something we should or will do, but I wanted to see what people felt about it.

[gmintoco]

Hey,
coming from the docker-compose issue before.

I think the approach with having multiple containers (sql, nginx, snipe-it) is absolutely correct and is in line with how containers are intended to be structured (the whole point is decoupling these services and allowing them to scale or be hosted independently etc.)

We are currently running snipe-it in K8s and the only problem I have with it is that it isn't built to be horizontally scalable mainly for resiliency, not so much performance (data isn't stored in object storage, so it would require an NFS backend to support ReadWriteMany storage which is just a terrible experience all around - I gave up on this and now just run a single replica)

The point of having multiple services makes a lot of sense in a cloud environment we were considering using cloudSQL as a backend for a little while (and this may make a lot more sense on more heavily used instance)

As for quickstarting with docker, the PR with a docker-compose file makes a lot of sense (a common way for quickstarting containierised apps/developing them too). If having secrets in the compose file is a concern a good approach would be to split the secrets out into a .env file. Directing users to clone the repo, fill out a blank env file, chmod it to read only by root, then run docker-compose up should be a fairly good experience (first retrieving a php artisan key just using a docker run of course).

just some thoughts