一开始并不了解linux系统的分类，默认Ubuntu==linux，结果闹出了大错误。下文详述。
首先，参考的配置教程是网络上的这个教程： 使用nvidia-docker2 - Gemfield的文章 - 知乎
第一步的配置Nvidia GPU驱动就出现了问题。首先，由于使用的是Amazon Linux，在线安装Nvida GPU的第一步就由于无法找到apt命令而失效。没办法只能转到下一步：手动安装驱动。由此我又花了大力气去google如何在Redhat版本的linux上安装apt-get命令、如何运行deb包、如何安装dpkg命令等等等等到最后追本溯源才发现了自己思维上的误区。
上面行不通之后又换了一个教程，在此， 强烈推荐使用PPA方法配置Nvidia 驱动
参考的是这个教程： [Ubuntu 1804]PPA方式安装Nvidia驱动
安装的是third-party free recommended版本的驱动。需要注意，安装之后一定得reboot，不然无法生效。部署项目服务器时，为了应对停电等情况影响正常web项目的访问，会把Docker容器设置为开机自动启动。
如果创建时未指定 --restart=always ,可通过update 命令设置
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模式的容器。
--restart选项不能与--rm选项同时使用。显然，--restart选项适用于detached模式的容器，而--rm选项适用于foreground模式的容器。
在docker ps查看容器时，对于使用了--restart选项的容器，其可能的状态只有Up或Restarting两种状态。
示例：
补充：
查看容器重启次数
查看容器最后一次的启动时间因为最近有人修改服务器的防火墙，所以docker容器重启失败，然后百度了一下，重启docker即可解决，但是重启docker后，在portainer看docker的状态却是down，这种情况下，重启一下portainer就可以了，因为不想重启docker的时候容器都挂掉，所以加了一点配置，不知道是不是这个引起的
Docker 是一个开源的 应用容器引擎 ，让 开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows 机器上，也可以实现虚拟化 。容器是完全使用沙箱机制，相互之间不会有任何接口。
由于本地开发好的程序往往都需要部署到服务器上进行运行，这就导致了程序需要运行在不同的环境上，这通常是一个令人头痛的事情。在过去，开发团队需要清楚的告诉运维部署团队，其所使用的全部配置文件+所有软件环境。不过，即便如此，仍然常常发生部署失败的状况。
于是乎， 虚拟化 技术应运而生。开发团队将开发好的程序在虚拟机上运行，这样就能解决运维的问题。但是由于虚拟机技术过重的特性导致了其 资源占用多、冗余步骤多以及启动慢的缺陷 。而这个时候 一种新的虚拟化技术搭配上容器化的思想 的产品便出现了，而它就是Docker。
下图是虚拟机技术和容器化技术架构的对比。我们可以得出以下总结：
[上传失败(image-efadd2-1643314980201)]
]( >导致服务器也down掉了。再次启动服务器的时候，docker服务不能正常启动了，原因可能是服务器直接down掉的，并没有把docker的服务给stop掉，所以dockersock认为服务还是启动的。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）