We should also take into consideration the development cycle with mounted paths. In case of development, the code is over mounted on top of the sources from inside the container, and the entry point changes to install new node_modules (or update old already installed) and then start the service with the config, that's also over-mounted from the cloned repo. So we need something like /bin/reinstall_deps_and_start

Also, it would be nice to install dependencies in the dev environment to some of the minikube persistent volumes so that when the user restarts minikube they don't need to reinstall all the dependencies again.

I think the proposal is pretty sound - with a couple of suggestions to keep things more "familiar" for ops, and more in line with what we use for our production environment:

1. Use /srv/service instead of /opt
2. Use /etc/service-config instead of /config
3. I would pick /bin/run_service, but maybe even /usr/local/bin/run_service, which adheres more to the FHS.

I agree with the assmuptions and I don't want us to have to template the service name everywhere - having the exact same hierarchy in every container is a good idea.

I do think we should expand on this proposal - but this is a good starting point.

I would add that run_service and run_tests should be a link to a base script that will change depending on the specific language/frramework used, and should be included in our base images.

Added @Joe's proposals to the description. Except for /etc/service-config, which I shortened to just /etc/service.

Overall, there seem to be two broad directions emerging:

1. Follow the Filesystem Hierarchy Standard, and use the generic "service" as the service name.
   • Config in /etc/service, code in /srv/service, binary in /bin/run_service and /bin/run_tests`, possibly data in /var/service.
2. Follow external Docker conventions.
   • Config in /conf/, code in /src/, binary in /entrypoint, data in /data/.

I personally am fine with either option, but wouldn't be too keen on using a mix between the two. One minor niggle with the first option is the need to use run_service and run_tests instead of the plain service name. I am wondering if we can find a better service name that avoids these issues, and lets us use consistent binary names.

FTR, I would really prefer us to stay close to FHS. I 've had to debug containers that did not follow it already and the time lost trying to figure out where things were was pretty significant. We can make the argument that we would get used to a non FHS solution, but if we add the time it would take every new person to get accustomed to it I am willing to bet it would end up being considerable. Given we also want to create an environment that would be welcoming to new developers we should probably avoid extra surprises. They would already have enough new things to get accustomed to, let's not add more.

I am also not fully sold on the idea that we should not template some things. I do expect e.g. mathoid's configuration to be under /etc/mathoid and not under /etc/service but I am I guess this is something I can work around.

In T169998#3607722, @akosiaris wrote:

FTR, I would really prefer us to stay close to FHS. I 've had to debug containers that did not follow it already and the time lost trying to figure out where things were was pretty significant. We can make the argument that we would get used to a non FHS solution, but if we add the time it would take every new person to get accustomed to it I am willing to bet it would end up being considerable. Given we also want to create an environment that would be welcoming to new developers we should probably avoid extra surprises. They would already have enough new things to get accustomed to, let's not add more.

I don't believe that to be such an overhead, but in general I'm +1 on going with FHS, it just feels more natural.

I am also not fully sold on the idea that we should not template some things. I do expect e.g. mathoid's configuration to be under /etc/mathoid and not under /etc/service but I am I guess this is something I can work around.

Why not? This to me is the big advantage of containers - the fact that we don't have to template names and worry about exact locations, but stick to a pre-defined contract. What would be the point of putting Mathoid's configuration in /etc/mathoid/ over /etc/service/ when we know that that is going to be the only service running inside the container?

I am also not fully sold on the idea that we should not template some things. I do expect e.g. mathoid's configuration to be under /etc/mathoid and not under /etc/service but I am I guess this is something I can work around.

Why not?

Me finding it instantly and not having to do the indirection of "oh wait.. we are talking about a WMF containerized service, these guys do it some other way, what is it again?<some time later>ah, here it is" But as I said, I 'll survive that part.

This to me is the big advantage of containers - the fact that we don't have to template names and worry about exact locations, but stick to a pre-defined contract. What would be the point of putting Mathoid's configuration in /etc/mathoid/ over /etc/service/ when we know that that is going to be the only service running inside the container?

To me it is not, in fact this is the biggest problem of containers. Encouraging shipping code somehow somewhere inside a tar file alongside a few steps "here's how to run me", is not the big selling point for me. Not that I 've ever seen any container company actively encouraging that practice. Anyway, It's the orchestration that is made possible, or the decoupling of developer's code from system provided library versions increasing portability and extensibility that make containers appealing.

In T169998#3607989, @akosiaris wrote:

To me it is not, in fact this is the biggest problem of containers.

I meant in the context of path layout naming.