I cannot start the container while pointing to an external MySQL DB

[maxacarvalho]

Shlink version

3.6.3

PHP version

8.1

How do you serve Shlink

RoadRunner Docker image

Database engine

MySQL

Database version

8

Current behavior

Hi,

I have a local dev environment using Docker compose. Pretty standard stuff:

version: '3'
services:
  web:
    build: docker/web
    depends_on:
      - myapp
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "$PWD/docker/web/nginx.conf:/etc/nginx/nginx.conf"
      - "$PWD/docker/web/templates:/etc/nginx/http.d"
      - "$PWD/docker/web/tls:/etc/nginx/tls"
      # Applications
      - "$PWD/src/myapp/public:/app/myapp/public"
      - "$PWD/src/myapp/storage/app:/app/myapp/storage/app"
    tty: true
    networks:
      myapp:
        aliases:
          - myapp.test
          - nks.test

  myapp:
    build: docker/php
    depends_on:
      - mysql
    tty: true
    volumes:
      - "$PWD/src/myapp:/app/myapp"
    working_dir: /app/myapp
    environment:
      - DEVDOCK_DB_HOST=${DEVDOCK_DB_HOST:-mysql}
      - DEVDOCK_DB_PORT=${DEVDOCK_DB_PORT:-3306}
      - DEVDOCK_DB_DATABASE=${DEVDOCK_DB_DATABASE:-myapp}
      - DEVDOCK_DB_USERNAME=${DEVDOCK_DB_USERNAME:-root}
      - DEVDOCK_DB_PASSWORD=${DEVDOCK_DB_PASSWORD:-secret}
      - DEVDOCK_MYSQL_ROOT_PASSWORD=${DEVDOCK_DB_PASSWORD:-secret}
      - DEVDOCK_IDE_KEY=${DEVDOCK_IDE_KEY:-docker}
      - DEVDOCK_XDEBUG_CLIENT_HOST=${DEVDOCK_XDEBUG_CLIENT_HOST:-host.docker.internal}
      - DEVDOCK_XDEBUG_MODE=${DEVDOCK_XDEBUG_MODE:-off}
    networks:
      - myapp

  mysql:
    build:
      context: docker/mysql
      dockerfile: Dockerfile
    ports:
      - "${DEVDOCK_FWD_DB_PORT:-3306}:3306"
    volumes:
      - "$PWD/docker/mysql/config-file.cnf:/etc/mysql/conf.d/config-file.cnf"
      - "$PWD/docker/mysql/docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d"
      - "myapp_data_mysql:/var/lib/mysql"
    networks:
      - myapp
    healthcheck:
      test: [ "CMD", "mysqladmin", "ping" ]
    environment:
      - MYSQL_ROOT_PASSWORD=${DEVDOCK_DB_PASSWORD:-secret}
      - MYSQL_DATABASE=${DEVDOCK_DB_DATABASE:-myapp}
      - MYSQL_USER=${DEVDOCK_DB_USERNAME:-myapp}
      - MYSQL_PASSWORD=${DEVDOCK_DB_PASSWORD:-secret}

  shlink:
    image: shlinkio/shlink:3.6.3
    depends_on:
      - mysql
    networks:
      - mynetwork
    environment:
      - DEFAULT_DOMAIN=shlink.test
      - GEOLITE_LICENSE_KEY=${DEVDOCK_GEOLITE_LICENSE_KEY:-}
      - INITIAL_API_KEY=${DEVDOCK_INITIAL_API_KEY:-}
      - DB_DRIVER=${DEVDOCK_SHLINK_DB_DRIVER:-mysql}
      - DB_NAME=${DEVDOCK_SHLINK_DB_NAME:-shlink}
      - DB_USER=${DEVDOCK_SHLINK_DB_USER:-myapp}
      - DB_PASSWORD=${DEVDOCK_SHLINK_DB_PASSWORD:-secret}
      - DB_HOST=${DEVDOCK_SHLINK_DB_HOST:-mysql}
      - DB_PORT=${DEVDOCK_SHLINK_DB_PORT:-3306}

networks:
  mynetwork:
    driver: "bridge"

volumes:
  myapp_data_redis:
    driver: local
  myapp_data_mysql:
    driver: local

Every time I try to start the stack the Shlink container won't boot up.
Checking the Docker compose logs I can see the following:

myapp-shlink-1  | Initializing database if needed...
myapp-shlink-1  |
myapp-shlink-1  |
myapp-shlink-1  |  [ERROR] Error generating database.. Run this command with -vvv to see specific
myapp-shlink-1  |          error info.
myapp-shlink-1  |
myapp-shlink-1  |

If I try to run the container with something like docker compose run shlink sh, the first time I get some errors like this:

handle_serve_command: Function call error:
	got initial serve error from the Vertex *http.Plugin, stopping execution, error: static_pool_allocate_workers: WorkerAllocate:
	goridge_frame_receive: validation failed on the message sent to STDOUT, see: https://roadrunner.dev/docs/known-issues-stdout-crc/2.x/en, invalid message:
Fatal error: Uncaught PDOException: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction in /etc/shlink/vendor/doctrine/dbal/src/Driver/PDO/Statement.php:121
Stack trace:

Once I try again it works. From that point on I can start the stack normally.

I already tried to create the shlink DB before hand, the table structure I mean, still won't work.

Any advice?

Thanks!

Expected behavior

I believe I should be able to start the container successfully.

How to reproduce

I believe the docker-compose file described above should be enough.

[acelaya]

Provided docker-compose has a lot of dependencies on other files (mounted volumes, Dockerfile, etc), so it's not possible to just grab and run.

I would recommend adding SHELL_VERBOSITY=3 to the Shlink container. It will print further information about the error.

[maxacarvalho]

Hi @acelaya
That env variable helped. It seems me that the shlink container is trying to connect to the DB before the DB container is available. Perhaps that happens because it tries to connect when the ENTRYPOINT runs.
It executes the file docker-entrypoint.sh, which runs the command php vendor/bin/shlink-installer init ${flags}. I believe that's the issue.

If I try to start the container after the mysql container started it works ok.

So, if I run docker compose up -d the shlink container throws an error because the mysql container is not ready when the ENTRYPOINT executes. Then, after the mysql container started, if I run docker compose start shlink everything goes well.

[maxacarvalho]

@acelaya here's what worked:

Still, now the stack takes much more time to start, some 30 seconds, Without that it takes less than 5 secs.

[acelaya]

Correct, that's the expected behavior. Shlink needs the database to be available when started, so if both the database and Shlink start at the same time, there can be a race condition.

Everything is documented here https://shlink.io/documentation/supported-db-engines/ (see "database availability").

In addition to depends_on option, I would also recommend setting some restart policy, like restart: always. That way, Shlink will restart if the database is not available yet.

There are plans to improve this, though, but it's tricky to do it right #469

[maxacarvalho]

Awesome. The restart: always solves all the problems. No need to have the condition: service_ready anymore. That way the stack starts much faster and all the services end up running as expected.
Thank you!