2016-02-27 3 views
0

Я создаю очень основное изображение на моей машинке debian wheezy. Это Dockerfile:docker монтирует хост/каталог в контейнере/в debian wheezy 7.8

FROM ubuntu:trusty 
USER root 

# Activate multiverse repos 
RUN echo 'deb http://archive.ubuntu.com/ubuntu/ trusty universe multiverse' >> /etc/apt/sources.list 
RUN echo 'deb http://security.ubuntu.com/ubuntu trusty-security universe multiverse' >> /etc/apt/sources.list 
RUN echo 'deb http://archive.ubuntu.com/ubuntu/ trusty-updates universe multiverse' >> /etc/apt/sources.list 
RUN apt-get update 

RUN apt-get install -y supervisor 

WORKDIR/

CMD ["/usr/bin/supervisord", "-n"] 

Чтобы создать образ, я использовал docker build -t basic-ubuntu .

Чтобы запустить контейнер, я использовал docker run -d basic-ubuntu

Чтобы перейти в контейнер, я использовал docker exec -i -t <container_id> bash

Когда Я попал в контейнер, я вижу, что корневой каталог контейнера / имеет тот же контент, что и хост. Когда я создаю файл в контейнере, он также создается на хосте. Даже когда я добавляю в Dockerfile RUN apt-get install -y некоторого пакета, который у меня нет на хосте, я не нахожу его в контейнере. Фактически даже переменная $ PATH на контейнере такая же, как и хост.

Вот некоторая информация о моем окр

host$ lsb_release -a 
No LSB modules are available. 
Distributor ID: Debian 
Description: Debian GNU/Linux 7.8 (wheezy) 
Release:  7.8 
Codename:  wheezy 

host$ docker version 
Client: 
Version:  1.10.1 
API version: 1.22 
Go version: go1.5.3 
Git commit: 9e83765 
Built:  Thu Feb 11 19:20:12 2016 
OS/Arch:  linux/amd64 

Server: 
Version:  1.10.1 
API version: 1.22 
Go version: go1.5.3 
Git commit: 9e83765 
Built:  Thu Feb 11 19:20:12 2016 
OS/Arch:  linux/amd64 

монтирует показанный докером инспектировать

"Mounts": [] 

Для полного докер инспектировать след: http://pastebin.com/t4uSu4ZH

Я думаю, что проблема возникает из шаг докера. Потому что сборка и работа кажутся работоспособными.

ответ

1

Я думаю, что проблема исходит от docker exec шага

То есть, конечно, случай, учитывая контейнер здесь, чтобы изолировать вас от хозяина.
(другая файловая система, процесс, корень, пользователь, ...)

Когда вы "Exec баш" в контейнер, вы должны увидеть приглашение:

[email protected]<short_container_id> 

Если вы не видите, что , это потому, что каким-то образом ваш docker exec не выполнялся должным образом.

Если вы видите это, то то, что вы думаете на хосте, на самом деле остается содержимым контейнера.

Также применимо, если используется .
См. "Why do there exist “-i” and “-t” options for the “docker exec” command?".

OP amine подтверждает это дело in the comments:

Issue 8755 ("Docker tty is not a tty with docker exec") означает -t (TTY) не корректно открывает TTY на centos7 (не centos6).

Это происходит, даже если TERM установлен в xterm (не забудьте issue 9299: docker exec не установлен TERM окр когда -t прошло)


Другой вопрос, упомянутый в Op является:

Когда я вернулся к howto install docker in debian, я обнаружил, что в предварительных условиях: «kernel must be 3.10 at minimum» и «These older versions are known to have bugs».
И моя версия ядра debian - 3.2.
Решение состояло в том, чтобы перейти на более новую версию debian с версией ядра выше 3.10.

+0

Нет, я не имею эту проблему: 'MyUser @ myhostname $ Docker Exec -i -t 151961654ce5467cff51c606d6e9886c01008c4a9a81c0076715dfca77318f73 bash' ' корень @ 151961654ce5:/# ' – amine

+0

и создать файл там создает его ваш хозяин тоже? Поскольку вы не установили том (https://docs.docker.com/engine/userguide/containers/dockervolumes/#mount-a-host-file-as-a-data-volume), это маловероятно. – VonC

+0

Да, что происходит, и это совершенно странно, я согласен – amine

0

Я встретил ту же проблему, где docker volume mount function работал неправильно. И это оказалось проблемой версии ядра. После обновления ядра Debian с 3.2 до 3.16 все работает нормально.

$ uname -a 
Linux 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3~bpo70+1 (2016-01-19) x86_64 GNU/Linux 
Смежные вопросы