Docker volumes примеры windows

Содержание
  1. Adam the Automator
  2. How to Create (and Manage) Docker Volumes on Windows
  3. Adam Bertram
  4. Storing Persistent Data
  5. Enumerating Data in Docker Volumes
  6. Creating Docker Volumes
  7. Inspecting Docker Volumes
  8. Deleting Docker Volumes
  9. Summary
  10. Хранилище Docker-контейнеров
  11. Введение
  12. Куда отправляются данные, когда они записываются в контейнер?
  13. Тома Docker
  14. Варианты Использования Тома Docker
  15. Сохранение данных за пределами срока службы контейнера
  16. Совместное Использование Данных Между Контейнерами
  17. Другие Типы Монтирования
  18. Bind Mount
  19. Tempfs Mount
  20. Драйвера Томов
  21. Вывод
  22. Docker под Windows для разработки, разбор подводных камней
  23. Содержание
  24. Предварительные настройки
  25. Выбор между Docker Toolbox on Windows или Docker for Windows
  26. Windows контейнеры и Linux контейнеры
  27. Особенности монтирования папок
  28. Права доступа к монтируемым файлам и папкам
  29. Монтирование с хост-машины или volume
  30. Особенности разметки диска GPT и MBR
  31. Docker Toobox to Windows
  32. Docker Swarm
  33. Проблемы с кодировкой
  34. Полезные ссылки
  35. Заключение
  36. Основы Docker за Х часов и Y дней
  37. 0. Вступление
  38. 1. Теория
  39. Основные термины
  40. Вкратце о том, как работает билдинг образов
  41. 2. Практика
  42. Pitfalls

Adam the Automator

How to Create (and Manage) Docker Volumes on Windows

Adam Bertram

Read more posts by this author.

Docker volumes are the preferred way of handling persistent data created by and used by Docker containers. Let’s take a look at how this works by covering how to create Docker volumes on Windows. You’ll also learn how to manage them too!

This blog post has a companion video created by TechSnips contributor, Matt McElreath. Feel free to have a watch or, if you prefer text, read on!

Storing Persistent Data

If you want to store persistent data for containers, there are a couple of options. First, I’ll show you how to use a bind mount. I’m currently in a folder called data on my C:\. If I list the contents of this folder, you can see that I have five text files.

If I want to make this folder available to a container, I can mount it when starting the container.

For this, I’m going to specify the C:\shareddata folder. Then I’ll specify the Windows server core image and finally, I’ll specify that I want to run PowerShell once I’m inside the container.

Now that I’m inside the new container, if I list the contents of C:\, you can see that I have a shareddata folder.

Let’s go into that folder and list the contents. Here are my five test files that are located on my container host.

I can also create files in this folder, which will be available to other containers or my container host. Let’s go ahead and run new item to create a file called containertest.

Enumerating Data in Docker Volumes

Now let’s list the contents of the data folder again from my container host.

We can see the new file that was created from inside the container called containertest. Bind mounts have some limited functionality, however, so volumes are the preferred way to accomplish what we are trying to do. To get started with volumes, we can run the same command to start up a container, but this time with a couple of small differences. Where we specified the volume, instead of using the path on the container hosts’ file system, I’m going to use the word hostdata as the name of a volume I want to create and use.

From inside the new container, if I list the contents of C:\, you can see again that I have a folder called shareddata.

If I list the contents of that folder, it is currently empty because we created a blank volume. Now let’s run Ctrl-P-Q which will take us out of the running container, but keep it running in the background.

If I run docker ps we can see our running container.

Creating Docker Volumes

Another way to create a volume is to use the docker volume create command. If you don’t specify a name, docker will give it a name which is a long list of random characters. Otherwise, you can specify a name here. I’m going to call this volume logdata. Now we can see it is in the list when we list the volumes again.

You’ll now mount that to a new container. Use docker run again and for the volume specify the volume that just created and mount it to c:\logdata.

From inside the container, go into the logdata folder and create a couple of files. Right now, there are no files in this directory, so go ahead and create some.

Now I have two log files in this directory.

Run Ctrl-P-Q again to exit this container while it is still running. While that container’s running, start up a new container with the same volume mounted.

If we run a listing on the logdata folder in the new container we can see the two log files being shared.

Now, exit this container. You should still have one running container and two exited containers.

Now stop all running containers, then run docker rm to remove all exited containers.

List the volumes again. The logdata volume is still available to be mounted to future containers.

Inspecting Docker Volumes

