记一次由docker容器使得服务器cpu占满密码和密钥无法访问bug
Bug场景：
前几天在服务器上部署了一个免费影视网站，这个应用需要四个容器，同时之前的建站软件workpress也是使用docker部署的，也使用了三个容器。在使用workpress之前，我将影视软件的容器全部停止。
再使用workpress时，服务器的内存资源一切正常，此后就没管了。过了两天重新登入服务器时，发现完全登不进去。
问题描述
ssh登入失败，aliyun的workbench提示无法使用密码登入，此刻还没有意识到问题的严重性，以为是常见的配置问题（之前不小心配置了设置密钥对），首先重置密码，而后重启。
当服务器状态重启了半天还没有启动的时候，我就意识到了事情的严重性，使用VNC无密码登入，发现连接不上，使用finalshell连接访问超时。这时我理解估计是我服务器内部出现了问题。
原因分析：
使用阿里云的安全服务（推荐大家使用阿里云的云助手和自助的运维排查），发现是由于内存和cpu占用过高，当时我以为服务器被攻击了，因为之前的cpu的状态一直是很稳定的水平此刻一下子占百分之百。
通过查询资料，我发现cpu和内存的关系使用更加复杂
当内存资源紧张时，操作系统会启动一系列的内存管理机制来释放内存。操作系统通过 页面交换（swap） 和 内存回收（page reclaim） 来释放内存。
-
页面交换（Swap）：当物理内存（RAM）不足时，系统会将一些不活跃的内存页（数据）移动到交换空间（swap），从而腾出内存供当前活跃的进程使用。如果交换空间不足，或者交换操作过于频繁，会导致系统变得非常慢，因为硬盘的读取速度远低于内存。
-
内存回收（Page Reclaim）：这是指操作系统通过回收未被频繁使用的页面（通常是程序或数据的缓存）来释放内存。当系统发现某些内存页面长时间没有被访问时，它会将这些页面释放回空闲内存池。
当内存不足且系统开始触发内存回收和清理：
-
清理内存：内核在进行内存回收时，将某些数据从内存移动到磁盘，或者将不再活跃的内存页面写入交换空间。如果内存中有大量的数据需要清理（例如缓存、文件系统数据、进程的私有内存等），那么这些清理动作就会导致磁盘的读写。
-
磁盘缓存回收：当系统回收内存时，缓存（例如文件系统缓存、应用程序缓存等）中的数据会被清理。这些数据如果稍后还需要用到，就必须从磁盘重新读取。因此，系统的磁盘 IO 会迅速增加，因为很多。
所以根本原因是：内存不足，系统开始触发清理内存策略，而系统及程序运行本身就是需要那么多的数据，数据被清理后又必须重新加载，因此就导致了系统IO读高（清理掉的仍然需要从磁盘上读取）。同时清理本身需要磁盘输出，两者相加导致了磁盘IO高，当IO达到磁盘性能峰值时，CPU就只能等待磁盘数据什么也做不了，对于我们的响应无法回应。
解决过程——修改容器由docker自动重启策略：
-
首先由于已经无法登入，无法对操作系统做出指令，只能借助阿里云官方来协助。再控制台点击售后在线描述问题
-
阿里云安排工程师来服务解决
-
首先建立快照（备份）授权给阿里云。工程师帮云盘暂时扩容，就可以操控系统了
-
再获得命令控制权之后，修改了/etc/sysctl.conf文件下的vm.swappiness 值 ，修改成了40。
执行了sysctl -p。vm.swappiness 是一个与 Linux 内存管理相关的参数，它控制着系统在内存使用达到一定水平时，使用交换空间（Swap）的程度。交换空间（Swap）是硬盘上的一个区域，用来存储暂时不需要常驻内存的内容，从而释放内存给更重要的进程。vm.swappiness 值的范围是 0 到 100。40 是一个平衡的设置，既能确保内存使用率不至于过高，也能避免过早地使用交换空间。 -
执行 sysctl -p执行 sysctl -p 命令的使 /etc/sysctl.conf 文件中的配置生效。
-
上述任务是使得内存到80使用swap，而不是等到90再使用，这样cpu不会被占满，使得再原先内存环境下仍可以使用cpu。
-
再登入系统之后使用配置下 atop监控工具，可以检查系统的进程
这里第一个进程是由于内存过大而产生的，此时我发现原先我关闭的docker应用居然全部都再运行，我之前明明是停止了的 -
原来因为我的容器再部署的时候直接默认是docker容器重启的时候同时自动重启如下代码所示，这就导致了当我7，8个容器运行的时候内存占用直接超过容量，而此刻我的swap策略没有过早的进行交换，这些使得cpu宕机，无法正常响应其他的操作。直接将容器停止并展示删除即可恢复正常的内存和cpu，重新部署的时候配置不自动重启
ocker inspect --format '{{.Name}}: {{.HostConfig.RestartPolicy.Name}}' wordpress_wnjx-wordpress_Wnjx-1
/wordpress_wnjx-wordpress_Wnjx-1: always
docker自动重启：
为什么需要设置自动重启策略？
自动重启策略可以确保即使在 Docker 或系统重启后，关键应用（如数据库、Web 服务器等）能够持续运行，减少人为干预。使用自动重启策略，容器会在错误退出后自动恢复,如果你有多个容器，手动监控和重启容器会非常麻烦。设置自动重启能够帮助自动化这个过程，减少运维负担。
重启策略如何与 Docker 守护进程重启结合使用
Docker 守护进程（Docker Daemon）会随着主机的重启而重启Docker 守护进程管理容器的生命周期，包括启动、停止、重启等。当 Docker 守护进程启动时，它会检查每个容器的重启策略，并决定是否重启这些容器。因此，如果设置了自动重启策略（例如 always 或 unless-stopped），当 Docker 守护进程启动时，符合条件的容器会被自动重启。
容器重启策略和系统服务管理（如 systemd）
可以将 Docker 容器配置为 systemd 服务，通过 systemd 来控制容器的启动和停止。例如，使用 systemd 也可以实现容器的自动重启。这样，即使 Docker 守护进程重启，systemd 也会确保容器按期望重启。
[Unit]
Description=Docker Container for my_container //描述服务的名称。
After=docker.service //确保容器在 Docker 守护进程启动后才会启动。
Requires=docker.service //如果 Docker 守护进程没有启动，容器服务将不会启动。
[Service]
Restart=always/no //确保容器在退出时自动重启。也可以设置为 on-failure，只在容器异常退出时重启。
ExecStart=/usr/bin/docker start -a my_container//启动容器的命令，-a 选项确保容器的输出会连接到当前的终端。
ExecStop=/usr/bin/docker stop -t 2 my_container//停止容器的命令，-t 2 表示在容器关闭时等待 2 秒。
//指定该服务应该在系统的多用户模式下启动
[Install]
WantedBy=multi-user.target
//重新加载启动服务
sudo systemctl daemon-reload
sudo systemctl start docker-my-container.service
