负责任地使用容器

视频记录

嗨,大家好。欢迎参加“负责任地使用容器”网络研讨会。希望你们今天都过得愉快。今天，在这个网络研讨会上，我们将讨论一些关于如何使用容器的问题，一些你可能没有想到的事情，一些细节，一些高层次的信息。但在我们开始之前，让我们先来谈谈一些日常用品。我们总是被问到是否会有这个网络研讨会的录音。是的，会有录音，我们会在网络直播结束后发出去。
此外，你处于静音状态，摄像机也不会出现，所以不要害羞。继续使用你喜欢的平台，随意移动那些窗口。一定要在最后加入我们的问答环节。在本次网络研讨会期间，大家可以随时提问。我们在网上有一些人可以在网络研讨会期间帮助回答这些问题，这样他们就可以在你问他们的情况下得到回答。
好了，介绍一下。我是Melissa McKay。首先，我是一名开发人员。很多很多年了，从刚毕业的实习生到首席工程师。所以我花了很多时间在各种不同的项目上。在我职业生涯的后期，我主要专注于Java服务器端应用程序。还有一些Node，一些Python。近来，我很少遇到不同时从事其他工作的Java开发人员。
我确实成为了一名演讲者。这是我真正感兴趣的事情，成为一名开发者倡导者是有意义的。我现在已经在JFrog担任这个职位有一段时间了。我很享受。即使在流感大流行期间，我也很高兴能够在网上与人们交流。现在我们又开始旅行了，所以这是一个与开发者见面的好机会，能够找到他们所处的位置，能够进行这些对话，特别是在新项目出现的时候，找出他们的困境，希望能够帮助他们，让他们的生活变得更轻松。
我是Java的拥护者和Docker的队长，所以我尽量保持这两种技术的最新和最好的。这张幻灯片上是我的Twitter账号和LinkedIn账号。随时联系我，问问题，诸如此类的。我有空，当然会把我不能回答的问题转达给那些能回答的人。今天，在议程上，我们将讨论容器今天是如何使用的，以及随着时间的推移它是如何变化的。然后我们会讨论如何负责任地建造它们。我不会在这里讨论太多细节，但我会选择我在Docker文件中看到的一些最常见的东西，然后是一些其他建议和在构建自己的容器时要考虑的事情。我们将讨论在我们的软件管道中应该在哪里关注容器，我们应该如何管理它们。我们只会接触到这一点，然后我们会讨论一下保护我们的容器，我们的选择是什么，我们有什么可用的。
所以我记得有一段时间，在生产环境中使用Docker容器被认为是特别危险的，而我在职业生涯的早期并没有这样做。当然，尽管容器的概念已经存在了很长时间，但看着它们在过去十年中得到如此广泛的应用是一种令人难以置信的经历。这个图表实际上来自云原生计算基金会网站上的一个页面。这与容器没有任何特别的关系，但我确实喜欢它如何描述项目的不同阶段以及随着时间的推移采用项目的用户类型。
我认为随着时间的推移，这是一个很好的应用于容器使用甚至Docker使用的方法。就像我说的，容器并不是什么新鲜事物。它们已经存在了很长时间，但是花了一段时间才在生产环境中流行起来。如果你今天问我我们现在在哪里，我会猜我们在这个图表的顶峰附近，也许稍微向右一点，开始看保守的采用者。有人说我们还没到那个地步，但我认为我们已经很接近了。
我们可以指出一些原因，过去发生过的事件，我们看到容器使用爆炸式增长的原因。其中之一是在2013年，当然Docker是开源的。这是一个很大的进步。然而，2015年发生了更多的事情。事实上，在2015年6月22日，开放集装箱倡议宣布成立。这是一个隶属于Linux基金会的组织。它的目标是为容器运行时和映像规范创建开放标准，现在仍然有这个目标。Docker是一个很大的贡献者，他们捐赠了一些实现和规范。但在这个新组织的公告中，据说有20多个组织参与其中。
因此，集装箱化确实已经发展到这种程度，以至于一些组织希望为所有人的利益而努力建立一些共同的基础。OCI成立一个月后，云原生计算基金会(CNCF)也成立了。公告的一部分是Kubernetes 1.0的正式发布，它是由谷歌捐赠给CNCF的。因此，随着容器本身得到更广泛的应用，我们现在在这些容器的编排方面也取得了进步。似乎2018年，也就是那一年左右，可以被视为集装箱进入流行区的一年。
看到容器的广泛使用，以及不同公司开始研究它们在生产环境中的使用，这是非常有趣的。这里有一个例子。这是Sysdig做的报告。这个信息来自那些。Sysdig是一家提供强大监控工具的公司。它是Linux的故障排除工具。如果您经常在生产环境中工作，您可能会意识到这一点。
但有一件事要注意，我回到过去，试图找到最早有意义的报告，在2017年，他们有一份报告，他们分析了45,000个集装箱。这些都是他们可以访问的容器，显然是使用Sysdig的容器。他们没有一个图表或任何东西来列出正在使用的运行时，因为当时99%的运行时都是Docker的，所以把它们分开是没有意义的。在接下来的2018年，他们重复了这个过程，做了相同类型的报告，报告了不同的运行时间，他们观察了9万个容器。在这里，我们开始看到除了Docker之外的其他容器运行时出现。这看起来很有趣。
然而，在2019年，该报告跃升至200万个集装箱。今天，这个数字并不大，但在当时，从9万到200万似乎是一个相当大的飞跃。他们说，它既包括SaaS用户，也包括本地用户。这些报告的链接在幻灯片上。它们绝对值得一看。里面有一些有趣的信息。这个特别的例子显示了containerd的增长，我想指出的是Docker作为一个运行时，尽管现在它越来越少被使用，Docker现在实际上使用containerd作为它的运行时。这就解释了为什么containerd越来越流行，而Docker的运行时使用量却在减少。这并不意味着Docker已经消失或者不那么流行了，只是意味着所涉及的运行时与今天可用的编排更加一致。
另一份Sysdig报告，2020年和2021年，我们仍在寻找200万个集装箱。他们在报告中明确指出，这只是客户容器的一个子集，所以现在有超过200万个。最后一份报告我会展示一个有趣的图表。这是2021年和2022年的300万个集装箱。这里运行时间的划分很有趣。我发现了更多支持2018年转折点的证据，这些证据是由Datadog提供的，这是另一个为应用程序提供监控解决方案的组织。我从2018年发布的一份报告中截取了这张特别的图表。它被称为关于真正的码头工人收养的八个令人惊讶的事实。该图采用了2014年至2018年收集的数据。你可以看到采用的进展，10000家公司中有25%现在采用Docker。 Really interesting. Also in the methodology for this report, they said that data was being taken from 700 million containers. That’s pretty wild. Again, there’s a link there to that report if you’re interested in taking a look at that.
在2018年，Datadog也开始更多地关注编排，并查看和观察运行时的使用情况，就像我之前展示的那些Sysdig图表一样。这句话摘自Datadog的研究报告《容器编排中的八大新兴趋势》。它分别于2018年年底和12月发布。再一次，联系在这里。所以如果你有机会，去看看，因为还有很多其他有趣的观察，在这里和后来的报告中。但我从这篇报告的开头引用的一句话是，容器化现在已经正式成为主流，Datadog的总客户群中有25%采用了Docker和其他容器技术。拥有超过1000台主机的公司中，有一半做得非常好。以前，当我在会议上问听众是否有人在使用容器时，可能会有一些人举手。现在是很多了。任何处理云原生基础设施的人，处理由微服务组成的应用程序的人，现在都非常流行。
现在，仅仅因为某些东西流行并不意味着它是安全的，尤其是在云原生环境中。你不能认为这是理所当然的，你也不能认为表现或效率是理所当然的。如何将应用程序或服务打包到容器中，将在这两个方面产生巨大的差异。所以，不要以为因为今天的技术更先进，你就没有什么事情要做了，而是要利用它们。有一些方法可能会给你自己带来一些问题，并且使用不当。
在我们讨论这个之前，我们会详细讨论一下，让我们先讨论一下在一个典型的软件管道中发生了什么，甚至在我们开始添加容器之前。在我们的开发和交付过程中都涉及到什么?这里显示的是一个典型的管道。它有很多不同的步骤。这是巨大的。它是复杂的。不要指望你能看到这里的所有东西，屏幕上所有的小标志和所有的文字。但要注意的是，从最初的开发到持续集成，再到与构建服务器、构建工具和依赖管理器的集成，再到测试过程，最后部署到生产环境中。现在，在这个特定的图中缺少的是在部署到生产环境之后应该发生的监视和其他操作任务所涉及的步骤。
你通常会在无限软件开发生命周期图中看到这些步骤，这些方面，但是今天我们将重点关注部署之前的步骤。集装箱化。我以前也听过这样的说法，也许这不是开发者或任何接近管道的人所关心的问题。但问题是，至少到目前为止，容器化通常是构建过程的一部分。了解一些东西是如何构建的，然后了解它将如何部署，这显然会影响开发人员做出的决定，在设计阶段就很清楚了。例如，我们已经看到了容器化微服务的出现。所以我们不能，开发者不能就这样放手不管。如果您正在编写打算在云原生基础设施中开发或部署的应用程序，在这样的环境中，您将需要学习如何使用容器。
这是上一张幻灯片中显示的管道的一个更简化的版本。一路走来，从开发开始，到持续集成，经过QA测试，然后可能是发布过程，最终部署。在这个过程中，我们应该关注容器的哪些方面?我们已经通过Node应用程序、Python应用程序和Java应用程序完成了这个过程。我们现在在什么地方需要关注集装箱?这有什么关系呢?
事实证明，就像我说的，容器化是构建和部署的一部分，开发人员需要能够做这些事情。事实上，我们每天在做项目的时候都会重复做这些事情。所以开发者设计，他们编码，他们构建，他们测试，他们排除故障，他们重复所有这些。开发者需要能够重现问题，特别是当他们致力于修复漏洞时。他们需要能够重现可能需要运行特定版本的应用程序才能重现问题的问题。这是在一个容器里。您希望与发现问题的地方保持一致。
能够开发测试或完整测试bug修复或新功能，这可能涉及部署到开发环境。甚至可以在本地开发机器上运行容器。能够以与在生产环境(将在容器中)中部署应用程序或服务几乎相同的方式进行部署是有意义的。因此，开发人员需要了解如何构建和运行容器。
好的，持续集成过程，我通常认为只是构建一般的服务器。在源代码控制中合并更新。这是建造新工件的地方。这就是自动化单元测试发生的地方。构建和测试成功后的工件存储。如果没有通过单元测试，就会发送警报，构建失败，诸如此类。然后这个过程一遍又一遍地重复。这里引用的构件不仅仅是应用程序源代码中使用的库中的库，容器映像本身也包含在此列表中。容器映像被认为是一个工件，因此我们在这里当然也需要关注它。
QA测试也是如此。这个工件和我们应用程序中涉及的所有其他工件，它们都需要被检索。我们需要提供功能验证。您可以在这里运行进一步的集成测试。这可以是手动的，也可以是自动的。这是所有测试通过的地方，这是您对所有这些工件进行一轮提升的地方，这意味着对它们进行分级，让它们为管道中的下一步做好准备。然后再一次，重复。
释放。这可能涉及到另一个工件提升。此时，您可能正在创建发布包。这些工件同样是容器映像以及其他工件。一个发布包可能会包含容器映像。最后是部署。显然，要部署某些东西，您需要部署工件。这就是容器图像。
所以很明显，我们有很多需要关注的地方，但在我看来，我们对容器的大多数安全和效率的关注确实可以在开发管道的开始和持续集成阶段得到解决。这些阶段会产生工件和容器映像，这些工件和容器映像可能会一直移动到生产中。这就是将用于启动我们的生产容器的容器映像生成的地方。所以关注这些领域是有意义的。
有相当多的方法用于构建容器。让我们开始负责任地构建容器映像。这是开发人员要做的主要任务，也是构建服务器要做的。所以花点时间在这部分上是有意义的。如何以及何时构建容器映像将在安全性、效率和性能方面产生重大影响。在how类别下，您可以选择使用或不使用Docker的解决方案。我建议大多数人从Docker Desktop开始，特别是如果您是容器的新手。文档非常出色。他们很好地引导您完成了整个过程，并准确地解释了容器映像意味着什么，运行容器意味着什么，以及在幕后发生的事情。它具有构建、运行、存储容器以及将它们推送到注册表(无论是公共的还是私有的)所需的所有功能，并且还负责缓存机制。 And also launching containers on your local machine. So it’s pretty advantageous.
如果出于某种原因，您不想使用Docker，那么您的另一个选择可能是Buildah。如果您是一个Linux商店，这可能是您已经研究和考虑过的东西。这只是构建图像的另一种选择。另一件要考虑的事情是是否需要编写Docker文件。当我之前谈到容器化的时候，我听说也许不应该由开发人员负责，我听到最多的争论之一是为什么我们需要学习编写另一种东西?现在我们必须学习如何编写Docker文件。有时候，当开发人员被要求学习和做所有这些事情时，它会变得非常压倒性，但我发现编写Docker文件可以让我对如何构建和生成这些映像有更多的控制。所以我个人更喜欢使用Docker文件。我认为这是一种非常标准的方式来传达层是如何构建的以及容器中究竟包含什么。
如果你不喜欢写Docker文件，或者正在寻找摆脱Docker的方法，这里有一些解决方案。有很多选择。Buildpacks就是其中之一。另一个是使用构建插件。因此，如果你已经在使用Maven或Gradle，你可以简单地将其中一个插件添加到你的palm文件或Gradle构建文件中，并能够以这种方式使用它。Jib是另一个选项，也被用作插件。
你什么时候建造这些容器?显然，在积极的开发过程中，开发人员会一直构建这些。一件让我抓狂的事情是，这在我过去一次又一次地发生在我身上，当做出更改并检入内容时，开发人员可能忘记或只是没有尝试在他们的机器上构建和运行容器。因此，也许所有的单元测试都通过了，但是当您尝试启动容器时，可能会出现问题。也许某些配置不太正确，诸如此类，容器无法运行。它立即死亡。
当它被推入源代码控制并且下一个开发人员必须弄清楚所有这些时，这是没有帮助的。所以开发人员需要能够在他们的机器上运行这些工具。此外，正如我们前面所讨论的，出于故障排除的目的，这是另一个原因。
在持续集成期间，很明显构建将一直发生在那里。这是另一个构建容器映像的时候。其他时候，我也看到过构建容器映像。我们一会儿会讨论这个。我不认为这是最好的做法。我会在后面的幻灯片中讲到。
由于使用Docker文件非常常见，我们就从这里开始吧。但首先我想谈谈依赖性。这将是最重要的部分。我知道这是一个被过度使用的冰山图，但软件是由开发人员不一定拥有第一手知识的大量组件组成的概念，不能低估。如今构建的应用程序和服务比以往任何时候都更加复杂。如果没有必要，开发人员通常不希望重新创建轮子。
这意味着你需要引入很多库代码，而这些代码不一定是你自己写的。它们可以是开源组件，也可以是其他内部团队编写的其他库。它甚至不需要是开源的。可能只是另一个团队负责软件的那一部分。所以很明显，我们需要注意每一件即将到来的东西，因为你可能会带来一些容易受到攻击的东西，或者让你容易受到攻击的东西。
让我们来谈谈这些事情。这是一个非常做作的Docker文件。编写本文是为了说明在构建这些容器映像时需要考虑的一些问题。但是不要误解我的意思，如果你想在网上找一些关于如何构建Docker文件的例子，你很可能会发现Docker文件存在我们在这里讨论的一些同样的问题。你在网上找到的这些例子都只是这些例子。简单，简单的演示目的，并不一定具有生产价值。显然，这不仅仅适用于容器映像构建示例。你也可以在网上找到其他代码，你真的需要理解它。花点时间阅读文档。不要只是复制粘贴内容。
我们来看看这个问题，找出其中的问题。我不会把所有东西都挑出来。我将挑选一些明显的，我认为很常见的。第一。这是一个父图像。Docker文件可以以一种有层次结构的方式编写。您可以从基本映像或父映像开始，然后Docker文件的其余部分将添加到该映像中。这就是直线1。我们有不被信任的父母形象。很明显你不会看到这样的问题，但我经常看到。 People will pick a particular base image and just use it because they’ve seen it used elsewhere, without doing the due diligence to figure out if this is an actual image that is safe to use. In fact, let’s take a moment and talk about official base images. Official images. You can find them on Docker hub and I’m just going to show you, let’s just go to Docker Hub and take a look.
让我们搜索一个高山图像，看看高山图像是Docker的官方图像。所以Docker有一个团队致力于跟踪这些图像，确保它们是开放的，其中的内容是明显的，他们正在管理更新并关注新漏洞的新闻，并确保所有内容都是最新的。所以如果你要使用Docker hub，一个公共注册中心的图片，这些图片对任何人都可用，任何人都可以发布，最好使用官方图片，除非你有其他资源告诉你，你选择的图片如果不是官方图片，你需要一些其他的理由来认为它是可信的。2022世界杯阿根廷预选赛赛程
能够信任映像的一种方法是拥有其原始Docker文件、用于构建该映像的原始工件和文件。查看官方图片的一种方法是，打开搜索引擎。如果你只是搜索Docker的官方图片，首先你会得到文档链接，但是向下到第一个链接，那是一个GitHub链接，这就是有趣的地方。这是官方图片所在的GitHub存储库。有一本图书馆目录。在这个库目录中，您将看到所有官方图像。
我们之前在阿尔卑斯山上停过车。如果你往下看，你会看到这里有一条线。所有这些都是这样做的。你会看到一个Git-repo。让我们来看看这个。git存储库。这是管理阿尔卑斯官方形象的地方。在这个repo中，我们应该能够找到原始的Docker文件。现在，其中一些可能有不同版本的分支或不同类型的不同目录。让我们转到最新版本的alpine，现在我们可以看到，我们有代表不同类型的目录，您可以构建。 If we just go into… Let’s go into this top one here, drill down, and we should be able to find a Docker file like this. And here you go. Here is the original Docker file for the alpine image.
现在有一些问题，很明显，你能把它打开看吗?这需要你做更多的工作。注意第一行。上面写着从头开始。对我来说，这告诉我这是一个基本图像，意味着你不能再往回走了。其中一些官方图片将在这里列出另一个父图片。不是scratch，但这将是另一个你需要重复这个过程的官方形象，为了回到你已经达到scratch的点。因此，如果您好奇这些官方映像是如何构建的，那么您可以通过以下方式找到它们的原始Docker文件。
好了，继续。好的，第二行到第四行。这些行的问题是，没有指定版本。在这个例子中，父图像没有所有我们需要的包不管我们要运行的是什么。所以安装了一些软件包。第三行，我们有一些包，没有版本。在第四行，我们有一个易受攻击的旧包。它有一个指定的版本，所以这里有更多的控制。但它很脆弱，没有更新，我们甚至知道它很脆弱。这是非常可耻的。 I see this all the time. It’s easy to forget that OS packages need to be managed the same way as our libraries and our source code, the packages that are built from those.
所以确保你总是指定你的版本。原因是下次需要构建这个，需要构建这个映像时，你不会得到相同的映像。你再也不会得到同样的图像了。您可能会得到一个更新的包，因为您没有指定版本。这可能会给你带来很多麻烦，尤其是在持续集成过程中。这通常是我看到这种情况发生的地方，因为在持续集成中，您喜欢构建一些新鲜的东西，而不涉及旧包和资源的现金。2022世界杯阿根廷预选赛赛程所以这是一个机会，你希望能够在不受那些可能导致事情破裂的移动部件的影响的情况下进行构建，然后需要一段时间才能弄清楚发生了什么。
好，第六行，这个复制语句。这可能是一个效率和性能问题。如果你没有设置一个。Git忽略文件。你可能抄袭了不该抄袭的东西。基本上，这是说复制所有从我的工作目录到图像。您可以复制秘密，可以复制不应该在生产环境中出现的本地配置。您可能正在复制测试文件、工件或日志，而这些确实不应该放在生产映像中。这只会让它变得更大更笨重。
此外，这也会增加构建时间。这样做的原因是，当您进行构建时，需要将所有这些文件发送到Docker守护进程，然后对所有这些文件进行解析。它们都是用来复制的，在这种情况下，我们复制所有的东西然后所有这些都被移动到图像上。移动所有这些文件以便将其用作Docker上下文的过程，会在构建过程中花费很多时间。特别是在持续集成中，您可能会在一天中重复构建。
好了，第七行。我也经常看到这种情况。看到curl语句，还有w-get语句，我真的很烦。对我来说，这些都是你无法控制的外部资源。现在，如果这是从您管理的私有存储库中拉进来的，这是一回事，但我也见过这种情况，这可能是来自另一个组织的安装脚本，可能是用于您的映像中包含的产品或其他东西，您需要使用他们的脚本来安装。
更好的方法是将该脚本置于内部并自己管理它。这样你就不会出现在别人的更新时间轴上，因为这个脚本可以从你的眼皮底下更新出来，它可以从你的眼皮底下移走，它可以被删除，然后突然之间，你所有的东西都失败了。所以尽量避免像第7条这样的句子。还有，第7题需要旋度。所以如果你还没有安装curl，你需要安装它才能运行这行代码。
最后,9。9包括一个入口点。它正在运行一个启动脚本。默认情况下，它实际上是作为一条路由运行的。所以你应该遵守最小特权原则。让该脚本只拥有所需的权限。给它，创建一个组，创建一个用户，并让脚本作为用户和组运行，但作为路由运行它最好有一个很好的理由这样做。这些只是我在Docker文件中经常遇到的几个问题。这肯定不是一个详尽的清单，但它是一个很好的开始。
这是最佳实践。同样，使用可信的或官方的父基映像。不要使用庞大的父图像。利用多级构建。我经常看到Docker文件可能会引入Maven或NPM之类的东西。多阶段构建是在介绍部分构建的一种方法，然后在最后部分只拉入你需要的东西，并保持图像非常小。因此，如果您实际上正在使用Docker文件构建软件，请花一些时间查看多阶段构建的文档。指定所有包的版本，使用。ignore文件，git-ignore文件。抱歉，这不是。git-ignore文件。应该是。Docker ignore file。 It is like a git-ignore file, but it’s not the same thing. All right. And then making your external resources internal and then do not run your processes as route.
好吧，给你选择。如果你想使用Docker文件，你会很满意的。显然，您可以使用Docker Desktop。对于有一定数量的组织来说，它不是免费的，我相信它赚了一定数量的钱，有一定数量的员工，但是当你使用开源工具时，考虑到拥有这种支持的优势，你需要支持它。所以看看这个成本，看看这对你来说是否合理。如果有意义，我会这么做的。它是一致的，很容易在Mac、Linux和Windows上安装。它是一个非常好的开发人员工具。
Buildah也使用Docker文件。我把链接放在这里，如果你想看看Buildah。它是为Linux设计的，所以如果你在Linux商店工作，你可能会更开心。Docker不需要运行Buildah。这就是你的选择。您将需要Podman来启动和管理容器。例如，Buildah不能为您做Docker或Desktop所做的一切，但是与其他工具(如Podman)相结合，您将完成所需的工作。
这里有一些不需要Docker文件的选项，Buildpacks，我会在这里放一个链接。这些都是非常固执己见的构建。它们会检测你正在使用的应用的类型。例如，Python Buildpack可能会查找特定的Python特定文件，如setup.py requirements.text。Node Buildpack可能会查找包锁定JSON文件。然后是该过程的构建阶段，可能运行PIP安装或MPM安装。
所以这是有利的。它们非常简单。这些构建包由属于CNCF一部分的项目维护。Cloud Native Buildpacks项目是CNCF的一部分。为了使用它，您需要安装一个名为Pack CLI的工具，如果您只是在学习，他们有一些很好的教程供您使用。构建插件。我们讨论的另一个选项是Jib。这是你可以添加到Maven或Gradle文件的插件。它在处理Java项目方面做得非常好，它没有使用一个大罐子，而是将其拆分，使图像稍微小一些。添加这个插件很容易。
关于它的一件事是，它构建并推送图像到注册表。对于将图像推送到注册表，我有一种复杂的感觉。似乎开发者并不想这么做。您可能只希望推送到特定于开发的注册中心，诸如此类。例如，它肯定不会是你的持续集成所推动的那个。Spring Boot Docker插件用于Maven和Gradle，这也很简单。你只需要添加，阅读文档，添加插件。它实际上使用Paketo Buildpacks。我一开始并不知道，因为我没有阅读文档。我只是想运行它，看看它是如何工作的。 And I realize that it’s actually pulling these external images, these Buildah images. That’s okay. Just you might want to consider relocating those images to under your control and your management in your private registry, so that you can handle updates appropriately. And you may want to do a custom Buildpack for example.
好了，管理这些容器。我刚刚讲了注册表。每当我们构建容器映像或在部署环境中启动容器时，我们都需要从某处获取这些基本映像或最终生产映像。我们把这些容器存放在哪里?我看到的一些东西被忽略了很多，默认情况下，如果没有指定注册表或图像没有标记注册表，Docker hub将被假定。这是我们之前的Docker文件中的第一行，我们可能想把它改成什么;在那里添加我们的私有注册表，清晰地标记该图像，使其成为可信图像，而不是不可信图像。将它移动到我们的注册表中，然后引用它。
关于管理容器的另一件事是，一旦在持续集成期间构建了映像，就不应该在管道中的任何地方重新构建它。相反，当该版本的容器映像通过了测试和其他验证过程时，应该推广它。这意味着移动或复制到QA、登台，然后最终到生产注册表或存储库。通过这种方式，您可以确信所测试的内容就是将要部署的内容。
最后，让我们谈谈如何保护这些东西。最终，我们希望能够从指定的容器映像启动容器，并有理由相信容器不会立即受到攻击。显然，这里有额外的基础设施和设计问题，但我们可以做的最简单和最好的事情之一是定期扫描容器映像，以查找已知的漏洞和随着时间的推移发现的新漏洞。过去，像这样的安全性是在最后添加的，但现在有很多方法可以在开发过程的早期发现问题。这包括在签入之前扫描、在CI构建之后或在CI构建期间扫描、在测试期间和之后扫描、扫描发布包、定期扫描或按需扫描甚至获取新信息。
有许多不同的方式，你可以利用JFrog x射线。我在这里列出了其中的几个。我们有IDE插件。Github仓库有Frog Bot。JFrog Docker桌面扩展。JFrog CLI也有Xray的API。当然还有JFrog平台。我想给你们看一下，用Jfrog扩展，Docker桌面扫描是什么样子的。这里是分机。您可以通过这个过程添加它。 You can set it up to connect to an existing environment that you have. You can also create, it’ll give you an option to create a new environment if you don’t have one already.
这将访问本地机器上可用的所有内容。我要取其中一张，扫描一下，看看会出现什么。我们得到了一个非常详尽的漏洞列表，我们需要看看。我们可以深入研究每一个，得到它们的总结，更多的信息。我们还可以准确地找出哪个层是相关的，这样我们就确切地知道我们需要更新什么。非常漂亮。
花点时间，看看其他的。我想我还可以再给你们看一个。如果我能记住我的登录信息。我想向您展示它在JFrog平台中的样子。如果你已经有一个可用的SaaS版本，你可以去packages视图，寻找任何你感兴趣的Docker包。我将选择这个并深入研究这个Hello包的这个版本。我这里有一些x射线数据，再一次，它告诉了我更多关于cbe的信息。我可以深入到每一个，找到更多的信息。所以我可以在这里做很多事情。使用JFrog CLI也可以使用其中的许多功能，因此您可以根据管道决定要做什么，而不必使用这样的GUI。
好了，就这样。大家可以提问。看起来有几个人进来了。一个是你们有工作室吗?是的，我们有工作坊。我在这里没有讲很多实现。这更多的是关于让你的大脑工作，确保你在构建管道和构建容器时沿着正确的路线和正确的事情思考。如果您要b谷歌JFrog即将到来的研讨会，您将进入一个包含即将到来的研讨会列表的页面。它们非常频繁，而且在不同的时区，所以要充分利用它们。
让我们来看看。这里还有一个。哦，使用JFrog容器注册表是免费的吗?我可以试试吗?你绝对可以。我给你们展示一下，这里有一个免费实例。这是我注册的免费套餐。如果你去jfrog。com，有一个按钮，上面写着免费试用或免费开始。点击它，你就可以注册一个帐户，你就可以使用JFrog容器注册表了。
设置好环境后，登录，这里有一个快速设置部分。如果愿意，您可以在这里设置Docker存储库。但我想指出的是这个学习中心。这里有一个视频是关于如何用Docker做这个的。所以我会从这里开始，看看你能走多远，然后参考文档。
好吧。接下来，我在哪里可以了解更多关于JFrog x射线的信息?我在哪里可以试吃?相同的地方。你也可以在那里玩JFrog Xray。你可以学习如何设置手表和政策，诸如此类的东西。如果你去jfrog。com并导航到资源部分，那里有很多关于Xray的信息。2022世界杯阿根廷预选赛赛程这是你的另一个选择。好的，JFrog IDE插件支持哪些IDE ?这是一个非常好的问题。 And I’m sorry I keep jumping back and forth to a browser, but I just want to bring up this link here.
这是我们的IDE集成文档，它提供了我们目前支持的所有IDE。当然，我最喜欢的是IntelliJ。我一直用那个，我也用这个插件。非常好。我可以对我的掌上文件进行更改，并且我可以立即判断，甚至不需要签入我的代码，我添加的包是否有问题。太酷了。
我也会推荐Frogbot。如果您正在使用GitHub存储库，那么这将是一个很好的集成到您的源代码控制中。这里是链接。如果你有机会，去看看那个。这很酷。
好了，我想就这样了。这就是我们今天的全部内容。就像我说的，这个网络研讨会的录音将被发送给那些今天无法现场直播的人。对于其他人，感谢你们的到来。如果您还有任何问题，我们将尽力收集并回复您。你可能还会得到一些后续信息。
再次感谢大家的到来祝你们在管道中使用容器工作顺利。