我们需要一种方法来高效、稳健地向现场用户推送更新，这些用户都拥有我们提供的相同的 Ubuntu 盒子。我们还需要一些东西，当我们升级操作系统时（正如你所知，我们早该进行 Ubuntu 升级了），我们可以对我们的软件包“正常工作”感到相对安全。
我最初想到的是 Docker，但越想越觉得可能不是，因为这些盒子是我们的，我们控制上面的操作系统，这是 Docker 价值主张的重要组成部分，至少我是这么理解的。因此，如果我们知道我们的机器将始终是 Ubuntu，并且我们基本上只有一个 Django 应用程序和一些要运行的进程，那么 Docker 比 deb 包更好吗？
TL;DR：Docker 与 deb 软件包的分布式设备始终运行 Ubuntu，因此平台独立性并不那么重要。
答案1
容器很好，您被迫将应用程序及其依赖项打包在一起，并且基本上被迫将其自动化。然后，在一台机器上自动启动一个（或多个）就相对容易了。
这可以帮助升级。稍后再回到这一点。
我们需要一种方法来高效、稳健地向现场用户推送更新。
Docker 和 rkt 都有自己的容器存储； rkt 至少还提供完整的加密完整性检查。 Docker容器是分层构建的，这提供了一些效率（只需要拉取更改的层）。rkt目前每次都会提取完整的图像，或者至少在我安装的版本中是这样。
可以在两者之间转换映像 - 例如，在最近的一个项目中，我使用 Docker 进行开发（因为这些层可以提供很大帮助），然后将映像转换为 rkt 进行部署（因为 rkt 对系统管理员更友好且更少）安全担忧，至少对我来说）。
请注意，这两种技术目前都在快速发展。例如，容器格式正在发生变化。因此，如果您决定使用 Docker 或 rkt，您应该期望进行频繁的升级。
顺便说一句：所有依赖项都打包在容器中，因此容器外运行的操作系统版本不太重要。但您通常会运送一个新集装箱每一个更新。这会消耗相当多的带宽。
我们还需要一些东西，当我们升级操作系统时（正如你所知，我们早该进行 Ubuntu 升级了），我们可以对我们的软件包“正常工作”感到相对安全。
您在这里需要的是一个测试实验室。对升级有效的信心主要来自于您已经测试过，在您支持的所有变体中重复。
容器可以提供帮助——您可以使用它们自动运行测试（例如，请参阅 GitLab 的自动化测试设置）。就主机资源而言，容器相当轻量，比虚拟机轻得多。因此您可以经常进行测试——甚至是每次提交。并且应该使用构建您要发送的容器的相同自动化脚本来运行测试，这样您就可以确信您的容器映像可以正常工作。
但对于实际的基础操作系统升级，您需要在实际硬件上进行测试。您也可以使用虚拟机测试操作系统升级（这很好，因为您可以非常轻松地回滚映像，并且可以自动化执行此操作），但您还需要测试实际硬件。特别是因为他们在现场，升级失败可能代价高昂。
简而言之：容器对于很多这样的东西很有用，但我认为该软件还不够成熟，以至于我可以放心地依赖它在未来 5 年的稳定性。不过，我预计在一两年内，这种情况将会改变，所以现在就考虑这个问题是个好主意。
PS：需要考虑的非技术性问题：如果您从 Ubuntu 档案库下载软件包，Ubuntu 可能会通过从同一位置提供可用源来处理您的 GPL 合规性。如果您发送容器镜像，则必须担心这一点。 （当然，您在运输机器时也应该这样做。）