Запускаем PostgreSQL в Docker: от простого к сложному
Трудно представить современную разработку без контейнеризации. Docker и Kubernetes прочно обосновались на рынке, и, если вы ещё не знакомы с этими технологиями, им явно стоит уделить внимание.
В этой статье я хочу рассмотреть типовые способы запуска ванильного (то есть чистого/оригинального) PostgreSQL в контейнере, а также проблемы и их возможные решения, с которыми может столкнуться software engineer. Статья задумывалась как небольшое руководство для новых ребят, приходящих в мою команду, но, уверен, будет полезна и более широкой аудитории.
Прежде чем мы начнём
Вам понадобится Docker на машине, где вы будете проводить эксперименты. Скачайте его с официального сайта и установите. Настоятельно рекомендуется использовать актуальную версию.
Все приведенные в этой статье команды и скрипты запускались на версии Docker Desktop 3.5.2 и выше. Их работоспособность на старых версиях Docker не гарантируется.
Работоспособность скриптов на более старых версиях Docker не гарантируется
Так же подразумевается, что у вас есть базовые навыки работы с Docker. Если ещё нет, то для начала крайне желательно ознакомиться со статьями один и два.
Где взять образы PostgreSQL?
Официальные образы PostgreSQL опубликованы на Docker Hub. Там же можно найти базовые инструкции по использованию этих образов. Я буду опираться в том числе и на них.
Hello Postgres
Официальный образ Постгреса очень продвинутый и позволяет настраивать множество параметров. Для быстрого старта большинство из них можно оставить как есть, но вот пароль суперпользователя придётся задать явно:
Эта команда запустит нам контейнер PostgreSQL в фоновом (detached) режиме и присвоит ему имя habr-pg:
Контейнер с PostgreSQL, запущенный в Docker
Классно, не правда ли? А что мы можем делать с этой базой данных? К сожалению, на текущий момент не так уж и много. Через интерфейс Docker можно запустить CLI, подключиться к контейнеру и уже оттуда запустить, например, psql:
Далее я буду использовать сокращенный вариант этой команды:
Теперь вопросов об используемой версии БД не возникает, но работать с ней по-прежнему не очень удобно. Нам нужно сделать эту БД доступной извне, чтобы к ней могли подключаться приложения и IDE. Для этого нужно выставить наружу порт:
Отлично! С этого момента к базе данных можно подключиться, например, из IntelliJ IDEA:
Настройка подключения к БД в IntelliJ IDEA
Сейчас мы используем пользователя и базу данных в контейнере, создаваемых по умолчанию, я же предпочитаю указывать их явно. Финальная версия команды для запуска будет иметь вид:
И соответствующий compose-файл:
Инициализация структуры БД
К текущему моменту мы научились запускать в контейнере необходимую нам версию PostgreSQL, переопределять суперпользователя и создавать базу данных с нужным именем.
Это хорошо, но чистая база данных вряд ли будет сильно полезна. Для работы/тестов/экспериментов нужно наполнить эту базу таблицами и другими объектами. Разумеется, всё это можно сделать вручную, но, согласитесь, гораздо удобнее, когда сразу после запуска вы автоматически получаете полностью готовую БД.
если БД уже была проинициализирована ранее, то никакие изменения к ней применяться не будут;
если в каталоге присутствует несколько файлов, то они будут отсортированы по имени с использованием текущей локали (по умолчанию en_US.utf8).
Инициализацию БД можно запустить через однострочник, но в этом случае требуется указывать абсолютный путь до каталога со скриптами:
Например, на моей машине это выглядит так:
В качестве обходного варианта можно использовать макрос, на лету определяя рабочую директорию, и запускать команду из каталога со скриптами:
Использование docker-compose файла в этом случае более удобно и позволяет указывать относительные пути:
Здесь хотелось бы акцентировать ваше внимание на одной простой вещи, о которой уже говорил в предыдущей статье: при создании миграций БД для ваших приложений отдавайте предпочтение чистому (plain) SQL. В этом случае их можно будет переиспользовать с минимальными затратами.
А куда сохраняются мои данные?
Базы данных – это в первую очередь история про персистентность. И. Хьюстон, кажется у нас проблема… К настоящему моменту мы никак не управляем долговременным хранением нашей базы данных. Эту задачу целиком на себя берёт Docker, автоматически создавая volume для контейнера с БД. Есть целый ворох причин, почему это плохо, начиная от банальной невозможности просматривать содержимое volume’ов в бесплатной версии Docker Desktop и заканчивая лимитами дискового пространства.
Разумеется, хорошей практикой является полностью ручное управление физическим размещением создаваемых баз данных. Для этого нам нужно подмонтировать соответствующий каталог (куда будут сохраняться данные) в контейнер и при необходимости переопределить переменную окружения PGDATA:
Вариант с макросом, использующий для инициализации БД скрипты из предыдущего раздела:
С однострочниками на этом закончим. Все дальнейшие шаги будем осуществлять только через compose-файл:
При запуске этого скрипта рядом с ним создастся директория pgdata, где будут располагаться файлы БД.
Healthcheck? Нет, не слышал…
Проверка состояния/работоспособности – healthcheck – вполне устоявшийся архитектурный шаблон, который вы должны взять на вооружение для всех ваших приложений. База данных, запускаемая в контейнере, не является исключением.
Основная задача healthcheck’а – как можно скорее уведомить среду, управляющую контейнером, о том, что с контейнером что-то не так. И самая простая стратегия решения проблемы – перезапуск контейнера.
Healthcheck для PostgreSQL обычно основывается на использовании утилиты pg_isready как показано ниже:
А если хочу изменить параметры БД?
Ванильный образ PostgreSQL позволяет тюнить параметры и добавлять расширения на старте контейнера БД:
Разумеется, можно указать свой postgresql.conf. Оставлю это в качестве домашнего задания.
Не люблю консоль; дайте мне человеческий UI!
Далеко не все пользователи любят работать с БД из командной строки. Очень многие предпочитают использовать для этого продвинутый графический интерфейс, например pgAdmin.
Запустить ещё один контейнер, в котором будет бежать GUI, не сложно, но для удобной коммуникации с БД их лучше объединить в одну сеть:
pgAdmin стартует на порту 5050: перейдя на нужный адрес, можно будет настроить подключение к БД.
К БД можно подключиться как по имени контейнера, так и по имени сервиса
А как насчёт мониторинга?
После запуска скрипта экспортер будет доступен на порту 9187 и отдавать метрики в формате Prometheus:
Разумеется, для полноценной постановки на мониторинг нужно ещё поднять сам Prometheus + Grafana, а так же загрузить подходящий dashboard, но это уже выходит за рамки данной статьи. Более того, если ваша служба информационной безопасности исповедует Zero Trust, то экспортер придётся прикрыть с помощью nginx и настроить mTLS.
В качестве заключения
На этом у меня всё. Приведенной выше конфигурации более чем достаточно для развёртывания БД PostgreSQL в Docker-контейнере на стенде разработки или локально.
Все приведённые в статье команды и docker-compose файлы также доступны на GitHub.
Установка и настройка PostgreSQL в Docker
Docker — удобный инструмент для создания изолированных сред. Именно этой своей особенностью он и удобен для разворачивания различных приложений, требующих дополнительных зависимостей.
Managed Kubernetes помогает разворачивать контейнерные приложения в инфраструктуре Selectel. Сосредоточьтесь на разработке, а мы займемся рутинными операциями по обеспечению работы вашего кластера Kubernetes.
В прошлой статье о Docker-контейнерах мы рассказывали о преимуществах контейнеризации в целом, а в этой рассмотрим их относительно СУБД PostgreSQL, также расскажем о ее установке внутри контейнера.
Зачем использовать PostgreSQL в контейнере
Чтобы больше понять о преимуществах контейнеризации PostgreSQL, немного забежим вперед и для примера посмотрим на те зависимые пакеты, которые автоматически будут установлены вместе с приложениями, относящимся непосредственно к PostgreSQL, если мы будем ставить СУБД на сервер:
В нашем примере их три: libllvm10, libpq5, libxslt1.1. Однако, в зависимости от дистрибутива, может быть и больше. Посмотрим от каких пакетов на самом деле зависит пакет postgresql-12 (спойлер: 25 обязательных пакетов и 1 рекомендованный):
Наличие или отсутствие тех или иных пакетов, различные версии и другие факторы напрямую влияют на стабильность работы PostgreSQL. Используя контейнеризацию, возможные конфликты несовместимости нивелируются, т.к. все необходимые зависимости уже будут находиться в среде контейнера. Если загрузить готовый образ контейнера с ресурса Docker Hub (об этом ниже в статье), мы получим протестированную на совместимость и полностью готовую к работе среду.
И, наконец, отказоустойчивость. Если с сервером что-то случится, точно такой же контейнер может быть запущен на другом сервере с уже примонтированным хранилищем датафайлов.
Откроем консоль управления Selectel, перейдем в представление Облачная платформа и нажмем на кнопку Создать сервер.
Далее вводим имя сервера, выбираем образ операционной системы (остановимся на Ubuntu 20.04 LTS 64-bit) и фиксированную конфигурацию сервера с 2 vCPU и 4 ГБ RAM. Объем дискового пространства диска установим в 20 ГБ. Еще раз проверяем конфигурацию сервера и нажимаем Создать.
Проверим сетевые настройки, копируем пароль для root и удостоверимся в нижней части экрана, что все настройки корректны. Нажмем кнопку Создать.
Подождем минуту или две пока сервер не перейдет в состояние Active.
Теперь можем приступать к установке PostgreSQL в Docker. Поехали!
Как установить PostgreSQL в Docker из образа
Перед началом работы с PostgreSQL в контейнере Docker, установим сам Docker. Предварительно, добавим ключ для работы с репозиторием Docker Hub:
Добавим этот репозиторий в локальный список репозиториев и установим Docker:
Запустим демон Docker и активируем его автозапуск:
Поскольку за пределами жизненного цикла контейнера не остается каких либо данных, на файловой системе сервера (или другом файловом хранилище) необходимо создать каталог для хранения данных, которые будут появятся в процессе работы экземпляра PostgreSQL.
Чтобы получить из репозитория Docker Hub готовый образ контейнера с PostgreSQL, выполним следующую команду:
Теперь все готово к запуску.
Как запустить контейнер PostgreSQL
Выполним команду docker с ключом run:
Если возникла ошибка вида: «Error starting userland proxy: listen tcp4 0.0.0.0:5432: bind: address already in use.», то следует вначале посмотреть какой процесс задействует порт 5432:
Затем прибить” процесс по его PID и вновь выполнить запуск Docker-контейнера:
Разберем ключи, которые мы использовали для запуска контейнера:
Как подключиться к PostgreSQL в контейнере
После успешного запуска контейнера с PostgreSQL, попробуем к нему подключиться при помощи утилиты psql. Установим ее из пакета postgresql-client:
Теперь можно подключиться и выполнить тестовый SQL-запрос:
Если появилось приглашение к вводу запроса, значит все действия были выполнены правильно.
Еще один вариант подключиться к базе данных, не устанавливая дополнительных утилит — подключиться непосредственно к Docker-контейнеру. Для этого выполним команду docker exec с дополнительными ключами:
Приглашение к вводу запроса будет означать корректность ввода команды. Разберем ключи, которые мы использовали для выполнения команды:
Теперь попробуем создать новую таблицу, добавить в нее данные и выполнить запрос:
Чтобы остановить запущенный контейнер выполним docker stop и укажем имя контейнера:
Файлы и процессы, созданные контейнером, принадлежат пользователю postgres, который является внутренним по отношению к контейнеру. В отсутствие пространства имен пользователей внутри контейнера, UID и GID в контейнере могут иметь произвольное значение. На самом сервере этим UID и GID могут соответствовать привилегированные пользователи или группы соответственно.
Например, пользователь на хосте с тем же UID или GID, что и пользователь postgres в контейнере, сможет получить доступ к данным в различных каталогах хоста, а также сможет завершить любой запущенный процесс. Чтобы избежать такой бреши в безопасности, укажем при запуске контейнера специализированные переменные USERMAP_UID и USERMAP_GID:
Как запустить PostgreSQL в контейнере в составе docker-compose
Еще одним вариантом запуска PostgreSQL в Docker-контейнере, является запуск контейнера с базой данных в составе docker-compose. В первую очередь, создадим соответствующий yml-файл:
Затем установим docker-compose:
Теперь запустим контейнер:
Ключ -d указывает, что docker-compose должен быть запущен в в фоновом режиме (вернет управление после его запуска).
Проверим возможность подключения к базе данных:
Появление приглашения к вводу команд для PostgreSQL означает корректность выполненных настроек.
Чтобы остановить запущенный контейнер, выполним docker-compose stop:
Заключение
Мы рассказали о работе с базой данных PostgreSQL в контейнере Docker, запуске, выполнении запросов и остановке. Как и говорили в начале статьи, работа с контейнеризованной в Docker базой данных упрощает процесс разработки и администрирование. Контейнеры могут быть легко перезапущены на другом сервере и сервис, предоставляемый базой данных, не прервется.
PostgreSQL в контейнере Docker
Ранее стал разбираться с использованием Docker`a: Как установить и использовать Docker в Ubuntu 18.04. А использовать хочется PostgreSQL в этих контейнерах. Это можно сделать, сейчас пока как.
Н о, в продолжение той статьи, рекомендую разобраться в основных отличиях образа и контейнера в Docker, а еще (вот это уже по желанию), подробнее почитать про слои и не только в Docker.
Подключение через psql с хостовой машины:
Подключение к контейнеру:
Внутри него подключение к psql:
Приступим к длинной статье со скриншотами и теми ошибками, которые я словил.
Сначала нужно найти образ с нужной версией PostgreSQL, я использую команду:
Буду использовать верхний (официальный) контейнер, 12 версия. Скачиваю его с помощью команды:
Нужно немного подождать, всё-такие размер образа составляет 314 мегабайт, так что зависит от скорости интернета.
Размер образов можно посмотреть командой:
Теперь можно контейнер запускать (в статье по ссылке выше отличие образов от контейнеров есть). Попробую сделать это вот такой командой:
Появляется ошибка (на самом деле, команду выше надо дополнить, тогда всё нормально будет, но на ошибку тоже нужно посмотреть):
Текст ошибки можете сами прочитать. Суть — нужно произвести различные инициализации, указать пароли и так далее, чтобы контейнер правильно сформировался. Я же этого не сделал еще, так что в базу зайти не могу. То есть, нужно правильно команду запуска сформировать.
Наверное, в данном случае лучше зайти на ту страницу, с которой производили скачивание образа postgres — со страницы хранилища контейнеров, dockerhub. В поле поиска вбиваем имя и находим результат:
Попадаем на страницу с описанием данного контейнера:
Описание большое, желательно всё прочитать. Я чутка поторопился, поискал в интернете интересующую меня информацию, мне ведь хотелось запустить контейнерный PostgreSQL и подключиться к нему. Поэтому, про официальную страницу помните и изучите её, а я далее покажу, что делал.
ВАЖНО: Возможно, что-то я делаю не правильно. Но я только начал изучать Docker, так что ошибки могут быть. Но код ниже работает 🙂
Итак, сначала предлагаю проверить, доступен ли «запущенный» выше PostgreSQL. Для этого я попробую запустить psql (можно установить с помощью команды apt и нужного пакета, там за версией надо следить) и подключиться к чему-нибудь:
Появляется ошибка — естественно, ведь PostgreSQL у меня не установлен.
Вот теперь запускаем контейнер с PostgreSQL следующей командой:
Убедимся, что всё получилось:
Снова попробуем подключиться к контейнерному PostgreSQL с помощью psql, установленного на хостовой машине:
Обратите внимание, что нужно ввести тот пароль, который указали в команде run:
Всё получилось! Можно даже таблицу создать:
Теперь осталось подключиться к PostgreSQL из контейнера. Для этого необходимо выполнить вот такую команду:
Можно походить по директориям. Подключены как пользователь ОС root.
Видим все те данные, которые были созданы с хоста. Еще можно найти каталог с данными и зайти туда — и можно там похозяйничать, если нужно.
Напоминаю, что, если удалить контейнер — все пользовательские (созданные нами) данные потеряются!
Например, я сейчас останавливаю мой контейнер, потом его удаляю, создаю заново, подключаюсь и вижу:
Можно свой образ сделать с этими данными, а потом его использовать.
Уф, ну вроде всё! Наверное, я буду контейнер с PostgreSQL использовать для различных тестирований — удобно и быстро, заморачиваться с виртуальной машиной не надо.
Docker контейнер с данными на Postgres для интеграционного тестирования и лёгким расширением
Соответственно, хочется, чтобы каждый разработчик, приступая к работе над проектом, мог запустить его одной командой, например:
и приложение поднялось бы сразу со всеми необходимыми связанными контейнерами? А главное чтобы в нём уже были бы данные для большинства кейсов разработки и багфиксинга, стандартные пользователи и большинство работающих сервисов, над которыми сразу можно было бы приступить работать, не тратя времени на экспорт-импорт каких-то там образов или демоданных!
Как приятный бонус, ну разве не здорово иметь базу данных в несколько гигабайт и возможность откатиться к её исходному (или любому другому коммиту) состоянию в течении пары секунд?
Разумеется мы поговорим о написании Dockerfile для такого образа с данными, и некоторых подводных камнях этого процесса.
Чего хочется
Для начала определим проблему подробнее. Мы готовим образ, с данными, с которыми сможет работать каждый, кто работает с нашим приложением:
Приступаем
Стоит отметить что официальный docker образ postgres уже имеет несколько точек расширения:
Однако, для наших целей этого мало:
Как видите, я постарался добавить комментарии прямо в файл, возможно они даже более чем исчерпывающие, но всё-таки остановимся на паре моментов подробнее.
Стоит обратить внимание
Готовому образу остаётся только присвоить тэг и запушить в репозиторий. Чаще всего, конечно, это будет приватный репозиторий, если вы не работает над каким-то публичным сэмплом данных.
Я буду очень рад, если это поможет кому-то сделать его процесс подготовки создания тестовых образов с данными хоть чуточку проще.
Глава 6. Добавляем базу данных: Postgres
Содержание
Не знаю как вы, но я очень вдохновлён нашим развитием. Мы постепенно совершенствуем свои навыки и теперь в шаговой доступности от своего приложения Dockerized Rails имеющего все те возможности, которые мы применяем когда запускаем Rails локально.
Тем не менее есть одно явное упущение: мы не настроили базу данных. Подавляющему большинству приложений Rails требуется постоянное хранилище.
В этой главе мы исправим его, основываясь на своём опыте добавления сервера Redis, для подключения базы данных Postgres.
При чтении данной главы помните об сохранении в памяти всей большой картины. Изучаемые вами навыки применимы ко всем службам, которые вы можете пожелать добавить в своё приложение, будь то запуск фоновых заданий (таких как Sidekiq), Elasticsearch или некий интерфейс JavaScript для API Rails.
Запуск сервера Postgres
Для применения в своём приложении Rails мы хотим запустить некий сервер Postgres. Этот процесс очень похож на то как мы добавляли Redis.
Давайте добавим в свой файл docker-compose.yml Postgres:
Как и в случае с redis нашей новой службе database не требуется установление соответствия порта или тома. Мы не хотим в своём приложении наличия доступа к нашей базе данных извне и нам не требуется монтировать какие бы то ни было файлы в этот контейнер Postres.
Зачем мы это сделали?
Мы запустили свою службу database в отключённом режиме (detached). Вы можете убедиться что она поднята и исполняется при помощи:
В качестве дальнейшей проверки мы можем просмотреть вывод контейнера этой базы данных:
Подключение к Postgres из отдельного контейнера
По мере того вам будет становиться всё удобнее и удобнее при использовании Compose, вы обнаружите что вы доверяете ему делать всё что вам нужно. Скорее всё что вам потребуется для проверки того что некая служба исполняется, это быстрый запуск docker-compose ps (а порой вы даже можете пропускать и это).
Однако так как запуск служб подобных Postres внутри некого контейнера всё ещё внове для нас, давайте проделаем дополнительный шаг вручную подключившись к нему с другого контейнера, в точности как мы проделывали это с Redis. При обучении, по крайней мере для меня лично, это помогало моей уверенности в работе с данными инструментами.
Мы можем сделать это при помощи такой команды:
Когда вы выполните эту команду, вы получите приглашение на ввод пароля:
Подключение нашего прикладного приложения Rails к Postgres
Только что мы рассмотрели как поднять свою базу данных и достичь её из другого контейнера в своей сетевой среде приложения. Однако прежде чем мы начнём её применять, нам понадобится настроить своё приложение Rails на подключение к ней.
Давайте это сделаем прямо сейчас.
Установка Gem Postgres
Обо всём по порядку. Чтобы заставить наше приложение Rails общаться с Postgres, нам нужно установить соответствующий gem клиента Postgres. Откройте свой Gemfile и обновите его чтобы заменить:
и после этого выполним повторную сборку своего образа:
Создание базы данных нашего приложения
Давайте откроем config/database.yml в неком редакторе и заменим его содержимое следующими настройками Postgres:
К счастью, всё выглядит для нас достаточно знакомым.
Давайте исправим это. Нам придётся изменить свой docker-compose.yml чтобы обеспечить эти переменные настроенными на наш контейнер приложения Rails, подобно следующему:
Прежде всего давайте создадим некие каталоги для хранения своих специфичных для среды настроек:
Теперь нам требуется сообщить Compose о необходимости использования этих файлов вместо явной установки значений переменных напрямую. Мы делаем это с помощью соответствующей директивы env_file :
Закончив это небольшое форматирование мы готовы создавать свои базы данных для разработки и тестирования при помощи стандартной команды bin/rails db:create нацелив эту команду на свою службу web :
Вы должны обнаружить следующий вывод, отображающий что наша база данных была успешно создана:
Отлично, мы уже почти на месте.
Перезапуск нашего сервера Rails
Вот как мы это делаем:
Рисунок 6-1
Практическое применение базы данных
Мы знаем, что настроив своё приложение Rails для общения с нашей базой данных Postgres это наше приложение Rails успешно запустилось; однако мы полагаемся на отсутствие ошибки в качестве подтверждения того что наша база данных корректно подключилась. Хотя с технической точки зрения это всё что нам требуется, давайте убедимся что всё работает должным образом выполняя взаимодействие с базой данных нашего приложения. Это также позволит нам получить дополнительную практику при разработке своего приложения Rails с Docker через CLI Compose.
Убедитесь что вы выполнили chown для данных файлов запустив:
За дополнительными подробностями отсылаем к Дополнению A. Владельцы файлов и полномочия.
Рисунок 6-2
Великолепно, у нас имеется Postgres целиком настроенный в Compose.
Отделение данных от контейнера
Это прекрасно что мы настроили свою базу данных и поэтому мы теперь способны удерживать данные в своём приложении Rails. Однако, в настоящий момент существует основной провал в том как это работает. Давайте рассмотрим в чём состоит проблема и как его обойти.
Теперь, когда мы намерены сохранять в своей базе данных важную информацию, нам необходимо подумать об этом слегка более аккуратно.
В точности как и в своём коде, в котором мы пытаемся отделить часто изменяющиеся вещи от тех которые не так этому подвержены, мы желаем отделить свои данные от самих контейнеров, которые их создают и применяют их. Наши данные следует хранить отдельно от самих контейнеров, которые их и исполняют. Таким образом мы можем удалять, уничтожать и воссоздавать такой контейнер не касаясь самих данных.
Ответ такой: мы храним постоянные данные в томах, которые по своей природе отсоединены от самого жизненного цикла контейнеров. Даже если мы удаляем некий контейнер с каким- то подключённым томом, сам том продолжит существовать независимо, сохраняя в безопасности наши данные. Затем мы можем воссоздать этот контейнер, подцепить этот том и всё шито- крыто.
Docker позволяет нам создавать несколько различных видов томов, каждый из которых выполняет собственное задание. Например, мы уже видели как смонтировать некий локальный том. Однако существует и другой вид тома, который лучше отвечает нашей цели. На самом деле нас не заботит где или как хранятся наши файлы, нас беспокоит лишь то, что они хранятся где- то отдельно. Для этого мы можем создать некий именованный том : автономную корзину (bucket) файлового хранилища, полностью управляемую Docker.
Но хватит теории; давайте посмотрим как это делать практически.
Вот наш docker-compose.yml изменённый для хранения наших постоянных данных в неком томе:
Самый первый шаг состоит в том чтобы сообщить Compose что нам требуется некий именованный том. Именованные тома определяются под имеющимся свойством верхнего уровня volumes (строка 25); здесь мы определили некий именованный том с названием db_data (строка 26).
Вначале остановим свою службу database :
Затем давайте явным образом удалим её контейнер:
Хорошо, самое время вернуть нашу базу данных обратно:
Так как наш новый том теперь смонтирован в данном контейнере, мы стёрли все предыдущие базы данных и хранимые данные, следовательно нам требуется воссоздать необходимые базы данных и выполнить миграцию.
Давайте сделаем это сейчас:
Давайте докажем что наши данные теперь остаются постоянно даже когда мы удаляем их контейнер базы данных. Прежде всего нам требуется запомнить некие данные: добавим одного или более пользователей через подмостки Rails. на следующем рисунке я создал для себя некого отдельного пользователя:
Рисунок 6-3
Теперь когда у нас имеются некие сохранённые данные, давайте остановим свой контейнер базы данных:
а затем и удалим его (вам потребуется выдать подтверждение после получения запроса):
Затем мы воссоздадим его и запустим его через:
Мы сказали что Docker управляет некой областью файловой системы для именованных томов, но где она расположена в действительности? Мы можем обнаружить где расположен наш именованный том db_data (который снабжён со стороны Compose префиксом папки нашего приложения и превращён в myapp_db_data ), исполнив:
Беглый обзор
Давайте повторим то что мы прошли:
При помощи Compose мы запустили некий сервер Postgres в контейнере.
Мы убедились что наш сервер Postgres был запущен подключившись с помощью клиента Postgres из некого отдельного контейнера.
Мы настроили своё приложение Rails на общение с Postgres установив требующийся gem Postgres, изменив свой файл database.yml и запустив соответствующую задачу Rake для создания требуемой базы данных.
Мы продвинули свою новую базу данных, создав подмостки, выполнив миграции а также вставки, удаления и обновления записей.
Мы обсудили почему будет хорошей мыслью отделить наши контейнеры базы данных от сам их данных, которые мы хотим видеть постоянными.
Наконец, мы воспользовались именованным томом для хранения своих данных обособленно, позволяя нам управлять их жизненным циклом независимо от самого контейнера.
Теперь нам уже известно как добавлять две службы: Redis и Postgres. Вы должны быть способны применять те же самые знания для добавления прочих служб, о которых вы можете помышлять. < Прим. пер.: например, взамен Potgres поставить MS SQL Server, ха! > На самом деле в своей следующей главе мы добавим ещё одну службу, когда отвлечёмся от внутренних технологий чтобы изучить как внедрять современный интерфейс для вашего приложения Rails.