MySQL and SSL Proxy on Mac (M1)

[hardtmedia]

Hello,

I am currently working on getting dockerized ingrid to work on a Mac (m1).
The MySQL container config requires the platform to be specified.
Otherwise, docker will try to fetch MySQL for arm64, which does not exist.

However, MySQL runs fine through rosetta2, so it will work if the linux/x86_64 platform is used.

 mysql:
    image: mysql:5.7
    platform: linux/x86_64             <--- add this
    command: docker-entrypoint.sh mysqld --character-set-server=utf8 --lower-case-table-names=1 --collation-server=utf8_unicode_ci
...

With this change MySQL is running. Another option would be to switch to MariaDB, since they provide an arm64 native image.
https://hub.docker.com/r/arm64v8/mariadb/

I am still working on the SSL proxy and may add more information, if and when I find it.

[hardtmedia]

I think was a little ahead of myself. The container does indeed start, but the mysql service is not running.

[joachimmueller]

Hi, thanks for testing the setup. Currently MacOS ist not one of our Testing/Dev Env. I find it strange, that the mysql container/service does not start. Do you get any logs out of the container?

Did you have had success with mariadb?

[hardtmedia]

Currently MacOS ist not one of our Testing/Dev Env.

I am aware :)

The logs from the MySQL container are quite short.
It's just a single line, indicating no problem, unless the entrypoint script should provide more logs.
2022-03-11 10:36:57+01:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.37-1debian10 started.

From the logs of other containers, e.g., iplug-ige, the logs begin with:

ERROR [2022-03-10 21:02:50] (JDBCConnectionProxy.java:122) - Can't connect to database! Please check your connection parameters.
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

Opening an sh session in the mysql container works, the container itself is running.
Inside:

# service mysql status
[info] MySQL Community Server 5.7.37 is not running.

service mysql start yields no response. The command never completes and there will never be a new prompt. Letting it sit for a few minutes and then checking in a second session, the status is still stopped.

/var/log/mysql/error.log contains some shutdown notices from a few days ago, where it should show entries from today.
I will attach the log file.

_data/mysql should contain the databases, if I'm not mistaken. The folder remains empty.
The entire _data folder is chown -R 1000:1000 and currently also chmod -R 777.
I have tried to remove the container, double check permissions and the to recreate the container.

MariaDB

Using MariaDB, some files are written in _data/mysql. General success was not achieved yet.
Running service mariadb status here also shows that it's not running. So possibly there is a lack of knowledge and this is not the correct indication in this scenario. Checking ps -aux shows a running mysql process.

Trying to connect via cli (inside the container) yields one of:

• ERROR 2002 (HY000): Can't connect to local server through socket '/run/mysqld/mysqld.sock' (2)
• ERROR 2002 (HY000): Can't connect to server on '0.0.0.0' (115)
• ERROR 2002 (HY000): Can't connect to server on '127.0.0.1' (115)
• ...

SSL Proxy
There is an issue with Docker Desktop, which leads to problems when a folder and a single file are mounted within the same scope.
docker-archive/compose-cli#1795

My changes to docker-compose.yml regarding sslproxy:

. . .
sslproxy:
    image: linuxserver/swag:version-1.15.0
    platform: linux/arm # <----- Added platform
    privileged: true # <----- added privileged mode (might not be needed, haven't tested again without this setting)
    environment:

      . . .

    volumes:
      - ./_data/sslproxy:/config
      # - ./sslproxy/nginx.conf:/config/nginx/site-confs/default # <----- remove this line
    
    . . .

After the container started once and set up all it's files in _data/sslproxy I replaced the nginx config file manually.
The container dies start like this and the logs ultimately say Server ready.
The access/error logs stay empty.