Hacker News new | ask | show | jobs
by archivator 4429 days ago
As someone just now learning how docker works, I absolutely agree.

Personally, I think there are some new-ish interesting immutability ideas that can be explored with regards to static files. It's not clear to me whether static assets (or even static sites) belong inside the container. I would be really interested in experienced folks' opinions on the immutability of the image. Where do you draw the line on what goes inside it and what's mounted in?

2 comments

This is my general rule of thumb, but bear in mind it's only my approach. I'm not even going to claim that it's good. Just that it works for me...

Is it source or configuration? Then its external to the container, either mounted at runtime of the container (typically always true for source code) or injected into the image at build time through the Dockerfile. Application source is almost always mounted, things like nginx/apache configuration files are nearly always injected during the build process.

I prefer this approach because my source is decoupled from the image, and if another developer wants a dev setup free from Docker, he/she can do so.

I prefer the source I use for config files because it allows me to keep the dockerfile, the configuration files for various services, and a readme all beside one another in source control. This allows other developers to get a basic idea of the container's configuration (if they so desire), and also modify that configuration if they want to tweak/alter a setup.

I see the configuration file approach being potentially a bad idea, but with the small group I currently work with, we're all fairly comfortable making configuration changes as necessary and communicate those changes to others effectively. I don't know how well that approach would hold up at scale.

I would do the same thing with static sites and files, I think. Why? The static site isn't the part of the system, it's the product that should be executed on the system. Therefore, at least in my opinion, it should be as decoupled from that system as possible.

But, like I said, this is just my philosophy. I'm sure someone else will have an equally valid but totally opposite approach.

You don't have to choose between what's inside and what's mounted in. You can mark persistent directories (directories that should live longer than any given instance) as volumes with "dockercrun -v". Docker will arrange for them to live separately from the rest of the container filesystem. Then you can share volumes between containers with "docker run --volumes-from"