DevOps是关于流程、工具和人员的。好了，我们来谈谈流程、工具和人员。当我们谈论更快地交付产品的过程时，我们希望使用自动化来帮助我们减少手工任务和过程。因此，从开发到发布的每一步都应该尽可能地自动化，当开玩笑说像CI\CD工具、云提供商工具、分发、安装或只是监控我们的部署时。当然，像你这样的人提到。
实施DevOps正在改变组织中所有人的思维方式。因此，我们都同意，人员、流程和技术的结合能够为您、您的用户和客户持续交付价值。我们想带你走过我们在JFrog的DevOps之旅，将Kubernetes编排扩展并提高我们的生产力。所以就像在其他组织一样，在JFrog，我们需要……释放…-快。按比例…-快。保持…-快。支持客户需求和业务…当然要快，我爱我们的顾客。有一个快速的…自助服务和集成的JFrog应用程序…快。
当然在彼此之间，我们有一个巨大的平台。所以我们要确保所有东西都能非常非常快地交流。换句话说，我们想要快速发布。不可能。好吧，让我们从一个小测验开始。
你喜欢Kubernetes吗?让我们在聊天中看看你的答案。让我们等一会儿。你可以回答如果你使用Kubernetes，如果你喜欢Kubernetes，你对Kubernetes的感觉如何……你认为你知道如何使用Kubernetes吗?我认为我们很好。我们可以开始了。确定。我们先来谈谈我们自己，然后再回到答案上来。我叫巴特尔·佐哈尔。我是JFrog开发者倡导团队的一员。
在那之前，我已经在JFrog工作了四年，所以在那之前，我是JFrog的支持团队和解决方案的一员。在那之前我是一名嵌入式工程师。我有一只很棒的狗狗，你可以在图片中看到，它的名字叫班卓琴。治疗结束后可以随时联系我。我总是很乐意帮忙。所以请不要犹豫，给我发邮件或推特或任何你想要的。今天我有一个很棒的搭档，安娜斯塔西娅，非常感谢你的加入。
谢谢你，巴特尔，谢谢。
我的名字是Anastasia，过去五年我一直在JFrog担任DevOps工程师，我每天都在挑战自己，通过自动化和基础设施的采用使我们的生活更轻松。如果有任何问题，请随时联系我。与快乐。非常感谢。因此，让我们从头开始部署JFrog应用程序。
是的，JFrog应用程序准备以各种部署包类型分发，就像您在图片中看到的那样，包括helm、rpm、Debbie和document等等。这些应用程序的每个版本都需要构建和测试，并包含所有的发行包依赖项。
今天，我们有9个不同的发行版，未来还会有更多。我们知道发布周期将更具挑战性。采用更主动的方法来交付和验证可信代码，并通过添加更多功能来增强流程。我们都明白，我们必须尽可能多地使用自动化。也许这是显而易见的，我们都知道这一点，但重要的是要提到人类会犯错误。
当然，我们都会犯错误，这完全没有关系。与其花10分钟手动触发一些半自动化的测试来得到我们真正需要的东西，不如把重点放在增强应用程序保护层上，采用不同的资源，比如每个应用程序或分布类型的CPU和内存。2022世界杯阿根廷预选赛赛程
我们正在改进我们的安全程序根据我们的组织需要，配置该服务满足了客户的需求，我们希望简化对添加新应用程序和服务的支持。正确的。那么为什么是Kubernetes呢?使用自动化，我们增加了部署准备的规模和有效性。现在我们进入微服务。——没错。
它使我们能够更多地关注代码的细节，而不是代码本身代码运行的基础设施。Kubernetes已经有7年的历史了，它已经成为最受欢迎的平台之一，也是编排容器工作负载的事实上的标准。为了迁移正在运行的微服务和用户Kubernetes集群，我们必须准备一些基础设施的更改，并确保我们知道我们将要进入什么。
让我们观察一下在迁移到Kubernetes之前需要完成的应用程序更改的简要高级4级操作。好，让我们从应用程序安全性开始。转到有状态与无状态应用程序的状态。我们也有优雅的关闭。并将基础设施作为代码覆盖。
好的,很酷。我们开始吧。是的。正如我提到的，第一项是应用程序安全性。Kubernetes集群充当主动包装器，将应用程序与自动容器和操作系统计算机系统隔离开来。
它作为专用用户运行应用程序，我们将路由特权权限，扫描容器的漏洞，保护与系统互连的API，如网络应用程序和设备。它还将敏感信息存储在秘密中，从而提供敏感的环境变量，从秘密和更多。
是的，我们要讨论的第二项是有状态与无状态的应用程序。在实际开始运行应用程序生产Kubernetes集群之前，了解应用程序体系结构非常重要。因此，让我们讨论一下无状态应用程序的最佳实践。因此，有状态应用程序的最佳实践是不依赖于本地存储。
存储在不同的环境中可能会发生变化，并且在不同的应用程序中可能会有不同的行为。因此，不要依赖本地存储或不要存储状态信息，以防您的应用程序随时消失，或者只是可以重新启动。我们希望避免特定的服务器信息。
Docker也是非常轻量级的，所以它喜欢使用环境变量或系统属性来确保应用程序总是可以恢复，以确保我们可以很容易地你知道，恢复它，再次更改它，然后再次运行它。副本，当多个副本同时运行时，应用程序需要恢复并查看所有副本之间的每个副本，因为我们想要非常容易地增长，并确保我们以不同的方式拥有相同的副本。所以我们可以在Kubernetes集群的背景下总结一下，我们可以谈论一些逆转的capeterium CAP，比如一致性，可用性和分区容忍度。
这是什么意思?一致性是指每次读都会得到最近的写，它的意思是如果写请求是在pod A上完成的，那么pod B必须显示最新的数据或给您一个错误消息。应用程序上下文中的可用性，即它必须尽可能接近完美的功能，当我们谈论分区容错性时，它指的是在应用程序不运行的故障中存活下来的能力。第三个项目是优雅关机，当我们开始观察应用程序中断的信号，比如kill信号，键盘中断和更多。我们要确保一旦我们重新部署的应用程序，重新启动或只是崩溃，你的运行和进程将优雅地关闭，信息不会丢失，我们要确保一切都是安全的，没有什么会崩溃，有一天消失。
我们需要为要完成的任务设定一个时间。跟踪它是很重要的，我们可以说运行服务器需要40秒，这是很乐观的假设运行服务器需要40秒确保我们有应用程序。此外，我们希望为应用程序状态添加更多的输出，以便能够在需要时调试它。再一次，如果我知道运行应用程序需要30秒，但我需要一个日志来显示它实际上已经运行并且服务器已经启动，我想添加越来越多的错误或调试代码来确保我能尽快找到这个解决方案。这样才能知道到底发生了什么。完全正确。最后但并非最不重要的是，作为代码的基础设施项目。
事实上，基础设施即代码是DevOps实践(如版本控制、代码审查、持续集成、持续部署)的关键和基础。提供新的基础设施可能需要很长时间。例如，网络布局、服务器、数据库、安全规则，这些都做得很仔细，但还是会出错。构型漂移偶尔会发生。
此外，区域和云提供商之间可能存在一致性。例如，新区域的配置时间可以从手动任务的三周减少到自动配置的30分钟，甚至更多。是啊，所以每次我们说到三周，你知道，就像你告诉我的，节点和配置，服务器，数据库，安全规则，我们手动需要做的一切都可以很容易地自动化，这将大大减少时间。因此，在准备扩展时，它必须与统一的配置管理结合在一起，以充当事实的来源。这意味着不能进行手动更改，只能通过配置管理工具进行更改。任何更改都必须记录或允许，我们希望确保团队了解这些过程，记录这些过程对于将来更好地理解，纠正更改并获得每个更改的完整详细信息非常重要。因此，这使我们能够安全有效地更改和控制基础设施的版本。当代码到达主服务器时，就意味着它可以用于生产了。
从主版本发布的版本应该进行测试，并为生产部署进行推广。不可变的基础结构避免了配置漂移，将代码与环境的当前状态进行比较。当应用计划时，可以添加或删除资源。2022世界杯阿根廷预选赛赛程因此，我们倾向于认为微服务之旅通常伴随着容器化，但这些路径并不一定相互绑定。是的，我同意。他们想从Docker工具集中获益，但这就是Docker告诉你微服务用法的原因。
一些组织为你的Docker文件实现微服务，或者Xamarin单块应用文件Docker。每个组织都是不同的。所以没有人能告诉你做的是对还是错，只要根据你的组织的需要去做就行了。这总是取决于您的组织的需求。完全正确。因此，应用程序的规模越大，需要的系统管理和控制就越多。
即使我们开始使用管理集群，我们仍然需要改变和采用我们的组织策略和需要的集群。我们在这里有一些例子与你分享我们在这段旅程中的经历。是的。所以让我们从NGINX入口控制器的第一项开始，以及我们为什么推荐它。实际上，这很简单，我们建议应用表示层和多层体系结构来分离公共端点和应用程序。
这是什么意思?这意味着应用程序将运行在web服务器或负载均衡器之后，这些服务器或负载均衡器可以作为攻击的第一道防线，保护、防止和卸载应用程序的投票。对应用程序的访问将配置为TLS。此外，不建议使用未加密的纯文本通信。是的，当然。我们要尽量保证安全。因此，我们还可以讨论一下DNS服务器，默认情况下，集群自带已经部署的多维数据集DNS，您可能需要把它迁移到手风琴，我有几个原因为什么我更喜欢手风琴。accordialist是多线程的，它是go语言编写的，而不是运行在立方DNS上的单线程，它是用C语言编写的，CPU和内存消耗是服务和端点的数量，所以每个DNS端口的内存需求在默认设置下，我的accordialist应该比立方DNS使用更少的内存。
这是由于多维数据集DNS经常使用的硬件开销所致是的，下一个项目是插件，Kubernetes集群中有很多插件我们可以开始使用和推荐设置。让我们来看看Calico这样的插件。它在Azure上默认启用。这是一个网络策略插件。
我们推荐使用Calico的主要动机是保护和隔离运行在同一集群中的应用程序与其他服务和第三方。此外，还可以在名称空间内使用它来控制和隔离特定的pod或服务。当然可以。所以我们也有记录和监控，我们可以决定是否要自己管理库存，比如安装DRK或Meteos，或者我们可以使用弹性加载服务，并将端口的STD发送到系统进行进一步分析和监控。
这里我们谈到NFS提供程序。,为什么?有时，您可能希望将其用于存储，用于某些应用程序，用于共享公共数据或在重新启动或部署pod之后保留信息。每个云提供商都提供NFS提供程序(如AWS)或NFS客户端提供程序(如GCP)。我们可以自由地拒绝为Kubernetes提供服务。在Azure上，这一层是不必要的，因为您可以使用存储类直接连接到Azure文件。
是的，但是，你总是可以添加更多的服务来部署在你的集群上，每个组织都使用自己的工具，而且有很多开源工具和插件可供你使用，所以你可以根据自己的需要随意编辑。是的。此外，他们还开始在Kubernetes集群上进行安全增强。作为旅程的一部分，我们可以推荐以下内容。
首先，我们总是建议使用TLS包含到数据库的连接。此外，我们总是使用私有网络来运行Kubernetes集群节点，以更好地保护集群。任何外部访问都可以完成，我们已经设法不在需要的地方进行端口转发。但还是那句话，尽量保持简单、安全、私密。
我们不能交谈关于没有加密的安全，对吧?在使用特定的云提供商时，您可以使用KMS等云提供商服务来加密敏感数据。此外，我们使用私有的Docker注册表，它是Kubernetes集群中部署的Docker镜像的可信源。此外，事实上，我们必须保持Kubernetes集群版本的更新，以获得新特性的支持以及安全漏洞的改进。此外，一旦你在专用的节点池上运行不同的服务，以保护与我们的微服务共享容器。例如，我们将在不同的节点池中运行前端服务应用程序，以隔离可能在其他节点上运行的恶意应用程序，就像数据库等一样，这将保护我们的核心服务不受破坏，我们想要对不同的节点进行隔离，尽量保持简单，尽量隔离它们。听起来不错。
现在，当我们的集群准备好后，我们就可以开始应用程序部署了。所以无论什么时候，只要相信密码，我们就可以说铁密码，或者希伯来语中的巴泽尔密码。为此我们必须有一些业务部署服务，我们可以称其为自助服务，它运行业务逻辑的部署安装或升级。这意味着应用程序服务或Helm版本在哪个状态下运行并不重要，从应用程序版本、Helm图表版本、环境配置设置的角度来看，重新部署操作将使应用程序或服务达到所需的状态，它可以是每个开发、阶段或生产版本。
该代码附带了业务逻辑支持，以及根据需要启用或禁用特性标志的能力，等等。好了，我们将在接下来的幻灯片中讨论特征标志。现在，让我们谈谈如何让这个过程更快，你知道，我们当撤销发布或将任何新版本加载到生产环境时，如果我们需要重新部署一些服务器应用程序(带或不带默认配置)，该怎么办?或者我们如何确保构型没有被删除，或者被覆盖，或者其他错误发生的事情?
因为正如我们所说，人都会犯错。由于部署通常需要在登台环境中进行一个测试周期，这通常是一个痛苦和耗时的过程，并且部署过程可能依赖于外部配置。因此，最好依赖于经常变化的外部配置。因此，可以加载此配置，比如签出它，并将其用作运行时部署过程的一部分。因此，它确实缩短了处理时间，并在已经通过使用不同的配置管理进行测试的情况下交付代码。
好酷。我们来看一些例子。因此，无论何时我们使用配置作为代码，我们都将部署过程作为铁代码，因此我们可以使用从外部源加载的新配置来重新部署应用程序，无论是否更改自动化代码。因此，从上面的例子中，您可以在Helm值YAML中看到应用程序资源的初始化，但它没有改变。2022世界杯阿根廷预选赛赛程这个参数包含在部署中，这是静态初始化。因此，由于它从外部单元获得所有实际资源，在Git和2022世界杯阿根廷预选赛赛程这样可以频繁地进行更改，就像您在下面的示例中看到的那样。这里是另一个例子，您可以看到Java选项配置，它可以根据应用程序的需要进行更改。因此，Helmvalues、YAML可以对每个Java选项使用一个低函数来保持持久化。
它给了我们灵活性，液体过程自动化和交付，它给了我们持续的更新，而不是因为配置变化而发布新版本，实际上，它给了我们对过程的信心。是的，我们可以改变这个特定的配置确保一切都能像以前一样运行，它让我们能够信任我们的代码，信任我们的产品。
因为实际上改变的是配置而不是产品部署的业务层。是的,没错。我们只是改变了Java选项，我们的应用程序没有改变任何东西。正确的。
我们也希望有能力启用一个特定的功能，对吧?就像我们之前说的，我们想要为一个特定的地区添加一个特定的功能，或者为一个特定的客户改变默认值，或者只是允许每个人都有一个新功能，对吧?但一旦你创造了一个特定的新功能，我不知道什么时候会允许。因此，为了自动启用它，我们将需要添加一些代码更改，这些更改将静默运行，直到启用该特性，它将需要重新部署，我们将提供我们的barzel代码的初始启动。因此，在配置损坏、对象丢失、其他通信错误或应用程序服务之间的连接可能中断、应用程序版本更新或部署更改交付、甚至是在某些客户上运行的应用程序重新启动等所有情况下，重新部署将始终是事实的来源。所以我们想确保我们的代码是可靠的，我们可以信任它，我们可以重新部署，就像你说的，随时问任何问题。我们希望你喜欢这次会议。是的。谢谢大家收听我们的节目。
非常感谢大家今天来到这里，很高兴见到大家。祝你今天愉快。
再见。-再见，伙计们。
祝你今天愉快，再见。
