退出容器命令 容器中进程退出后容器不会退出

unraiddocker自动重启

为了保证容器运行时健壮性（自愈），Docker 提供了容器重启策略，即使用参数 --restart，它可以让容器在退出时自动尝试重启。

退出容器命令 容器中进程退出后容器不会退出

退出容器命令 容器中进程退出后容器不会退出

退出容器命令 容器中进程退出后容器不会退出

场景

Docker 容器的重启策略一般用于生产环境，开发环境和实验环境可以忽略。例如使用 Docker 运行 Nginx。Nginx 作为目前常用的 web ，我们肯定更希望看到它在因停电、主机重启等意外中尝试自动恢复。

原理

Docker 容器的自动重启是由 Docker 守护进程完成的。在较老版本 Docker 中，如果 docker 守护进程重启，容器会全部挂掉。新版本 Docker 中，允许设置，当 docker 守护进程重启，容器不受影响。该场景比较多见，例如修改了 docker 的配置而需要重新加载 docker 守护进程，如果 docker 容器重启，业务会短暂中断，尤其是在生产环境这是不可接受的。所以这个设置很有必要。

具体设置方法有两种：

种，编辑 /etc/docker/daemon.json，添加 "live-restore": true ：

{ "live-restore": true, }

第二种，命令启用

dockerd --live-restore d

Docker 容器的重启策略具体如下：

no

默认策略，在容器退出时不重启容器。启动容器时不添加参数 --restart 即可。

on-failure

在容器非正常退出时（退出状态非0），才会重启容器。

on-failure:n

在容器非正常退出时重启容器，并且指定重启次数。n 为正整数。如果不指定次数，则会一直重启。

always

只要容器退出就重启容器。

unless-stopped

在容器退出时总是重启容器，但是 Docker 守护进程启动之前就已经停止运行的容器不算在内。

2. Docker 容器的退出状态码

Docker 容器也有退出状态码，这一点类似 Linux 命令。Docker 容器的重启策略就是基于状态码。具体如下：

表示容器正常退出。例如 stop 容器。

非 0

表示容器退出异常（退出状态码采用 chroot 标准）。例如执行 docker run 失败后的容器退出。

125

Docker 守护进程本身有错误。

126

容器启动后，要执行的默认命令无法调用。

127

容器启动后，要执行的默认命令不存在。

其他命令状态码

容器启动后在容器内部执行命令，该命令退出时的返回状态码，就作为容器的退出状态码。

3. 获取 Docker 容器退出状态码的方法

3.1 使用命令 docker ps -a

该命令结果的第 5 列中 Exited 后面括号中的数字就是容器的退出状态码。如下所示，Exited (1) 33 minutes ago，1 就是这个容器的退出状态码。但是 1 并不是容器本身的退出状态码，而是容器中运行的命令执行失败后退出的状态码。在 Linux 系统定义的命令退出状态码中，1 表示未知，即系统不知道具体错误的原因。这时候就需要看具体的日志来判断。

[root@k8s- /]# docker ps -a | grep nginx 3e64cad716c0 192.168.100.20:5000/mynginx:latest "nginx" 36 minutes ago Exited (1) 33 minutes ago nginx-demo

3.2 使用 inspect 命令

inspect 命令是用来获取容器的命令，配合其他参数就能获取容器的退出状态码。如下所示，还是上面案例中的容器，获得其退出状态码为 1

[root@k8s- /]# docker inspect 3e64cad716c0 --format='{{.State.ExitCode}}' 1

4. docker run 的 --restart 参数说明

--re选择基础镜像start 选项通常只用于 detached 模式的容器。

detached 即后台运行模式（类比 Linux 命令的前台运行和后台运行）。Docker容器的两种运行模式：Foreground，Detached。docker run 时添加了 -d 或者 -d=true 参数，就是后台模式运行。

--restart 选项不能与 --rm 选项同时使用。

因为 --rm 选项只适用于 foreground 模式的容器。

在 docker ps 查看容器时，对于使用了 --restart 选项的容器，其可能的状态只有 Up 或 Restarting 两种状态。

5. --restart 参数中的其他设定

猜测一下，--restart 的重启时间间隔是怎样的？这个参数会失效吗？又会在什么情况下失效？

来看实验：

如下所示：

