想问一个有关于 docker 的小白的问题。

[ggp1ot2]

最近用使用docker 搭了个 bookstack 文档。

之前只是学过一点docker的皮毛，了解点概念和最基本的命令。

现在项目必须要用docker，但是用的是docker-compose。

貌似比docker要简单点，没有印象中的docker pull ，docker run，也没有dockerfile什么的。

就一个yaml文件，配置好之后直接docker-compose up 就启了几个容器跑起来了。

==================

让我有点疑问的是，在这种情况下，还需要使用 git 来管理代码吗？

我除了 docker-compose 之外再也没有代码层面的操作。所有数据写入都是在容器起的端口的网页上操作。

如果我想换台机器部署已经写入数据的容器，我尝试了只需要带着 yaml 文件过去重新docker-compose up之后，替换掉 volumes 的几个文件夹就行了，数据都还在。

如果用 git ，是去管理数据库对应的文件夹吗？

================= 最后还想问一个感觉比较弱智的问题，有点想不明白，之前我用 github 管理项目，因为要频繁修改项目里面的各种文件，写代码，所以要 git 去管理。

对于 docker ，尤其是这种用别人弄好的镜像启动的 web 项目，启动完了就网页点点点，没有代码层面的直接改动，github 这样的工具还有什么样的作用呢？定期备份数据库不就完了。

还是说，github 可以实现，我托管某个 docker 项目，然后在新的机器上只要把项目文件夹拉下来，然后启动就能无缝恢复到项目最新的状态？

[sdk234]

你在管理页面上的操作最终还是写入到配置文件里了啊。这样你把配置文件的目录挂载到宿主机上，然后用 git 管理配置文件的更改不就行了？

[ggp1ot2]

@sdk234 #1 所以按照我的理解就是，我在网页上的任何操作，本质上都是修改了这个容器背后也就是 docker inspect 的 work 那个文件夹里面文件的内容。所以 git 应该管理这个文件夹。

[foam]

一时间不知道该从哪里开始纠正

[ggp1ot2]

@foam #3 哈哈哈哈，说你最想吐槽的吧，我虚心请假

[yidinghe]

docker-compose 并不是源码版本管理工具，git 才是。但你如果没有源码要管理，那自然用不着 git 。

[hsfzxjy]

干嘛老纠结 git 不放。定时备份几个 volumes 文件夹不就好了

[ggp1ot2]

@hsfzxjy #6 我目前就是这么做的，因为我发现，换台机器只要带着几个 volumes 文件夹就能恢复。。但就是纠结是不是有更优雅的方式

[hsfzxjy]

我自部署的几个服务都是这样的。你这些应该都是“数据”，而不是“代码”，用 git 才不优雅。

[ggp1ot2]

所以是不是有一种方案。

我 docker-compose 启动几个容器，运行一段时间后。我将当前的容器打包成镜像推到 git 上，这样我就有多个可以恢复的镜像文件了。

其实我本质上想知道的是，docker 运维工程师是怎样去管理项目，迁移项目的，总不能是最古老的备份文件夹吧。

不知道有没有大神解答

[seers]

git 全称叫分布式开源版本控制系统，多念几遍就可以解除你的疑惑

[foam]

Git 和 docker 解决的完全不是同一个问题。
1, Git 解决多人协作下的文件版本控制问题，管理的是源文件。
2, Docker 解决的是程序运行环境差异，程序运行依赖问题。
3, docker 镜像是由代码编译之后打包而成，这是产物。不应当放在 git ，该产物可以在 CI 这一步骤生成，即每次都基于基础镜像，从 git 拉取代码，编译代码，生成可执行文件，打包镜像，上传镜像。供 CD 步骤在服务器拉取镜像，启动容器。
4, 数据库和版本控制没关系。定期备份就行

[zpf124]

1 、docker-compose 是做容器编排的，是用来代替你写多条"docker run xxx -e a=1 -e b=2"这样内容的。 而 dockerfile 是用来制作镜像的，如果你有自己制作镜像的需求，那么用 docker-compose 也省略不了 dockerfile 。

