背景：正在学习docker期间，接到一个任务，通过docker部署一个应用A。该应用A类似于之前部署的应用B，结果很自然地犯了形而上学的错误。
思路：基于dockerfile+docker-compose.yml来部署。
基本操作：编写dockerfile，制作基础镜像；docker-compose.yml作端口映射，数据卷挂载等操作。
出现问题：docker-compose up时，创建容器。docker ps看到容器的状态为restart状态，而不是正常的up。
难点：容器外部docker logs没能查看到容器应用运行的任何日志信息。同时因容器不断处于restart态，无法进入容器内查看应用运行的任何日志信息。
定位：
1、怀疑是docker-compose.yml中设置的内存太少，把内存大小限制设置为4G，没能决定问题。排除内存不够原因。
2、检查docker-compose.yml端口映射,确保没有与现有应用端口冲突。排除端口问题。
3、检查docker-compose.yml中数据卷的挂载及CMD的命令执行参数。排除数据挂载及命令参数问题。
4、怀疑是应用的执行权限问题，可是在不作修改情况下，docker容器中默认用的就是root权限。排除权限问题
5、本地非docker容器内运行该应用，一切正常。排除程序自身问题。
6、容器中前后台进程的影响，A是前台，B后台。（最终元凶）
出现问题原因：dockerfile中的CMD命令，是容器启动后运行的第一条命令，其PID为1。而Docker容器仅在它的1号进程运行时，会保持运行。如果1号进程退出了，Docker容器也就退出了。而我们要部署的应用属于后台进程，容器运行时，pid为1的进程不是A，而是bash，这个bash执行完指令后就挂了。同时因为容器中设置的restart策略为unless-stopped，因此会看到容器一直处于restart态。作为验证，将原本在容器中运行正常的B应用，在其CMD的执行参数中加上&，会看到B容器应用也一直处于restart态。
解决：在运行A应用后增加&&tail -f XXX.log，至此容器运行正常，进入A容器内进行相关区块链测试符合预期。
结论：容器生命周期和其内部PID为1的进程一致。