用例-大规模的Docker

(Viraj)好。好吧，我得从这个开始。

[贾根]哦，我忘了。

[Viraj]这是我们的律师要求我们的，你知道，放在那里。

[Viraj]这就是我的团队的一些情况。所以，我们做了很多事情，就像在座的各位一样。如果你在DevOps领域工作，你知道，我们做CI/CD，我们写管道，我们有一个DSL，通过它我们能够，你知道，创建一堆CI/CD管道，你知道，做一堆事情。你知道，在农场上运行测试，进行构建，进行单元测试，创建Docker实例，在生产中部署它们，所有这些都是通过这些管道驱动的。我们的团队负责这类工作。

[Viraj]我们围绕Docker，围绕Artifactory，围绕Carson这样的内部工具做了很多工具开发，你知道，我的一个朋友会在今天晚些时候的演讲中谈到这个。我们做分析，做POCs。因此，无论何时我们有新产品或Docker的新版本，甚至当我们第一次开始使用Docker时，我们都是第一个尝试事物的团队。写出关于它的规格，给出关于它的建议，你知道，我们提出了驱动整个过程的文档。

Viraj:你知道，在制作过程中，我们会与其他团队进行交流，他们会在制作过程中使用我们的一些不同服务。

[Viraj]我们非常专注于测试，所以我们所有的部署到生产中，我们所有的部署到Artifactory数据中心，任何事情都是基于我们所做的自动化测试。我们尽量不手动部署任何东西。这就是我们如何将自己与Oracle内部或外部做同样事情的其他团队区分开来的原因。

[Viraj]我们也做很多图表，你知道，我们看数字。我们对代码进行了大量的工具化，我们查看了几乎所有的HTTP请求。我们在做什么。我们试图扳倒他们。只是，你知道，我们就是这样生活的。

[Viraj]你不需要这么快就翻新。

[贾根]他们得到指示要早点出去，嗯。好的。

维拉杰:我没那么坏。

[Jagan]所以，去年Viraj，你知道，在Maven构建方面有了巨大的增长，在甲骨文内部有了非常快速的适应。那么，自去年以来，情况发生了什么变化呢?

[Viraj]所以，去年他是那个给我这些数字的人，所以他可能是最后一个问我这些问题的人。但是，是的，去年我们有相当大的存储库。我不知道确切的数字是多少，但就一般存储而言，我们大约在40tb左右。现在我们有80tb的数据，这是在每天删除大约一百万个工件之后。这只是Artifactory的一般用法。包括很多不同类型的包装系统。但是,

[贾根]我认为幻灯片实际上并没有改变。

[Viraj]但是我们周围发生了很多变化。有内部的变化，有外部的变化，然后还有发生在Artifactory本身的变化。我会按顺序讲一遍。

维拉杰:所以第一个，就像这里，你知道，去年我想这几乎是一样的事情，但我们没有意识到这一点。但是大约90%的人，无论是在这里还是在外面，他们已经知道Docker。其中，70%的人尝试过Docker。他们中的大多数人都在运行一些东西，如果不是在生产中，至少是在开发中。

[Viraj] StackEngine是甲骨文去年收购的公司之一。这些是他们提供的数字，但他们这么做的核心原因，核心驱动因素是因为，混合云，虚拟机软件成本等等。

Viraj:除此之外，我们还有一些内部驱动因素。如果你看一下甲骨文去年的存储空间，这张幻灯片有点过时了，但是我们有大约800pb的存储空间。这是我们目前的云足迹。所有这些，至少，就像我说的，很多都是通过Docker相关或Docker部署的应用程序驱动的。所以在这个时候，我们真的是在喝水。

[Viraj]然后，你知道，这里有各种各样的神器。2015年我们只使用Maven。你知道，可能这里和那里有一些不同类型的打包系统的存储库。显然，我们的数据库在Oracle上。我们使用，你知道，部署Artifactory的Oracle Linux。

[Viraj]但如果你看看2016年的数据，我们有很多这样的人。比如，你知道的，Python。我们有RubyGems。我们有Yum存储库。很明显，Docker就是其中之一。而这仅仅发生在爆炸发生的一年之内。所以，你知道，我们周围的事情真的在发生变化。

Jagan哇。这里面有很多技术。那么，JFrog - JFrog平台如何帮助你，你知道，从这种转变到适应这种多样化的，你知道，包装类型和努力类型的建立，以及所有这些你拥有的东西。

[Viraj]所以我认为这是相当明显的。但是，尽管它很明显，它确实是驱动我们的东西。所以，每天，你知道，如果你喜欢，让我们说如果你看一下我在这里展示的存储库类型，你知道，如果我必须去安装一个Yum存储库和一个Nuget存储库和一个node。js npm存储库或者，你知道，一个Bower存储库或其中任何一个，我必须与不同的公司合作，分别安装它们。你知道，为它们分别配置负载平衡。分别为它们中的每一个配置[…]代理。我是说，爆炸还在继续。从我们的角度来看，在Artifactory中完成这一切，你知道，没有什么比这更好的了。这就是我们选择Artifactory的一个重要原因。

