4 ms·

> Any company-wide (GNU/)Linux deployment that uses LDAP... You can go the extra mile and turn the UID:GID into build args like the original parent and you're

by nickjj 5y ago

> Any company-wide (GNU/)Linux deployment that uses LDAP... You can go the extra mile and turn the UID:GID into build args like the original parent and you're good to go. No hacks necessary, and since it's all self contained into a .env file there's nothing extra you need to run since you're likely using an .env file already for other vars. Alternatively you could do this: https://news.ycombinator.com/item?id=27344491 https://news.ycombinator.com/item?id=27344491 In either case you can solve the problem without too much effort.

q3k 5y ago
> You can go the extra mile and turn the UID:GID into build args like the original parent and you're good to go. That doesn't help you if you're attempting to use pre-built/existing Docker images that are not built internally and make the assumption that “1000:1000 is good enough”. You then not only have to hack around Docker limitations, but also around someone else's broken assumption.
- nickjj 5y ago
  > That doesn't help you if you're attempting to use pre-built/existing Docker images that are not built internally Most pre-built images that I've come across don't require bind mounts to function. Images like PostgreSQL aren't affected by this because you can use a named volume, and most pre-built applications that are shipped as images tend to store their state in a database and don't require bind mounts to function.