Docker compose что такое volumes

Docker compose volumes

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

Для примера возьмем с dockerhub инструкцию для образа с wordpress, в немного измененном виде будем использовать ее.

Проект будет представлять собой сайт на wordpress с базой данных MySQL.

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

На машине должны быть установлены сам Docker и docker-compose. Создаем docker-compose.yml

В файле 2 сервиса. Структура типовая, 80 порт из контейнера пробрасывается на порт 8080 хост машины. Используются стандартные образы с dockerhub.

Для каждого контейнера заданы блоки volumes:

— /home/site:/var/www/html для сайта

— /home/site/db:/var/lib/mysql для базы данных

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

Содержимое /var/www/html в /home/site, содержимое /var/lib/mysql в/home/site/db

Эта информация будет изменена при жизни контейнера и останется на хост машине после его удаления.

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
bf264537c63d wordpress «docker-entrypoint.s…» About a minute ago Up About a minute 0.0.0.0:8080->80/tcp home_wordpress_1
ae9cd7efb0a8 mysql:5.7 «docker-entrypoint.s…» About a minute ago Up About a minute 3306/tcp, 33060/tcp home_mysql_1

Они успешно стартовали, с хоста обращаться к сервису можно только по порту 8080, на который пробрасываются запросы.

В браузере обратившись к IP адресу серверу и порту 8080 можно запустить установку CMS, затем попасть в административный раздел.

Внесем минимальные изменения в структуру перового поста. Поменяем заголовок «Hello World» на «Hello Docker» и единственное существующее по-умолчанию предложение.

Пересоздадим существующую структуру

Going to remove home_wordpress_1, home_mysql_1
Are you sure? [yN] y
Removing home_wordpress_1 … done
Removing home_mysql_1 … done

Контейнеров нет, с ключем -a выводятся все контейнеры, в т.ч. незапущенные

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Файлы при этом сохранены на диске

db readme.html wp-blog-header.php wp-config-sample.php wp-includes wp-login.php wp-signup.php
index.php wp-activate.php wp-comments-post.php wp-content wp-links-opml.php wp-mail.php wp-trackback.php
license.txt wp-admin wp-config.php wp-cron.php wp-load.php wp-settings.php xmlrpc.php

Также как и содержимое /var/lib/mysql из контейнера

auto.cnf ca.pem client-key.pem ibdata1 ib_logfile1 performance_schema public_key.pem server-key.pem wordpress
ca-key.pem client-cert.pem ib_buffer_pool ib_logfile0 mysql private_key.pem server-cert.pem sys

При обращении к тому же URL:8080 сейчас будет возникать ошибка — веб-сервер, являющийся частью контейнера не работает.

Запускаем контейнеры через docker-compose вновь

Creating home_mysql_1
Creating home_wordpress_1

Сейчас можно убедиться в том, что сайт вновь стал открываться и контент отображается в том же виде. При старте информация из docker-compose.yml считалась.

Были задействованы те же каталоги, что использовались ранее, с имеющимися данными.

Источник

linux-notes.org

Работа с томами (Volumes) в Docker

Volumes — являются механизмом для сохранения данных, создаваемых и используемых Docker контейнерами (с хостевой машины на контейнер).

Надеюсь что у вас уже имеется докер на хостевой машине, если нет, вот полезные статьи:

Работа с томами (Volumes) в Docker

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

Создание Volumes в Docker

Чтобы создать Volume, выполните:

Проверим что имеется в докере:

Или вывести только необходимый:

Получим подробную инфу:

Создадим index.html файл:

Скопируем созданный файл в волюму:

Смотрим, есть ли файл:

И запустим контейнер nginx:

Посмотрим какой порт юзает созданный контейнер:

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

Собственно, что и требовалось доказать — все есть и работает должным образом.

Создание TMPFS Volumes в Docker

Рассмотрим пример создания TMPFS Volume (данные хранятся в RAM) следующим образом:

Создание BTRFS Volumes в Docker

Рассмотрим пример создания BTRFS Volume (данные хранятся на /dev/sda2 разделе) следующим образом:

Создание NFS Volumes в Docker

Рассмотрим пример создания NFS Volume (в удаленной части NFS) следующим образом:

Монтирование Volumes с хостевой машины в контейнер.

