Docker под Windows для разработки, разбор подводных камней
Данная публикация является разбором особенностей контейнерной виртуализации Docker под системой Windows.
Она не претендует на роль исчерпывающей и по мере необходимости будет обновляться и дополняться.
За практическим руководством с нуля советую обратиться к этой публикации.
Содержание
Предварительные настройки
Контейнерная виртуализация или виртуализация на уровне операционной системы Docker нативно работает только на дистрибутивах Linux и FreeBSD (экспериментально).
На Windows вам понадобится гостевая Linux система либо специальная минималистичная виртуальная машина с ядром Linux от разработчиков Docker, которая и ставится из коробки.
Само собой разумеется, что вы включили виртуализацию у себя в BIOS/UEFI
Пункт настройки может называться по-разному: VT-x, VT-d, Intel VT, AMD-V, Virtualization Technology.
Еще одним минимальным системным требованием будет разрядность системы x64 и версия не ниже Windows 7 Pro.
Выбор между Docker Toolbox on Windows или Docker for Windows
Сборка включается в себя сам docker, утилиту docker-compose, утилиту для работы с виртуальной машиной docker-machine и клиент Kitematic.
Используется виртуальная машина (по умолчанию на VirtualBox) с минималистичным Linux окружением.
Позже для новых операционных систем выпустили Docker for Windows и Docker for Mac, которая на текущий момент является актуальной версией и продолжает развиваться.
Выбор между версиями не сложный:
— Если у вас Windows 10 x64 Pro, Enterprise или Education то включаем службу Hyper-V и ставим Docker for Windows.
Заметьте, что после включения службы Hyper-V пропадет возможность запускать и создавать x64 виртуальные машины на VirtualBox.
— Если же у вас другая версия Windows(7 Pro, 8, 8.1, 10 Home) то ставим VirtualBox и Docker Toolbox on Windows.
Несмотря на то, что Docker Toolbox разработчиками признан устаревшим работа с ним слабо отличается от Docker for Windows.
Вместе с установкой Docker Toolbox будет создана виртуальная машина.
В самом VirtualBox можно будет добавить оперативной памяти и ядер процессора на ваше усмотрение.
Windows контейнеры и Linux контейнеры
Docker for Windows предоставляет возможность переключать контейнеризацию между Linux и Windows версией.
В режиме Windows контейнеризации вы можете запускать только Windows приложения.
Замечу, что на май 2018 года в официальном Docker Hub существует всего 13 образов для Windows.
После включения Windows контейнеризации не забудьте добавить внешнюю сеть.
В конфигурационном файле docker-compose.yml это выглядит так:
Особенности монтирования папок
На примонтированных volume-ах не кидаются события файловой системы, поэтому inotify-tools не работает.
Спасибо пользователю eee
Если вы разрабатываете свой проект и пользуетесь docker-compose вне домашней папки то вам нужно будет проделать некоторые манипуляции.
Используя Docker for Windows для монтирования нового диска у вашего локального пользователя обязательно должен стоять пароль, который будет использоваться для доступа к shared папки.
Особенность заключается в том, что монтируемые внутрь контейнера диск будет монтироваться как от удаленной машины //10.0.75.1/DISK_DRIVE по протоколу SMB.
Для Docker Toolbox диски монтируются в самом VirtualBox на вкладке «Общие папки»
Пример для диска «D»:
Права доступа к монтируемым файлам и папкам
Как бы вам не хотелось, но для всех примонтированных из хост-машины файлов и папок будут стоять права 755 (rwx r-x r-x) и поменять их вы не сможете.
Остро встает вопрос при монтировании внутрь файла закрытого SSH ключа, права на который должны быть только у владельца(например 600).
В данном случае либо генерируют ключ при создании образа, либо прокидывают сокет ssh-agent с хост-машины.
Монтирование с хост-машины или volume
Монтирование внутрь контейнера происходит с использованием сети и протокола SMB, следовательно, внутри контейнера диск «D:\» будет примонтирован из источника //10.0.75.1/D
Использование volume внутри контейнера отображается как монтирование локального диска /dev/sda1, что влияет на скорость работы.
Простым тестом копирование файла на обычном HDD скорость работы получилась следующая:
Такая разница в скорости скорее всего связана с тем, что в volume данные сбрасываются на диск постепенно, задействуя кеш в ОЗУ.
Особенности разметки диска GPT и MBR
Данный пункт не является истинной так как опровергающей или подтверждающей информации в интернете найти не смог.
Если на хост-машине таблица разделов MBR, то контейнер с MySQL/MariaDB может упасть с ошибкой:
InnoDB: File ./ib_logfile101: ‘aio write’ returned OS error 122. Cannot continue operation
По умолчанию в базе данных включеён параметр innodb_use_native_aio, отвечающий за асинхронный ввод/вывод и его надо будет выключить.
Данная проблема также встречается на некоторых версиях MacOS.
Docker Toobox to Windows
Главное правило: начинать работу с запуска ярлыка на рабочем столе «Docker Quickstart Terminal», это решает 80% проблем.
— Бывает возникают проблемы с отсутствия переменных окружения, решается командой:
— Если все же возникают проблемы из разряда «docker: error during connect», необходимо выполнить:
Название Docker Machine по умолчанию default.
Docker Swarm
Ни в Docker for Mac, ни в Docker for Windows — нет возможности использовать запущенные демоны в качестве клиентов кластера (swarm members).
Спасибо пользователю stychos
Проблемы с кодировкой
Используя Docker Toolbox(на Docker for Windows не удалось воспроизвести) нашлась проблема с тем, что русские комментарии в docker-compose.yml файле приводили к ошибке:
Полезные ссылки
Заключение
Особенности работы с Docker контейнеризацией на системе Windows не отличается от работы на Linux за исключение разобранных выше.
В статье я умышленно не упомянул заметно низкую скорость работы контейнеров и overhead используя систему Windows как само собой разумеющееся.
Буду рад услышать ваши отзывы. Не стесняйтесь предлагать улучшения или указывать на мои ошибки.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Locating data volumes in Docker Desktop (Windows)
I’m trying to learn docker at the moment and I’m getting confused about where data volumes actually exist.
I’m using Docker Desktop for Windows. (Windows 10)
In the docs they say that running docker inspect on the object will give you the source:https://docs.docker.com/engine/tutorials/dockervolumes/#locating-a-volume
however I don’t see this, I get the following:
Can anyone help me? I just want to know where my data volume actually exists is it on my host machine? If so how can i get the path to it?
7 Answers 7
Your volume directory is /var/lib/docker/volumes/blog_postgres-data/_data , and /var/lib/docker usually mounted in C:\Users\Public\Documents\Hyper-V\Virtual hard disks . Anyway you can check it out by looking in Docker settings.
You can refer to these docs for info on how to share drives with Docker on Windows.
BTW, Source is the location on the host and Destination is the location inside the container in the following output:
Updated to answer questions in the comment:
My main curiosity here is that sharing images etc is great but how do I share my data?
Actually volume is designed for this purpose (manage data in Docker container). The data in a volume is persisted on the host FS and isolated from the life-cycle of a Docker container/image. You can share your data in a volume by:
Mount Docker volume to host and reuse it
docker run -v /path/on/host:/path/inside/container image
Then all your data will persist in /path/on/host ; you could back it up, copy it to another machine, and re-run your container with the same volume.
Create and mount a data container.
Create a data container: docker create -v /dbdata —name dbstore training/postgres /bin/true
Run other containers based on this container using —volumes-from : docker run -d —volumes-from dbstore —name db1 training/postgres , then all data generated by db1 will persist in the volume of container dbstore .
For more information you could refer to the official Docker volumes docs.
Simply speaking, volumes is just a directory on your host with all your container data, so you could use any method you used before to backup/share your data.
can I push a volume to docker-hub like I do with images?
No. A Docker image is something you can push to a Docker hub (a.k.a. ‘registry’); but data is not. You could backup/persist/share your data with any method you like, but pushing data to a Docker registry to share it does not make any sense.
Yes, as posted above 🙂
When running linux based containers on a windows host, the actual volumes will be stored within the linux VM and will not be available on the host’s fs, otherwise windows running on windows => C:\ProgramData\Docker\volumes\
Update: Not applicable for Docker running on WSL.
If you have wsl2 enabled, u can find it in file explorer under \\wsl$\docker-desktop\mnt\host\wsl\docker-desktop-data\data\docker
Mounting any NTFS based directories did not work for my purpose (MongoDB — as far as I’m aware it is also the case for Redis and CouchDB at least): NTFS permissions did not allow necessary access for such DBs running in containers. The following is a setup with named volumes on HyperV.
The following approach starts an ssh server within a service, setup with docker-compse such that it automatically starts up and uses public key encryption between host and container for authorization. This way, data can be uploaded/downloaded via scp or sftp.
The full docker-compose.yml for a webapp + mongodb is below, together with some documentation on how to use ssh service:
this is unrelated, but for a fully working example, before any docker-compose call the following script needs to be run:
Update: Please note that you can also just use docker cp nowadays, so the sshd container outlined above is probably not necessary anymore, except if you need remote access to the file system running in a container under a Windows host.
I’m on Windows + WSL 2 (Ubuntu 18.04), I found my Docker volumes in this location, type in the Windows file explorer :
You will have one direcotory per volume.
Each container has its own filesystem which is independent from the host filesystem. If you run your container with the -v flag you can mount volumes so that the host and container see the same data (as in docker run -v hostFolder:containerFolder).
The first output you printed describes such a mounted volume (hence mounts) where «/var/lib/docker/volumes/fac362. 80535/_data» (host) is mounted to «/webapp» (container).
I assume you did not use -v hence the folder is not mounted and only accessible in the container filesystem which you can find in «/var/lib/docker/volumes/blog_postgres-data/_data». This data will be deleted if you remove the container (docker -rm) so it might be a good idea to mount the folder.
As to the question where you can access this data from windows. As far as I know, docker for windows uses the bash subsystem in Windows 10. I would try to run bash for windows10 and go to that folder or find out how to access the linux folders from windows 10. Check this page for a FAQ on the linux subsystem in windows 10.
Update: You can also use docker cp to copy files between host and container.
How to mount a single file in a volume
I am trying to dockerize a PHP application. In the dockerfile, I download the archive, extract it, etc.
Everything works fine. However, if a new version gets released and I update the dockerfile, I have to reinstall the application, because the config.php gets overwritten.
So I thought I can mount the file as a volume, like I do with the database.
I tried it two ways, with a volume and a direct path.
Which results in the error:
And I tried it with a given path, as a mounted volume.
However, both ways are not working. With the mounted volume, I see that upload gets created.
But then it fails with:
/var/www/html/config.php\» caused \»not a directory\»»»
Docker creates the upload folder and then a config.php folder. Not a file.
Or is there another way to persist the config?
14 Answers 14
TL;DR/Notice:
If you experience a directory being created in place of the file you are trying to mount, you have probably failed to supply a valid and absolute path. This is a common mistake with a silent and confusing failure mode.
File volumes are done this way in docker (absolute path example (can use env variables), and you need to mention the file name) :
If you fire the docker-compose from /src/docker/myapp folder
I had been suffering from a similar issue. I was trying to import my config file to my container so that I can fix it every time I need without re-building the image.
I mean I thought the below command would map $(pwd)/config.py from Docker host to /root/app/config.py into the container as a file.
However, it always created a directory named config.py , not a file.
while looking for clue, I found the reason(from here)
If you use -v or —volume to bind-mount a file or directory that does not yet exist on the Docker host, -v will create the endpoint for you. It is always created as a directory.
Therefore, it is always created as a directory because my docker host does not have $(pwd)/config.py .
Even if I create config.py in docker host. $(pwd)/config.py just overwirte /root/app/config.py not exporting /root/app/config.py .
Use mount ( —mount ) instead volume ( -v )
Example:
Ensure /tmp/a.txt exists on docker host
For anyone using Windows container like me, know that you CANNOT bind or mount single files using windows container.
The following examples will fail when using Windows-based containers, as the destination of a volume or bind mount inside the container must be one of: a non-existing or empty directory; or a drive other than C:. Further, the source of a bind mount must be a local directory, not a file.
net use z: \\remotemachine\share
docker run -v z:\foo:c:\dest .
docker run -v \\uncpath\to\directory:c:\dest .
docker run -v c:\foo\somefile.txt:c:\dest .
docker run -v c:\foo:c: .
docker run -v c:\foo:c:\existing-directory-with-contents .
It’s hard to spot but it’s there
The way that worked for me is to use a bind mount
You need to use the «long syntax» to express a bind mount using the volumes key: https://docs.docker.com/compose/compose-file/#long-syntax-3
As of docker-compose file version 3.2, you can specify a volume mount of type «bind» (instead of the default type «volume») that allows you to mount a single file into the container. Search for «bind mount» in the docker-compose volume docs: https://docs.docker.com/compose/compose-file/#volumes
In my case, I was trying to mount a single «.secrets» file into my application that contained secrets for local development and testing only. In production, my application fetches these secrets from AWS instead.
If I mounted this file as a volume using the shorthand syntax:
Docker would create a «.secrets» directory inside the container instead of mapping to the file outside of the container. My code would then raise an error like «IsADirectoryError: [Errno 21] Is a directory: ‘.secrets'».
I fixed this by using the long-hand syntax instead, specifying my secrets file using a read-only «bind» volume mount:
Now Docker correctly mounts my .secrets file into the container, creating a file inside the container instead of a directory.