第1节 Docker运行容器的常见用法

docker怎么管理容器的

概述

image-20240415101723667

image-20240415103201163

image-20240415103824654

互联网上的镜像，不需要登入，直接下载，一般公司私有的镜像才需要login后去下载

COMMAND

image-20240415104528966

image-20240415105021283

​ 可以修改为自己希望执行的命令，以及加上ARG也就是跟上参数，但是加的的cli必须是人家容器里有的命令否则无法执行的。比如上图hello-world容器里只有/hello这个命令，其他的红色框框👆里的cil都是没有的， 所有都是报错的。 # 我就想到其实容器里是否可以封装一个busybox呢，哈哈基本很多常用cli就都有了。我觉得还不错~

​ 镜像就是没有boot(内核)的根文件系统+app程序文件(mysql、nginx、等各自的程序包括各自依赖的库)。

下个busybox看看多大是否可以后面集成到我工作中的images里

1、首先hub.docker.com搜索latest

image-20240415113859282

2、然后找哈希值一样的版本号，

有同学问，那你为什么不直接下latest，你猜我为啥

image-20240415114000088

image-20240415114057219

5MB不到，可以接受吧~

alpine举例，说明commond的是前台cli，否则就是运行后即退出

image-20240415112457390

​ 容器运行起来不退出，要求容器运行时对应的COMMAND的是前台执行，而👆/bin/sh是一个后台执行的cli，所以运行后就提出了。类似docker run nginx执行了就是前台占用。

​ 所谓前台执行就是执行后就霸占了前台，而传统systemctl start nginx这种启动方式在容器里就不能使用了，因为后台执行，容器里执行就退出了。

image-20240415112958240

image-20240415113014809

image-20240415131028393

怎么停不掉啊👆，关闭窗口还是up的，因为没有-it交互，你的ctrl c 发不进去👆

image-20240415131139775

加个-d 放后台，但是不会退出，因为用的cli 是前台就行。

image-20240415131210932

image-20240415131722121

image-20240415131829745

--name选项，指定容器NAME

比如指定容器的NAME方便后面，比如容器之间的互访

image-20240415133543953

随机的名字肯定可读性不好👆

image-20240415133729937

image-20240415134402626

-it交互模式进入容器里，看看文件，看看状态等操作

image-20240415135101975

-i是交互，还不够，还需要一个tty接口，类似交换机的vty

-i -t 还不够，还需要交互的sh否则👇

image-20240415135433555

-it 配合什么shell，就是尝试尝试就行了

image-20240415135719648

👆这就进来了

不仅仅有bash也有/bin/sh

image-20240415140235224

只是用了bash交互，run的command还是原来的那个脚本

image-20240415160059055

image-20240415160130449

进来后，

image-20240415160311606

通过👆boot里是空的就知道了，容器用的是宿主的boot(内核)，所以这里只是空的。

image-20240415160438367

这个nginx是基于Debian做出来的，Debian系列的典型代表就是ubuntu了，apt就是yum了

安装ps

image-20240415161859681

image-20240415161921232

ps就有了👇

image-20240415161938718

容器里用sed修改为清华源，安装更快，调试更方便

容器安装东西大多数都是调试用的。

sed -i 's|http://deb.debian.org/debian|https://mirrors.tuna.tsinghua.edu.cn/debian|g' /etc/apt/sources.list.d/debian.sources
sed -i 's|http://deb.debian.org/debian-security|https://mirrors.tuna.tsinghua.edu.cn/debian-security|g' /etc/apt/sources.list.d/debian.sources

容器exit就真的将容器退出了，即使容器本来时run起来就前台执行的那种，你用-it bash进去再exit，容器就不再时running了👇

image-20240415163327923

如果不想exit退出的时候把本来应该前台执行的容器退出也可以用ctrl p q 组合键来安全退出，不过此时nginx就不再时前台了，而是后台up了，类似于docker run -d nginx了

image-20240415163851622

上图👆不是nginx这种run起来就up的，一样也会被ctl p q变成后台up👇

image-20240415164200367

这下倒学到了一个让hello-world后台UP的方法，赶紧试试👇，不行人家压根就没有shell，所以无法进去。而有shell的倒是可以用这种方式后台UP着。

run -it用的少，大多数都是exec -it来针对运行中的容器进行交互排错

比如run了一个nginx

image-20240415170121263

发现某个问题，需要进去排错，于是docker exec -it进去

image-20240415170306952

image-20240415170755466

hostname只在容器内部生效，不具备容器互通的功效，只是在容器内部可以拿来本地通信。