Добавление Volum-ов в контейнер(ы) являются хорошим решением т.к при завершении жизни контейнера все ваши данные будут утеряны. Если ваш контейнер генерирует непостоянные данные, рассмотрите возможность использования монтирования tmpfs, чтобы избежать постоянного хранения данных в любом месте и увеличить производительность контейнера, избегая записи на перезаписываемый слой контейнера.

Или вот еще примеры:

Монтирование tmpfs в Docker

Монтирование tmpfs является временным и сохраняется только в памяти хоста. Когда контейнер остановится, монтирование tmpfs будет удалено, и файлы, написанные там, не будут сохранены.

Ограничения монтирования tmpfs:

Источник

Хранение данных в Docker

Важная характеристика Docker-контейнеров — эфемерность. В любой момент контейнер может рестартовать: завершиться и вновь запуститься из образа. При этом все накопленные в нём данные будут потеряны. Но как в таком случае запускать в Docker приложения, которые должны сохранять информацию о своём состоянии? Для этого есть несколько инструментов.

В этой статье рассмотрим docker volumes, bind mount и tmpfs, дадим советы по их использованию, проведём небольшую практику.

Особенности работы контейнеров

Прежде чем перейти к способам хранения данных, вспомним устройство контейнеров. Это поможет лучше понять основную тему.

Контейнер создаётся из образа, в котором есть всё для начала его работы. Но там не хранится и тем более не изменяется ничего важного. В любой момент приложение в контейнере может быть завершено, а контейнер уничтожен, и это нормально. Контейнер отработал — выкидываем его и собираем новый. Если пользователь загрузил в приложение картинку, то при замене контейнера она удалится.

На схеме показано устройство контейнера, запущенного из образа Ubuntu 15.04. Контейнер состоит из пяти слоёв: четыре из них принадлежат образу, и лишь один — самому контейнеру. Слои образа доступны только для чтения, слой контейнера — для чтения и для записи. Если при работе приложения какие-то данные будут изменяться, они попадут в слой контейнера. Но при уничтожении контейнера слой будет безвозвратно потерян, и все данные вместе с ним.

В идеальном мире Docker используют только для запуска stateless-приложений, которые не читают и не сохраняют данные о своём состоянии и готовы в любой момент завершиться. Однако в реальности большинство программ относятся к категории stateful, то есть требуют сохранения данных между перезапусками.

Поэтому нужны способы сделать так, чтобы важные изменяемые данные не зависели от эфемерности контейнеров и, как бонус, были доступными сразу из нескольких мест.

В Docker есть несколько способов хранения данных. Наиболее распространенные:

Особые типы хранения:

На схеме показаны самые популярные типы хранения данных для Linux: в памяти (tmpfs), в файловой системе хоста (bind mount), в томе Docker (docker volumes). Разберём каждый вариант.

Тома (docker volumes)

Тома — рекомендуемый разработчиками Docker способ хранения данных. В Linux тома находятся по умолчанию в /var/lib/docker/volumes/. Другие программы не должны получать к ним доступ напрямую, только через контейнер.

Тома создаются и управляются средствами Docker: командой docker volume create, через указание тома при создании контейнера в Dockerfile или docker-compose.yml.

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

Один том может быть примонтирован одновременно в несколько контейнеров. Когда никто не использует том, он не удаляется, а продолжает существовать. Команда для удаления томов: docker volume prune.

Можно выбрать специальный драйвер для тома и хранить данные не на хосте, а на удалённом сервере или в облаке.

Для чего стоит использовать тома в Docker:

Монтирование каталога с хоста (bind mount)

Это более простая концепция: файл или каталог с хоста просто монтируется в контейнер.

Используется, когда нужно пробросить в контейнер конфигурационные файлы с хоста. Например, именно так в контейнерах реализуется DNS: с хоста монтируется файл /etc/resolv.conf.

Другое очевидное применение — в разработке. Код находится на хосте (вашем ноутбуке), но исполняется в контейнере. Вы меняете код и сразу видите результат. Это возможно, так как процессы хоста и контейнера одновременно имеют доступ к одним и тем же данным.

Особенности bind mount:

Когда использовать тома, а когда монтирование с хоста

Монтирование tmpfs

