环境：
os:=====>centos 7.4
docker:=====>1.13.1
docker-compose:=====>1.23.2
image:=====>php:7.2-apache
image:=====>mysql:5.7问题表现：
使用同一个docker 镜像启动服务，一部分节点启动服务正常，一部分节点容器内服务启动报错！
问题起因：
公司需要建立官网站点，使用wordpress服务，借助docker的可移植性，自己封装了一组运行环境。将运行服务环境结合docker-compose 做了标准化，以后再需要其它博客站点随时可以拉起一组环境，简单、方便、快。
启动第一组环境时很顺利，启动站点初始化、插件安装，很快就顺利完成了（第1台主机）。很Happy！但是在按照同样的环境方法在另外一台主机启动另外一套环境时，遇到了一个看似很简单，又略坑的问题。使用同样的docker-compose文件启动wordpress 环境，发现wordpress 服务无法启动，查看日志，发现打印错误日志如下：
docker-compose :
https://blog.51cto.com/michaelkang/2362202
报错内容：
2019/5/23 下午9:51:18AH00534: apache2: Configuration error: No MPM loaded.
2019/5/23 下午9:51:28[23-May-2019 13:51:28 UTC] PHP Warning: Module 'ldap' already loaded in
。。。。。。。。 略 。。。。。。。。。。
2019/5/23 下午9:51:28[23-May-2019 13:51:28 UTC] PHP Warning: Module 'ldap' already loaded in Unknown on line 0
2019/5/23 下午9:51:28AH00534: apache2: Configuration error: No MPM loaded.
PHP Warning: Module 'ldap' already loaded in Unknown on line 0开始排查
1
初步看到报错内容，有点怀疑拉起的镜像有问题，docker最牛B的特性就是可移植性，Image 没问题的话，不可能再起一套环境配置就报错啊！此时为了排查这个问题，修改了一下ci脚本，重新触发了一次构建，除了重新构建镜像还把镜像存储到了另外一个docker registry仓库。然后修改compose 文件修改拉取镜像地址为新的镜像仓库地址。然后再次启动wordpress环境，结果还是无法启动。报错核心内容如下：
2019/5/23 下午9:51:18AH00534: apache2: Configuration error: No MPM loaded.
2019/5/23 下午9:51:28[23-May-2019 13:51:28 UTC] PHP Warning: Module 'ldap' already loaded in
还是老样子 ！！！
2
此时有点动摇，有点怀疑构建镜像是修改的配置文件有问题，就登陆到之前启动的wordpress 镜像内部，逐个核对配置，重点查看了 apache 的MPM loaded 配置文件，竟然镜像里面的配置都是对的。深吸一口凉气。。。。。。
3
怀疑这台主机的docker环境配置或者docker版本有问题，开始与能够成功启动的服务主机的系统配置做对比，现在的主机跟已成功启动环境的主机配置略有不同，开始执行相关操作，将系统内核，docker版本，系统配置等等都搞成一致的。然后再次启动服务。然后再次启动服务，wordpress 服务依然无法启动，报错日志依旧相同。 ( ⊙ o ⊙ )啊！
4
怀疑docker存储有问题目录有问题 ，删除所有本机已经下载images，重新启动还是报错，还是报错，不行。。。。
5
再残忍一点，
删除docker软件包，然后再删除docker的存储目录，
重新安装配置docker，再次启动，还是不行！对docker 镜像的可移植特性都快产生怀疑了。。。。
6
新建一个虚拟机（第3台主机）使用同样的配置再次启动环境，能够成功启动，排除镜像问题。但是为什么只是在第2台主机无法正常启动那？
7
再次回到问题节点（第2台主机），继续破案，换一组别的服务，使用docker-compose 启动，服务启动正常。。。。。 这个如何是好？
为何只有我们的镜像？在这台主机启动服务有问题？查了一写资料有些说apache 新特性导致的，有的说修改冲编译的等等，都没有彻底解决问题。
8
重点查docker 存储方面的资料，发现有资料说是docker 使用的overlay存储，可能出这种问题，可以将docker 的存储改为 devicemapper 类型。好吧，试一次。
1：Stop docker
2：备份 /var/lib/docker 目录（按需）
3：
vi /etc/sysconfig/docker-storage
修改内容为：
DOCKER_STORAGE_OPTIONS="--storage-driver overlay2 "
如下：
DOCKER_STORAGE_OPTIONS="--storage-driver devicemapper "
4：
然后启动 docker服务
5：然后使用compose 启动服务，耐心等待。。。。。
wordpress 服务启动成功了！！！！！！有一个问题，为什么只有使用这么老的docker存储驱动才行 ？9
后面去docker 官网看了一些关于存储的介绍信息，其实docker 存储驱动配置有许多细节要注意。详细可以下看下官网介绍：
https://docs.docker.com/v17.03/engine/userguide/storagedriver/overlayfs-driver/
https://docs.docker.com/storage/storagedriver/overlayfs-driver/10
收一下思路，以上是问题排查的大至过程，以上问题排查过程并非安装文档顺序排查，另外还有一些琐碎排查确认没有进行描述。本次问题确实由于docker存储驱动引起。下面简要总结一下：
故障排查总结，docker使用存储驱动注意事项：
1：RHEL或CentOS 使用新的docker存储驱动（overlay or overlay2）,需要升级系统内核版本到3.10.0-514以上版本。
2:docker 官方建议，在 docker-ce 17.06.02及以上的版本使用 overlay2，以及在docker-ce的版本，也使用 overlay2。而overlay 虽然在docker-ce 版本中是支持的，但是并不推荐。
3：Docker数据存储，强烈建议另外准备一块磁盘或者分区；
4：如果使用XFS格式文件系统，在格式化为xfs的时，必须，注意必须！指定ftype=1 (开启 d_type 特性)，否则可能出现未知问题！
参考文档地址：
https://blog.51cto.com/michaelkang/23998805:Docker 使用overlay or overlay2 一定验证通过 docker info 验证信息如下：
$ docker info
Storage Driver: overlay2
Backing Filesystem: xfs <=== 重点关注对象
Supports d_type: true <=== 重点关注对象
Native Overlay Diff: true
如何检测当前的文件系统，是否支持 d_type ？
$ xfs_info /
meta-data=/dev/sda1 isize=256 agcount=4, agsize=3276736 blks
.........................
data = bsize=4096 blocks=13106944, imaxpct=25
.........................
=version 2 bsize=4096 ascii-ci=0 ftype=1 《===重点关注对象重点关注对象解释
xfs文件系统的 d_type是什么
d_type 是 Linux 内核的一个术语，表示 “目录条目类型”，而目录条目，其实是文件系统上目录信息的一个数据结构。d_type，就是这个数据结构的一个字段，这个字段用来表示文件的类型，是文件，还是管道，还是目录还是套接字等。
d_type 从 Linux 2.6 内核开始就已经支持了，只不过虽然 Linux 内核虽然支持，但有些文件系统实现了 d_type，而有些，没有实现，有些是选择性的实现，也就是需要用户自己用额外的参数来决定是否开启d_type的支持。
为什么docker在overlay2（xfs文件系统）需要d_type
不论是 overlay，还是 overlay2，它们的底层文件系统都是 overlayfs 文件系统。而 overlayfs 文件系统，就会用到 d_type 这个东西用来文件的操作是被正确的处理了。换句话说，docker只要使用 overlay 或者 overlay2，就等于在用 overlayfs，也就一定会用到 d_type。
如果在不支持 d_type 的 overlay/overlay 驱动下使用docker，会出现什么问题？
可能出现 docker在操作文件的时候，可能会遇到一些错误，比如： 无法删除某些目录或文件，设置文件或目录的权限或用户失败、运行的docker 镜像目录文件莫名奇妙的丢失，等等。这些都是不可预料的错误。举个具体的场景，就是，docker构建的时候，可能在构建过程中，删除文件等操作失败，导致构建停止。
结尾：
我们通过上面的方法进行验证，发现只要是使用xfs文件系统的，格式化的时候没有开启 d_type 特性的，wordpress 镜像都启动报错。另外回顾在在日常工作期间也发现一些docker文件异常的现象，所在的主机基本存在这个问题。这里面还有最后一个坑，就是推荐拿一个独立分区给docker使用，可以按需格式化docker分区，如果docker使用的是根分区，系统都要重装了，动静略大。
参考文档：
https://help.nextcloud.com/t/docker-container-fails-with-ah00534-apache2-configuration-error-no-mpm-loaded/29491