我在一家提供Linux设备以及在该设备上运行的自定义应用程序套件的私人公司工作。该应用程序套件由大约13种不同的C ++应用程序组成，其中一个是GUI（Qt）应用程序，另一个作为服务运行，并通过IPC从GUI控制所有其他组件。 Linux设备只是在可满足我们客户特定需求的专用硬件上运行的Debian安装。
当前，开发人员使用git在自己的开发计算机上工作，当需要构建应用程序套件进行测试时，我们使用Jenkins克隆存储库，然后在单个管道中依次构建每个应用程序。我们正在努力使各个应用程序并行构建，但是我们正在尝试解决一些依赖性问题（例如，一个应用程序需要先构建另一个应用程序，然后才能构建），以使其有效运行。这使我们的构建时间超过了一个小时。而且，如果倒数第二个应用程序使构建失败，那么我们只是浪费了很多时间，只是发现了一个问题，需要回馈给开发人员。不理想。构建套件后，将其发送给质量检查人员，由质量检查人员将套件加载到自己的设备上并开始执行测试。没有Web应用程序，该套件不是公开的，甚至没有下载，它们都是通过生产/销售方式提供给客户的，因为已经安装了该应用程序套件的Linux设备。
我们的公司已开始对事物采取更加敏捷的方法，因此我们确实在尝试改善我们的业务方式。除其他外，关于如何尝试将Docker纳入我们的工作流程以使事情变得更容易的说法很多。我一直在阅读docker.io文档并搜索非Web应用程序用例，但我似乎无法理解Docker如何切实适合我们当前的环境。
我读过一些共同的好处，但我认为这不适用于我们的组织。
标准化。消除了“在我的机器上工作”的问题。
开发人员在Linux设备之上使用他们自己的开发环境。构建应用程序套件并将其发送给QA后，他们会将套件加载到自己的设备上，以模拟最终用户的需求。我认为Docker不会从这种情况中受益，因为这些设备需要运行Docker Engine才能使用Docker容器，而这不是将设备提供给客户的方式。
使部署更快/更容易
我们实际上没有在外部部署任何东西。我们通过Ansible在内部将“应用程序”套件“部署”到需要在其设备上使用的人，但是我们的规模如此之大，因此QA不能仅仅复制该套件并将其安装在他们的机器上。我们不会部署到服务器或云，所有内容都在设备本身上。
如果我们能够解决影响某些应用程序的依赖关系问题，我认为Docker可能真正拥有的唯一好处就是在构建过程中。我全都想尝试新事物，但是尝试它们通常会带来明显的收益/投资回报。我只是看不到Docker。还有什么我在忽略或者只是看不到的东西？
答案 0 :(得分：0)
这可能是错误的stackexchange，但这是我自己的工作得出的一些想法。列表不完整，但是我注意到了一些明显的好处。
构建/配置项过程肯定会让您从使用容器中受益。我假设您有构建服务器来构建软件。考虑您引入了服务器上需要的新工具/库。现在您提到您使用Ansible，因此您可能已经对此有了解决方案，但是如果没有，您将只能更改一个Dockerfile，重新构建容器并将其部署到构建计算机，或者在安装过程中直接使用它。自己建造。
现在您说您有一些依赖问题。我经常用这种C ++设置看到的一个问题是，很少有人知道构建环境中实际需要什么。您的Jenkins设置如何？通常，它是一款静态软件，没人愿意接触，因为几年前离开公司的某个人提供了构建服务器并创建了Jenkins职位。使用Dockerfiles进行版本控制后，您将获得有关环境中所需内容以及这些要求如何更改的全部历史记录和文档。
Docker还有助于扩展和平衡构建服务器。同样，通常对于C ++，您想为代码运行一些QA工具，例如Valgrind或某些静态分析工具。在大多数情况下，这些应用程序占用它们正在运行的计算机的全部CPU或RAM容量。使用docker，例如，您可以运行同一Docker映像的十个相同副本，并且可以相对轻松地限制它们的资源。这将帮助您并行化构建过程。上下扩展执行程序的数量也非常容易。
新开发者加入公司后会发生什么？他们是否需要从尘土飞扬的文档中搜索还是等待Bob放假来解释他们的机器需要什么才能开始构建。再次，您可能已经使用例如虚拟机解决了此问题，但是再次，您可以告诉它们安装您/他们选择的IDE和docker，然后提供Dockerfile和源代码。该Dockerfile将包含所有其他依赖项，并且将立即能够使用该映像构建软件。使用受源代码控制的Dockerfile版本，您大多数时候也将知道在应用程序历史记录的什么位置需要什么。