2

I've seen a lot of Docker images ignoring the Filesystem Hierarchy Standard (FHS). Most examples (some official) ignore the FHS. For instance, some may choose to put their binaries in /app and their data in /data, having an entrypoint.sh in the root directory and so on.

The intention of FHS is better interoperability of distribution and application. FHS compliance of a Dockerfile allows to change the Linux base image to another version or distribution. Such an upgrade may for instance be required to solve bugfixes of distribution packages.

It seems to be common practice to write non-FHS compliant Dockerfiles. Will this make maintenance more complicated?

G. Fiedler
  • 664
  • 4
  • 12
  • 4
    I'm really not convinced this question is a good fit for the site -- it's very broad, answers are likely to be opinion-based, and there's no provably-correct canonical answer that exists or can exist. *However*, I can speak a little bit about why, in my opinion, this probably isn't important. – Charles Duffy Jul 19 '17 at 16:24
  • A container is effectively intended to provide an application with its own private namespaces. Within that namespace, *what it does isn't particularly important*, because the only contents there are supposed to be there specifically to support that one application. – Charles Duffy Jul 19 '17 at 16:26
  • ...now, if you're building software packages for a distro, it's still important for you to follow FHS, because your packages need to play nicely with each other, to play nicely with 3rd-party packages, to not surprise your users, etc. That's true even if your users are going to be using your OS distro to build containers, because they're going to be installing other pieces of software in that distro, any/all of which may make assumptions about what constitutes a reasonable default PATH, or where lockfiles should live, or so forth. – Charles Duffy Jul 19 '17 at 16:26
  • However, if "you" isn't the distro packager but instead is the developer *building a container*, the FHS matters only inasmuch as it gives you a bunch of invariants you can rely on your OS providing -- it doesn't constrain what you-the-app-developer are expected to do, because your users don't care what's where inside your container -- they only care about your application's documented interfaces: That it offers service X on port Y, and mounts volume Z for data. Where binaries live inside the container is entirely irrelevant. – Charles Duffy Jul 19 '17 at 16:28
  • ...so, as someone who's done userland packaging for a distro professionally before, that's where I stand. But still, I'm not sure this fits into the "practical, answerable" guidance (or has an "actual problem to be solved", or avoids the "open-ended, hypothetical" category) from [What types of questions should I avoid asking?](https://stackoverflow.com/help/dont-ask). – Charles Duffy Jul 19 '17 at 16:32
  • @charlesduffy Sounds like some good content for an answer, very poor for comments. –  Jul 19 '17 at 16:43
  • 1
    @Thebluefish, sure, but it's an off-topic question, so it should be closed, not answered. See "Answer Well-Asked Questions" in [How to Answer](https://stackoverflow.com/help/how-to-answer). – Charles Duffy Jul 19 '17 at 16:44
  • 1
    If a Dockerfile starts with `FROM ubuntu` the developer building a container could have a problem? – G. Fiedler Jul 19 '17 at 17:13
  • Maybe the question should have been: should the fhs be followed in containers or is there other convention? – pmiguelpinto90 Feb 17 '22 at 14:37

0 Answers0