负责任地使用容器

视频记录

嗨,大家好。欢迎参加本次网络研讨会，负责任地使用容器。我希望你们今天都过得愉快。今天，在这个网络研讨会上，我们将讨论一下如何使用容器，一些你可能没有想到的事情，一些细节，一些高层次的信息。但在我们开始之前，让我们先谈谈一些日常事务。我们总是被问到这次网络研讨会是否会有录音。是的，会有一段录音，我们会在网络直播结束后发出。
此外，你是静音的，摄像头也没有显示，所以不要害羞。继续使用你想要的平台，随意移动那些窗口。请务必在最后加入我们的问答环节。在这次网络研讨会上，大家可以随时提问。我们有在线的人可以在网络研讨会期间帮助回答这些问题，这样他们就可以在你问他们的情况下得到回答。
好了，自我介绍。我是梅丽莎·麦凯。首先，我是一名开发人员。已经做了很多很多年了，从一个实习生，刚毕业就成为了总工程师。我花了很多时间在各种不同的项目上。在我职业生涯的后期，我主要专注于Java服务器端应用程序。还有一些Node，一些Python。现在我很少遇到一个Java开发人员不做其他事情。
我确实成为了一名演讲者。这是我真正感兴趣的事情，成为一名开发人员的倡导者是有意义的。我现在已经在JFrog这个职位上工作了一段时间。我很享受。即使在疫情期间，我也很高兴能够在网上与人们互动。现在我们又开始旅行了，所以这是一个很好的机会来认识开发人员，找到他们在哪里，能够进行这些对话，特别是对于新项目和即将推出的所有东西，了解他们的问题是什么，希望能够帮助他们，让生活更轻松。
我是一个Java冠军和Docker船长，所以我尽量保持在这两种技术的最新和最好的顶端。这张幻灯片上是我的推特和领英。随时可以联系我，问问题，什么都可以。我随时都有时间，当然我会把我不能回答的问题交给那些可以回答的人。今天，在议程上，我们将讨论容器在今天是如何使用的，以及随着时间的推移它是如何变化的。然后我们将讨论负责任地建造它们。在这里我不会讲得太详细，但我会选择一些我在Docker文件中看到的最常见的东西，然后是其他一些建议和当你构建自己的容器时要考虑的事情。我们将讨论我们应该在软件管道中的哪些地方关注容器，以及我们应该如何管理它们。我们只会涉及到这一点，然后我们会讨论一下保护我们的容器，我们有什么选择，我们有什么可用的。
所以我记得有一段时间，在生产中使用Docker容器被认为是特别危险的，而不是我在职业生涯早期所做的事情。当然，尽管容器的概念已经存在了很长一段时间，但看着它们在过去十年中被如此广泛地使用，是一种令人难以置信的体验。这张图实际上来自云原生计算基金会网站上的一个页面。这与容器没有任何特别的关系，但我喜欢它描述项目的不同阶段以及随着时间的推移采用项目的用户类型。
我认为它适用于容器的使用，甚至随着时间的推移适用于Docker的使用。就像我说的，容器并不是什么新鲜事。它们已经存在了很长一段时间，但是在生产环境中使用它们需要一段时间。如果你今天问我我们现在在哪里，我会猜我们在这个图表的顶峰附近，也许稍微向右一点，开始关注保守的采用者。有一种观点认为我们还没有达到那个目标，但我认为我们已经很接近了。
我们可以指出一些原因，过去发生的事件，为什么我们看到容器使用的爆炸式增长。其中一个是在2013年，当然Docker变成了开源。这是一个相当大的发展。然而，2015年发生了更多的事情。事实上，在2015年6月22日，开放集装箱倡议的成立被宣布。这是Linux基金会下的一个组织。它的目标是为容器运行时和映像规范创建开放标准，现在仍然是这样。Docker是一个重量级贡献者，他们捐赠了一些他们的实现，一些规范。但在这个新组织的公告中，据说有超过20个组织参与其中。
因此，集装箱化确实已经发展到这一点，以至于许多组织都希望为所有人的利益而努力寻找一些共同点。在OCI成立一个月后，云原生计算基金会(CNCF)也成立了。公告的一部分是Kubernetes 1.0的正式发布，由谷歌捐赠给CNCF。因此，随着容器本身的使用越来越广泛，我们现在在这些容器的编排方面也有了进步。似乎2018年，也就是大约那一年，可以被视为集装箱进入流行区的一年。
非常有趣的是，容器的广泛使用出现了爆炸式增长，不同的公司也开始研究它们在生产环境中的使用。这里有一个例子。这是由Sysdig做的报告。这个信息来自于那些人。Sysdig是一家提供强大监控工具的公司。它是Linux的故障排除工具。如果您经常在生产环境中工作，您可能会意识到这一点。
但有一点需要注意的是，我回到过去，试图找到最早有意义的报告，在2017年，他们有一份报告，分析了45000个集装箱。这些都是他们可以访问的容器，显然这些容器使用了Sysdig。他们没有一个图表或任何东西来列出正在使用的运行时间，因为当时99%的运行时间都是Docker，所以把它们分开是没有意义的。第二年的2018年，他们重复了这个过程，做了同样类型的报告，报告了正在使用的不同运行时间，他们观察到了9万个容器。在这里，我们开始看到除了Docker之外的其他容器运行时。这看起来很有趣。
但在2019年，该报告跃升至200万个集装箱。今天，这不是一个大数字，但在当时，从9万到200万似乎是一个相当大的跳跃。他们表示，这包括SaaS用户和on-prem用户。这些报告的链接在幻灯片上。它们绝对值得一看。这里有一些有趣的信息。这个特别的显示了containd的增长，我想指出的是Docker作为运行时，尽管现在越来越少使用它，Docker实际上使用containd作为运行时。这就解释了为什么containd变得越来越流行，而Docker的运行时使用率却在下降。这并不意味着Docker已经消失或不那么受欢迎，只是意味着所涉及的运行时与当今可用的编排更加一致。
另一份Sysdig报告，2020年和21年，我们仍然认为有200万个集装箱。他们在这份报告中明确指出，这只是客户容器的一个子集，所以现在有超过200万。最后一个报告我将展示一个有趣的图表。这是2021年和22年的300万个集装箱。这里运行时间的划分非常有趣。我发现了更多的证据来支持2018年的转折点，这些证据是由Datadog提供的，这是另一个为应用程序提供监控解决方案的组织。我从2018年发布的一份报告中截取了这张图表。这篇文章叫做《关于Docker应用的八个惊人事实》。该图采用了2014年至2018年收集的数据。你可以看到采用Docker的进度在增加，10,000家公司中有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的方法，这里有一些解决方案。还有其他选择。构建包就是其中之一。另一个是使用构建插件。因此，如果你已经在使用Maven或Gradle，你可以简单地将这些插件中的一个添加到你的palm文件或Gradle构建文件中，并能够以这种方式使用它。Jib是另一个也被用作插件的选项。
你什么时候建造这些容器?显然，在积极的开发过程中，开发人员将一直构建这些。让我抓狂的一件事是，当做了一个更改并签入了一些东西，但可能开发人员忘记了，或者只是没有尝试在他们的机器上构建和运行容器，这在过去已经发生了一次又一次。因此，也许所有的单元测试都通过了，但当您尝试启动容器时，可能会出现错误。也许某些配置不太正确，诸如此类，容器无法运行。它会立即死亡。
当它被推到源代码控制中，而下一个开发人员必须弄清楚所有这些时，这是没有帮助的。所以开发人员需要能够在他们的机器上运行这些程序。此外，正如我们前面所讨论的，出于故障排除的目的，这是另一个原因。
在持续集成期间，显然构建将一直在那里进行。这是另一个构建容器图像的时候。在其他时候，我还见过构建容器映像。我们待会再讨论。我不认为这是最佳做法。我会在后面的幻灯片中讲到。
由于使用Docker文件是非常常见的，让我们从这里开始。但首先我想谈谈依赖关系。这将是最重要的部分。我知道这是一个被过度使用的冰山图形，但软件可能由大量组件组成的概念，开发人员不一定有第一手的知识，这是不可低估的。今天构建的应用程序和服务比以往任何时候都更加复杂。如果没有必要，开发人员通常不希望重新创建轮子。
这就意味着需要引入大量的库代码，而这些代码不一定是您自己编写的。它们可以是开源组件，也可以是其他团队内部编写的其他库。它甚至不需要是开源的。它可能只是另一个团队负责软件的那一部分。所以很明显，我们需要注意所有进入构建的东西，因为你可能会带来一些脆弱的东西，或者让你容易受到攻击的东西。
让我们来谈谈这些事情。这是一个非常做作的Docker文件。本文是为了说明在构建这些容器映像时需要考虑的一些问题。但不要误解我的意思，如果你打算在网上寻找关于如何构建Docker文件的例子，你很可能会发现Docker文件遭受了我们在这里将要讨论的一些相同的问题。你在网上找到的这些例子就是那些例子。简单，简单是为了演示目的，不一定值得生产。显然，这不仅仅适用于容器映像构建示例。你也可以在网上找到其他代码，你真的需要理解它。花点时间阅读文档。不要只是复制粘贴。
让我们仔细看一下，找出问题所在。我不会把所有东西都挑出来。我会挑出一些显而易见的，我认为很常见的。第一。从这一行，这是一个父图像。Docker文件可以以一种有层次结构的方式编写。您可以从基本映像或父映像开始，然后Docker文件的其余部分将添加到其中。这就是我们在第一行得到的。我们从不信任父母的形象。显然你不会看到什么，很明显问题是这样的，但我经常看到这种情况。 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.
让我们搜索一张alpine图片，看看这个alpine图片是Docker的官方图片。所以Docker有一个团队专门负责跟踪这些图像，确保它们是开放的，其中的内容显而易见，他们管理更新，关注新漏洞的新闻，并确保所有内容都是最新的。因此，如果你要使用Docker中心的一个图像，一个公共注册中心，这些图像对任何人都可用，任何人都可以发布，最好使用官方图像，除非你有其他资源告诉你你所选择的图像是如果它不是官方图像，你需要一些其他理由来认为它是可信的。2022世界杯阿根廷预选赛赛程
能够信任一个映像的一种方法是拥有它的原始Docker文件、最初用于构建该映像的原始工件和文件。看官方图片的一种方法是，打开搜索引擎。如果你只是搜索Docker官方图片，首先你会得到文档链接，但下到第一个链接，那是一个GitHub链接，这就是有趣的地方。这就是官方图片所在的GitHub仓库。有一个图书馆目录。在这个库目录中，您将看到所有的正式图像。
我们之前在阿尔卑斯山停过。如果你往下看，你会看到这里有一条线。所有这些都是这样做的。你会看到一个Git-repo。让我们来看看这个。git存储库。这里是阿尔卑斯官方形象的管理场所。在这个回购中，我们应该能够找到原始的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.
现在有一个问题，很明显，你能打开这个看吗?这就需要你多花点功夫了。但是请注意第一行。它说从零开始。对我来说，这告诉我这是一个基本图像，意味着你不能再往前走了。其中一些官方图像将有另一个父图像列在这里。不是刮，但它将是另一个你需要重复这个过程的官方图像，为了回到你到达刮的地方。所以如果你好奇这些官方图像是如何构建的，这是你可以找到这些原始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世界杯阿根廷预选赛赛程所以这是一个机会，你希望能够在不受那些移动部件影响的情况下建造，这些部件可能会导致东西破裂，然后需要一段时间才能弄清楚发生了什么。
好的，第六行，这个copy语句。这可能是一个效率和性能问题。如果你还没有设置一个dot Git忽略文件。你可能抄袭了不该抄袭的东西。基本上，这是说将我的工作目录中的所有内容复制到映像中。您可能复制了秘密，也可能复制了不应该出现在生产环境中的本地配置。您可能正在复制测试文件、工件或日志，这些都不应该放在生产映像中。它只会让它变得更大更笨重。
此外，这也会增加构建时间。这样做的原因是，当你进行构建时，所有这些文件都需要被发送到Docker Daemon，然后所有这些文件都被解析。它们都可以用于复制，在这里，我们复制了所有东西然后所有这些都被移动到图像上。因此，移动所有这些文件以将其用作Docker上下文的过程，会在构建过程中花费大量时间。特别是在持续集成中，您可能会在一天中重复地进行构建。
好的，第七行。我也经常看到这种情况。看到curl语句，另一个w-get语句，这些真的让我很困扰。对我来说，这些意味着你不一定能控制的外部资源。现在，如果这是从您管理的私有存储库中提取出来的，这是一回事，但我也见过这样的情况，这可能是来自另一个组织的安装脚本，可能是您在映像中包含的产品或其他东西，您需要使用他们的脚本来安装。
更好的方法是将脚本放在内部，自己管理它。这样你就不在别人的更新时间轴上了，因为脚本可能会在你眼皮底下被更新，可能会被移动，可能会被删除，然后突然之间，你的所有东西都失败了。所以尽量避免像7号这样的行。还有，第7个需要旋度。如果你还没有安装curl，你必须安装它才能运行这一行。
最后,9。9包括一个入口。它正在运行一个开始脚本。默认情况下，它实际上是作为路由运行的。所以你真的应该遵守最小特权原则。让脚本只拥有它所需要的权限。给它，创建一个组，创建一个用户，让脚本以该用户和组的身份运行，但作为路由运行它最好有一个很好的理由这样做。这些只是我在Docker文件中经常遇到的几个问题。这绝对不是一个详尽的清单，但它是一个很好的开始。
这就是最佳实践。同样，使用可信的或官方的父基映像。不要使用笨重的父映像。利用多阶段构建。我经常看到Docker文件可能会引入Maven或NPM之类的东西。多阶段构建是一种在介绍部分实际进行构建的方法，然后只在最后部分引入您需要的内容，并保持图像非常小。因此，如果您实际使用Docker文件构建软件，请花些时间查看多阶段构建的文档。指定所有包的版本，使用dot ignore文件，git-ignore文件。抱歉，这不是。git-ignore文件。那应该是。Docker忽略文件。 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的一部分项目维护。云原生构建包项目是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回购。JFrog Docker桌面扩展。JFrog CLI也有一个用于x射线的API。当然还有JFrog平台。我想向你们展示，展示Docker桌面扫描用Jfrog扩展的样子。这是扩展。您可以通过这个过程添加它。 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版本，你可以到包视图，寻找任何你感兴趣的Docker包。我将选择这个，并向下钻取这个Hello包的这个版本。我这里有一些x射线数据，同样，它告诉了我更多关于cbe的信息。我可以深入其中的每一个并找到更多信息。我可以做很多事情。你也可以使用JFrog CLI来实现这些功能，这样你就可以在你的管道中做出决定，而不必使用像这样的GUI。
好了，就这样吧。我现在欢迎大家提问。看起来我们有几个人进来了。一个是你们有讲习班吗?是的，我们有研讨会。在这里，我没有太多的实现。这更多的是让你的大脑工作，确保你在构建管道和容器时沿着正确的路线和正确的事情思考。如果你要谷歌JFrog即将到来的研讨会，你会得到一个页面，其中包括即将到来的研讨会列表。它们非常频繁，而且在不同的时区，所以要好好利用它们。
让我们来看看。这里还有一个。哦，使用JFrog容器注册表是免费的吗?我可以试试吗?你绝对可以。我给你们看一下，这里有一个免费的例子。这是我报名的免费层。如果你去jfrog。com，有一个按钮说免费尝试或免费开始。继续，点击它，你可以注册一个帐户，你可以玩JFrog容器注册。
设置好环境后，登录，这里有一个快速设置部分。如果您愿意，可以在这里设置Docker存储库。但我想在这里指出的是这个学习中心。实际上，这里有一个视频是关于如何用Docker做到这一点的。所以我会从这里开始，看看你已经了解了多少，然后再参考文档。
好吧。接下来，我可以在哪里了解更多关于JFrog x射线的信息?我在哪里可以试试?相同的地方。你也可以在那里玩JFrog x射线。你可以学习如何设置监视和策略之类的东西。如果你访问jfrog。com，并导航到资源部分，那里有很多关于x射线的信息。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。我一直在用那个，我也用这个插件。非常好。我可以对我的palm文件进行更改，甚至不需要检入我的代码，我就可以立即知道我添加的包是否有问题。非常酷。
我也推荐Frogbot。如果你正在使用GitHub存储库，这将是一个很好的集成到你的源代码控制。这是链接。如果你有机会看看这个。这很酷。
好了，我想就这样吧。这就是我们今天的全部内容。就像我说的，这个网络研讨会的录音将发送给那些今天不能来现场的人。至于其他人，谢谢你们的到来。如果你还有其他问题，我们会尽量收集并回复你。你可能也会得到一些后续信息。
所以，再次感谢大家的到来，祝你们在处理管道中的容器时好运。