[Viraj]另一个重要的事情是，你知道，它允许我们做的是我们在Artifactory的基础上开发的一系列服务。我们仍然可以重复使用它们。所以我们有一个工作流引擎，它是基于特定事件驱动的。它驱动我们如何配置我们的系统。它决定了我们如何在系统上为用户提供服务。它驱动，你知道，减轻不同的存储库。我们不需要写任何东西，因为我们已经为Artifactory写过了，一旦完成，我们要做的就是添加类型，我们就可以开始了。

[贾根]所以你的意思是Artifactory的普遍性确实让你受益。您不必寻找其他自定义解决方案。

[Viraj]。是的。还有标准的东西，比如Logstash或者Sensu监控。所有这些都是内置的，你知道，我们也有自己的内部，你知道，代理，像EM等等。都准备好了。我们能够扩大规模。例如，我们的系统运行在大约6到7个不同的数据中心。我们不需要为这些存储库中的任何一个单独设置所有这些。我们可以从头开始。

[贾根]所以，很明显规模很大。对吧?所以，你知道，当你经历这一演变时，为什么你会选择Docker。或者说达到这一步的挑战是什么。

[Viraj]所以，有很多原因，我马上就会讲到，但我认为你可能应该看看我们的Docker数字。好的。和。好的。这就是我们现在的情况。如果你看一下这些数字就能大致了解我们使用Docker的程度。所以，我们总共有80tb的人工制品。在这4tb中，只有纯Docker。目前我们正在处理1.5 Docker特定的请求。这就是我们在这个层次上与Docker集成的深度。

现在来谈谈我们这么做的原因。嗯，首先是数字。对吧?就像我在业界的一些朋友，他们仅仅因为数字而对Docker中心产生了问题。我们能够得到所有这些信息，因为我们有系统，现有的系统，可以为我们提供这些数据。但我们选择Docker的原因其实是多方面的。有两条不同的路径，如果我看它。有开发用例。所以，你知道，我们在生产中提供了很多服务，它们要么是基于Docker的，要么是作为容器的Docker本身。有一些服务还没有投入生产。 And I’ll get to that slide in a second.

[Viraj]所以我们选择Docker的一个重要原因是，你知道，持续集成所提供的需求。你知道，一件大事是我们有很多产品。hth华体会最新官方网站我现在都数不清有多少人了。但是这些产品中的每一个都有一个很长的测试用例hth华体会最新官方网站列表，这些用例是每天都在进行的。每次他们运行测试用例的时候系统都必须停止运行。有一些清理工作需要做。需要安装预配置。我们需要一种能把所有这些组合成一个原子单位的东西。你知道，我们有安装程序可以做一些事情，但能够一次完成所有事情的能力是我们至少缺失的。这就是驱动我们核心的东西，你知道，驱动Docker。

[Viraj]另一个重要原因是，你知道，你可以给Docker打补丁。您知道，您可以对Docker映像进行小的更改，然后就可以开始了。显然，还有一些与基础设施整合相关的小问题。使用Docker，我们能够以100%的利用率运行我们的大部分东西。对于虚拟机，我们只有2%，5%，10%。所以有很多，你知道，我们能够处理的数字。

[维拉杰]很明显，你知道，在公司内部有很多农场。你知道，有很多DI - DIY PaaS服务，所以，你知道，有团队做Kubernetes。有团队做Mesos和Docker Swarm。

[Viraj]很明显，我的意思是，我们不需要安装jvm或应用服务器，然后将工件部署到其中。我们只构建一次容器，然后将其部署到任何地方。在我看来，这是最重要的一点。容器应该没有状态和配置。这是目前安装程序无法做到的。

[Viraj]你知道，甲骨文的另一部分并不太关注开发人员，而是更关注我们向客户提供的服务，也就是甲骨文在云上实际提供的服务。这个可以分成四个不同的部分。我们把现有的甲骨文产品捆绑在Docker容器中。hth华体会最新官方网站目前已认证Oracle Linux、WebLogic、Tuxedo、HTTP服务器和Coherence。在这个演讲的最后，我有一张幻灯片，我们提供了一些链接，你们可以去那里得到这些。

[Viraj]然后，你知道，基础设施即服务。所以基本上客户可以在Oracle提供的计算云服务中进行自己的部署、管理或编排。所以你可以使用你自己的第三方工具或开源软件。然后，有一个新的服务，你知道，它还没有推出。我没有具体的日期，但实际上你可以设计你想要部署的容器堆栈，并提供镜像，Oracle将运行这些镜像，管理你的编排和Docker工作负载。