Tmpfs — временное файловое хранилище. Это некая специально отведённая область в оперативной памяти компьютера. Из определения выходит, что tmpfs — не лучшее хранилище для важных данных. Так оно и есть: при остановке или перезапуске контейнера сохранённые в tmpfs данные будут навсегда потеряны.

На самом деле tmpfs нужно не для сохранения данных, а для безопасности, полученные в ходе работы приложения чувствительные данные безвозвратно исчезнут после завершения работы контейнера. Бонусом использования будет высокая скорость доступа к информации.

Такое хранилище может одновременно работать только с одним контейнером и доступно только в Linux.

Общие советы по использованию томов

Монтирование в непустые директории

Если вы монтируете пустой том в каталог контейнера, где уже есть файлы, то эти файлы не удалятся, а будут скопированы в том. Этим можно пользоваться, когда нужно скопировать данные из одного контейнера в другой.

Если вы монтируете непустой том или каталог с хоста в контейнер, где уже есть файлы, то эти файлы тоже не удалятся, а просто будут скрыты. Видно будет только то, что есть в томе или каталоге на хосте. Похоже на простое монтирование в Linux.

Монтирование служебных файлов

С хоста можно монтировать любые файлы, в том числе служебные. Например, сокет docker. В результате получится docker-in-docker: один контейнер запустится внутри другого. UPD: (*это не совсем так. mwizard в комментариях пояснил, что в таком случае родительский docker запустит sibling-контейнер). Выглядит как бред, но в некоторых случаях бывает оправдано. Например, при настройке CI/CD.

Монтирование /var/lib/docker

Разработчики Docker говорят, что не стоит монтировать с хоста каталог /var/lib/docker, так как могут возникнуть проблемы. Однако есть некоторые программы, для запуска которых это необходимо.

Ключ командной строки для Docker при работе с томами.

Для volume или bind mount:

Команды для управления томами в интерфейсе CLI Docker:

Создадим тестовый том:

Вот он появился в списке:

Команда inspect выдаст примерно такой список информации в json:

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

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

То же самое, отлично.

Теперь примонтируем каталог с хоста:

Docker не любит относительные пути, лучше указывайте абсолютные!

Теперь попробуем совместить оба типа томов сразу:

Отлично! А если нам нужно передать ровно те же тома другому контейнеру?

Вы можете заметить некий лаг в обновлении данных между контейнерами, это зависит от используемого Docker драйвера файловой системы.

Создавать том заранее необязательно, всё сработает в момент запуска docker run:

Посмотрим теперь на список томов:

Ещё немного усложним команду запуска, создадим анонимный том:

Такой том самоуничтожится после выхода из контейнера, так как мы указали ключ –rm.

Если этого не сделать, давайте проверим что будет:

Хозяйке на заметку: тома (как образы и контейнеры) ограничены значением настройки dm.basesize, которая устанавливается на уровне настроек демона Docker. Как правило, что-то около 10Gb. Это значение можно изменить вручную, но потребуется перезапуск демона Docker.

При запуске демона с ключом это выглядит так:

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

Если вам нужно вручную очистить содержимое всех томов, придётся удалять каталог, предварительно остановив демон:

Если вам интересно узнать подробнее о работе с данными в Docker и других возможностях технологии, приглашаем на двухдневный онлайн-интенсив в феврале. Будет много практики.

Автор статьи: Александр Швалов, практикующий инженер Southbridge, Certified Kubernetes Administrator, автор и разработчик курсов Слёрм.

Источник

Изучаем Docker, часть 6: работа с данными

В сегодняшней части перевода серии материалов о Docker мы поговорим о работе с данными. В частности — о томах Docker. В этих материалах мы постоянно сравнивали программные механизмы Docker с разными съедобными аналогиями. Не будем отходить от этой традиции и здесь. Данные в Docker пусть будут специями. В мире существует множество видов специй, а в Docker — множество способов работы с данными.

Обратите внимание на то, что этот материал подготовлен с использованием движка Docker версии 18.09.1 и API версии 1.39.

Данные в Docker могут храниться либо временно, либо постоянно. Начнём с временных данных.

Временное хранение данные

В контейнерах Docker организовать работу с временными данными можно двумя способами.