Let’s open that folder using Invoke-Item and have a look. Under the logdata folder, there’s a folder called data. If we open that, we can see the files that were created from the container earlier.

Deleting Docker Volumes

Now if I list the volumes, logdata is no longer there.

Finally, we can use prune to remove all unused local volumes. This will delete all volumes that are not mounted to a running or stopped container.

You want to be careful with this command, so there’s a warning and a prompt to make sure that you are sure that you want to do this. If I type Y and hit enter, it will show me which volumes were deleted.

And if I list my volumes again you can see that they have all been deleted.

Summary

In this blog post, you should have gotten a good overview of managing Docker volumes in Windows. Docker is a great container platform. With its support for Windows and your newfound skills at managing Docker volumes, you will be unstoppable!

Источник

Хранилище Docker-контейнеров

Введение

Виртуализация на основе процессов Docker имеет много преимуществ, особенно в сочетании с преимуществами слоев образов. Это позволяет невероятно быстро производить генерацию контейнеров и использовать легкий вес ресурсов. Однако одним из побочных эффектов эфемерной модели процесса Docker является то, что вы должны обязательно планировать, когда и как вы хотите сохранить постоянные данные. В этом руководстве мы познакомим вас с собственным решением Docker для этой проблемы: Docker volumes (тома Docker).

Читайте также:  Windows advanced menu options

Куда отправляются данные, когда они записываются в контейнер?

Предположим, что мы заходим в оболочку внутри busybox контейнера:

Затем, давайте запишем некоторые данные, скажем, в /tmp:

echo «Data!» > /tmp/data
cat /tmp/data

Мы видим, что данные определенно записываются. Но куда же на самом деле идут эти данные? Как мы узнали ранее, образы Docker состоят из слоев, уложенных друг на друга, чтобы привести к окончательному образу. Каждый из этих слоев содержит данные, измененные в такой операции, как установка инструмента, добавление исходного кода и т.д. Каждый из этих слоев становится доступным только для чтения после его создания. Когда контейнер создается из образа, тонкий R/W слой добавляется поверх предыдущих слоев образа. Этот слой обрабатывает все вызовы записи из контейнера, которые, в противном случае, были бы направлены на слои ниже, доступные только для чтения. Помните, что контейнеры эфемерны по своей природе. Они предназначены для того, чтобы иметь определенную продолжительность жизни и умереть в какой-то момент, как и любой процесс. Тонкий слой чтения/записи также эфемерен — он исчезает вместе с контейнером. Таким образом, любые записи, которые мы выполняем в контейнере, ограничены временем жизни этого контейнера. Они исчезнут, когда контейнер будет уничтожен. Это очевидное ограничение, которое не способствует хранению статусной информации. Итак, как разработчики и администраторы работают с этим? Они используют Тома Docker.

Тома Docker

Тома Docker — это способ создания постоянного хранилища для контейнеров Docker. Тома Docker не привязаны к времени жизни контейнера, поэтому сделанные в них записи не исчезнут, как это произойдет с контейнером. Они также могут быть повторно подключены к одному или к нескольким контейнерам, чтобы можно было обмениваться данными и подключать новые контейнеры к существующему хранилищу. Тома Docker работают путем создания каталога на главной машине и последующего монтирования этого каталога в контейнер (или в несколько контейнеров). Этот каталог существует вне многослойного образа, который обычно содержит контейнер Docker, поэтому он не подчиняется тем же правилам (только для чтения и т. д.).

Давайте создадим том Docker и посмотрим его в действии:

docker volume create

Простой вызов docker volume create позволит создать новый том. Если мы проверим этот том, мы можем увидеть, где он живет на хост-файловой системе:

docker volume inspect 1d358c3fc3750f98345713eee5c294dee526a3f5d0bd41a0ff4d117218c4af73

[
<
«CreatedAt»: «2020-05-17T16:25:30Z»,
«Driver»: «local»,
«Labels»: <>,
«Mountpoint»: «/var/lib/docker/volumes/1d358c3fc3750f98345713eee5c294dee526a3f5d0bd41a0ff4d117218c4af73/_data»,
«Name»: «1d358c3fc3750f98345713eee5c294dee526a3f5d0bd41a0ff4d117218c4af73»,
«Options»: <>,
«Scope»: «local»
>
]

echo «Hello!» > /data/hello

Эти данные видны снаружи контейнера, в пути монтирования тома на хосте:

DRIVER VOLUME NAME
local 1d358c3fc3750.
local c63a0af5c8282.
local testdata

