Docker postgresql mac os

Setting up Database Servers for Development on Mac OS X Using Docker

If you are beginning your software development career and using Mac, and interested in using relational databases like MySQL/MariaDB, PostgreSQL, Microsoft SQL Server, Azure CosmosDB SQL or Oracle Database, then this article is for you!

If you like this article, please clap for it! Click on the little hands icon to the left or bottom of this page.

Now, in the past when I used to run Linux on my laptops, I’d just install each database directly into my environment. Sometimes I’d face problems like dependency-hell, conflicts, native libraries missing, and would eventually end up running the databases in isolated VirtualBox VMs. In today’s containerized world, this is past.

If you really want to make your own developer life easier, get used to Docker and spin up databases in containers. All of them.

Running RDBMS in containers may not be suited for production, but for development/testing environments? It is the perfect fit.

If you haven’t already done it, make sure you install Homebrew and Cask — package managers for Mac OS. Not only for this article but pretty much for everything you will eventually install in the future.

Pre-requisites

You will have to install Docker. And while Kitematic is optional, I actually recommend you do so. Easier to manage the containers in your system once you create them (start/stop/restart/delete).

Once you have Docker installed, make sure you have an account in the Docker Store — sign-up here. That will be needed for some of the databases. Once you have your account, log in to it either in the UI or with docker login.

CLIs for Database Clients

To connect to a database, you will need a client, and ideally one that you can quickly use through the command-line/terminal. For each database below you will find two instructions: one to install and start the database using Docker, and one to install and connect to that database using a CLI.

Most databases provide Client CLI within the Docker image, but I find it extremely useful to have these clients installed so you can easily connect to databases running elsewhere, such as in the Cloud, or remote in some server in your intranet. Plus, you can also automate stuff writing scripts.

Not that you can’t do these things with CLI inside Docker… It’s just my preference.

Getting Started

All four major databases provide Docker images these days. And I was closely involved in the build up of the Docker image for the Oracle Database, gracefully put together by my friend Gerald Venzl. But the other databases provide very useful and well-assembled Docker images too, and I am sure you will appreciate them all.

MySQL

There are two MySQL images on Docker Hub you should be aware of:

I always prefer to use products through tools officially provided by the maker of that product. Feel free to try [2], but below are instructions for Oracle’s MySQL Server.

Download and start MySQL container:

Note the use of special environment variables. Check the documentation of this image for more information and other options such as how to connect with root.

Install MySQL Shell and connect to the database:

Microsoft SQL Server

Microsoft has been doing pretty cool stuff in recent years. Not only they have made this product available for Linux, they now also offer pretty good Docker images for it.

Download and start Microsoft SQL Server container:

Install and connect using sqlcmd — more details here.

Connect to SQL Server:

PostgreSQL

This image is provided and supported by the PostgreSQL Docker Community. Basically people at Docker and also folks who are involved in PostgreSQL development. I found this image to also be very straightforward and simple to use.

Download and run PostgreSQL:

Install and connect using PSQL:

Azure CosmosDB

CosmosDB is an interesting Microsoft Azure’s service that allows developers to use different APIs to connect to the same datastore. For example, you can use CosmosDB as a drop-in replacement for MongoDB, or Cassandra. It also provides a SQL API. You just point an existing application previously developed for one of these databases on CosmosDB, and it will just work (well, give it or take). It also scales beautifully. Even Thomson Reuters is using it.

The easiest way to use CosmosDB is again, IMO, through the command line. But to play with it of course you will first need an Azure account. Besides giving some few hundreds of dollars for you to use in your first 30 days, Microsoft Azure also has many services that are always free (to certain limits/quotas), and some services that are free in your first 12 months, if you activate your subscription during or after the first 30 days.

So, go to azure.microsoft.com/free right now and create an account.

Install the Azure CLI. For Mac OS X you just use Homebrew:

For Linux, check the documentation which contains instructions for different package managers and distributions.

And if you do decide to play with it, just follow this » Create an SQL API account using CLI» sample!

Oracle Database

During my time at Oracle, I led the company’s presence on GitHub, helping teams structure their projects, and also launch newly open sourced libraries, tools, resources, and samples sets. There was, though, one particular project I was taking care of since the beginning: the docker-images repository. And I am extremely proud of the advancements and improvements of developer experience for some key Oracle products that we were able to deliver thanks to Docker and the amazing work from folks like Monica Riccelli, Avi Miller, Gerald Venzl and many other engineers and product managers.

In the past it used to be quite frustrating to install and run Oracle Database for development purposes, but thanks to Gerald and Docker, it is now as simple as it can get.

Now, while anyone can go to the docker-images repository, download Dockerfiles and build their own images for the commercial products, in fact there are some pre-built images available for common products on the Docker Store and also on the Oracle Container Registry server.

Below I outline the steps required fordownloading and running an Oracle Database image from the Docker Store.

At this point I will assume you already have a Docker ID (account). If you don’t, create one.

— Go to the Oracle Database image page on Docker Store
— Click on Proceed to Checkout (blue button to the right)

Источник

Запускаем PostgreSQL в Docker: от простого к сложному

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

Запуск баз данных и других stateful приложений в контейнере – это тема интересная, но способная вызвать очередной Большой взрыв в комментариях. Оговорюсь сразу, мы не используем в production окружении PostgreSQL в Docker. Но делаем это в локальной разработке и на dev-стендах. Почему? Потому что это чертовски удобно!

В этой статье я хочу рассмотреть типовые способы запуска ванильного (то есть чистого/оригинального) 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:

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

И тут мы сталкиваемся с первой проблемой: что вернёт нам запрос select version(); , выполненный в консоли? Мы не указали явным образом версию БД, которую хотим использовать. Давайте это исправим:

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

