所以我现在问一下，希望有人在该领域有足够的经验可以为我指明方向，这样我就不会多次走错方向。
简化的情况：
假设我写了一篇针对我的客户的具有Web界面和REST API的软件，这些软件绝对必须在客户所在地的本地网络中运行，并将作为“黑匣子”硬件设备提供给他们。除此之外，我基本上将“作为服务”提供给他们，这意味着维护和更新是我的责任。我带着一台无头预装和预配置的小型PC来到他们那里，将其连接到他们的网络，仅执行网络配置，然后就完成了。该设备已准备就绪，可以与客户网络中运行的任何其他软件组件进行通信。
为了更精确一点，我的软件产品在Linux（以及Windows）下运行，也应该可以构建将它作为Docker容器使用（如果对我提出的解决方案有意义，尽管我对Docker的专业知识仍然有限）。我希望在设备上安装CentOS7。
现在我面临两个挑战：
保持最新的CentOS软件包
保持软件包为最新版本
为了防止所有客户同时遇到相同的错误，我想完全控制哪些客户在设备上的哪个时间点更新哪个软件包。 （基本上是分阶段推出）。
关于我自己的软件包，它很可能以不同的更新渠道（测试版，稳定版等）的形式出现。
理想情况下，我也能够获取并向设备推送配置和其他文件。
如果我可以将现有解决方案用于所有方面，而不是滚动自己的机制，那就太好了。
该解决方案应该可以扩展到成百上千的客户。
到目前为止，我还没有想到：
Spacewalk，Puppet等。
用于管理CentOS系统。但是，我不知道是否有人擅长管理不在单个公司网络中运行的计算机。
将我的软件组件打包为RPM
或
将我的软件打包为Docker容器
我不知道在更新方面哪个更好。 Docker可能是过大了，对于每个客户而言，它只是一台计算机上的单个软件应用程序，我只是认为这样做可以简化应用程序更新。也许最好使用RPM软件包，这样我就可以将更新通道作为不同的RPM存储库进行处理，并使用Spacewalk / Puppet自己控制更新。
OpenELEC / LibreELEC JeOS方法
我不知道这是什么确切名称，也不知道是否有预构建的解决方案，但是我首先在OpenELEC中遇到过。基本上，整个操作系统和应用程序都打包在一个不可修改且可更新的（内核）映像中，该映像安装在目标计算机上，并且为用户和本地配置数据提供了一个单独的分区。
我知道是一个很大的问题，但是任何指针将不胜感激。
#1 楼
红帽曾经将Spacewalk命名为“红帽卫星5”，并决定将其废弃并从头开始构建新的工具集。然后，红帽将他们现在称为“红帽卫星6”的品牌基于Foreman的Katello插件。此外，Foreman还具有适用于Docker，Puppet和其他几个相关系统的插件。
但是，老实说，系统有点粗糙，需要完善。我经常碰到错误，并且不得不花费大量时间使所有部分正常工作-尽管它仍然非常酷和强大。
但是，您可能会遇到任何问题具有严格安全要求的客户端网络。在我的雇主处，我们不允许直接连接到互联网，并且几乎不能使用需要严格安全审查的代理，因此我们的能力仍然很有限，因此可能需要考虑您的更新模型-您将禁止这些类型的客户。另一方面，这是“即服务”模型优势的一部分。您不必担心或维护它，因此您将以客户的身份从事更多的中小型企业。
评论
非常感谢您的回答，我想我会带头去看看工头。
– Stefan Podskubka
18年4月23日在15:00
#2 楼
我可以在这里提供一些个人经验。我在一家有同样需求的公司工作。产品是BeagleBone（例如Arduino或Raspberry Pi），它运行我们的软件并将数据发送回我们的SaaS。它必须安装在客户网络内部，并且是一个黑盒子，他们不会碰。当我走进这家公司时，系统的管理是一场噩梦。联网是一场噩梦。操作系统更新，保持在线状态，发布软件的新版本等等，这真是一场噩梦。
我们最终选择的途径最终运行得非常好：整个应用程序和支持软件包作为Docker容器交付。这使我们能够轻松交付应用程序代码更改并控制任何支持软件（ffmpg，gcc等）的版本。
将应用程序抽象化后，可以使操作系统尽可能地简化。我们需要的是一个可以运行docker的简单的简单操作系统。我们的一位低级工程师实际上是制作了自己的Debian内部分叉（如果我还记得的话），并且我们将其直接嵌入到设备中。
我们已经与所有客户签订了服务合同为了每年对这些机器进行维护，因此，当我们的现场技术人员上门服务时，程序就是用最新嵌入式操作系统附带的新硬件替换整个设备。我们不必为了运行Docker而进行许多操作系统更改，因此通常甚至没有必要进行交换。但是出于程序上的考虑，我们总是交换硬件，无论是紧急服务电话还是年度维护。
我不能说这是否是一种标准方法，而只是说它确实有效对我们有好处，并且是救生员。听起来您的想法是将OS作为不可变的映像交付，这是相同的想法。
编辑：当我离开时，我们仍在使用本地生成的bash脚本来自动化Docker容器部署，但想法是转向配置管理工具（如Chef，Salt或Ansible）。基本前提是您在某处有一个私有Docker注册表，然后在设备上只需运行几个命令：
docker pull my-private-registry/my-custom-image:latest
docker run my-custom-image:latest
如果您将始终使用“最新”标签，然后可以让设备附带cronjob，然后cronjob始终关闭其本地运行的Docker容器，并在计划的维护时段内每周重新拉出“最新”标签。
评论
感谢您提供有用的答案，您能否详细说明如何自动更新Docker容器？我了解在服务器端，您可以选择（Docker注册表，Docker Hub等）。但是，您如何在客户端管理这些更新？作为Docker的新手，我尚未掌握如何更新Docker容器的实际工作方式。是否有自动的工作流程，还是必须手动删除容器的旧版本并运行新版本？谢谢！
– Stefan Podskubka
18 Mar 5 '18在9:39
当然。我已经编辑了答案以提供更多详细信息。
–BoomShadow
18 Mar 5 '18 at 16:34
评论
有趣的挑战...但是，“我想完全控制哪些客户在哪个时间点更新哪个软件包”在我看来像白日梦...组织越大，您获得的东西就越少你要。那么，您是否会远离此类潜在客户/客户？更好地为那些...制定计划b ...@ Pierre.Vriens感谢您的评论，但我认为这不会成为问题。所有客户都是特殊业务部门的一部分，他们通常只有一个很小的组织，没有自己的IT部门/专家，因此他们会对“黑匣子”方法进行更新和（希望）能够正常工作感到非常满意。这更像是我为客户托管的服务，但是由于某种原因，它必须托管在客户办公室中。客户只是软件的用户，如果出现任何问题，他们需要拨打支持热线。