Это означает, что мы можем использовать этот том снова с другим контейнером или даже несколькими контейнерами. Давайте проверим это прямо сейчас. Во-первых, подключите том к busybox контейнеру:

Внутри контейнера давайте напечатаем информацию о системе, а затем запишем на том:

Linux 7e299450b997 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64 GNU/Linux

Теперь запустите второй busybox контейнер, работающий одновременно с первым:

Нам доступны данные, которые были записаны в первом контейнере:

Linux c5bf9ca04d3a 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64 GNU/Linux
Hello 2

Это подчеркивает еще одно из преимуществ томов Docker: совместное использование данных между контейнерами.

Варианты Использования Тома Docker

Есть много допустимых вариантов использования для контейнеров Docker, но здесь мы рассмотрим два наиболее распространенных. Для каждого из этих примеров давайте представим, что у нас есть простое приложение, которое работает и собирает данные с некоторых датчиков погоды. Мы хотим собрать кучу метеорологических показателей, сохранить их, а затем использовать их снова в будущем. Давайте назовем наше тестовое приложение WeatherMon.

Сохранение данных за пределами срока службы контейнера

Совместное Использование Данных Между Контейнерами

Предположим, что мы уже используем контейнер WeatherMon некоторое время и собрали довольно много данных. Мы хотим проанализировать эти данные, чтобы определить информацию, такую как средняя температура за день, или какая неделя в месяце имела самую высокую среднюю влажность. Используя тома Docker, мы можем смонтировать существующий том в новый контейнер, WeatherMon-Analytics. Этот новый контейнер может считывать данные, не прерывая их сбор контейнером WeatherMon. Затем он может выполнять аналитику, которую мы хотим, и хранить эту информацию в том же томе или в другом томе, если это необходимо.

Другие Типы Монтирования

Есть два других типа томов Docker, которые мы еще не обсуждали: bind mount и tempfs mount.

Bind Mount

Tempfs Mount

Задача tempfs монтирования состоит в том, чтобы обеспечить доступное для записи расположение, которое специально не сохраняет информацию после окончания срока службы контейнера. Возможно, вы думаете: «зачем это нужно?” В контейнере, который не имеет подключенного тома, все записи идут в тонкий слой R/W, вставленный во время выполнения. Любая запись, направленная на этот слой, влияет на файловую систему, поскольку эти записи выполняются на базовом хосте. Обычно это не является проблемой, если вы не пишете значительные объемы одноразовых данных (таких как журналы). В этом случае вы можете наблюдать снижение производительности, так как файловая система должна обрабатывать все эти вызовы write. tempfs монтирование было создано для предоставления контейнерам временного пути записи, который не влияет на операции файловой системы. В частности, tempfs это эфемерное монтирование, которое записывается непосредственно в память. Этот том можно создать с помощью —tempfs аргумента.

Драйвера Томов

По умолчанию тома хранят информацию о базовой хост-системе. Docker также имеет концепцию, называемую драйверами томов, которая позволяет указать, как и где хранить тома. Например, вы можете хранить том Docker внутри корзины Amazon S3. Это может быть удобно, если вы хотите, чтобы информация сохранялась не только за пределами срока службы контейнера, но и за пределами срока службы хоста.

Вывод

Все обсуждаемые здесь понятия разбиты на гораздо более подробные части в документации Docker о хранилище. Примеры использования каждого типа монтирования и более подробное введение в концепцию драйверов томов доступны по этой ссылке.

Источник

Docker под Windows для разработки, разбор подводных камней

Данная публикация является разбором особенностей контейнерной виртуализации Docker под системой Windows.

Она не претендует на роль исчерпывающей и по мере необходимости будет обновляться и дополняться.

За практическим руководством с нуля советую обратиться к этой публикации.

Содержание

Предварительные настройки

Контейнерная виртуализация или виртуализация на уровне операционной системы Docker нативно работает только на дистрибутивах Linux и FreeBSD (экспериментально).
На Windows вам понадобится гостевая Linux система либо специальная минималистичная виртуальная машина с ядром Linux от разработчиков Docker, которая и ставится из коробки.
Само собой разумеется, что вы включили виртуализацию у себя в BIOS/UEFI
Пункт настройки может называться по-разному: VT-x, VT-d, Intel VT, AMD-V, Virtualization Technology.

Читайте также:  Nclayer не запускается windows 10

Еще одним минимальным системным требованием будет разрядность системы 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_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 как само собой разумеющееся.