[root@k8s- /]# docker run -d --name nginx-demo -p 8010:80 -v /data/nginx/html/:/usr/share/nginx/html/ -v /data/nginx/logs/:/var/log/nginx/ -v /data/nginx/conf/:/etc/nginx/ --restart=always 192.168.100.20:5000/mynginx:latest 3e64cad716c0d60e9249dc72c11cc5cc7ece42d3f69fcf276ff28fd84782ed89 [root@k8s- /]# [root@k8s- /]# ls /data/nginx/ /data/nginx/conf: /data/nginx/html: /data/nginx/logs: error.log [root@k8s- /]# [root@k8s- /]# tail -f /data/nginx/logs/error.log 2022/03/30 04:00:54 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:00:55 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:00:55 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:00:56 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:00:57 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:00:58 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:01:02 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:01:08 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:01:21 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:01:47 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:02:39 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) [root@k8s- /]# [root@k8s- /]# docker stop nginx-demo nginx-demo [root@k8s- /]# [root@k8s- /]# tail -f /data/nginx/logs/error.log 2022/03/30 04:00:56 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:00:57 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:00:58 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:01:02 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:01:08 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:01:21 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:01:47 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:02:39 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:03:39 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory) 2022/03/30 04:04:39 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)

通过上面的实验，发现了几个很有意思的现象：

04:00:54，容器首次重启失败。 04:00:55，容器开始次尝试重启，直到第 5 次重启，每次重启时间间隔为 1 秒。 04:01:02，从第 6 次重启开始，时间间隔变为 3 秒。 04:01:08，从第 7 次重启开始，时间间隔变为 6 秒。 04:01:21，从第 8 次重启开始，时间间隔变为 13 秒。 04:01:47，从第 9 次重启开始，时间间隔变为 26 秒。 04:02:39，从第 10 次重启开始，时间间隔变为 52 秒。从这之后，时间间隔稳定变为 1 分钟。

从实验中我们推断出关于 --restart 重启策略中的一些设定：

关于时间策略的设定：

- 前 5 次时间间隔为 1 秒

- 第 6 次开始时间间隔为之前的 2 倍。

- 直到时间间隔超过 1 分钟时，后续的每一次重启的时间间隔都固定为 1 分钟。

关于 --restart 策略失效的设定：

- 当执行容器 stop 时， --restart 失效，容器不再尝试重启。实验中，重启日志一直停留在“2022/03/30 04:04:39”。

6. 容器启动时忘记使用 --restart=always 如何补救

6.1 使用 update 命令

[root@k8s- /]# docker container update --restart=always 3e64cad716c0 3e64cad716c0

6.2 修改容器的配置文件

vim /var/lib/docker/containers/容器ID/hostconfig.json，找到关键字 RestartPolicy，将 no 改为 always

修改前：

"RestartPolicy:{"Name":"no","MaximumRetryCount":0}

"RestartPolicy:{"Name":"always","MaximumRetryCount":0}

重启容器即可。如果无法修改容器的配置，可先将容器停止，修改配置文件后再启动。

7. 获取容器重启信息

查看容器重启次数

[root@k8s- /]# docker inspect -f "{{ .RestartCount }}" 3e64cad716c0 13

查看nginx查看标准输出的日志通过前台启动时可以看到，其他服务也是一样，通过前台启动时即可查看到。容器一次的启动时间

[root@k8s- /]# docker inspect -f "{{ .State.StartedAt }}" 3e64cad716c0 2022-03-30T04:04:39

docker commit和docker file的区别

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

制作镜像的方式主要有两种：

通过docker commit 制作镜像

通过docker build 制作镜像

这两种方式都是通过改进已有的镜像来达到自己的目的。制作基础镜像，会在另外一篇文章“从零开始制作基础镜像”中介绍。

docker commit

docker commit 是往版本控制系统里提交一次变更。使用这种方式制作镜像，本质上是运行一个基础镜像，然后在基础镜像上进行软件安装和修改。再将改动提交到版本系统中。

基础镜像的选择要结合自己的需求。可以选择已有的应用镜像来改造，也可以选择Ubuntu，Debian，OpenSuse这类基础系统镜像

我们以ubuntu为例子来说明

docker run -i -t ubuntu /bin/bash

步骤2：安装软件并修改软件配置, 比如：安装apache2

apt-get -yqq update

apt-get -y install apache2

安装完成后，对apache2进行配置和修改

步骤3：退出docker并保存镜像

使用“exit”命令退出容器

运行docker comit 命令, 进行保存

docker commit 61412230ae46 own-apache2

docker commit 命令参数说明

命令格式

docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]

OPTIONS:

-a, --author= 提交的镜像作者

-c, --change=[] Apply Dockerfile instruction to the created image, 没用过

