(copied from GitHub https://github.com/discourse/discourse_docker/issues/82)
Hi. I want to rain on your deployment parade for a minute. Sorry, I’m not trying to be rude, but I think this is really important to get right, and I had to do a redeploy today, it took awhile, there was a lot of fighting with your launcher script. I won, but somewhat unsatisfied with the parley.
So as far as making deployment good for newbies–which is a fine goal for an early-stage product–you’ve basically succeeded, or at least as close as you can without offering a hosted solution. You tell the user what OS to run, what directories things should be stored in, and everything’s fine.
The trouble is that as the product matures, more and more people with actual sysadmin/devops skills will be maintaining it, and the deployment really isn’t at all intuitive to that group.
For example, the way Docker is supposed to work is you are supposed to be able to run “docker build .” at a command line and something sensible will happen. You can’t do this with Discourse.
Now that’s not really your fault, since the Dockerfile format is ridiculously underpowered and cannot possibly do the kind of configuration processing you want to do. But in this case the answer is to get involved on issues like here here and here to get the format to a place where it can start handling these cases.
Or alternatively, the answer is to write a standard tool that could build docker images with sufficient configuration power. And then that tool could get re-used among various projects that want to package complicated things in Docker. You’re early in on the scene, I think people would listen to you.
But the answer definitely isn’t for every vendor to write their own shell script installer with their own syntax to install every package. That is so 90s.
Here is a laundry list of similar complaints:
- Discourse assumes things about the file structure of my host system, for example that I’ll have a
/var/docker/shareddirectory. If only there was some kind of lightweight container system, that would let me organize my host FS how I want and let each guest lay out the filesystem how it likes… Oh wait that’s how Docker is supposed to work.
- Discourse makes me reach into some vendor-specific yml file to edit what ports will be forwarded on the host system. If only there was some vendor-independent syntax, like
docker run -p, that could specify ports for any applications I run…
- Discourse has ssh enabled by default. That’s not how Docker is supposed to work. Puzzlingly, Discourse also installs
- Discourse requires git to be installed on the host. If only there was some vendor-independent syntax, like
docker pull, to move software across a network
I could go on, but this is getting long.
Really what I’m saying is this: Docker isn’t a private interface that you can hide behind a shell script. It’s a public interface, and one that you potentially share with other tenant applications on the machine. My job as a sysadmin is to expose ports, start and stop containers, mount volumes, and I am tired of wrestling with a shell script that thinks it knows how to be a sysadmin better than me.