Docker Compose question (Security question)

I am still very new to just about everything linux, and even newer to docker, but I have a security question pertaining to the docker compose samples provided by pydio.

In the docker compose it appears the MySQL ports are being externally exposed, yet the software is made to run in a closed network. Would it not be safer to remove the ports flag and use the service name as the host when setting up cell as to not expose mysql?

(This method is what I am using and ti seems to work just fine.)

yes you could use mysql without exposing the ports and even use a separate docker network,
actually our example was made to be the most user friendly possible, but if you have suggestions i could add them to the documentation.

I also deployed using docker-compose, and I definitely removed the host-exposed port. If their on the same network, it only makes an unnecessary attack surface.

As a note: the mainline pydio cells image I used could not resolve the hostname using “mysql” or whatever you named your database container. This is a small issue, because it should not be assumed that the docker compose network IP would stay the same if the container was to be recreated (like on an update).

I actually found that you could put the mysql sock in a named volume and connect via the sock. It worked for me, and I highly recommend it! Let me know if you need examples.

thanks for your hints,
i’m not against some examples i would like to know how it is done and later i’ll try to add that to the admin guide if it fits.

I use docker-compose also, with docker in swarm mode, and the db container resolves perfectly - not sure if there’s a difference in the two modes.

1 Like

I forgot to mention that on my test installation on macOS that the container did resolve. I’m only running a single node, but I’m also running in network mode: bridge to properly interact with my nginx-proxy container. I’m not sure if that would be the cause for my issue.

In any case, for a single-node installation, I really prefer the mysqld.sock method.

@zayn, here’s an example of my configuration:

# Pydio-cells config for use alongside the nginx-proxy & letsencrypt containers. 
# For deployment on a Portainer single-node instance.

# Required version 2 for Portainer single-node stack (restricted by latest available API)
version: '2'
      image: pydio/cells:latest
      restart: unless-stopped
          # Args for cells
          # Publish on all interfaces inside docker network (doesn't expose on host)

          # Match the FQDN that the end user will see
          CELLS_EXTERNAL: files.example.tld

          # Turn off SSL *management* by Cells container (using Caddy)
          # SSL will still be served by nginx-proxy
          CELLS_NO_SSL: 1

          # Args for nginx-proxy
          VIRTUAL_HOST: files.example.tld
          LETSENCRYPT_HOST: files.example.tld
          LETSENCRYPT_EMAIL: admin@example.tld
          - cells-config:/root/.config/
           # Access the database using the mysqld sock.
          - mariadb-sock:/var/run/mysqld/
      # Using `expose:` here gives the nginx-proxy a clue about how to proxy Cells.
        - "80"
      # The container must be on the `bridge` network in order for nginx-proxy to reach it.
      network_mode: bridge

    image: mariadb:latest
    restart: unless-stopped
        MYSQL_ROOT_PASSWORD: weakpass # Change this password after installation!
        - database:/var/lib/mysql
        # Give access to the mysqld sock via a named container.
        - mariadb-sock:/var/run/mysqld/
    # Since Cells is on the bridge, this one is as well... 
    # but with the current named volume config, it may not need to be.
    network_mode: bridge
    command: [mysqld, --character-set-server=utf8mb4, --collation-server=utf8mb4_unicode_ci]

  # `driver: local` is required for Portainer management. It's also a good practice to specify.
    driver: local
    driver: local
    driver: local

thank you,
i will take a look and use it, once i understand it i’ll add something in the admin guide.