Буду рад услышать ваши отзывы. Не стесняйтесь предлагать улучшения или указывать на мои ошибки.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Источник

Основы Docker за Х часов и Y дней

0. Вступление

Цель данной статьи собрать в небольшую кучку основную информацию, минимально достаточную для того, чтобы начать работать с докер на ежедневной основе и удалить с рабочей машины локально установленные apache, mysql, virtualenv, python3, mongodb, memchaced, redis, php5, php7 и весь остальной зоопарк, который мы используем при разработке, и который зачастую еще и конфликтует между собой от версии к версии.

А еще я в автобусе и ближайшие 7 часов мне все равно делать будет нечего. Ну и вдобавок я наконец-то соберу в одном месте ссылки и команды, за которыми мне самому периодически приходится лезть в документацию, например — как на маке добавить IP алиас к локалхосту: sudo ifconfig lo0 alias 10.200.10.1/24 (зачем это надо будет сказано позже)

Статья называется так, как называется, потому что я не смог более-менее точно подсчитать сколько нужно времени на поставленную задачу. У меня на это ушло примерно 6 часов в течение 3 дней. Во многом, потому что в тот момент я работал фулл тайм в офисе и осваивал докер, так сказать, без отрыва от производства.

У вас может уйти меньше дней или больше часов, зависит от того, как интенсивно вы будете вникать.

Но мое личное мнение – лучше все же не пытаться “ворваться” за один день. Просто потому что если Вы никогда не имели с этим дело, то в конце первого дня у вас будет где-то вот такая голова

И лучше в этот момент остановиться, переварить информацию, может даже поспать.

1. Теория

Если Вы ранее имели дело с виртуальными машинами и такими инструментами как virtualbox, vmware, vagrant и подобными штуками – лучше забудьте о них.
Лично моей ошибкой была попытка работать с докер как с виртуальной машиной. Докер – средство виртуализации процессов, а не систем. Важное правило – каждому процессу свой виртуальный контейнер.

Читайте также:  Mac dock for windows 10

Контейнер следует воспринимать как отдельный процесс и наоборот. Например не следует пихать в один контейнер mysql и redis. Или еще хуже всю связку apache+php+mysql.

Основные термины

Image (образ) – собранная подсистема, необходимая для работы процесса, сохраненная в образе.
Container (контейнер) – процесс, инициализированный на базе образа. То есть контейнер существует только когда запущен. Это как экземпляр класса, а образ это типа класс. Ну я думаю идея понятна.
Host (хост) – среда, в которой запускается докер. Проще говоря – ваша локальная машина.
Volume – это дисковое пространство между хостом и контейнером. Проще – это папка на вашей локальной машине примонтированная внутрь контейнера. Меняете тут меняется там, и наоборот, миракл.
Dockerfile – файл с набором инструкций для создания образа будущего контейнера
Service (сервис) – по сути это запущенный образ (один или несколько контейнеров), дополнительно сконфигурированный такими опциями как открытие портов, маппинг папок (volume) и прочее. Обычно это делается при помощи docker-compose.yml файла.
Docker-compose (докер-композ, чаще композер, но не путать с php composer) – тулза, облегчающая сборку и запуск системы состоящей из нескольких контейнеров, связанных между собой.
Build (билд, билдить) – процесс создания образа из набора инструкций в докерфайле, или нескольких докерфайлов, если билд делается с помощью композера
В данной статье позже (завтра) я опишу процесс сборки связки nginx+mysql+php7-fpm с примерами и описаниями dockerfile и docker-compose файлов.

Вкратце о том, как работает билдинг образов

Сначала есть docker hub, это такой репозиторий, куда все желающие самоутвердиться публикуют свои собственные сборки образов. За это некоторым большое спасибо, а некоторым нет, все как и в любой другой свалке пакетов.

Обычно докерфайл начинается с инструкции FROM, которая указывает с какого пакета/образа из хаба начать.

Далее обычно идет инструкция maintainer, задача которой увековечить имя создателя очередного гениального творения.

Затем наиболее часто встречающиеся команды:
RUN – выполняет команду внутри образа.
ADD – берет файлы с хоста и кладет внутрь образа.
А также COPY, EXPOSE, ENTRYPOINT, CMD — обо всем этом Вы узнаете в процессе.

Сейчас внимание. Докер выполняет инструкции из докерфайла последовательно поверх предыдущего результата. Таким образом организовано хранение кеша.
Не поняли? Сейчас покажу. Вот простейший докерфайл:

Как докер его билдит:

