3 ms·
I think all those problems disappear when you run containers with proper orchestration tools, such as Kubernetes. And not only that, I think that examples give
by 988747 5y ago
I think all those problems disappear when you run containers with proper orchestration tools, such as Kubernetes.
And not only that, I think that examples given in the article ("Assume that your Apache/PHP container is mounting the host’s /home/alexandros/myapp/ application directory to the container’s /var/www/html directory.") are in fact anti-patterns. If your container depends on specific file being available at specific location on the host then you're doing it wrong. The only place where that makes sense is on developer's local environment. In shared enviornments you want something like Kubernetes ConfigMap to contain config files, and dedicated persistent volumes for everything else.
- 0xbadcafebee 5y agoThe orchestration tool does not provide any additional functionality to fix this problem, it's up to the container execution environment, and today's container execution environments have no way (that I am aware of) to natively map file permissions outside of the container. It could be I just haven't dug enough into the kernel internals, maybe there is a transparent permissions remapping thing. But something would absolutely have to map permissions. Otherwise there is no way to use filesystem ownership between execution environments without them using conflicting UID/GIDs, to say nothing of changing the file perms.