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之前需要完成的应用程序更改。好的，让我们从应用程序安全性开始。转到有状态应用程序与无状态应用程序的状态。我们也有优雅的关机。并以代码的形式覆盖基础设施。
好的,很酷。我们开始吧。是的。第一个项目是应用程序安全性。Kubernetes集群充当一个主动包装器，将应用程序与自动容器和操作系统计算机系统隔离开来。
它以专用用户的身份运行应用程序，我们将路由特权权限，扫描容器中的漏洞，保护与系统互连的API，如网络应用程序和设备。它还将敏感信息存储在秘密中，提供敏感的环境变量，从秘密和更多。
我们要讲的第二点是有状态应用和无状态应用。在真正开始运行应用程序生产Kubernetes集群之前，了解应用程序架构非常重要。因此，让我们讨论一下无状态应用程序的最佳实践。因此，有状态应用程序的最佳实践是不依赖本地存储。
存储在不同的环境中会发生变化，在不同的应用程序中也会有不同的表现。因此，不要依赖于本地存储，也不要存储状态信息，以防应用程序随时消失，或者只是重新启动。我们希望避免使用特定的服务器信息。
Docker也是非常轻量级的，所以它会使用环境变量或系统属性来确保应用程序总是可以恢复，以确保我们可以很容易地恢复它，再次更改它，并再次运行它。副本，当多个副本正在运行时，应用程序需要恢复并查看所有副本之间的每个副本，因为我们希望非常容易地增长，并确保我们以不同的方式拥有相同的副本。所以我们可以在Kubernetes集群的背景下总结一下，我们可以讨论一些capterium CAP的反转，比如一致性，可用性和分区容忍度。
这是什么意思?一致性意味着每次读取都得到最近的写入，这意味着如果写请求是在pod A上完成的，那么pod B必须显示最新的数据或给你一个错误消息。应用程序上下文中的可用性，它必须尽可能地接近完美，当我们谈论分区容忍时，它指的是在应用程序无法运行的情况下存活的能力。第三个项目是优雅关机，当我们开始观察应用中断的信号，比如终止信号，键盘中断等等。我们希望确保一旦我们重新部署、重新启动或崩溃的应用程序，您的运行和进程将优雅地关闭，信息不会丢失，我们希望确保一切都是安全的，没有任何东西会在某一天崩溃或消失。
我们需要为要完成的任务设定一个时间。跟踪它很重要，我们可以说运行服务器需要40秒，这很乐观假设运行服务器需要40秒，确保我们有应用程序。此外，我们希望为应用程序状态添加更多输出，以便在需要时能够调试它。因此，如果我知道运行我的应用程序需要30秒，但我需要一个日志来显示它实际上正在运行，服务器已经启动，我想添加越来越多的错误或调试代码，以确保我能尽快找到这个解决方案。能看到实际发生了什么。完全正确。最后但并非最不重要的，是作为代码的基础设施项目。
事实上，作为代码的基础设施是DevOps实践(如版本控制、代码审查、持续集成、持续部署)的关键和基础。新基础设施的配置可能需要很长时间。例如，网络布局、服务器、数据库、安全规则，这些都是仔细完成的，但错误会发生。配置漂移偶尔会发生。
此外，区域和云提供商之间可能存在一致性。例如，新区域的供应时间可以从3周的手动任务减少到30分钟的自动化供应，甚至更多。所以只要我们说到三周，你知道，就像你告诉我的，节点和配置，服务器，数据库，安全规则，我们需要手动做的所有事情都可以很容易地自动化，这将大大减少时间。因此，在准备扩展时，它必须与统一的配置管理结合在一起，以充当真相的来源。这意味着不能手动更改，只能从配置管理工具进行更改。任何更改都必须被记录或允许，我们希望确保团队意识到这些过程，记录它对于将来更好地理解、纠正更改并获得每个更改的完整详细信息非常重要。因此，这允许我们安全有效地更改和版本化基础设施。当代码到达主版本时，就意味着它可以投入生产了。
从主版发布的版本应该进行测试，并推广到生产版。不可变的基础结构避免了配置漂移，代码与环境的当前状态进行比较。当应用计划时，将添加或删除资源。2022世界杯阿根廷预选赛赛程因此，我们倾向于认为微服务的旅程通常伴随着容器化，但这些路径不一定相互绑定。是的，我同意。他们想从Docker工具集中获益，但这就是为什么Docker会告诉你微服务的使用情况。
一些组织为你的文件Docker实现微服务，或者Xamarin的整体应用程序文件Docker。每个组织都是不同的。所以没有人可以告诉你你做的是对还是错，只是根据你组织的需要去做。这总是取决于您的组织的需要。完全正确。所以应用技能越大，需要的系统管理和控制就越多。
即使我们开始使用管理集群，我们仍然需要改变并采用集群来适应我们的组织策略和需求。我们这里有一些例子来与你们分享我们在旅程中的经历。是的。让我们从NGINX Ingress控制器的第一个项目开始，以及我们为什么推荐它。实际上，这很简单，我们建议应用表示层和多层架构来分离公共端点和应用程序。
这是什么意思?这意味着应用程序将运行在web服务器或负载均衡器之后，这些服务器或负载均衡器可以作为攻击的第一道防线，并保护、防止和卸载应用程序的投票。对应用程序的访问将采用TLS配置。此外，不建议使用像纯文本通信这样的不加密通信。是的，当然。我们要尽量保证安全。我们还可以谈谈DNS服务器，默认情况下，集群已经部署了立方体DNS，你可能想要转向手风琴，我有几个喜欢手风琴的原因。accordionist是多线程的，它是用go写的，而不是运行在cube DNS上的单线程，它是用C写的，CPU和内存消耗是服务和端点的数量，所以每个DNS端口的内存需求在默认设置下，我的accordionist应该比cube 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集群版本，以获得新的特性支持以及安全漏洞的改进。此外，一旦你在专用的节点池上运行不同的服务，以保护与我们的微服务共享容器。例如，我们将在不同的节点池中运行一个前端服务应用程序，以隔离可能在其他节点上运行的恶意应用程序，就像，你知道，数据库等等，这将保护我们的核心服务不受破坏，我们想要隔离不同的节点，尽量保持简单，尽量隔离它们。听起来不错。
现在，当我们的集群准备就绪时，我们就可以开始应用程序部署了。所以无论何时相信密码，我们都可以说铁密码，或者希伯来语的巴采尔密码。为此，我们必须有一些业务部署服务，我们可以称其为self service，它运行安装或升级部署的业务逻辑。这意味着应用程序服务或Helm版本运行在哪种状态并不重要，重新部署操作将从应用程序版本、Helm图表版本、环境配置设置的角度将应用程序或服务带到所需的状态，它可以是每个开发或登台或生产版本。
该代码提供了业务逻辑支持，并能够根据需要启用或禁用特性标志，等等。好的，我们将在下一张幻灯片中讨论特性标志。现在，让我们谈谈如何加快这个过程，你知道，我们当撤销发布或将任何新版本加载到生产时，如果我们需要重新部署一些服务器应用程序(使用或不使用默认配置)，该怎么办?或者我们如何确保构型没有被删除，或者被覆盖，或者其他错误发生的事情?
因为我们说过，人都会犯错。由于通常部署需要在登台环境中进行测试周期，这通常是一个痛苦和耗时的过程，而且部署过程可以依赖于外部配置。因此，最好依赖于频繁变化的外部配置。因此，这个配置可以被加载，比如检出它，并用作运行时部署过程的一部分。因此，它确实缩短了处理时间，并在使用不同的配置管理已经测试过的情况下交付代码。
好酷。我们来看一些例子。因此，无论何时我们使用配置作为代码，我们都将部署过程作为铁代码，因此我们可以使用从外部源加载的新配置重新部署应用程序，同时也可以不更改自动化代码。因此，从上面的示例中，您可以看到Helm值YAML内部的应用程序资源初始化，但它没有改变。2022世界杯阿根廷预选赛赛程这个参数包含在部署中，这是静态初始化。因此，由于它从外部单元格获得所有实际资源，在Git和2022世界杯阿根廷预选赛赛程这样就可以频繁地进行更改，如下面的示例所示。这是另一个例子，你可以看到Java选项配置，它可以根据应用程序的需要而改变。因此，对于每个Java选项，使用Helmvalues, YAML可以保持持久。
它给了我们灵活性，液体过程自动化和交付，它给了我们持续更新，不会因为配置变化而发布新版本，实际上，它给了我们对过程的信心。是的，我们可以改变这个特定的配置确保一切都能像以前一样运行，它让我们能够信任我们的代码，信任我们的产品。
因为实际上改变的是配置而不是产品部署的业务层。是的,没错。我们只是改变了Java选项，我们没有改变应用程序的任何东西。正确的。
我们还希望能够启用特定的功能，对吗?如前所述，我们想为特定区域添加特定功能，或为特定客户更改默认值，或只是允许每个人都使用新功能，对吗?但是一旦你创建了一个特定的新功能，我不知道什么时候会被允许。因此，为了自动启用它，我们将需要添加一些代码更改，这些更改将静默运行，直到该特性被启用，它将需要重新部署，我们将提供barzel代码的初始启动。因此，在所有情况下，重新部署将始终是真相的来源，例如配置损坏、对象丢失、应用程序服务之间的其他通信错误或连接可能被破坏、应用程序版本更新或部署变更交付、甚至某些客户正在运行的应用程序重新启动等等。所以我们想要确保我们的代码是可靠的，我们可以信任它，我们可以重新部署，就像你说的，请随意问任何问题。我们希望你喜欢这节课。是的。谢谢大家的聆听。
非常感谢你们今天来到这里，很高兴见到你们大家。祝你有愉快的一天。
再见。-再见，伙计们。
祝你有愉快的一天，再见。