-m, --message= 提交时的说明文字

-p, --pause=true 在commit时，将container 暂停

CONTAINER:

REPOSITORY

指定镜像仓库，上述例子中，指定的是本地存储

可以指定远程镜像仓库，如docker hub。也可自建仓库来存放image

TAG:

镜像TAG

docker build

使用docker build创建镜像需要编写Dockerfile.

步骤：

编写自己的Dcokerfile

运行docker build 命令打包镜像

仍然以apache打包为例子。以下是Dockerfile的例子

MAINTAINER sky

ADD sources.list /etc/apt/sources.listADD .bashrc /root/.bashrcENV DEBIAN_FRONTEND noninteractive# PackagesRUN rm -rf /var/lib/apt/listsRUN apt-get update -q --fix-missingRUN apt-get -y upgrade#ubuntu wwwRUN apt-get install -y apache2 c libapache2-mod-php5 php5-c php5-gd php5-mysql rsync mysql-client -qqRUN apt-get autocleanRUN rm -rf /var/lib/apt/lists/# Setup environmnt for apache's init scriptENV APACHE_CONFDIR /etc/apache2ENV APACHE_ENVVARS $APACHE_CONFDIR/envvarsENV APACHE_RUN_USER www-dataENV APACHE_RUN_GROUP www-dataENV APACHE_RUN_DIR /var/run/apache2ENV APACHE_PID_FILE $APACHE_RUN_DIR/apache2.pidENV APACHE_LOCK_DIR /var/lock/apache2ENV APACHE_LOG_DIR /var/log/apache2ENV LANG CRUN mkdir -p $APACHE_RUN_DIR $APACHE_LOCK_DIR $APACHE_LOG_DIRRUN find "$APACHE_CONFDIR" -type f -exec sed -ri ' s!^(sCustomLog)s+S+!1 /proc/self/fd/1!g; s!^(sErrorLog)s+S+!1 /proc/self/fd/2!g; ' '{}' ';'EXPOSE 80CMD ["apache2", "-DFOREGROUND"]

docker build -t apache-img .

如果没有命令出错，docker build会持续运行直到镜像创建完成

而创建的过程本质上是运行一个镜像，然后在镜像中按序执行在Dockerfile中的命令，直到执行结束。

如果中间有命令执行失败，镜像创建会停止。这时就需要看log，并修改Dockerfile，然后再次执行docker build

注：两种镜像创建方式的对比：

docker commit

docker build

难度相对容易，适合新手和对Linux不熟悉的用户相对难，要求有一定的linux和脚本基础知识

文档化

文档化在通过其他文件来实现

Dockerfile本身就是比较好的文档，可读和可理解性比较强。也可配合其他文档带来详细说明

升级，维护

后续升级和维护麻烦，需要再次运行镜像并对内部软件进行升级或者安装新软件增加特性

后续升级和维护会相对简单，可以直接在dockerfile中更改并增加新特性

具体选择哪种方式来制作镜像需要结合实际情况来选择

Dockerfile 关键字详解

FROM

FROM用来指定基础包。在上面的例子中，基础包用的是ubuntu。

MAINTAINER

镜像作者信息，或者维护人员信息

ADD

将文件拷贝到Container内文件系统对应的路径

格式 ADD

所有拷贝到C步骤1：运行ubuntu 镜像ontainer中的文件和文件夹权限为0755，uid和gid为0

如果需要修改owner用户或者权限，需要使用RUN进行修改

ADD文件，文件路径要在docker build中指定的下

RUN

创建镜像时执行

ENV

用来设置环境变量

EXPOSE

Container内部服务开启的端口

主机上如果要使用，还需要在启动Container时，做host-container的商品映射

使用EXPOSE后，一些自动化布署工具可以直接读取这个信息，自动进行端口映射

EXPOSE可以有多条，指定多个端口

WORKDIR

切换工作目录，可进行多次切换（相当于cd命令）

切换目录对RUN，CMD，ENTRYPOINT有效

USER

执行container的用户，如未指定，则默认使用root用户

ENTRYPOINT

Container启动时执行的命令，一个Dockerfile中只能有一条ENTRYPOINT

ENTRYPOINT没有CMD的可替换特性

CMD

Container 启动时执行的命令，一个Dockerfile 中只能有一条CMD命令，如果有多条则只执行一条CMD

如果有多条命令希望在启动后执行，可以考虑使用shell 脚本

与ENTRYPOINT的区别

