Não foi possível montar a pasta docker no host usando o docker-compose

Aqui eu criei o container docker que usa a mariadbimagem e criei três volumes, como abaixo.

docker-compose.yml

version: '2.0'

services:
  mariadb:
  image: mariadb:latest
  restart: always
  container_name: mariadb
  environment:
    - MYSQL_ROOT_PASSWORD=root
    - MYSQL_DATABASE=testdb
  ports:
   - 3307:3306
  volumes:
   - ./database:/var/lib/mysql
   - ./_conf/mariadb.cnf:/etc/mysql/my.cnf:ro
   - ./logs:/var/log/mysql

Os dois primeiros volumes funcionam com êxito, mas não consigo encontrar os arquivos mariadb-logs na logspasta. Parece logspasta mostrando em branco no host, bem como no recipiente (/ var / log / mysql). Acho pasta host substituir no sistema de arquivos docker.

Se eu remover esse volume ( ./logs:/var/log/mysql) da janela de encaixe, os arquivos de log serão exibidos no contêiner.

Meu plano é montar a /var/log/mysql/pasta na máquina local.

Obrigado !

Se você usa o CentOS 7 (como eu tenho). Você pode ter o SELinux ativado por padrão.check https://www.rootusers.com/how-to-enable-or-disable-selinux-in-centos-rhel-7/ ou montado assim:

  volumes:
   - ./database:/var/lib/mysql:Z
   - ./_conf/mariadb.cnf:/etc/mysql/my.cnf:Z
   - ./logs:/var/log/mysql:Z

Se você estiver executando uma distribuição baseada em RedHat, por exemplo, Fedora ou CentOS, poderá ter o SELinux ativado por padrão. Você pode permitir automaticamente que seus contêineres acessem arquivos nos hosts montando com a :Zopção, da seguinte maneira:

  volumes:
   - ./database:/var/lib/mysql:Z
   - ./_conf/mariadb.cnf:/etc/mysql/my.cnf:Z
   - ./logs:/var/log/mysql:Z

Se /var/log/mysql:/var/log/mysqlfor definido como um volume, o conteúdo que residir no contêiner /var/log/mysql/será armazenado na /var/log/mysql/pasta no host.

Pode ser possível que não seja possível montar o /var/lib/mysqlSElinux ou a armadura do aplicativo está impedindo isso.

https://hub.docker.com/_/mysql/

Observe que usuários em sistemas host com o SELinux ativado podem ver problemas com isso. A solução atual é atribuir o tipo de política SELinux relevante ao novo diretório de dados para que o contêiner tenha permissão para acessá-lo:

$ chcon -Rt svirt_sandbox_file_t /my/own/datadir