[Viraj]然后你有，你知道，你使用的一堆服务，但是，你知道，你不能访问Docker api或Docker客户端。但在内部，我们使用Docker部署它们。这五个东西的合并。所以开发人员的工作流程和，你知道，我已经谈到的四种不同类型的服务，你知道，这是真正推动我们进入Docker工作空间的原因。

[Jagan]酷。看起来很不错。所以，很明显你们有很多注册表。从你们之前的幻灯片中可以看出。那么如何在您的工作流中使用这些注册中心呢?

(Viraj)好。

[Viraj]他们不太明白，所以他们不得不再重复一遍。这就是它的意思，对吧?嗨,Siri。

[贾根]所以是的，关于[…]。去做吧。

(Viraj)好。所以在大多数情况下，我的意思是，如果你看这里。正确的。所以我们让一群开发人员检查他们的核心变化。它们具有Docker文件中提到的声明性依赖关系。一旦他们完成了他们的构建，无论是在Jenkins或Hudson或TeamCity或其他地方，这些构建，你知道，他们创建了他们的图像，并进入注册表。现在我们使用的每一个服务通常在图像之间有一个一对一的映射。可能还有更多。我们把这些图像组合成堆栈。

[Viraj]所以你可以有一个堆栈，其中有mySQL, Tomcat，一堆Tomcat实例，以及那些堆栈。这些堆栈，基本上就是我们的服务足迹。然后我们使用CD或其他方式来发现服务，因为没有任何主机名或IP地址被特别嵌入到服务中。然后运营团队，我的意思是，他们帮助我们建立资源池和小组。如果我们有图像，实际上通过了整个测试，没有任何问题，然后我们将这些图像部署到生产中。这实际上是一个非常简单的工作流程。但真的，我是说，这就是原因。

(Jagan)好。所以，你知道，很明显你有大量的产品。hth华体会最新官方网站

[Viraj]。

[Jagan]版本和模块需要结合在一起。你能不能给我们一个感觉，比如这个复杂的[…]是如何管理的?你的渠道是什么样的?

[Viraj]我们拥有的CI/CD渠道。

(Jagan)是的。

(Viraj)好。传统上，我们有一个管道看起来像这样。直线流动，你知道，会有一些，你知道，在上面或下面或其他地方，但对更好的部分来说，大部分是线性的。但每一条管道都在做不同的事情。所以你会有服务1，它会使用内部工具来创建虚拟机。在那些虚拟机中，我们有一堆，你知道，[…]集群，你知道，web逻辑服务器和诸如此类的东西。那就是跑步。还有另一个服务，它会做一些非常类似的事情，但在Docker内部。所以他们不是使用虚拟机，而是使用Docker实例或Docker容器来做同样的事情。

[Viraj]所以有了这样的复杂性，有了这样的差异，你知道，可用的拓扑结构，我们必须做的是寻找一些实际上不会改变它们做事方式的东西，因为它们已经在那条路上走了。但我们需要提供标准，可以用来开发其他工具集或提供管理报告和诸如此类的东西。

[Viraj]所以我们所做的是使用一个事件经纪人，我们公司的另一个团队，他们会在接下来的几次演讲中谈论这些东西。事件代理拓扑是如何工作的我们所做的是这样的。所以我们把我们的管道分成阶段，这些阶段，你知道，是相当标准的。这些名字都是很标准的，你知道，都是一样的。但在每一个阶段中，具体发生的动作都是不同的，这取决于你使用的产品。

[Viraj]所以这些工作，所以你看到的这些橙色点，这些是Jenkins或Hudson的工作。我们把他们分成了不同的阶段。如果你看这个，你可以有一个工作做环境清理，另一个工作做这个，你知道，服务注册表。但是可能有很多工作可以为你创造这个角色。诸如此类。所以这让我们，你知道，在上面有一个一致的接口，而在下面这些工作可以完全不同。我们的工具与上层相互作用——我们谈到的阶段和这些具体的，你知道的，部分。因此，创建部分或删除部分实际上可以是正在运行的Docker命令。

[贾根]嗯，看起来是一段漫长的旅程。我相信这非常简单，对吧。你能告诉我们一些挑战吗，你知道，这里的发展是什么。

(Viraj)是的。所以在这个问题上，我们经历了一点痛苦。因此，当您运行一个80tb的存储库时，没有什么是容易的。因此，备份和恢复几乎是不切实际的。大多数文件在100tb时开始耗尽空间，Docker本身就很漂亮。所以我要切换到下一张幻灯片。你能看到这个吗?

(观众)。

(Viraj)没有?

[贾根][…]通读一遍。

