Coolify это бесплатный инструмент, который позволяет легко запускать приложения на ваших серверах и управлять ими через визуальный интерфейс.
В прошлых статьях мы уже разобрались, как подготовить сервер, затем установить на нём Coolify и запустить простые приложения из GitHub.
А сегодня посмотрим, как с помощью Coolify создать базу данных на своем сервере и какие преимущества это даёт.
❯ Создание базы
Сначала заходим в Проекты (Projects). Там создаем новый проект или заходим в существующий.
Затем в проекте нажимаем кнопку «Добавить ресурс». Открывается страница создания нового ресурса.
На этой странице есть на выбор 3 группы ресурсов: Приложения (Applications), Базы Данных (Databases) и Сервисы (Services).
На момент написания статьи в Coolify предлагается 8 вариантов баз для установки: PostgreSQL, MySQL, MariaDB, Redis, KeyDB, Dragonfly, MongoDB, ClickHouse.
Отметим, что в группе Services можно найти и сервисы вида Backend-as-a-service со встроенными базами данных. Например, Supabase, Pocketbase или Directus. Но это немного другая история, и сегодня мы не будем их рассматривать.
Отметим также, чтобы если нужной вам базы нет в списке, то вы всё равно сможете её поставить, но уже через Приложения (Applications). Только тогда вам самим нужно будет настраивать её запуск. Например, через файлы Dockerfile или Docker Compose. Мы разбирали работу с Приложениями в прошлой статье про Coolify.
Сегодня в качестве примера мы возьмем PostgreSQL — самый популярный вариант реляционной БД для серьезных проектов.
После того, как вы выбрали базу данных из списка, предлагается выбрать сервер. Это может быть ваш сервер с Coolify (по умолчанию он называется localhost) или же отдельный дополнительный сервер. Второй вариант лучше, потому что в целом лучше размещать все приложения, базы и сервисы отдельно от админки Coolify.
После этого вам будет предложено выбрать версию PostgreSQL.
По умолчанию предлагается последняя версия, на момент написания статьи это PostgreSQL 18. При необходимости можно выбрать и другой вариант. Например, Supabase PostgreSQL, если вы переносите свою базу из Supabase или вам просто нравятся дополнительные возможности, которые есть в этой версии.
❯ Основные параметры подключения
После этого мы попадаем на главную страницу настройки созданной базы. Сама база данных на данный момент пока что еще не запущена.
Страница настроек базы в целом напоминает страницу настройки приложения, но со своими особенностями.
Первым идёт блок General.
Здесь мы можем поменять имя (Name) ресурса. По умолчанию будет что-то вроде «postgresql-database-ak2qve0elfobwleejabxdtdw». Можно оставить имя или поменять на что-то более подходящее, например «myproject-pg-prod», где «myproject» — название вашего проекта, а «prod» — роль окружения (тестовая база или для продакшена). При этом учтите, что во всей вашей системе Coolify не должно быть одинаковых названий у ресурсов.
Тут же вы можете поменять имя вашей базы данных (Initial Database), логин (Username) и пароль (Password), или же можно оставить варианты по умолчанию. Для большей наглядности заменим Username на «user1», а Initial Database на «default».
Чтобы изменения применились, не забываем нажимать кнопку Save сверху возле заголовка.
Остальные поля этого блока пропустим, потому что это уже специфичные настройки.
❯ Настройки сети и SSL
Для подключения к базе данных нужно знать параметры подключения: адрес, порт, название базы, логин и пароль. Чаще всего их объединяют в одну строку, которая называется URL для подключения.
И в блоке Network (Сеть) есть поле Postgres URL internal — это URL для подключения к базе из внутренней сети, к которой подключен данный ресурс.
Внутренние сети в Coolify называются Destinations, и по умолчанию все ресурсы, кроме сервисов и приложений с Docker Compose, объединяются в одну внутреннюю сеть «coolify».
Значит, в эту сеть по умолчанию попадёт и наша созданная база данных. И другие ресурсы из этой сети (например, веб-приложения) смогут подключаться к ней по Internal URL.
Обратите внимание, что если вы поменяете какие-то параметры подключения к базе (логин, пароль и т. д.), то они автоматически поменяются и в URL для подключения. Однако это происходит только после сохранения изменений по кнопке «Save».
Если же доступ к базе нужен вне внутренней сети, то для этого нужно настраивать внешний доступ.
Один вариант, это напрямую использовать поле Ports Mappings, что позволяет пробрасывать порт контейнера наружу, т. е. связать его с каким-то портом сервера. Например, если прописать 3000:5432, то при обращении к серверу по порту 3000 мы будем общаться с базой, если она слушает порт 5432.
Но вообще для включения удобного внешнего доступа к базе в её настройках есть специальная опция Public URL, и позже мы вернёмся к этой теме.
Дальше идёт блок SSL Configuration с одной галочкой — Enable SSL. Если её включить, то для подключения будет использоваться SSL, что при правильной настройке обеспечит шифрование данных и безопасность подключения. Это полезная функция, однако мы не будем на ней останавливаться. Пока для подключения в тестовых целях можно оставить как есть.
❯ Запуск базы и проверка
Теперь запустим базу данных. Для этого нажмите кнопку «Start» в верхнем правом углу.
Откроется окно лога, по которому можно отследить процесс запуска контейнера с базой. Если установка пройдет нормально, то через несколько секунд база данных будет запущена.
Об успешном запуске будет говорить то, что индикатор состояния ресурса в верхней части страницы станет зеленым и будет сообщать «Running (Healthy)», а кнопки сверху справа сменятся на «Restart» (перезапустить) и «Stop» (остановить).
Но на всякий случай убедимся лично, что база запущена и работает. Для этого нам нужно сначала зайти в терминал контейнера.
Переходим на вкладку Terminal. Там открывается консоль, где мы запустим встроенную консольную программу для подключения к базе:
psql "postgresql://user:password@host:5432/dbname"
Только вместо "postgresql://user:password@host:5432/dbname" будет ваш Internal URL для подключения.
Если всё ок, то мы увидим сообщение psql (18.3) Type "help" for help. и далее default=# в начале строки, где «default» — название вашей базы.
Для проверки создадим таблицу:
CREATE TABLE pokemons ( id SERIAL PRIMARY KEY, name TEXT, element TEXT );
Заполним ее данными:
INSERT INTO pokemons (name, element) VALUES ('Pikachu', 'Electric'), ('Charmander', 'Fire'), ('Bulbasaur', 'Grass');
И для проверки тут же запросим эти данные:
SELECT * FROM pokemons;
Если всё ок, то увидим такой ответ:
id | name | element ----+------------+---------- 1 | Pikachu | Electric 2 | Charmander | Fire 3 | Bulbasaur | Grass
❯ Внешнее подключение к базе
Иногда вы хотите сделать базу доступной не только из внутренней сети ресурса, например:
Для доступа к базе с вашего локального ПК. В целях разработки или чтобы работать с базой через локальную UI-программу, вроде pgAdmin.
Для приложений, которые не управляются через вашу админку Coolify.
Для ресурсов в Coolify, которые явно назначены в другую внутреннюю сеть (Destination).
Для ресурсов, которые по умолчанию работают в своих внутренних сетях — это Сервисы (Services) и приложения с Docker Compose.
Чтобы включить внешнее подключение, нужно сначала указать порт. На странице настроек базы для этого есть поле Public Port в блоке Proxy. По умолчанию в поле уже есть подсказка, какой порт обычно используется для такого типа базы. Например, для PostgreSQL это 5432.
При этом нужно учитывать, чтобы указанный порт на вашем сервере не был занят другой базой данных или другим приложением, иначе будет возникать ошибка. Если порт 5432 уже занят, то можно спокойно указать следующий свободный — 5433, 5434 и т. д.
Также важно, чтобы данный порт был открыт в настройках файрвола вашего сервера.
Например, если вы создали VPS в Timeweb Cloud, то всё проще, потому что управление портами тут работает по принципу чёрного списка — по умолчанию будут открыты все порты, кроме явно закрытых. Точный список закрытых портов можно увидеть на дашборде сервера в панели справа.
Как видно, порта 5432 нет в списке закрытых, поэтому он сразу будет работать, если указать его в Coolify.
Но у других облачных провайдеров может быть и обратная ситуация — когда все порты по умолчанию закрыты, пока их явно не откроют в настройках файрвола. Этот момент вам нужно будет проверить у вашего провайдера самостоятельно.
Итак, когда порт будет открыт и прописан, включите галочку «Make it publicly available», чтобы включить внешнее подключение к базе. Уточним, что это можно сделать только тогда, когда база запущена.
После этого выше в блоке Network появится поле Postgres URL (public) — с URL для внешнего подключения к базе.
Для проверки попробуйте подключиться к базе с вашего локального ПК. Можно использовать консольные программы или же бесплатные программы с UI, вроде pgAdmin, Beekeeper Studio или DBeaver.
Имейте в виду, что даже с надежным паролем внешнее подключение к базе — это лишняя потенциальная уязвимость. Поэтому не открывайте его без явной надобности.
❯ Логи базы
В случае каких-то проблем с базой вам в первую очередь захочется посмотреть в логи контейнера.
Для этого в ресурсах Coolify есть вкладка Logs (Логи).
❯ Подготовка S3-хранилища для бэкапов
Если данные, которые хранятся в базе, имеют для вас хоть какую-то ценность, то надо обязательно настроить для этой базы автоматическое резервное копирование — бэкапы.
Для этого сначала нужно подготовить внешнее S3-хранилище, где эти бэкапы будут храниться. Потому что хранить бэкапы на том же сервере, где у вас база — ненадежно, да и будет отниматься ценное место.
Во-первых, нужно включить S3-хранилище в панели вашего облачного провайдера.
Например, в Timeweb Cloud для этого переходим в раздел «Хранилище S3» и нажимаем «Добавить», чтобы перейти на страницу создания нового бакета — пространства для хранения файлов.
Заполняем открывшуюся форму:
Выбираем «Холодный» класс хранения — он создан специально для резервного копирования и других случаев, когда обращение к файлам происходит очень редко.
Выбираем тип «Приватный», потому что нам нет необходимости раздавать файлы по ссылке для всех желающих.
«Имя бакета» для наглядности лучше отредактировать. Можно в начале добавить что-то своё, например «coolify-backups». Но при этом часть названия лучше оставить рандомизированной. Потому что имя должно быть уникальным по всем клиентам провайдера. В итоге получится что-то вроде «coolify-backups-e85f5d1d6790».
Нажимаем «Заказать».
Когда бакет будет создан, то на его главной вкладке в блоке справа будут все нужные параметры для подключения к бакету. В первую очередь, это: S3 URL, Название бакета, S3 Access Key, S3 Secret Access Key и Регион.
Теперь нужно добавить этот бакет в вашей админке Coolify. Для этого заходим в раздел S3 Storages и нажимаем «Add». В открывшейся форме вносим все нужные данные для подключения и нажимаем «Validate Connection and Continue».
Если всё ок, подключение к S3 будет создано и сверху будет сообщение «Current Status: Usable».
❯ Включение и настройка бэкапов
Теперь, когда S3-хранилище готово, можно вернуться на страницу настройки базы данных и перейти на вкладку Backups (Бэкапы).
У одной базы может быть несколько разных задач бэкапов. По умолчанию их нет, т. е. резервное копирование не включено. Чтобы добавить новую задачу, нажимаем «Add».
Откроется окно с формой создания новой задачи резервного копирования.
Сначала нужно указать Frequency — частоту выгрузки бэкапов. Можно написать просто словом daily (ежедневно), weekly (еженедельно) и т. д., а можно использовать cron-выражение, например 0 0 * * * — это значит «каждый день в 00:00». Правильно составить выражение можно на специальных сайтах, вроде этого.
Частоту выгрузки определяйте по своей ситуации, в зависимости от того, как часто обновляются данные.
По умолчанию бэкапы сохраняются только локально, т. е. на сервере с базой. Чтобы сохранять их ещё и в S3, ставим галочку «Save to S3» и выбираем S3-хранилище, которое мы подготовили до этого. Нажимаем «Save».
Видим, что задача на резервное копирование появилась в списке.
Но нельзя оставлять задачу в таком виде! Дело в том, что по умолчанию бэкапы будут храниться бесконечно. Для холодного S3 это не так критично, потому что гигабайты там дешёвые, но место на сервере обычно очень ценно, и если не ограничить число бэкапов, то ваш сервер скоро будет забит.
Поэтому кликаем, чтобы перейти в детальные настройки задачи бэкапа.
Нас интересует блок «Backup Retention Settings», в котором 2 раздела:
Local Backup Retention — ограничения локального хранения.
S3 Storage Retention — ограничения хранения в S3-хранилище.
Ограничения можно включать по трём признакам:
Число бэкапов (Number of backups)
Число дней хранения (Days to keep)
Максимальный объем (Maximum storage (GB))
Можно использовать один из этих признаков или сразу несколько. Как только будет срабатывать любое из этих правил, Coolify сам будет удалять старые бэкапы.
Выбирайте настройки на ваше усмотрение, но поскольку ключевой момент это занимаемое бэкапами место, то можно для начала поставить только Maximum storage (GB): 1 для local и 10 для S3.
Обязательно не забудьте нажать кнопку «Save» возле заголовка.
Также в настройках можно при необходимости поставить галочку «Disable Local Backup», чтобы вообще отключить сохранение бэкапов на сервере и оставить только S3. Тем не менее лучше оставить локальное хранение тоже, в качестве резерва. Но конечно с обязательным ограничением.
❯ Проверка бэкапов
Теперь для проверки нажмите «Backup Now» и через несколько секунд первый бэкап появится в списке ниже.
Для дополнительной проверки временно заменим частоту (Frequency) на */1 * * * *, что значит «каждую минуту». Это позволит убедиться, что автоматические бэкапы тоже работают. Поменяем значение и подождем, пока новый бэкап не появится в списке.
Не забудьте вернуть прошлое значение обратно.
После этого зайдите в S3 хранилище в панели облачного провайдера и убедитесь, что файлы бэкапов (т. н. «дампы базы») сохраняются в бакете.
И финально стоит убедиться, что сохраненные бэкапы валидны, и из них действительно получается успешно восстановить нужную базу.
Для этого снова подключимся к базе через терминал и удалим таблицу командой DROP TABLE pokemons; и затем командой SELECT * FROM pokemons; убедимся, что ничего не осталось.
Для импорта бэкапа на странице настроек базы есть боковая вкладка Import backup.
Можно загрузить файл дампа базы вручную или указать путь в S3-хранилище.
Для примера используем S3. В панели облачного провайдера в S3-хранилище находим нужный файл и копируем путь до него.
Вставляем этот путь, но при этом удалим из пути домен и название бакета, а также все query-параметры, чтобы остался только путь до файла внутри бакета, например «/data/coolify/backups/databases/root-team-0/myproject-pg-prod-ak2qve0elfobwleejabxdtdw/pg-dump-default-1774483206.dmp».
Нажимаем «Restore Database from S3», подтверждаем, видим лог операции и затем можем снова запустить SELECT * FROM pokemons; в терминале, чтобы убедиться, чтобы таблица и данные вернулись.
❯ Метрики
В настройках базы в боковой вкладке Metrics (Метрики) можно посмотреть, какую нагрузку на процессор (CPU) дает контейнер с базой и сколько оперативной памяти (Memory, RAM) он занимает.
Метрики в ресурсах доступны, только если они включены в настройках сервера.
❯ Приостановка базы
Можно приостановить работу базы, и этот процесс аналогичен тому, как происходит приостановка любого ресурса в Coolify.
Сначала нужно нажать на кнопку «Stop» в верхнем правом углу.
Перед остановкой Coolify запросит два подтверждения.
В первом окне просто запрашивается подтверждение, что вы действительно хотите остановить базу.
При этом есть чекбокс «Run Docker Cleanup (remove unused images and builder cache)», который сразу выбран. Это означает, что при отключении будет запущена очистка докера, в т. ч. будут удалены неиспользуемые образы и кэш сборки. Это полезный чебокс, потому что если за докером не подчищать, то диск вашего сервера быстро замусорится.
Но после этого появляется второе окно подтверждения, уже более грозное.
Coolify тут лишний раз поясняет, что именно произойдет при остановке ресурса:
База будет остановлена и перестанет быть доступна.
Если в данный момент с базой идет работа, то какие-то данные могут быть потеряны. Т.е. например, если какие-то данные прямо сейчас записываются в базу, то они могут не сохраниться до конца.
Все несохраненные в постоянных хранилищах (например, томах докера) данные будут удалены.
Будет запущена чистка от ненужных образов и кэша.
Здесь нужно подробней остановиться на третьем пункте.
Когда вы запускаете ресурс в Coolify, то создаются и запускаются нужные докер-контейнеры, а когда вы останавливаете ресурс в Coolify, то эти контейнеры останавливаются и удаляются. При этом все данные в этих контейнерах тоже удаляются.
Однако, если нужно сохранять данные постоянно, независимо от состояния контейнеров, то для этого в технологии Docker предусмотрены Постоянные хранилища (Persistent Storage) (не стоит путать с S3-хранилищами — это разное).
Например, в Coolify при первой настройке базы создаётся постоянное хранилище, которое называется Том (Volume). И данные для базы будут храниться там отдельно от контейнера. Поэтому, когда база останавливается и контейнер удаляется, то данные остаются.
Посмотреть список постоянных хранилищ ресурса можно в боковой вкладке Persistent Storage.
Таким образом, при остановке базы не стоит переживать о данных в целом — они сохраняются. Более того, сам Coolify в своём предупреждении явно говорит: «don’t worry, no data is lost and you can start the database again» — «не беспокойтесь, данные из базы не будут потеряны и вы сможете запустить базу данных снова».
Тогда возникает вопрос, а зачем тогда такое пугающее предупреждение? Дело в том, как мы уже заметили выше, подобный процесс приостановки ресурса — универсальный для всего Coolify. И такое же предупреждение показывается при остановке любого ресурса, например приложений. И во многих других случаях, если ваш проект не настроен правильно, то при остановке вы действительно рискуете вместе с удалённым контейнером навсегда потерять важную информацию: данные, файлы и т. д. Отсюда и потребность в предупреждениях.
Но в случае, когда ресурс это готовая база данных, можно относиться к этим предупреждениям спокойно.
После подтверждения база будет приостановлена через некоторое время. Её можно будет запустить повторно по кнопке «Start».
❯ Перенос базы
В боковой вкладке «Resource Operations» доступны некоторые действия с нашей базой:
Clone Resource — клонировать ресурс.
Move Resource — переместить ресурс.
Рассмотрим, как они работают.
Clone Resource почти полностью копирует данный ресурс на другой сервер. В дальнейшем можно удалить исходный вариант, и тем самым в результате мы сделали частичный перенос ресурса.
Но тут есть важный нюанс — при клонировании ресурса не происходит копирование «Постоянных хранилищ» (Persistent Storage) ресурса. А, как мы разобрались до этого, именно в Persistent Storage хранятся данные базы.
Т. е. когда вы копируете ресурс с базой, то данные не переносятся — их нужно переносить вручную. Например, через функцию бэкапирования, как мы показали выше.
А Move Resource позволяет перенести базу в другой проект или в другое окружение внутри Coolify, но в пределах текущего сервера. В таком случае данные сохраняются и их не нужно переносить вручную.
❯ Удаление базы
Полное удаление базы доступно в боковой вкладке Danger Zone (Опасная зона). Если нажать «Delete», то будет удален ресурс целиком, в том числе данные в постоянных хранилищах (Persistent Storage). Т.е. если потом потребуется восстановить данные, то это будет возможно только из бэкапов.
❯ Заключение
Как видно, работать с базами данных в Coolify вполне просто. Создание новой базы происходит в несколько кликов: достаточно выбрать нужный тип, указать сервер и можно запускать.
Управление базой максимально приближено к управлению другими ресурсами в Coolify. В том числе можно читать логи, работать с контейнером через терминал, отслеживать метрики и переносить ресурс между серверами и проектами.
При необходимости можно разрешить внешний доступ к базе и включать SSL для полностью безопасного соединения.
Также предусмотрены удобные инструменты для автоматического создания бэкапов.
В общем — есть всё необходимое, и всё это через удобный интерфейс.
Чтобы не пропустить мои следующие статьи: https://t.me/nickneustroev_blog
Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩
