先说说这个问题的起因：

Docker容器后台运行,就必须有一个前台进程！

OK，有次手贱，把容器内的php-fpm配置文件中的daemon改为yes，导致了没有前台进程，因此，容器启动后就停止了。
那么问题变成，如何修改没有启动的容器内的文件？（PS：正常情况下可以通过 docker exec命令打开容器的一个shell终端进去修改）

解决方案：创建新镜像
把这个问题容器用docker commit提交到一个新的镜像，然后用docker run -it 基于新镜像运行一个新的容器进去改变（修复）配置文件。
再通过新的容器再提交一个新的镜像，然后在基于新的镜像重新启动容器（同最初的容器）。
这个方法是可行的，但问题是步骤多，而且提交了新的镜像，对于后续维护增加了复杂性。

#把要修复的容器提交为镜像
docker commit <container_id> <image_name>:<tag>
docker rm <container_id> #这个删除老的容器，反正也用不了
#查看刚建立的新镜像
REPOSITORY                               TAG                 IMAGE ID            CREATED             SIZE
zhibin/php5                              2018                c6532c5ece91        10 minutes ago      1.549 GB
#利用这个新镜像创建容器，进入容器，修复配置文件
docker run -it --name tmp-fixphp5 zhibin/php5:2018 /bin/bash
#重新提交镜像
docker commit <container_id> <image_name>:<tag>
#创建修复后的容器
docker run -d --volumes-from nginx_server --name php-fpm_server_2018 --dns=10.100.17.21 --cap-add SYS_PTRACE -p 9000:9000 zhibin/php5:201802


# docker
Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生