我是所罗门·海克斯（Solomon Hykes）的仰慕者，他的公司由三位一体创投（Trinity Ventures）资助的dotCloud种子走到了南方，濒临出售花生的边缘。 然后，所罗门（Solomon）和密切的合作者做了一些疯狂的事情：他们决定开源为dotCloud构建的容器技术的源代码。
他的投资者对此表示反对，但三位一体的开放式风险投资人丹·斯科尔尼克写道：
多亏所罗门（Solomon）和他的团队，我们有了一个名为Docker的公司 ，该公司着火了，并且正在改变软件基础结构的世界…。
所罗门·海克斯（Solomon Hykes）是一位杰出的企业家。 没有他的洞察力和勇气，今天的Docker不可能取得成功，更不用说技术成就了。 他知道什么时候该减少诱饵，什么时候该去拿肠。 如果没有出色的，有远见的创始人领导，好主意和伟大的投资者将无法完成任何事情。 当然，所罗门不可能一个人做到。
在使用Mac，Windows或Linux机器进行30分钟的教程后，您可以制作一个Docker容器。
但是在2015年1月，很多人谈论Docker，一些人做了一些概念证明，几乎没有人对生产环境Docker进行过处理
分析师好评
这是2015年12月29日此博客中描述的Forrester 2016年预测示例。
容器风靡一时！
在过去的一年中，诸如Docker之类的容器在著名的云提供商中引起了极大的兴趣和欢迎，他们使用它们来提供一些最大，最流行的云服务和应用程序。 容器的采用是由以下承诺推动的：容器提供了“一次构建即可在任何地方运行”的能力，从而为技术经理提高服务器效率和可伸缩性。
也许我们可以在2016年底这么说，但是我们离实现梦想的目标还有几步之遥。 请进一步阅读此博客，然后您决定2015年12月的现实是什么
安全问题
关于此问题的最新最佳文章之一是，在开发过程中忽略安全性怎么办？ 他说了一些话：
- 新技术扩展了系统的攻击面。
- 攻击者将新功能和新技术视为潜在的弱点。
- 错误地认为，利用某些技术是更安全的即用型解决方案。 这并不一定意味着在集成新技术后系统仍将是安全的。
- 在开发生命周期的早期阶段（例如分析或设计），在其中收集需求并选择体系结构组件和技术，可能会引入安全漏洞。
由于这些原因，最有效的解决方案是：
从攻击者的角度将开发人员暴露于安全性。 更具体地说，与其仅仅培训有关安全编码实践的知识，不如像它们是攻击者一样 ， 应通过发现和利用软件漏洞来指导他们。
坚固宣言
该小组自2012年成立以来，致力于弥合开发人员社区与安全社区之间的鸿沟，以便我们可以更有效地进行交互和协作，以实现可靠和安全的应用程序的共同目标。
为什么Docker仍未在企业中广泛使用？
以下是2015年12月4日朱利安·邓恩 （ Julian Dunn）博客的一些名言， 朱利安·邓恩 （ Julian Dunn）是一位思想渊博，很酷的作家和经验丰富的程序员。
这篇文章只是关于令人恐惧的认识，即容器化为人们滥用提供了一个全新的竞争环境。 在未来的几十年中，许多技术专业人员将首当其冲， 因为人们如今在使用容器时会犯下错误 。 更糟糕的是，这些错误将长期存在，因为可以想象，容器（独立于运行时的可移植工件）在野外的生存时间比使用JSP，Struts 1.1编写并在Tomcat 3下运行的Web应用程序长得多。
原因如下：
在没有真正理解为什么的情况下使用容器
““ Docker Docker Docker”之所以如此有名，是因为与任何新技术一样，一大批不合格的技术“专业人员”已准备就绪，并渴望将其应用于所有领域。 在初创企业中，不乏开发人员坚持认为Docker是“未来”，并且必须将其用于所有方面。
盲目将遗留应用程序容器化
“ ..将旧有应用程序塞入容器中。 这是没有道理的。 容器设计用于按进程隔离，因此，每个容器一个进程。 容器对于运行具有一百万个进程的Oracle 12c或SAP HANA并不是特别有用。 您可以将它们容器化，但是为什么呢？ 如果一项服务不是您经常要翻新和更换的东西，那实际上是没有意义的。
我还看到容器技术被用于永久保留旧版应用程序，这更加可怕。 因此，我们可以预期，到2050年或以后，仍将在容器内运行当今的应用程序。”
忽略发展原则
但是，在容器化的世界中，对于没有采用devop惯例的团队来说，情况变得更糟。 现在，这些应用程序团队不仅在墙上扔了Java字节码，还把它们扔在了墙上。 他们正在抛出整个机器图像。 考虑一下Linux系统上所有可能出错的问题，以及需要进行多少维护才能使其平稳运行，例如安全补丁，重新启动，性能调整等等。 现在，将所有工作应用到微服务世界，在生产环境中，您可能有成千上万的容器（实际上是成熟的Linux系统）运行。 如果开发人员和操作人员之间没有良好的合作和共同的责任，那么保持开灯状态将成为一场噩梦。当发生生产故障时，这将导致两组人员崩溃。
缺乏标准的质量保证原则
企业如何知道图像正常工作？ 还是合规或安全的？ 还是即使做出更改也将继续保持这种方式？ 直到容器采用者意识到他们所了解的确保软件产品交付安全的所有知识都不会被扔进容器世界之前，我们可以预期会有很多错误，不安全的应用程序部署到生产环境或推到Docker Hub，像病毒一样，它们会被他人使用。
包含所有用户区的巨型容器图像
默认情况下，大多数容器都提供完整的Linux系统，包括/ bin，/ usr等所有内容。 构建基本映像的人员太少，或者从头开始构建容器（从Docker中从头开始是从头开始）。
我认为，“大攻击面”是一个基本的设计问题，容器是从虚拟机和裸机进化而来，而不是革命性的一步。 容器技术已经非常成功，纯粹是因为它能够有效地重复数据删除并将整个Linux用户域打包到可移植，随处运行的映像中。 但是应用程序进程仍然认为它可以在完整的多用户Linux OS中运行
结论
“技术可以持续很长时间。 美国数字服务部的Mikey Dickerson最近谈到，在过去30年中，Medicare如何仍然主要运行在7000个COBOL书面工作上。 没有人完整了解这些作业之间的依赖关系，甚至没有从哪里开始替换它们的完整地图。 由于模式是如此普遍地被复制，因此对于子孙后代，我们必须尽量减少不良解决方案，并提出更多好的解决方案，这一点很重要。”
令人遗憾的是，技术炒作造成了一个现实的失真领域，使人们无法清楚地评估他们对该技术的使用是否a）合适且b）设计合理，
Apcera Docker解决方案
来自Apcera的Josh Ellithorpe在DockerConEU上演示了此演示 。 什么是Apcera？ 最好的直观描述是在这个简短的博客中10X Savings
什么是Apcera Docker解决方案？ 恕我直言，它解决了朱利安·邓恩（Julian Dunn）的许多（如果不是全部）问题。 Apcera提出了一种作为其平台功能的一部分而实施的过程，因为容器漏洞是人为错误，直觉和判断的最佳组合，而后者是对容器的最佳选择，而不是对容器的最佳选择。
我使用Josh的视频中的屏幕截图来说明：
转向生产的企业希望使用图片中的三个项目符号来扩展Docker安全性和策略控制
在第二张幻灯片中，Apcera建议Docker的附加组件，以回答Docker到目前为止仅在注册表级别执行的特定问题。
如果我叫Container先生，那我自然会问“我可以走哪条路？” “我可以使用多少资源？” “我被允许在哪里着陆和部署？”，“我应该使用什么软件包，以及我永远都不要接触的软件包？” “有人总是知道我在做什么，谁能在我为时已晚之前帮助和纠正我的错误？”
企业怀疑的第一个症状是要求他们使用其他工具进行身份验证，这与他们现在使用的工具不同。 因此，Apcera有一个新命令“ apc docker run”来代替“ docker run”。 它使用企业熟悉并信任的所有授权工具
最后一张幻灯片列出了Apcera可以为与Docker相关的本机工作负载提供的基本策略示例
该网络研讨会介绍了Apcera与FlawCheck合作完成的工作，以测试Docker映像是否存在已知漏洞，然后再将其部署到生产环境中。
阅读了朱利安·邓恩（Julian Dunn）的博客之后，我可以看到Apcera如何在部署Docker或任何其他新技术时最大程度地减少企业对厄运的恐惧并建立信任。
如果像Apcera这样的公司更多，那么Forrester的预测（见上文）将立即成为现实。
我熟悉Apcera，但是如果您知道类似的公司，我们将很高兴收到您的来信。 我知道Docker 收购了Tutum等几家公司，我在2014年2月采访了Borja Burgos的前任首席执行官（请参阅Tutum打算对Enterprise进行docker化 ）。 但是，Docker有很多方向需要关注，以致优雅的Apcera解决方案仍然是我的第一选择。
翻译自: https://www.javacodegeeks.com/2016/01/docker-containers-not-used-widely-enterprises.html