(Viraj)好。所以，你知道，我们面临着一些问题。一个是Docker发布的频率，我的意思是，这是惊人的。所以，7天之后，他们就发布了。另一方面，我们的系统是基于Maven的，他们甚至可以在六个月内发布一个Artifactory版本。正因为如此，当我们更新Docker的最新版本时，Maven方面发生了巨大的变化。因为，我们说Docker从API版本v- 1变成了v- 2。或者客户端的兼容性改变了，所以我们不得不把我们的存储库切换到4.7。Oracle Linux版本本来应该运行1.0版本，结果发生了变化。

[Viraj]有很多这样的，相互关联的事情不断发生，所以我们最终做的是把我们的部署分开。Docker存储库将进入一个单独的Artifactory服务器，其他Maven或Bower或其他任何东西，它们都保留在一个存储库上。这并不是Docker与其他存储库类型的区别，我认为这更多的是关于部署的频率。如果你有版本变化相当大的存储库类型，我的意思是，相当频繁，那么我们就把它们放在一个单独的存储库上，否则我们就把它们放在我们拥有的主要稳定回购上。

[Viraj]除此之外，你知道，我们还有删除相关的问题。API的第一个版本，我们试着删除标签，我们试着删除图像，但它有问题。比如我们会删除图像，抱歉，我们会删除标签而图像不会被删除。空间不会被回收，你知道，考虑到我们已经有80tb的空间了，我们实际上遇到了一种情况，我们担心，我们会耗尽文件的空间。

[Viraj]所以我们的解决方案是，我的意思是，这很简单，只是转移到v- 2。但是将1tb的存储库从版本1转换到版本2，迁移本身就需要几个小时。所以，你知道，这些年来我们面临着这样的问题。还有一些具体的问题与Docker本身有关。他们改变了存储配置的机制从Docker cfg到。Docker文件夹中的config。json。大多数用户必须登录Docker并运行他们的命令和类似的东西。

[Viraj]所以有很多相关的培训，你知道，只是为了确保人们明白，存储库的版本刚刚从4.2版本变成了4.7版本。诸如此类。所以我们有一个内部团队，他们坐下来，对最新的测试进行测试。看看它和之前做的有什么不同，然后把它们作为一个指导方针发布。

[Viraj]我只是在想别的事情。是的。我想差不多就是这样了。我的意思是，还有其他更小的事情。

[贾根]所以，所以，是的。对你们来说，这似乎是一段相当长的旅程，在甲骨文和你们在JFrog Artifactory的实现中发生了很多变化。那么你们接下来要关注的是什么呢?

(Viraj)好。这就是我们现在关注的。所以我们的CI/CD管道是，我刚才用橙色点给你们看的那个，我们有很多服务实际上是遵循它的。但我们正专注于让越来越多的团队参与其中。但不仅如此，特别是从Docker的角度来看，你知道，测试件。因此，您编写的所有测试用例都应该在生产环境中运行。应该在任何其他拓扑环境中运行。我们开始把它们捆绑成Docker映像。

[Viraj]所以，你知道，所有与这些测试相关的配置都将通过Docker映像驱动。然后部署者本身，就像，如果你在部署某个东西时需要部署，你必须运行一个工作流。它本身在我们创建的Docker映像中运行。显然这是不标准的。这并不是全面的。我们和很多服务机构合作来做类似的事情。但我们的想法是向前滚动，在来年尝试我们的，你知道的。我认为我们现在最重要的是在生产中使用Bintray……所以无论我们在工件库中拥有什么工件，我们都希望能够以一种更标准的方式将它们推向生产。

[Jagan]所以，我猜今天早些时候发布的关于分发库的公告应该——应该会让这更容易。你能不能-你能不能多谈谈，你知道，用例是什么，生产基础设施有什么不同，以及你今天面临的挑战是什么，你正在尝试解决或在Bintray上寻找解决方案。

[Viraj]。所以，我们内部，你知道，我认为他在最初的谈话中暗示的最大问题是关于防火墙。我认为这是很标准的。每个人都有这样的问题。如何从DMZ中提取数据，或者，当您的客户端在DMZ中，而您想从企业内部网络中提取数据时。这是一件很重要的事。我们有现成的替代解决方案。比如，你可以写一个同步服务器。但是这并没有提供与LDAP的集成。这并不能让你与云中运行的其他服务集成。 And, so the idea is to have Bintray, you know, go there and, like, do pretty much whatever it gives.

(Jagan)好。

[Viraj]授权，认证，授权。这些是基本的东西。但在那里，你知道，因为你不能与其他服务集成，我们只有简单的服务，从点A到点B，而不是整个。

(Jagan)好了。

[Viraj]一系列行动。

[贾根]嗯，看起来真的很棒。我想我们的时间差不多了，如果有问题，我们可以开始提问。