Answer the question
In order to leave comments, you need to log in
How to make unix-socket MySQL (MariaDb) not work in Docker?
Good time colleagues!
Actually, I wondered if it was possible to somehow make the original MySQL / MariaDb image work in Docker using unix-socket.
The essence of the problem is that, as far as I understand, they try to create a mysql/mariadb unix-socket on behalf of the user from whom the database itself is launched, and with default parameters, it apparently succeeds ... The standard unix-socket location does not suit me for various reasons, I reassign it to a different path, for example, /var/run/mysql.socket
. And since this path is common for different containers and is mounted from external media - by default, write permissions to it belong to the root user, which in principle is not a problem for other programs running in a container and creating acc. socket as root 'a. But, from the MySQL documentation, we learn that running the database as the root user is a complete "ahtung" and it is strongly not recommended to do so, etc.
I hypothetically see several options for solving the problem:
1. Build your own image from the database
2. Heap crutches on top of the original database image
I don’t like both options too much. Is there any other way to get around these restrictions?
PS I understand that "running a database in a container is bad manners" and that Docker has a lot of problems on different systems other than Linux, especially regarding the database and everything else, but the question is not "why not to do this ?", the question is exactly what are the shortest ways to solve this problem?
UPD. As it turned out, it was not about the rights, everything was just fine with the rights to the folder (in the end). Moreover, setting the flagrw
when connecting a folder - automatically sets the rights to 777 when it is mounted. The problem was that the current FS (file system) did not support the creation of unix sockets (testing was carried out in OS other than Linux, on different FS, in order to cover the maximum number of potential developers). In the end, the solution to the problem turned out to be quite banal - there was no need to set the parameterdriver: local
when mounting the filesystem, at least for the purpose of application compatibility with non-Linux OS (which we installed since most of us are running Linux [and Linux, of course, it all works fine] and like this " feint" was a convenient entry point to a database that would otherwise become isolated). Although, one moment in this whole story remains unclear to me ... this config was partially copied from another container, in which a unix socket was also created, in the exact same way, and somehow the whole thing worked in exactly the same Windows OS with the same file system. At the moment, it does not really matter, but the situation looks curious...
Thanks to my colleague Vitaly Karasikfor participating in the discussion. In the context of the original question I asked incorrectly, I think his answer was correct, I mark it as a solution.
Answer the question
In order to leave comments, you need to log in
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question