5 ms·
Every problem you mention here is solved by working primarily from your compose file/deployment manifest and having that be your source of truth. - Where is th
by Karunamon 3y ago
Every problem you mention here is solved by working primarily from your compose file/deployment manifest and having that be your source of truth.
- Where is the data stored? Your compose file will tell you.
- Is the configuration file in that container or mapped? File tells you. (If you didn't map it, it's container-local)
- How do you get to it with admin tools? If you mapped those sockets outside, file tells you.
- tedunangst 3y agoProblem: too many config files. Solution: config file for the config files.
- saurik 3y agoI literally don't have to do any of that if I just install PostgreSQL the normal way as the confirmation file is in the same place the documentation for PostgreSQL says it is in, the daemon is probably already running, and all of the tools know how to find the local domain socket. Why am I having to configure all of this stuff manually in some new "compose file"? Oh, right: because I am now using a container.
- Karunamon 3y agoIt's really hard for me to not make some incredibly dismissive "okay, boomer" comment here, but you are not giving me much to work with and this really reads as obstinate resistance to learning new things. Are containers different? Without a doubt. The benefits are, however, impossible to ignore. The amount of work you are complaining about is, objectively, trivial. It's no harder than learning how to deploy on another distro or operating system, except in this case, your new knowledge is OS-agnostic.
- imtringued 3y agoI agree. All he is doing is making people uncomfortable for using containers. The only real major downside with containers is that the building process is quite expensive so you should get familiar with docker run -it --rm <id> bash or the same thing with docker exec. Oh and also that your container might not come with diagnostic tools.