CMD的主要用途是为可执行的container提供默认命令

CMD在运行时是可替换的，比如

在ubuntu中，CMD指定的是/bin/bash。默认情况下运行ubuntu，container中的/bin/bash会被执行

如果使用docker run指定运行命令，那CMD会被替换掉

如：docker run ubuntu /bin/echo "this is a echo". 这时，container 启动后会执行echo 而不是/bin/bash了

ENTRYPOINT是不会替换的，如果在ubuntu镜像中加入ENTRYPOINT，那ENTRYPOINT在启动后会先被执行

CMD可以为ENTRYPOINT来提供参数

例子：

FROM ubuntu:14.10

ENTRYPOINT ["top", "-b"]

CMD ["-c"]

VOLUME

语法：VOLUME [PATH]

VOLUME指令用来设置一个挂载点，可以用来让其他容器挂载以实现数据共享或对容器数据的备份、恢复或迁移

可以将本地文件夹或者其他Container的文件夹挂载到Container中

容器直装怎么上号器登录

这是因为安装了蓝灯或者其他类似软件的原因。

对于运行在后台的Docker容器，我们运维人员时常是有登陆进去的需求。登陆Docker容器的方式：

1）使用ssh登陆容器。这种方法需要在容器中启动sshd，存在开销和攻击面增大的问题。同时也违反了Docker所倡导的一个容器一个进程的原则。 参考Docker容器学习梳理--SSH方式登陆容器

2）使用自带命令docker attach登陆容器。命令格式：docker attach container_id。不过docker attach存在的问题是：当多个窗口同时attach到同一个容器时，所有的窗口都会同步的显示，如其中的一个窗口发生阻塞时，其它的窗口也会阻塞，docker attach命令可以说是不方便的进入后台docker容器的方法。

3）使用自带命令docker exec登陆容器。命令格式：docker exec -ti container_id /bin/bash。docker exec和docker attach是Docker的原生方法，大多数情况下就使用这两种命令登陆容器。docker exec命令是在docker1.3之后出现的，比docker attach命令更加方便！两者之间的区别：

1.Docker attach必须是登陆到一个已经运行的容器里。需要注意的是如果从这个容器中exit退出的话，就会导致容器停止！！这是极其不方便的！

[root@localhost ~]# docker p[root@localhost ~]# docker exec -t tomcat pwds

[root@localhost ~]# docker attach tomcat

[root@2faf24118766 /]# exit //按住ctrl+d退出当前窗口

[root@localhost ~]# docker ps //发现该容器也停止了！！

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

2.docker exec登陆容器，注意有两个参数：-t和-i，这两个参数很重要！

1）如果只用-i时，由于没有分配伪终端，看起来像pipe执行一样。但是执行结果、命令返回值都可以正确获取。

这种方式可以理解为：在运行的容器上执行新进程！即在宿主机上执行容器里的命令并查看到命令结果！这很方便的~但是仅仅使用-i参数无法直接登陆到容器内！

[root@localhost ~]# docker ps

2faf24118766 192.168.1.23:5000/tomcat7 "/bin/bash" 4 days ago Up About a minute 0.0.0.0:8888->8080/tcp tomcat

[root@localhost ~]# docker exec -i tomcat date

Sat Apr 1 06:53:46 UTC 2017

[root@localhost ~]# docker exec -i tomcat uptime

06:54:44 up 163 days, 23:28, 0 users, load erage: 0.00, 0.01, 0.05

[root@localhost ~]# docker exec -i tomcat /usr/local/tomcat7/bin/startup.sh

Tomcat started.

2）如果只使用-t参数，则可以看到一个console窗口，可以在宿主机上执行容器里的命令并查看到命令结果，但是这种方式登陆到容器内执行的命令是没有结果信息输出的！

[root@localhost ~]# docker exec -t tomcat uptime

07:02:38 up 163 days, 23:36, 0 users, load erage: 0.00, 0.02, 0.05

/[root@localhost ~]# docker exec -t tomcat /bin/bash //注意，使用-t参数登陆容器，退出当前窗口用的是ctrl+c而不是ctrl+d；而下面使用-ti参数，退出当前窗口使用ctrl+d

[root@2faf24118766 /]# uptime //仅仅使用-t参数登陆容器内，发现执行命令后，没有结果输出！

3）使用-it时，则和我们平常作console界面类似，而且不会像attach方式因为退出而导致 整个容器退出。 这种方式可以替代ssh或者nsenter方式，在容器内进行作。

[root@localhost ~]# docker ps