По умолчанию файлы, создаваемые приложением, работающим в контейнере, сохраняются в слое контейнера, поддерживающем запись. Для того чтобы этот механизм работал, ничего специально настраивать не нужно. Получается дёшево и сердито. Приложению достаточно просто сохранить данные и продолжить заниматься своими делами. Однако после того как контейнер перестанет существовать, исчезнут и данные, сохранённые таким вот нехитрым способом.

Для хранения временных файлов в Docker можно воспользоваться ещё одним решением, подходящим для тех случаев, когда требуется более высокий уровень производительности, в сравнении с тем, который достижим при использовании стандартного механизма временного хранения данных. Если вам не нужно, чтобы ваши данные хранились бы дольше, чем существует контейнер, вы можете подключить к контейнеру tmpfs — временное хранилище информации, которое использует оперативную память хоста. Это позволит ускорить выполнение операций по записи и чтению данных.

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

Постоянное хранение данных

Существуют два способа, позволяющих сделать срок жизни данных большим срока жизни контейнера. Один из способов заключается в использовании технологии bind mount. При таком подходе к контейнеру можно примонтировать, например, реально существующую папку. Работать с данными, хранящимися в такой папке, смогут и процессы, находящиеся за пределами Docker. Вот как выглядят монтирование tmpfs и технология bind mount.

Монтирование tmpfs и bind mount

Минусы использования технологии bind mount заключаются в том, что её использование усложняет резервное копирование данных, миграцию данных, совместное использование данных несколькими контейнерами. Гораздо лучше для постоянного хранения данных использовать тома Docker.

Тома Docker

Том — это файловая система, которая расположена на хост-машине за пределами контейнеров. Созданием и управлением томами занимается Docker. Вот основные свойства томов Docker:

Создание томов

Тома можно создавать средствами Docker или с помощью запросов к API.

Вот инструкция в Dockerfile, которая позволяет создать том при запуске контейнера.

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

Создавать тома в Dockerfile можно и используя формат JSON.

Кроме того, тома можно создавать средствами командной строки во время работы контейнера.

Работа с томами из командной строки

▍Создание тома

Создать самостоятельный том можно следующей командой:

▍Выяснение информации о томах

Для того чтобы просмотреть список томов Docker, воспользуйтесь следующей командой:

Исследовать конкретный том можно так:

▍Удаление тома

Удалить том можно так:

Для того чтобы удалить все тома, которые не используются контейнерами, можно прибегнуть к такой команде:

Перед удалением томов Docker запросит у вас подтверждение выполнения этой операции.

Если том связан с каким-либо контейнером, такой том нельзя удалить до тех пор, пока не удалён соответствующий контейнер. При этом, даже если контейнер удалён, Docker не всегда это понимает. Если это случилось — можете воспользоваться следующей командой:

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

Итоги

Вот полезные команды, которыми можно пользоваться при работе с томами Docker:

Уважаемые читатели! Какие материалы о Docker вы посоветовали бы изучить новичкам?

Источник

Использование volume в docker-compose?

Буду рад если кто то простыми словами разъяснит некоторые непонятные моменты использования volume в docker-compose.

Зачем нужна последняя директива в данном docker-conpose, какую конкретно роль она выполняет:

— db-data в данном примере этот каталог расположенный в одной директории с docker-compose.yml?
— db-data:/var/lib/mysql/data

version: «3.7»
services:
wordpress:
image: wordpress
ports:
— «8080:80»
networks:
— overlay
deploy:
mode: replicated
replicas: 2
endpoint_mode: vip

mysql:
image: mysql
volumes:
— db-data:/var/lib/mysql/data
networks:
— overlay
deploy:
mode: replicated
replicas: 2
endpoint_mode: dnsrr

Простой 2 комментария

— db-data в данном примере этот каталог расположенный в одной директории с docker-compose.yml?

Нет. Это именованный volume. Его фактическая папка спрятана где-то глубоко, можно посмотреть командой docker volume inspect db-data и изначально он пустой.

Такая запись первым параметром указывает не именованный volume, а подпапку в папке с docker-compose.yml Т.е. mysql получит папку со всем её содержимым по адресу, указанному вторым параметром.

Лучше использовать полноценные volume, чем просто монтировать локальные папки.

Источник