docker mysql-container 卷映射到项目中的文件夹 - 安全吗？

Question

I want to start off with that I'm discovering docker now for a few days. I have setup a docker-compose.yml with a stack that I run for development on my local machine. In my docker-compose.yml I have also created a mysql-container with a volume that connects a folder in my project to the mysql folder that is living in the container.

project structure:

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

container:

  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

I push this project to git. A devil called "newbie" on my shoulder tells me "great. this way you are saving the database in the git repo each time you push", While there is an angel called "gutfeeling" that tells me be careful. This could go horribly wrong, but i'm not sure what yet.

My question is if this is a safe method, and if anyone can foresee any troubles with this method in the future. I am aware that if I would put this project on a live server, and pull the git repo onto that server it would overwrite the database with the changes made in the local database, still working on a solution for that one.

Thanks in advance,

Bram

Answer 1

First and recommended approach is to put docker/mysql in gitignore so by doing this you will not worry about live and local both will maintain on local backup.

Ignoring files

From time to time, there are files you don't want Git to check in to GitHub. There are a few ways to tell Git which files to ignore.

Create a local .gitignore

If you create a file in your repository named.gitignore, Git uses it to determine which files and directories to ignore before you make a commit.

A.gitignore file should be committed into your repository, in order to share the ignore rules with any other users that clone the repository.

The second thing you can try to mount a different path other than ./docker/mysql . For example

/home/dev/docker/myslq/ in dev machine or in your live /home/live/docker/mysql .

Better to go with the first approach and do not mess with directory names.

Answer 2

Exactly the problem is that exporting your git repo to a live server will erase the database which is not too good.

I wouldn't put the db into git. But simply the structure. The table creation / edition (what is often called migrations).

Django is a Python web framework and handles this pretty well. And helps to version the right things in git:

• The database structure and changes (migrations)
• Some raw data that should always be there (fixtures).

So for instance if you build a shop, you would save and put in git: the database structure, and the migrations (like when you add a new field to a table), and the initial data: categories, items, delivery modes, etc... but not the clients user accounts for instance.

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

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

Simply put, what you could do, is remove your mysql volume from git, and instead put the database creation scripts, with version.

Like v0.1 for the database creation, v0.2 a sql script that would alter some fields, etc...

And one script per table to do the inserts of initial data, so that if you lose your server for some reason, you can just import that initial data on your new server.

Answer 3

I suppose it depends on your project. I'm in the WordPress world, so I will use that as an example.

If you are developing a theme or a plugin that will be used by more than one person, it makes sense to only put the theme or plugin in versioning.

In this case I will use wp-env (a script that spins up a couple of docker containers, and set up standard a WordPress environment for me), and only put the theme and/or plugin folder that is linked to the container in versioning. There is no point to actually version the generate WP source or DB files here, because they can simply be regenerated with the wp-env command again.

On the other hand, if you are developing a complete website for a client, that depends on a combination of plugins and some settings, together with a custom theme you build, and maybe even one or two plugins you develop uniquely for that client, I've come to learn that I want to put my ENTIRE development environment in a git repo like this:

-- docker-compose.yml (spins up a wp container and a mysql container) -- data (the raw database files mapped to the mysql container) -- wordpress (the web root for the WordPress project, mapped to the wp container) --.git

The reason I think this makes sense, is that I can just go to another computer, pull the repository, run docker-compose up, and I have everything exactly in the state that I left it when I last pushed the project on my other computer.

Of course, if you are working with other people, this might require some extra coordination.

Also, as some people have pointed out, you cannot simply go and push your git repo to live. Instead, you could write a script that only pushes the relevant files to a live environment.