2faf24118766 192.168.1.23:5000/tomcat7 "/bin/bash" 4 days ago Up About a minute 0.0.0.0:8888->8080/tcp tomcat

[root@localhost ~]# docker exec -t tomcat /bin/bash

[root@2faf24118766 /]# exit //按住ctrl+d退出当前窗口

[root@localhost ~]# docker ps //发现容器还在，并没有因为上面的窗口退出而停止容器！

2faf24118766 192.168.1.23:5000/tomcat7 "/bin

docker中/dev/stdout的理解

启动一个 Nginx 容器，当它找不到配置文件时，Nginx 报错并且进程退出，容器也随之推出。此时该容器会尝试重启。

以nginx.conf为例子

我们通常看到的日志都是输入到一个文件中，类似access.log,error.log。只要产生相关日志日志就会出现对应的文件中。

而我们在docker容器中，nginx.conf文件如下

supervisord.conf文件如下

可以看到日志并不是输出到一个文件内，而是 /dev/stdout 和 /dev/stderr 。它的#Add 163 ror for apt作用就是日志输出docker日志中，而不输入到具体的文件中。docker日志就是使用以下命令在前台输入的内容

或者是我们docker前台启动后，输出的内容

如docker前台启动一样，日志也会输出到nginx前台启动，通过nginx二进制命令启动

还有一个问题，就是起了一个容器后，该容器有nginx和php进程，而俩进程都是使用supervisord来守护进程的。nginx日志都可以在docker里面正常输出，当我有一个需求，需要开启定时执行任务。这时需要在dockerfile文件中新增CMD命令，因为dockerfile中只能执行一条CMD命令， 该命令就是容器的主进程 。所以我门既要保证原来的服务能正常启动，我们还要启动crontab。所以命令如下

如果执行上条命令的话，会报code为0的问题，表示容器退出，也就是后台启动完进程就退出了，所以容器也就没有存在的意义，也就退出了。所以我们加tail命令，tail可阻塞，挂起一个主进程，类似前台启动。

注意：这时意味着和之前相比，主进程发生了变化，也就意味着，此时nginx的相关日志就不会输出在docker前台了。可以想象成原来开启的是nginx服务，现在开启了一个mysql服务，nginx的相关日志信息也理所当然的不会出现在mysql的服务中了。

重要：如果使用CMD后改变主进程，类似nginx日志将不会输出到console，此时我们应该修改nginx的配置文件，让其log输出到文件中

docker 容器自动启动run

部署项目时，为了应对停电等情况影响正常web项目的访问，会把Docker容器设置为开机自动启动。

如果创建时未指定 --restart=always ,可通过2faf24118766 192.168.1.23:5000/tomcat7 "/bin/bash" 4 days ago Up About an hour 0.0.0.0:8888->8080/tcp tomcatupdate 命令设置

Docker容器的重启策略是面向生产环境的一个启动策略，在开发过程中可以忽略该策略。

Docker容器的重启都是由Docker守护进程完成的，因此与守护进程息息相关。

Docker容器的重启策略如下：

no，默认策略，在容器退出时不重启容器

on-failure，在容器非正常退出时（退出状态非0），才会重启容器

on-failure:3，在容器非正常退出时重启容器，多重启3次

always，在容器退出时总是重启容器

unless-stopped，在容器退出时总是重启容器，但是不考虑在Docker守护进程启动时就已经停止了的容器

docker run的退出状态码如下：

0，表示正常退出

非0，表示异常退出（退出状态码采用chroot标准）

125，Docker守护进程本身的错误

126，容器启动后，要执行的默认命令无法调用

127，容器启动后，要执行的默认命令不存在

其他命令状态码，容器启动后正常执行命令，退出命令时该命令的返回状态码作为容器的退出状态码

通过--restart选项，可以设置容器的重启策略，以决定在容器退出时Docker守护进程是否重启刚刚退出的容器。

--restart选项通常只用于detached模式的容器。

在docker ps查看容器时，对于使用了---restart选项不能与--rm选项同时使用。显然，--restart选项适用于detached模式的容器，而--rm选项适用于foreground模式的容器。-restart选项的容器，其可能的状态只有Up或Restarting两种状态。

示例：

补充：

查看容器重启次数

查看容器一次的启动时间

如何让docker容器在执行shell命令后不退出运行

