摘要：最近使用 docker-compose 构建了一个 sonarqube 的 server，其中学习了若干 docker-compose 的知识，在此总结一下创建过程中遇到问题（坑）
docker-compose
简单的说就是把一系列 docker 相关的东西放到一起，通过一个文件来 compose 这些内容，从而让孤立的点连成一条线或者组成一个面。通过这个文件能够快速重现复杂系统的搭建。
比较典型的场景就是，一个 web 服务需要数据库支持，同时可能还有 nginx 的反向代理需求，这样搭建该系统实际上是需要三个 docker 的容器，如果我们逐一创建然后再配置，当然没问题，但是这样做有很多缺点：
- 配置过程容易出错
- 配置过程不容易记录，从而很难简单的重现，大部分情况需要附加说明配置文档
- 如果更改配置，可能需要重新部署
如果使用 docker-compose，就能将多个 container 的关系提前定义好，就像一个乐谱，然后再使用 docker-compose 一下将定义好的容器和关系逐一建立，将乐谱演奏出来。这样一方面我们可以使用这个乐谱完整记录配置过程，其次该乐谱可以无限重复使用。所以搭建复杂的 docker 服务组，建议使用 docker-compose
docker-compose 学习
这里简单介绍 docker-compose 的学习，由于目前没有系统学习，只是根据目标来及时的学习，所以这里只说一下目前个人感想。
docker-compose 的学习分两部分：docker-compose 命令选项和 docker-compose.yml 文件的编写。
最权威肯定是参考官方的文档：
前者参考：docker-compose cli 参考
后者根据版本参考（比如第二版）Compose file version 2 reference
基本官方文档能够解决大部分问题。
docker-compose 搭建 sonarqube 服务实例
sonarqube 有官方的 docker 镜像，以及 dockfile 的 Github 主页，但是其 docker-compose.yml 很久没有更新过，这里需要注意一些问题。
docker-compose.yml 解释
这里使用第二版，然后有两个 service：db 和 sonarqube。 顾名思义一个是数据库，另外一个就是 sonarqube 服务。服务下面的定义类似于 dockerfile，需要参考不同的镜像手册。
比如 postgres 镜像，需要使用 POSTGRES_USER 和 POSTGRES_PASSWORD 来设定数据库访问的用户名和密码。而 sonarqube 镜像需要配置三个参数：SONARQUBE_JDBC_USERNAME, SONARQUBE_JDBC_PASSWORD and SONARQUBE_JDBC_URL。
所以这里原始的配置 sonarqube 缺少了两个变量，需要自行加入 SONARQUBE_JDBC_USERNAME 和 SONARQUBE_JDBC_PASSWORD
多个服务关系如何表示？
使用 depends_on。 因为 sonarqube 依赖 db，所以 sonarqube 服务需要 depends_on db
volumes 如何定义
一般我们只需要把本地的路径映射到容器内部的路径。其中 :z 选项为 SELinux 相关：如果宿主机开启了 SELinux，如果不加 “:Z”，会报错权限不足：Permission denied。这涉及到label权限的问题。 默认情况下 docker 会打上label: svirt_sandbox_file_t。 宿主机上需要 mount的目录，此时需要打上同样的label：使用:z相当于执行语句：
另外如果将 volume 列在最下面而不定义本地路径，则表示使用 docker 默认的路径映射 volume.
自动重启
通过设定 restart: always 可以实现服务自动重启。注意所有的服务都需要重启，这个选项的默认值为 no，一般在测试 compose 文件的时候不要开启，成功运行后再重新打开。
哪些常用命令？
执行 compose： docker-composer up
停止运行： docker-composer down
删除：docker-composer rm
容器启动后可以使用 docker 的命令和容器交互。
比如查看容器是否设置的重启 docker inspect sonarqube | grep Restarting
其他问题
如果在测试 compose 文件时出错了，尤其是数据出错，需要删除在 volume 中生成的文件，否则再次执行 up 的时候还会失败。