设置docker开机启动(设置docker开机启动的命令是)
1. 设置docker开机启动
在使用docker run启动容器时，使用--restart参数来设置：
# docker run -m 512m --memory-swap 1G -it -p 58080:8080 --restart=always
--name bvrfis --volumes-from logdata mytomcat:4.0 /root/run.sh
--restart具体参数值详细信息：
no - 容器退出时，不重启容器；
on-failure - 只有在非0状态退出时才从新启动容器；
always - 无论退出状态是如何，都重启容器；
Docker容器内应用服务自启动
如果想把Docker容器内的应用服务随着容器开启时自启动。只需要将服务启动的脚本写在Dockerfile里，然后用Dockerfile重构镜像即可实现：
编写应用服务自启动脚本
编写Dockerfile
重构镜像
开启容器
2. 设置docker开机启动的命令是
liveness与readiness的探针工作方式源码解析
liveness和readiness作为k8s的探针，可以对应用进行健康探测。
二者支持的探测方式相同。主要的探测方式支持http探测，执行命令探测，以及tcp探测。
探测均是由kubelet执行。
由kubelet，通过CRI接口的ExecSync接口，在对应容器内执行拼装好的cmd命令。获取返回值。
kubelet是根据执行命令的退出码来决定是否探测成功。当执行命令的退出码为0时，认为执行成功，否则为执行失败。如果执行超时，则状态为Unknown。
http探测是通过kubelet请求容器的指定url，并根据response来进行判断。
当返回的状态码在200到400(不含400)之间时，也就是状态码为2xx和3xx是，认为探测成功。否则认为失败。
tcp探测是通过探测指定的端口。如果可以连接，则认为探测成功，否则认为失败。
探测失败的可能原因
执行命令探测失败的原因主要可能是容器未成功启动，或者执行命令失败。当然也可能docker或者docker-shim存在故障。
由于http和tcp都是从kubelet自node节点上发起的，向容器的ip进行探测。
所以探测失败的原因除了应用容器的问题外，还可能是从node到容器ip的网络不通。
liveness与readiness的原理区别
探测方式相同，那么liveness与readiness有什么区别？首先，二者能够起到的作用不同。
liveness主要用来确定何时重启容器。liveness探测的结果会存储在livenessManager中。
kubelet在syncPod时，发现该容器的liveness探针检测失败时，会将其加入待启动的容器列表中，在之后的操作中会重新创建该容器。
readiness主要来确定容器是否已经就绪。只有当Pod中的容器都处于就绪状态，也就是pod的condition里的Ready为true时，kubelet才会认定该Pod处于就绪状态。而pod是否处于就绪状态的作用是控制哪些Pod应该作为service的后端。如果Pod处于非就绪状态，那么它们将会被从service的endpoint中移除。
readiness检查结果会通过SetContainerReadiness函数，设置到pod的status中，从而更新pod的ready condition。
liveness和readiness除了最终的作用不同，另外一个很大的区别是它们的初始值不同。
liveness的初始值为成功。这样防止在应用还没有成功启动前，就被误杀。如果在规定时间内还未成功启动，才将其设置为失败，从而触发容器重建。
而readiness的初始值为失败。这样防止应用还没有成功启动前就向应用进行流量的导入。如果在规定时间内启动成功，才将其设置为成功，从而将流量向应用导入。
liveness与readiness二者作用不能相互替代。
例如只配置了liveness，那么在容器启动，应用还没有成功就绪之前，这个时候pod是ready的（因为容器成功启动了）。那么流量就会被引入到容器的应用中，可能会导致请求失败。虽然在liveness检查失败后，重启容器，此时pod的ready的condition会变为false。但是前面会有一些流量因为错误状态导入。
当然只配置了readiness是无法触发容器重启的。
因为二者的作用不同，在实际使用中，可以根据实际的需求将二者进行配合使用。
3. docker开机启动命令
1.未设置docker开机自启，导致容器未启动。手动重启容器即可。启动命令参考docker常用命令教程。
2.【常见问题优先排查】青龙配置文件错误导致容器无法正常启动。 打开青龙容器日志目录，(ql/log/task_error.log)找到task_error.log文件，打开按报错日志修改对应文件错误后重启容器即可。
3.服务器异常重启或者强制重启导致容器文件损坏。这种较为少见，如果你日志中没任何内容，端口均正常放行，可以考虑重新拉容器镜像试试。
4. docker设置开机自启动
你要把 docker daemon 绑定到该端口上。默认情况下，docker daemon使用unix socket(unix:///var/run/docker.sock) 先停止docker daemon再重新启动： service docker stop docker -d -H unix:///var/run/docker.sock -H 0.0.0.0:4243 之后就可以.
5. 开机自动启动docker
可以修改docker run的CMD部分为sh，或 ping www.csdn.net 之类的。然后再docker exec -ti your-container sh。再看 run.sh 并进行修改。
6. docker开机启动脚本
避免Docker容器启动脚本运行后自动退出的解决办法 docker run指定的命令如果不是那些一直挂起的命令（比如运行top，不断echo），就是会自动退出的。-d命令是设置detach为true，根据官方的文档，意思是让这个命令在后台运行，但并不是一直运行（我们在一个正常的Linux Terminal中运行/bin/bash，运行完了也就完了，不会一直挂着等待响应的，所以确实没办法用daemon方式来跑/bin/bash）。这个地方官方早期和现在的文档也确实有些前后不一致，现在是detach，早期的文档说指定-d以daemon方式来运行容器，可能存在一定的误解。 另外，如果你需要跑容器里的bash，直接运行docker run -i -t CONTAINER_NAME /bin/bash 就可以了，如果觉得参数比docker attach多，可以设置一个别名（alias）来解决： alias dockerbash='docker run -i -t CONTAINER_ID /bin/bash'设置好别名后，直接运行dockerbash就可以进入容器的bash了
7. docker开机启动容器
有同学在docker下安装了nginx 但是不知道目录在哪，可以使用命令：sudo find / -name "50x.html"因为nginx里必定会有50x.html，所以查找它，结果发现nginx的目录在docker容器里，如果操作它，就需要进入容器的shell。必须先启动容器：sudo docker start “容器ID”
然后使用下边的命令进入shell：
sudo docker exec -it “容器ID”
bash将主机的文件复制到容器里：
sudo docker cp 主机目录 容器ID:容器目录
8. docker如何启动
你们这个虚拟机出现了一个失败的情况，很有可能是因为网络不佳的原因，你可以连接一个网络，或者是重新去对网络进行设置