ID я тут написал условные, но важно помнить, что идентификаторы этих “промежуточных” образов напрямую связаны с самими инструкциями, с файлами которые добавляются инструкцией ADD и с ID родительского образа. То есть фактически перед выполнением каждого шага сначала вычисляется ID (хеш) образа, поиск такого ID в локальном кеше, и только если такого ID в кеше нет, тогда выполняется шаг и сохраняется в кеш, иначе – используется образ из кеша.

А также это значит, что если вы решите поменять команду например run apt-get install nginx на другую, то Хеш(ID) инструкции изменится и весь дальнейший кеш после этого использоваться не будет. Потому не удивляйтесь если после изменения одной буквы в имени maintainer’а у вас вся сборка будет пересобираться от самого начала.

Также исходя из описанного сценария выполнения команд становится понятно, почему не имеет смысла в инструкциях выполнять команды ничего не сохраняющие после своего выполнения – частый вопрос на stackoverflow — “я запустил что-то, а в следующей инструкции оно не запущено”. Например кто-то хочет активировать source env/bin/activate и в следующей инструкции выполнить pip install

или другой пример – запустить монгодб и в следующей инструкции создать юзера/базу или выполнить импорт базы из файла (есть причины почему лучше так не делать, но сейчас не об этом)

RUN source /app/env/bin/activate \
&& pip install something

Думаю для начала работы этой теории вполне достаточно.

2. Практика

Перед началом думаю следует пойти немного передохнуть и сделать себе чайку.
А когда вернетесь, сначала установите себе Docker и Docker Compose.

Небольшое отступление для тех, кто читает это под виндой.

Итак, на данном этапе у вас уже установлен докер, и в панели задач радостно побулькивает блоками #синийкит (извините, не удержался). Теперь сходите вот по этой ссылке и пройдите туториал Get Started.

Теперь давайте представим, что мы разрабатываем веб сайт на php и будем его публиковать связкой nginx+php7-fpm+mysql.

Вот очень примитивный dockerfile для php сервиса:

EXPOSE 9000
CMD [«php-fpm»]

Вкратце человеческим языком:

В случае с nginx и mysql нам даже не нужно писать свои dockerfile, так как никаких дополнительных расширений нам ставить не нужно. Вот как будет выглядеть docker-compose.yml нашего проекта

Директива volumes монтирует папки из хостмашины внурть контейнера, таким образом осуществляется конфигурирование nginx и сохранение данных бд при перезапуске.
Директива links связывает сервисы между собой, app связан с db, это значит что после запуска внутри контейнера app будет доступен хост “db”, и он будет указывать на соответствующий контейнер.

Есть довольно интересный темплейт yii2-starter-kit, в коробке которого можно найти неплохую реализацию описанной сборки php7-fpm nginx mysql а также mailcatcher.

Тем кому, как и мне, больше по душе python и django можно вообще не париться и все сделать по официальному туториалу от Docker — docs.docker.com/compose/django
плюс, после того как уже пришло понимание как это все работает, не составит особого труда переработать любую понравившуюся сборку под свои нужды.

Pitfalls

— MacOS. Доступ к сервису на хосте (к примеру mongo или mysql) из контейнера.
Из-за ограничений “Docker for Mac networking stack” нельзя “просто так взять и подключиться” к локалхост. Но есть два обходных пути:

а) официальный и простой (доступен в версии Docker начиная с 17.06) — использовать для подключения специальный DNS хост (доступно только в Docker for Mac) docker.for.mac.localhost. Источник.

б) добавить алиас IP к сетевому устройству lo0:
`sudo ifconfig lo0 alias 10.200.10.1/24`
и использовать этот адрес для подключения

— MongoDB. На маке нельзя монтировать внешний диск для данных. Причины описаны здесь
WARNING (Windows & OS X): The default Docker setup on Windows and OS X uses a VirtualBox VM to host the Docker daemon. Unfortunately, the mechanism VirtualBox uses to share folders between the host system and the Docker container is not compatible with the memory mapped files used by MongoDB

— Под Windows не работают симлинки в примонтированных томах. Ожидаемо, но очень неприятно узнавать об этом уже после того как все остальное заработало.

— Отличия entrypoint и command — вот тут подробно и понятно описана разница между entrypoint и command.

UPD дополнение от saskasa: На маке скорость записи из контейнера на диск хоста (добавленный как VOLUME) очень медленная, для понимания масштабов — примерно в 50-100 раз.

Источник

Поделиться с друзьями
Советы экспертов и специалистов
Adblock
detector