Том mysql-контейнера docker, сопоставленный с папкой в ​​проекте - безопасно?

Question

Я хочу начать с того, что я открываю докер сейчас на несколько дней. Я настроил docker-compose.yml со стеком, который я запускаю для разработки на моей локальной машине. В моем docker-compose.yml я также создал mysql-контейнер с томом, который соединяет папку в моем проекте с папкой mysql, которая находится в контейнере.

структура проекта:

Project
|-- project folder 1
|-- project folder 2
|-- project folder 3
|-- docker
|   `-- mysql
|-- file1
|-- file2
`-- docker-compose.yml

контейнер:

  mysql:
        image: mysql:5.7
        ports:
          - "3306:3306"
        restart: always
        environment:
          MYSQL_DATABASE: xxx
          MYSQL_USER: xxx
          MYSQL_PASSWORD: xxx
          MYSQL_ROOT_PASSWORD: xxx
        networks:
          - network-woo
        volumes:
          - ./docker/mysql:/var/lib/mysql

Я отправляю этот проект в git. Дьявол по имени «новичок» на моем плече говорит мне: «Отлично! Таким образом, вы сохраняете базу данных в git-репо каждый раз, когда нажимаете». В то время как есть ангел по имени "gutfeeling", который говорит мне быть осторожным! Это может пойти ужасно неправильно, но я не уверен, что еще.

Мой вопрос заключается в том, является ли это безопасным методом, и может ли кто-нибудь предвидеть какие-либо проблемы с этим методом в будущем. Я знаю, что если бы я разместил этот проект на работающем сервере и перетащил git-репо на этот сервер, он бы перезаписал базу данных изменениями, внесенными в локальную базу данных, все еще работая над решением для этого.

Заранее спасибо,

Брэм

Answer 1

Именно проблема заключается в том, что экспорт вашего git-репо на работающий сервер сотрет базу данных, что не слишком хорошо.

Я бы не стал вводить БД в git. Но просто структура. Создание / редактирование таблиц (то, что часто называют миграциями).

Django - это веб-фреймворк Python, который прекрасно справляется с этим. И помогает корректировать правильные вещи в git:

• Структура базы данных и изменения (миграции)
• Некоторые необработанные данные, которые всегда должны быть (фиксаторы).

Так, например, если вы строите магазин, вы должны сохранить и поместить в git: структуру базы данных и миграции (например, когда вы добавляете новое поле в таблицу), а также исходные данные: категории, элементы,например, способы доставки и т. д., но не учетные записи пользователей клиентов.

https://docs.djangoproject.com/en/2.2/topics/migrations/

https://docs.djangoproject.com/en/2.2/howto/initial-data/

Проще говоря, то, что вы могли бы сделать, это удалитьваш том mysql из git, и вместо этого поместите сценарии создания базы данных с версией.

Как v0.1 для создания базы данных, v0.2 сценарий sql, который изменил бы некоторые поля и т. д ...

И по одному скрипту на таблицу для вставки исходных данных, так что если вы по какой-то причине потеряете свой сервер, вы можете просто импортировать эти исходные данные на новый сервер.

Answer 2

Первый и рекомендуемый подход состоит в том, чтобы поместить docker/mysql в gitignore , так что при этом вы не будете беспокоиться о оперативном, а локальном оба будут поддерживать локальное резервное копирование.

Игнорированиеfiles

Время от времени появляются файлы, которые вы не хотите, чтобы Git регистрировал на GitHub. Есть несколько способов сообщить Git, какие файлы игнорировать.

Создать локальный .gitignore

Если вы создаете файл в своем хранилище с именем .gitignore, Gitиспользует его, чтобы определить, какие файлы и каталоги следует игнорировать перед выполнением фиксации.

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

Второе, что вы можете попытаться смонтировать другим путем, отличным от ./docker/mysql. Например,

/home/dev/docker/myslq/ на компьютере разработчика или в вашем прямом эфире /home/live/docker/mysql.

Лучше придерживаться первого подхода и не связываться с именами каталогов.