我们自己新的Fedora Apache镜像正成功的运行，现在我们想添加一些我们网站的网页内容到Apache网络，使得网站能够开箱即用。为做到这点，我们需要创建一个新的Dockerfile，它会处理从网页内容到启用80端口的所有作。要达到这样的目的，我们需要使用我们喜欢的文本编辑器创建Dockerfile文件，像下面演示的一样。

有同学在docker下安装了nginx但是不知道目录在哪，可以使用命令：sudofind/-name"50x.html"因为nginx里必定会有50x.html，所以查找修改后：它，结果发现nginx的目录在docker容器里，如果作它，就需要进入容器的shell。必须先启动容器：sudodockerstart“容器ID”然后使用下边的命令进入shell：sudodockerexec-it“容器ID”bash将主机的文件到容器里：sudodockercp主机目录容器ID:容器目录

如何交互式地创建一个Docker容器

FROM ubuntu:latest

1. 运行一个Docker实例

Docker首先会尝试从本地取得并运行所需的镜像，如果在本地主机上没有发现，它就会从Docker公共注册中心拉取。这里，我们将会拉取镜像并在 Docker 容器中创建一个fedora实例，并连接到它的 tty 上的bash shell。

# docker run -i -t fedora bash

2.安装Apache网络

现在，在我们的Fedora基本镜像实例准备好后，我们将会开始交互式地安装Apache网络，而不是为它创建Dockerfile。为了做到这点，我们需要在终端或者shell运行以下命令。

# yum update

# yum install d

退出容器的 tty。

# exit

3.保存镜像

现在，我们要去保存在Fedora实例里做的修改。要做到这个，我们首先需要知道实例的容器ID。而为了得到ID，我们又需要运行以下命令（LCTT 译注：在容器外执行该命令）。

# docker ps -a

然后，我们会保存这些改变为一个新的镜像，请运行以下命令。

# docker commit c16378f943fe fedora-d

这里，修改已经通过使用容器ID保存起来了，镜像名字叫fedora-d。为了确认新的镜像是否在运行，我们将运行以下命令。

# docker images

4. 添加内容到新的镜像

# nano Dockerfile

现在，我们需要添加以下的命令行到文件中。

FROM fedora-d

ADD mysite.tar /tmp/

RUN mv /tmp/mysite/ /var/www/html

EXPOSE 80

ENTRYPOINT [ "/usr/in/d" ]

CM编辑完成后，在与Dockerfile同一目录下运行docker build 命令D [ "-D", "FOREGROUND" ]

这里，上述的Dockerfile中，放在mysite.tar里的网页内容会自动解压到/tmp/文件夹里。然后，整个站点会被移动到Apache的网页根目录/var/www/html/，命令exe 80会打开80端口，这样网站就能正常访问了。其次，入口点放在了/usr/in/s里面，保证Apache能够执行。

现在，我们要用刚刚创建的Dockerfile创建我们的容器，以便将我们的网站添加到上面。为做到这，我们需要运行以下命令。

# docker build -rm -t mysite .

建立好我们的新容器后，我们需要要用下面的命令来运行容器。

# docker run -d -P mysite

docker无法进入容器怎么办？

5. 构建并运行一个容器

你把蓝灯或者类似软件关闭了就不会出现这样的情况了。

现象描述

docker run -d centos:v1 /bin/bash创建容器或者docker exec -it container_name bash进入容器，都会报错“usrbindocker-current Error response from daemon:shim error.context deadline exceeded.”，docker ps、docker stats、docker 等命令均可用

基础环境

物理机作系统：CentOS Linux release 7.3.1611 (Core)

内核版本：3.10.0-693.el7.x86_64；该内核版本已修复单机多跑100个容器（否则触发xfs文件系统bug导致机器自动重启）的bug

问题分析

日志内容docker的日志里包含大量的error

谷歌搜索谷歌搜索“shim error: context deadline exceeded”，查到有人遇到相关问题，但是原因和解决办法没有找到，有的说是docker 1.12版本的一个bug，但是看样子文中的这个bug跟当前遇到的问题没啥关系。

尝试解决docker exec进程

怀疑使用了大量的“docker exec -it containe可以使用container 的名字或者IDrid bash”命令后没有正确的退出容器，导致过多的“docker exec”进程影响了docker run和docker exec命令的使用，所以kill掉了所有的“docker exec”进程。问题没有解决。

然后把这些Exited状态的容器删掉，docker run和docker exec命令恢复，问题解决。

现怀疑是过多的“Exited状态”的容器导致问题的出现。

因为是测试的宿主机，所以难免会试验性的建一些可能根本起不来的容器，起不来的话就变成“Exited”状态了。