Как через Github Actions развернуть на сервере в Докере СУБД со структурой моей БД?

Нужно выбирать пункт 2. Но не изобретать баш велосипед.

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

Прочитать документацию к образу mysql, который тянешь с докерхаба

Кстати, да. Сейчас займусь этим.

Ладно. https://hub.docker.com/_/mysql Собственно, там команда есть: $ docker exec -i some-mysql sh -c 'exec mysql -uroot -p"$MYSQL_ROOT_PASSWORD"' < /some/path/on/your/host/all-databases.sql

Ну, это понятно. Вопрос мой, вроде, не в этой команде.

Но да ладно.

Прииложение на React Я вас понял.

Я не кодер пока. Начинающий админ.

ну, ты как-то по диагонали читаешь..

Но да ладно. (тм)

держи (сам докерхаб у меня не откывается - заблочили cdn амазоновский, но в первоисточнике ты найдешь те же буквы)

Начинающий админ.

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

Спасибо.

А мне хочется поразбираться с Докером.

Ничего непонятно.

В какой момент и где ты разворачиваешь докер с базой данных?

Почему базу надо восстанавливать?

База же 1 раз восстановится в volume, и последующие пересборки images и перезапуски контейнеров на нее влиять не должны.

Вот это что значит? Ты базу удаляешь или что делаешь?

Ну, когда мы запускаем MySQL в Докере – там же сразу не может появиться наша БД с нашими таблицами и, возможно, с нашими данными. Верно?

А я хочу запустить в Докере сайт, который некоторое время уже поработал на тестах. База сайта уже немножко заполнена (хоть и тестовыми данными).

Причем, я хочу загрузить код сайта в репозиторий Гитхаба, настроить Github Actions на событие «push» нового коммита, чтобы по пушу нового коммита код сайта разворачивался в Докере на удаленном сервере. Хочу разобраться с этим, потому что нужно доработать сайт. Будет удобно настроить такой механизм: изменили код сайта, сделали пуш в репозиторий Гитхаба – по событию сделалась сборка в Докер-контейнерах на сервере – увидели результат.

Вопрос был с Базой сайта – как правильно её развернуть, чтобы тоже автоматом это было?

База же 1 раз восстановится в volume, и последующие пересборки images и перезапуски контейнеров на нее влиять не должны.

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

Поэтому, надо как-то в первый раз, когда мы только запустили контейнер с MySQL, присоединили к нему volume, создали чистую БД – как-то в первый раз восстановить из дампа нашу базу.

Вот я и думал, что можно один раз вручную, без Github Actions, закинуть дамп БД на сервер, и восстановить его в чистую БД контейнера MySQL.

Или можно автоматом через Github Actions дамп моей БД восстановить? Оно-то можно, но как лучше сделать – вот вопрос у меня.

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

Какой-то страшный антипаттерн тут обсуждается :)

Контейнер с приложением - это контейнер с приложением. Контейнер с БД - это отдельный контейнер, запуск которого никак не должен быть связа с пересборкой и запуском приложения. При пуше кода надо именно приложение пересобирать, а БД вообще ни при чем и ее надо исключить из уравнения. Иначе нахрен вам вообще этот докер и изоляции всякие, если вы фактически пытаетесь контейнер использовать как VM, на которой поднято все разом - и БД, и приложуха (как мне показалось из вопроса)

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

Вообще, есть ощущение, что топикстартер решил потыкать незнакомые технологии, но ушел немного не в ту степь :)

Во первых, прекрати использовать слова не по назначению.

Восстановить можно то, что было удалено или еще как нибудь испорчено. У тебя же «При уничтожении контейнера папка с базой никуда не исчезнет» то есть восстанавливать ничего не надо.

А надо проинициализировать БД. Это однократная операция. Нужно проверить, что папка с БД пустая и если так, выполнить скрипт. В докерах с БД обычно уже есть папочка, куда кидают скриптики инициализации БД.

https://forums.docker.com/t/create-mysql-db-through-init-sh/142992

Ладно. Мне пойду отдохну. А то внатуре бред написал.

Не, все правильно вы пишете. Да я так и думал в разных контейнерах все запускать. В одном контейнере — База, в другом — приложение.

Лады. Че-то я напутал.

Все это очень спорно.

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

Приложение надо пересобирать, но при обновлении приложения в общем случае меняется и схема бд. Логично держать текущую версию схемы (Инициализации базы и скрипты апгрейда с предыдущей версии) именно в проекте приложения, чтобы они обновлялись с оным.

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

Неужели только мне в голову стучатся мысли с вариациями вокруг термина «миграции баз данных»?

там же сразу не может появиться наша БД с нашими таблицами и, возможно, с нашими данными. Верно?

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

А вообще ты что-то не понимаешь в схеме, видимо.

1. У тебя есть исходники вебни.
2. У тебя есть настроенный экшнс.
3. Дергаешь экшнс по пушу в мастер, оно на раннере запускает сборку, в результате получаешь контейнер с актуальной версией.
4. Кладешь его в реджистри.
5. С этого же раннера дергаешь удаленный сервер, чтобы он выкачал и запустил новый контейнер вместо старого.
6. Всё.

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

А ещё там таймаут есть, если долго будет миграция шевелиться, то все кикнется. Таймаут то ли час, то ли полтора, не помню точно.