Отлично! С этого момента к базе данных можно подключиться, например, из IntelliJ IDEA:

Настройка подключения к БД в IntelliJ IDEA

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

psql можно запустить так: psql -U habrpguser -d habrdb

И соответствующий compose-файл:

Инициализация структуры БД

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

Это хорошо, но чистая база данных вряд ли будет сильно полезна. Для работы/тестов/экспериментов нужно наполнить эту базу таблицами и другими объектами. Разумеется, всё это можно сделать вручную, но, согласитесь, гораздо удобнее, когда сразу после запуска вы автоматически получаете полностью готовую БД.

Разработчики официального образа PostgreSQL естественно предусмотрели этот момент и предоставили нам специальную точку входа для инициализации базы данных — docker-entrypoint-initdb.d. Любые *.sql или *.sh файлы в этом каталоге будут рассматриваться как скрипты для инициализации БД. Здесь есть несколько нюансов:

если БД уже была проинициализирована ранее, то никакие изменения к ней применяться не будут;

если в каталоге присутствует несколько файлов, то они будут отсортированы по имени с использованием текущей локали (по умолчанию en_US.utf8).

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

Например, на моей машине это выглядит так:

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

Использование docker-compose файла в этом случае более удобно и позволяет указывать относительные пути:

Здесь хотелось бы акцентировать ваше внимание на одной простой вещи, о которой уже говорил в предыдущей статье: при создании миграций БД для ваших приложений отдавайте предпочтение чистому (plain) SQL. В этом случае их можно будет переиспользовать с минимальными затратами.

А куда сохраняются мои данные?

Базы данных – это в первую очередь история про персистентность. И. Хьюстон, кажется у нас проблема… К настоящему моменту мы никак не управляем долговременным хранением нашей базы данных. Эту задачу целиком на себя берёт Docker, автоматически создавая volume для контейнера с БД. Есть целый ворох причин, почему это плохо, начиная от банальной невозможности просматривать содержимое volume’ов в бесплатной версии Docker Desktop и заканчивая лимитами дискового пространства.

Разумеется, хорошей практикой является полностью ручное управление физическим размещением создаваемых баз данных. Для этого нам нужно подмонтировать соответствующий каталог (куда будут сохраняться данные) в контейнер и при необходимости переопределить переменную окружения PGDATA:

Вариант с макросом, использующий для инициализации БД скрипты из предыдущего раздела:

С однострочниками на этом закончим. Все дальнейшие шаги будем осуществлять только через compose-файл:

При запуске этого скрипта рядом с ним создастся директория pgdata, где будут располагаться файлы БД.

Healthcheck? Нет, не слышал…

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

Основная задача healthcheck’а – как можно скорее уведомить среду, управляющую контейнером, о том, что с контейнером что-то не так. И самая простая стратегия решения проблемы – перезапуск контейнера.

Так же стоит сразу позаботиться об ограничении ресурсов для контейнера с БД. Для экспериментов и локального запуска вполне подойдёт секция resources (флаг —compatibility больше не требуется).

Healthcheck для PostgreSQL обычно основывается на использовании утилиты pg_isready как показано ниже:

А если хочу изменить параметры БД?

Для администраторов PostgreSQL не секрет, что конфигурация СУБД из коробки далека от идеальной и не очень подходит для эксплуатации. Я немного рассказывал об этом в своей статье про pg-index-health: ряд параметров нужно изменить в обязательном порядке, так как они влияют на производительность. Так же существует большое количество расширений для Постгреса, которые сделают эксплуатацию БД более удобной, наблюдаемой и управляемой. Одно из таких расширений — pg_stat_statements (кстати, оно пригодится нам позднее для мониторинга БД).

Ванильный образ PostgreSQL позволяет тюнить параметры и добавлять расширения на старте контейнера БД:

Разумеется, можно указать свой postgresql.conf. Оставлю это в качестве домашнего задания.

Посмотреть список установленных расширений можно с помощью запроса select * from pg_extension; .

А команда show позволит узнать текущее значение того или иного параметра, например: show random_page_cost; .

Не люблю консоль; дайте мне человеческий UI!

Далеко не все пользователи любят работать с БД из командной строки. Очень многие предпочитают использовать для этого продвинутый графический интерфейс, например pgAdmin.

Запустить ещё один контейнер, в котором будет бежать GUI, не сложно, но для удобной коммуникации с БД их лучше объединить в одну сеть:

pgAdmin стартует на порту 5050: перейдя на нужный адрес, можно будет настроить подключение к БД.

К БД можно подключиться как по имени контейнера, так и по имени сервиса

А как насчёт мониторинга?

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

PostgreSQL не имеет встроенной интеграции с системами мониторинга наподобие Prometheus (или Zabbix). Вместо этого он полагается на использование внешних агентов — экспортеров. Мы у себя активно используем postgres_exporter, позволяющий добавлять свои собственные sql-запросы и кастомные метрики на их основе:

После запуска скрипта экспортер будет доступен на порту 9187 и отдавать метрики в формате Prometheus:

Разумеется, для полноценной постановки на мониторинг нужно ещё поднять сам Prometheus + Grafana, а так же загрузить подходящий dashboard, но это уже выходит за рамки данной статьи. Более того, если ваша служба информационной безопасности исповедует Zero Trust, то экспортер придётся прикрыть с помощью nginx и настроить mTLS.

В качестве заключения

На этом у меня всё. Приведенной выше конфигурации более чем достаточно для развёртывания БД PostgreSQL в Docker-контейнере на стенде разработки или локально.

Все приведённые в статье команды и docker-compose файлы также доступны на GitHub.

Источник