2 、你实际上是再将 docker 当虚拟机用，你的用法其实是生成了一堆快照，然后用 git 来传递这个快照了，一般这种非代码且不太需要版本管理的，我不推荐用 git ，这种用法我一般推荐用网盘或者 nfs 或者对象存储。当然你如果只是把 github 当成一个免费的网盘也没问题，github 不禁止这么做。

3 、docker 启动 web 项目这类的常规用法其实是目录挂在，比如启动 nginx ， 你的做法是把文件扔到容器内，然后把整个容器做个快照下次再启动这个快照，项目文件改了就再做一个快照。
但更推荐的做法是，把 /var/www/，/etc/nginx 这些目录挂载到宿主机上某个位置，然后把这些目录打包转移走就可以了，下次启动还是使用 nginx 标准镜像，只要把这几个目录挂载上就可以。

[ggp1ot2]

@zpf124 #12 感谢耐心解答，你这几段话，我学到了很多

[zpf124]

另外，一般运维会涉及项目管理吗？ 源码和部署包管理不应该是开发人员来维护吗？
运维需要注意的是服务器上用户生成的数据资源，比如用户上传文件的目录，项目生成的用户数据文件目录。

另外你如果觉得文件夹备份太过古老， 那你可以去看看 docker 的插件，其中有些可以用来支持使用 nfs 或者对象存储来当作 volume 挂载点，也就是说采用这种方式，你迁移的时候只需要在新机器的 docker 上添加对应的 plugin 不用迁移文件就可以直接启动项目，不过用这种方式注意控制好网络权限，防止被人攻击。

[ggp1ot2]

@foam #11 「即每次都基于基础镜像，从 git 拉取代码，编译代码，生成可执行文件，打包镜像，上传镜像。供 CD 步骤在服务器拉取镜像，启动容器。」

我的项目不涉及代码，是不是就替换成「拉取基础镜像 - 运行生成底层目录 - 用有数据的目录替换」

[Aixiaoa]

对于 volumes 建议打包成压缩文件依靠定时脚本来做备份。
compose 的 yaml 文件如果变动频繁可以 git 管理。
想放到其他机器就带着压缩包和 yaml 过去就行了。
如果你想要那种“快照”式的用法。建议导出容器。然后在别的机器上导入。这种办法下 volumes 同样要跟着迁移。除非你不挂载 volumes 出来

[wdssmq]

tar -czvf "bak_XXXX-$(date +%Y-%m-%d-%H-%M).tar.gz" XXXX

[shixuedela]

代码编写->上传到 Git 服务器
镜像制作->dockerfile 文件打包构建镜像,默认本地,也可以上传到 dockerhub 或者私有仓库 dockerharbor
服务部署->docker run 或者 docker-compose 或者 docker-swarm 或者 k8s

容器是为了解决代码运行环境产生的技术.你可以把一个镜像理解成一个系统进程,只是这个进程包含了所有的代码和运行代码说需要的环境.
因为相同的代码可以存在差异性的问题,比如编写的程序会把数据库的信息单独放在配置文件里而不会写死在代码里,这里 docker volume 就解决了类似的问题,通过本机或者其他驱动把文件挂在到容器中,让容器可以读取你单独的配置,来达到不同的代码可以运行不通的实例的效果.
而 git 的作用的是代码的维护,你可以保存 dockerfile 文件以及 docker-compose 文件 以及一些配置文件上传到 Git,就可以达到快速迁移的目的.

现在运维的话一般都是通过 cicd 工具 Jenkins 或者 Git 来拉取代码,自动打包构建镜像,上传镜像.然后远程部署拉取更新镜像
而部署所需要的配置文件.代码.构建镜像所需要的 dockerfile 都是在 Git 里维护的.
docker 镜像一般都会上传到专门的 docker 镜像仓库维护 dockerhub