我也用了挺久docker了，只是一直都是亲力亲为，最近用得比较频繁，而知识库也需要更新了。docker命令一旦废弃，那么自己的命令就得改。我之前是有一个备忘录，记录下了所有的命令，需要的时候再拿出来贴上回车。

这是一件比较傻的事，毕竟做开发都知道要封几层，改起来的时候方便，为啥工具就不懂了呢。

docker-compose对于普通用户来说就是将命令变成了文件，方便存储和保存，需要时运行一下就可以部署大多数枯燥的命令回车。对于专业的人来说，容器的编排在业务上有着更大的作用。

而docker-compose的学习成本也很低，是docker官方收购回来的工具，今天用完才知道真的巴适。

Dockerfile用于镜像定制，Docker Compose 负责快速的部署分布式应用。这两者还是不要搞混，Docker有很多图形化的管理工具，我目前也由kitmatic转到了portrainer了。积极拥抱新东西，会带来很多便利。

其实有人的文档写得非常好了 中文版：https://yeasy.gitbooks.io/docker_practice/content/compose/

官方版：https://docs.docker.com/compose/compose-file/

从一开始，就是看这份文档玩的，现在依旧。只是网上大多没有相关的不那么复杂的自己玩的容器的yml文件，这里说下我的吧。

需求：我是本地docker，自己用于测试和折腾的，并不需要太多的高级做法，mysql容器几乎不会变更，不需要依赖在yml上。

解决办法，创建一个docker-compose.yml文件：

version: "3"
services:
   wordpress:
    container_name: 【容器名】
    image: wordpress:latest
    ports:
       - "【需要暴露的端口】:80"
    network_mode: "【自己创建的网络名 用于容器间的互相访问】"
    environment:
        WORDPRESS_DB_NAME: 【DB名】
        WORDPRESS_DB_HOST: 【mysq容器名】:3306
        WORDPRESS_DB_USER: root
        WORDPRESS_DB_PASSWORD: 【DB密码】
    volumes:
        - 【本地路径】:/var/www/html

我这里是单独的拆开了每个容器，其实不是docker-compose的主要用途，比如：docker-compose.yml中编排的容器本身就在同一网段中，不存在自己填写network_mode的问题。【上面的怎么写？我也只是把run命令按文档中的compose写法进行了替换操作，很简单，不用慌，mysql等等都是这样】

然后，想说啥来着，就是对于新手，yml文件有个要注意的地方。一级的命令，也就是services，是用于创建的，同样的，还有volumes放在换行顶格执行的时候，也是用于创建的：

如果要用本地已经存在的volume。。。

这其实是不符合人性化的一件事情，因为volumes创建时会对volume名称加上当前文件夹的前缀，也就是说，上面的例子中db_date会变成download_db_date（假设脚本在download目录下）

而如果你一定要直接复用，需要加上external: true ，例：

version: "3.7"
 services:
   db:
     image: postgres
     volumes:
       - data:/var/lib/postgresql/data
 volumes:
   data:
     external: true

官方文档：https://docs.docker.com/compose/compose-file/#external

参考：

https://stackoverflow.com/questions/60148581/re-using-existing-volume-with-docker-compose