通过这个hostname和本机的程序通信

image-20240415171241453

容器运行起来后，退出自动删除，临时测试屁股擦的比较干净

image-20240415172738881

只要容器run完退出的，那么就给你删除

image-20240415173656774

​ image-20240415175042057

所以，要做守护式容器，就得至少有一个进程是前台永久运行的👆

很多添加前台永久运行的手段：

docker run alpine:3.19.1 tail -f /dev/null

image-20240415175639814

👆上图就是前台运行不会退出，防止被ctrl c退出，于是加一个-d，是先保证一个前台cli再放到后台👇

image-20240415175624436

然后前文也说了，这里也复制过来一并看下👇

image-20240415131028393

怎么停不掉啊👆，因为没有-it交互，你的ctrl c 发不进去👆 放屁-it也不行

image-20240415182339492

关闭窗口也没用

image-20240415180943058

只能docker rm -f了 👇

image-20240415180617565

那么问题来了，

1、docker run alpine tail -f /dev/null 无法ctrl c 中断

2、docker run nginx 为啥可以ctrl c 中断

难道nginx的COMMAND里的也就是xxx.sh里是用了-it的？

不行1：用sh -c 包装也不行，就是不接受ctrl c，不知道为啥

image-20240415182831970

docker run -d nginx -d的后台和nginx的前台

1、-d的后台是docker run 这个命令后台执行

2、nginx容器前台执行，是nginx容器的COMMAND是容器里的cli是在容器里前台

所以要区分开来

一般都是-d 在后台run，服务类的容器肯定要容器里的cmd是前天的。

nginx为例，容器里的cmd是前台执行的，日志(比如访问日志)就是屏幕STDOUT的，docker run -d run在后太后，日志就用cli去看

image-20240416111024282

后台运行-d 的容器log查看也简单docker logs idxxx就行👇

image-20240416111411691

docker logs -f xxx 就很nice

image-20240416112145563

还有传统艺能watch -n xxx

image-20240416112505684

下图是wathc -n 5 docker logs nginx001的效果👇，就是-n 5秒刷一次，也是实时的。

image-20240416112520742

容器的自启动，不是说原来exited，变成了up，而是说up还是up

1、之前学过一个，这是docker 服务重启，容器原本UP的还是UP。

image-20240416113106028

stop 过30s start 都是ok的，就是说容器随docker服务，原来启动的，还是启动的

image-20240416113451378

当然原来是停止的，就不会自启动了。

2、容器服务重启的时候，重启的时候容器的状态是什么 + policy 是什么 ==> 重启引擎后 容器的状态会是什么

image-20240416113650207

no ： 退出了不重新UP， 这是默认值，# 重启的时候容器是退出的（不管是异常还是正常），那么重启服务后，容器还是退出，这就是no。

on-failure[:max-retries] : 异常退出就重新UP，尝试N次。 non-zero exit status，这是$? ≠0 的意思，就是异常退出，状态码不等于0。 # 重启前容器是异常退出的，重启服务后，容器就会尝试起来。

always ： 无论退出码是什么--也就是不管是正常退出还是异常退出--也就是不管认为退出($?=0)还是异常退出($?≠0)都随宿主机器起来而起来； # 重启服务(啥重启机器，重启机器也是对应到重启docker 引擎，搞搞清楚，讲的什么东西，当然整体还是不错，这里讲的很，不好说什么了)的时候容器不管是怎么退出的，是你重启导致退出还是本来就是认为退出的，重启后都给你起来。 与no相对。

unless-stopped ： 重启机器(服务)的时候容器如果是人为退出的，那么启动了就不会给你UP容器，如果容器是异常退出的，比如重启的时候容器还是UP( 那么重启的时候容器就会是异常退出 )，重启后容器就给你UP起来

image-20240416142113963

image-20240416142548690

image-20240416142725440

然后重启机器，此时web003就不会起来了，因为docker run 的是后默认是---restart no的，就是说重启等动作反正导致你退出的，docker引擎起来你容器也不会up的。

通过上面的截图可知web01是--restart always 方式启动的容器

image-20240416143008774

启动后就是👇

image-20240416143124882

所以重启宿主要用--restart always 这种或者至少--restart unless-stoped，而重启docker 服务，原来是up的希望它继续在重启服务后继续up就可以用live-restore配置选项，但该选项也做不到原来退出重启服务后给你起来的，而--restart always就可以👇

image-20240416143448657

Copyright 🌹 © oneyearice@126.com 2022 all right reserved，powered by Gitbook文档更新时间： 2024-07-28 14:47:24

results matching ""

    No results matching ""