抬头仰望星空,是否能发现自己的渺小。

伪斜杠青年

人们总是混淆了欲望和理想

抛弃docker run,拥抱docker-compose

我也用了挺久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


0条评论

发表评论