можно

did

но контейнер должен быть в привелигированном режиме запущен(но давно не пробовал) или внутрь контейнера пробрасывается сокет от хостового докера и по факту контейнер стартует на хосте

но зачем?

всякое в голову лезет))

а у тебя какой CI? gitlab из коробки умеет сервисы запускать

Битбакет и дженкинс соответственно

cat и grep нормально работают с файлами > ТБ

Если не ошибаюсь, то есть уже готовые образы баз данных, заточенных для тестирования. Я в своё время делал такой свой для постгри. Там на самом деле очень много времени занимает инициализация кластера постгри. Поэтому я для своего образа просто выполнил инициализацию, создал все базовые структуры (юзера, базу данных), упаковал все файлы базы в tar и засунул в образ. При запуске контейнера tar распаковывается в папку постгри (которая на самом деле tmpfs подсунутая докером), после чего запускается постгря.

Ну и там ещё другие хаки (например отключение fsync и доп. настройки в конфиге).

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

А зачем нужен был хак с tar? Просто проинициализированную базу со всеми файлами в образе держать нельзя было?

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

Ну и фишка в том что данные базы лежат в tmpfs которая монтируется при запуске контейнера - в образе её нет. Потому и надо откуда-то в образе достать "дамп" и развернуть его в tmpfs. Самое быстрое было копировать из tar или может даже tar.gz (помню что подбирал вариант с максимальной скоростью "распаковки")

Чёт сложно, но ок, я ж тонкостей не знаю

Я б наверное начал с отдельного слоя незаполненной базы, а новые таблицы плодил отдельными слоями

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

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

То же самое примерно, но без дополнительных сущностей

Всё что я описывал - это для кейса, когда сами тесты запускают контейнер с базой перед своим запуском и гасят его при завершении (в pytest это фикстура с scope="session").
В других реализациях можно и по другому подойти к вопросу - например просто запустить в докере перстистентную тестовую базу и не убивать её.

Кроме того быстрый SSD может в теории ликвидировать необходимость использования tmpfs. Тогда можно всё что я выше писал про tar файл не делать и просто засунуть в образ уже проинициализированный кластер.