2015-05-28 10 views
8

na OS X.mysql w pojemniku Döcker nie można uruchomić za pomocą zamontowanego woluminu na os x

Próbuję uruchomić MySQL w kontenerze Döcker przez boot2docker, montując głośność /var/lib/mysql na komputerze, dzięki czemu Mogę mieć trwałe dane mysql. Mam zamiar użyć kontenera danych tylko w przyszłości, ale teraz próbowałem to zrobić za pomocą tej opcji.

używam następującą komendę, aby uruchomić pojemnik:

docker run -v /Users/yash/summers/db:/var/lib/mysql -i -t 'image name'

Folder /Users/yash/summers/db już tam jest.

Mam do czynienia z kwestiami persmission w tym. Korzystanie z wiersza poleceń, jestem w stanie uzyskać dostęp do katalogu, należy utworzyć/usunąć nowe pliki, ale kiedy używam service mysql start, pojawia się następujący błąd:

150528 15:43:43 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 
150528 15:43:43 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead. 
150528 15:43:43 [Note] /usr/sbin/mysqld (mysqld 5.5.43-0ubuntu0.14.04.1) starting as process 909 ... 
150528 15:43:43 [Warning] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive 
150528 15:43:43 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.150528 15:43:43 [Note] Plugin 'FEDERATED' is disabled. 
/usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist 
150528 15:43:43 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. 
150528 15:43:43 InnoDB: The InnoDB memory heap is disabled 
150528 15:43:43 InnoDB: Mutexes and rw_locks use GCC atomic builtins 
150528 15:43:43 InnoDB: Compressed tables use zlib 1.2.8 
150528 15:43:43 InnoDB: Using Linux native AIO 
150528 15:43:43 InnoDB: Initializing buffer pool, size = 128.0M 
150528 15:43:43 InnoDB: Completed initialization of buffer pool 
150528 15:43:43 InnoDB: Operating system error number 13 in a file operation. 
InnoDB: The error means mysqld does not have the access rights to 
InnoDB: the directory. 
InnoDB: File name ./ibdata1 
InnoDB: File operation call: 'create'. 
InnoDB: Cannot continue operation. 
150528 15:43:44 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 

Mam stara się rozwiązać ten problem w ciągu ostatnich 2 dni przeglądanie wielu stron, takich jak this, this i this.

Nie mogę rozwiązać mojego problemu. Myślę, że nie jestem w stanie perfekcyjnie tego, co proponują rozwiązania.

Z mojego zrozumienia wynika, że ​​na tych stronach wymieniono obejścia, które obejmują zmianę identyfikatorów i przewodników, ale uważam, że nie zostały one dobrze wyjaśnione.

Czy ktoś może mi wyjaśnić szczegółowe obejście tego problemu.

Aktualizacja 1: Próbowałem go również przy użyciu pojemnika z danymi również i nadal stoi ten sam problem.

Jestem w stanie uruchomić wszystko dobrze, jeśli nie używam żadnej opcji -v lub --volumes-from, więc myślę, że nie ma problemu w serwerze mysql.

Aktualizacja 2: Dockerfile wykorzystywane do tworzenia danych wyłącznie opakowania:

FROM ubuntu 

RUN mkdir /var/lib/mysql 

VOLUME /var/lib/mysql 
+0

próbowałem z danych wyłącznie pojemnika, i nadal stoi ten sam problem. – Yashasvi

+0

Mam ten sam problem.Poszukujesz również odpowiedzi – JTWebMan

+0

@JTWebMan: Czy masz jakieś rozwiązanie? – Yashasvi

Odpowiedz

-1

I podobnie wpadł na ten temat; Rozwiązałem go przez chmod/chown'ing wewnątrz mojego kontenera danych, np:

FROM ubuntu 

# Create data directory 
RUN mkdir -p /data /var/lib/mysql 
RUN chmod -R 777 /data /var/lib/mysql 
RUN chown -R root:root /data /var/lib/mysql 

# Create /data volume 
VOLUME /data 
VOLUME /var/lib/mysql 

Wierzę, że to działa, ponieważ UFS teraz poprawnie zapisuje uprawnienia zamiast polegać na bezpośrednim z hostem zamontować do tego, co, jak ty” ve odkryte, nie działa na OS X

+0

ta odpowiedź nie działa dla mnie w 1.8.1. Czy ktoś znalazł dobre rozwiązanie? –

+0

@ DanielPayne, aby było jasne, czy korzystasz z 2 kontenerów, jeden dla DB drugi jako czysty kontener "tylko do danych"? – Aaron

+0

Nie byłoby to rozwiązać problem uprawnień? Jeśli tak, czy masz do tego przykładowy kontener danych? –

0

