我不完全确定mongodb是做什么的，但我很确定它会在更新时重新启动自己。
docker-engine的问题不在于它不会自动重启，它实际上会重启，你可以在更新后运行以下命令来验证：

sudo service docker status

只是它不会重新启动正在运行的容器。我不知道为什么它必须是这样的，因为理论上它可以在服务重新启动时带回正在运行的容器，但无论出于何种原因，它都不会这样做。
有两种方法可以解决这个问题。
第一种也是简单的方法，它可以排除docker-engine的更新，如果你看到它可用，手动进行更新。

sudo apt-mark hold docker-engine
sudo apt-get upgrade

如果有更新以及更新是否被保留，您应该看到一个通知

...
The following packages were kept back:
docker-engine
...

如果你的容器在升级时无法重启，你应该走这条路。
但是，如果您可以重新启动它们，则可以使用第二种方法。您可以在启动容器时设置重启策略，如下所示：

sudo docker run --restart=always -d image-name

这样，当docker-engine重新启动时，容器也会随之启动。这意味着在更新时，以这种方式启动的容器会自动启动。

这是deb包中的预安装/后安装脚本的设计，也是构建包的人的决定（尽管在www. example上拆开了最新的杰西构建） www.example.com ，我没有看到他们的控制文件中的停止，只有注册和开始）。
我能给你的最好的建议是，当你不能忍受任何停机时间时，不要运行系统升级。在此之前只进行下载（apt-get upgrade -d），然后在中断窗口期间启动升级，从而最大限度地缩短升级时间。您也可以将docker-engine包置于挂起状态，这样它就不会使用dselect并在包名上按=来自动升级。

正确的方法似乎是docker守护进程的live-restore选项：
https://docs.docker.com/config/containers/live-restore/
对于Linux docker服务器（您似乎正在这里运行），您可以在/etc/docker/daemon.json中使用以下命令为守护程序启用live-restore：

{
  "live-restore": true
}

然后运行以下命令重新加载配置，而无需重新启动任何容器：

sudo service docker reload

完成后，您的apt upgrade不应在重新加载守护程序进行升级时关闭任何容器，并且不应导致任何问题，* 只要升级不是主要版本 *。
最后一个警告很重要，因为在容器运行时在主要发布边界上升级docker守护进程可能会使其无法重新连接到容器，这意味着您需要手动重新启动它们。我会计划关注新版本和任何主要版本，计划一些停机时间，并在升级之前停止容器。
总的来说，我觉得如果你有这个版本，你应该对你的版本控制和配置更加了解和警惕，因为版本和配置的同步不会在升级时为你处理。
但是对于docker-ce和相关包的标准升级，这似乎发生得非常频繁，到目前为止，这对我来说工作得很好。