How to connect to postgresql inside docker

Connect PostgreSQL in Docker from Your Local Host

Prerequisites

If you didn’t install them already look at these links:

You can check them via:

Build Container

Execute below command to create a PostgreSQL container:

This command will download Postgres 11.6 from Docker Postgre Hub.

If we look in detail:

I use PostgreSQL version 11.6 since I have it already but you can use whatever version you want.

Also if you leave tag blank docker will fetch the latest version.

However I definitely don’t recommend that since it may break your software stack.

Get Into the Container

After creating the container we can access it on our host:

Use the Container

Create a Database

We will create a database inside our PostgreSQL container:

Create a Table

Let’s create an example table inside our testdb:

Check Table/Relations

To check your table:

Use Docker Compose

Instead of raw docker command we can use docker compose to create and access to our PostgreSQL database.

Create a file named docker-compose.yml with below code:

Spin up our container:

This command builds, (re)creates, starts, and attaches to containers for a service.

Changelog

Connect to postgres in docker container from host machine

How can I connect to postgres in docker from a host machine?

From container I can connect successfully. Both from app container and db container.

List of dbs and users from running psql inside container:

DB image is not official postgres image. But Dockerfile in GitHub seem looking fine.

cat /var/lib/postgresql/data/pg_hba.conf from DB container:

I tried both users with no luck

Looks like on my host machine there is already PSQL running on that port. How can I check it?

6 Answers 6

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

I believe the problem is you have postgres running on the local machine at port 5432. Issue can be resolved by mapping port 5432 of docker container to another port in the host machine. This can be achieved by making a change in docker-compose.yml

Now the docker container postgres is running on 5433. (Locally installed postgres is on 5432) You can try connecting to the docker container.

I ran this on Ubuntu 16.04

And below from my mac to the VM inside which docker was running (192.168.33.100 is the IP address of the docker VM)

They both work for me.

PSQL version on VM

PSQL version on Mac

I had the same problem on elementary OS 5.0 while running postgres 10 official docker container though. I was able to connect from host using the ip of the running container.

You can change it to this:

This will make sure your host (totally different IP) can connect.

Since you’re running it in OSX, you can always use the pre-installed Network Utility app to run a Port Scan on your host and identify if the postgres server is running (and if yes, on which port).

Another potential solution:
As can be seen in this answer, mysql opens a unix socket with localhost and not a tcp socket. Maybe something similar is happening here.

Try using 127.0.0.1 instead of localhost while connecting to the server in the container.

Запускаем 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.

How to connect to Postgresql service inside Docker Swarm?

I have a Docker Swarm cluster setup with 3 servers(1 manager and 2 workers).

I started a Postgresql service using the command below:

I also created the data volume previously:

Now, I have another service that I want to start, which is basically a Java application that I bundled into a Docker image and I want to connect it to the postgresql service. I tried the following combinations for the url:

Any idea what could work?

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

You shall use a swarm overlay network to connect to your database inside swarm mode.

First create the overlay network:

Then make your postgresql service use this network:

Then, don’t forget to use the same network for your Java application container:

Then you can connect to your postgresql through DNS name like:

All service’s containers in the mynet network (you can call it as you want, it’s just a name reference), have DNS entries corresponding to service name. This is easier than having to retrieve container’s IP through docker inspect before launching your java application.

This SO QA also talks about overlay network.

Установка и настройка PostgreSQL в Docker

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

Зачем добавлять PostgreSQL в контейнер

Главное преимущество контейнеризации — сохранение и быстрое развертывание зависимостей. Для наглядности посмотрим, какие зависимые пакеты устанавливаются вместе с приложениями при установке СУБД на сервер с ОС Debian.

Заводим сервер на cloud.timeweb.com и устанавливаем PostgreSQL:

При выполнении команды install postgresql обращаем внимание на строчки в начале:

Postgres download приводит с собой ещё шесть библиотек: libllvm11, libpq5, libsensors-config, libsensors5, libxslt1.1 и libz3-4.

Теперь посмотрим список зависимостей PostgreSQL 13:

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

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

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

И это не все преимущества PostgreSQL в Docker. С контейнерами возрастает и отказоустойчивость. Если сервер перестаёт работать, можно запустить контейнер на другой машине и не беспокоиться о параметрах конфигурации.

Установка PostgreSQL в Докер из образа

Посмотрим, как выполняется установка PostgreSQL в Ubuntu. Сначала установим Докер.

Добавляем ключ для работы с Docker Hub:

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

Запускаем Docker и настраиваем его автозагрузку с помощью системной утилиты systemctl :

Пока изолированная среда не запущена, в ней нет никаких данных. Нам это не подходит. Поэтому создаем Docker Postgres Volume — каталог для хранения данных.

Устанавливаем образ Postgres из Docker Hub с помощью команды docker pull :

Установка PostgreSQL завершена, всё готово к запуску.

Запуск контейнера

Выполним команду docker run :

Разберём ключи, которые передали вместе с docker run :

При выполнении команды может возникнуть ошибка «Error starting userland proxy: listen tcp4 0.0.0.0:5531: bind: address already in use». В таком случае смотрим, какой процесс занимает порт 5531:

После устранения ошибки снова пробуем запустить Докер:

Подключение к PostgreSQL

Подключаемся к БД и выполняем тестовый запрос:

Ответ должен быть таким:

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

Подключиться к контейнеру можно и с помощью docker exec с ключами:

Результат тот же — приглашение к вводу запросов:

Ключи выглядят непонятно, давайте их разберём:

Чтобы протестировать соединение, создадим новую таблицу, заполним её и выполним запрос:

После выполнения запроса остановим контейнер командой docker stop:

Здесь мы обнаруживаем брешь в безопасности. Файлы и процессы, которые создаёт контейнер, принадлежат внутреннему пользователю postgres. Из-за отсутствия пространства имён внутри контейнера UID и GID могут быть произвольными.

Проблема в том, что на самом сервере с этими же UID и GID могут быть другие привилегированные пользователи и группы. Потенциально это приводит к ситуации, когда пользователь получает доступ к каталогам хоста и может завершить любой процесс. Избежать такой ситуации можно, указав при запуске переменные USERMAP_UID и USERMAP_GID.

Запуск PostgreSQL с помощью docker-compose

Сначала создадим файл YAML:

Затем установим Docker Compose:

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

Если в терминале появилось приглашение к вводу запроса, значит подключение прошло успешно.

Проверка состояния

Примерная PostgreSQL-настройка в YAML-файле:

Обратите внимание на секцию resources. В ней можно ограничить ресурсы для БД. Такой подход разумен для локального запуска и экспериментов.

Заключение

В этом руководстве мы изучили нужные для установки PostgreSQL-команды Docker и Docker Compose, а также особенности развертывания контейнера и соединения с локальной машиной.