Jeśli korzystasz z opcji docker run -v, to okno dokowane nie będzie modyfikować własności plików. Tak więc właściciel zamontowanego folderu wewnątrz kontenera będzie miał ten sam identyfikator UID, co w systemie hosta (nazwa użytkownika może być inna). Możesz zmienić własność pliku lub katalogu wewnątrz kontenera za pomocą komendy chmod, ale ona również zmienia prawa własności w systemie hosta. Dzięki temu można przygotować poprawne prawo własności do systemu hosta przed uruchomieniem kontenera w doku. Ten przykład pokazuje, jak to działa (spróbuj go w systemie):

Mam katalogu ~/foo, które jest własnością mnie - mój UID jest 1000

~ $ ls -lnd foo 
drwxr-xr-x 2 1001 1000 4096 Nov 24 22:47 foo 

Run doker pojemnik zamontować ~/foo do nich i wyświetlają własność wewnątrz kontenera

~ $ docker run -it --rm -v ~/foo:/tmp/foo busybox ls -ln /tmp 
total 4 
drwxr-xr-x 2 1000  1000   4096 Nov 24 21:47 foo 

Właściciel UID wewnątrz kontenera jest taki sam. Teraz zmieniam prawa własności do katalogu na moim komputerze. ponownie

~ $ sudo chown 1001 foo 

start pojemnik zamontować katalog foo i własności wyświetlacza

~ $ docker run -it --rm -v ~/foo:/tmp/foo busybox ls -ln /tmp 
total 4 
drwxr-xr-x 2 1001  1000   4096 Nov 24 21:47 foo 

Właściciel UID został zmieniony, a także

Ale jest jeden wyjątek. Jeśli spróbujesz zamontować wolumin do katalogu nieistniejącego wówczas doker stworzy ten brakujący Directory automatycznie (ale to jest przestarzałe funkcji, więc nie rób tego) i ten katalog będzie być tworzone z UID 0. Spróbuj:

~ $ docker run -it --rm -v ~/foo:/tmp/bar/foo busybox ls -ln /tmp 
total 4 
drwxr-xr-x 3 0  0    4096 Nov 24 22:10 bar 
3

Istnieją dwa różne rozwiązania.

  1. Rozwiązanie nr 1. Z Dockerfile

    (nie podoba mi się to, bo ja wolę oficjalne zdjęcie z Docker Hub bez zmian)

    Dodaj RUN usermod -u 1000 mysql do pliku Docker do Set ID 1000 dla użytkownika "mysql" (ten sam identyfikator jak wewnątrz maszyny-dokowania).

  2. Rozwiązanie # 2. Z plikiem my.cnf.

    Nadal używam własnego pliku konfiguracyjnego. Preferuję to rozwiązanie. Mamy alredy mieć roota o ID 1000, ponieważ od tego my można uruchomić MySQL z tym użytkownikiem:

    • my.cnf

      Główny wiersz jest user = root (można użyć sed zmienić tylko ten wiersz w pliku. wolę zamontować cały plik)

      [client] 
      port  = 3306 
      socket  = /var/run/mysqld/mysqld.sock 
      default-character-set = utf8 
      
      [mysqld_safe] 
      pid-file = /var/run/mysqld/mysqld.pid 
      socket  = /var/run/mysqld/mysqld.sock 
      nice  = 0 
      
      [mysqld] 
      user  = root 
      pid-file = /var/run/mysqld/mysqld.pid 
      socket  = /var/run/mysqld/mysqld.sock 
      port  = 3306 
      basedir  = /usr 
      datadir  = /var/lib/mysql 
      tmpdir  = /tmp 
      lc-messages-dir = /usr/share/mysql 
      explicit_defaults_for_timestamp 
      init_connect='SET collation_connection = utf8_unicode_ci' 
      init_connect='SET NAMES utf8' 
      character-set-server=utf8 
      collation-server=utf8_unicode_ci 
      skip-character-set-client-handshake 
      
      # Instead of skip-networking the default is now to listen only on 
      # localhost which is more compatible and is not less secure. 
      #bind-address = 127.0.0.1 
      
      #log-error = /var/log/mysql/error.log 
      
      # Recommended in standard MySQL setup 
      sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES 
      
      # Disabling symbolic-links is recommended to prevent assorted security risks 
      symbolic-links=0 
      
      # * IMPORTANT: Additional settings that can override those from this file! 
      # The files must end with '.cnf', otherwise they'll be ignored. 
      # 
      !includedir /etc/mysql/conf.d/ 
      
    • Zmień d EFAULT my.cnf z tego pliku:

      doker run -to -v -v ./my.cnf::/etc/mysql/my ./mysql/var/lib/mysql:/var/lib/mysql .cnf MariaDB: 10.0.22

Powiązane problemy