[字幕已自动生成。] 感谢大家加入本NetApp。 这是用于开发运营自动化的优素福Trident。 今天、我们有David Fox、他是NetApp 平台工程团队的主管。 Dave是 NetApp的平台工程团队主管、 专门负责 在KubeNet上设计和部署服务。 他的职责包括领导一支充满活力的团队实施 创新解决方案、以增强 公司内的容器化和自动化。 所以不用 再多说，大卫，把它带走。 Chris、您好、再次感谢您的介绍。 我是 NetApp IP平台工程团队主管David Fox。 今天、我们将讨论 Trident的开发运营自动化。 因此、在议程上、我们首先要讨论 云之旅的内容。 我们在这段旅程中已经走过了很长一段时间。 嗯、我们将稍微谈谈 这段旅程的样子。 其次、我们将讨论Kubbernetes、并 稍微谈谈它如何适应这一过程。 此外、您知道、我们将 从 应用程序开发人员的角度讨论Kubelnetes如何真正帮助我们。 最后、我们将讨论 Trident如何真正融入其中、 以及它如何真正促进应用程序 交付流程。 下面简要介绍一下我们的发展历程。 嗯、我是2014年开始在NetApp工作的。 当我开始工作时， 我们提供应用程序的方式是， 如果您已经在 这个行业工作了足够长的时间，您会记住这一点，您知道， 有点像手动部署。 您像域架构师一样与 存储工程人员一起聚集在一起。 计算机工程。 网络工程。 你会有一个 会议或一组会议， 大家会写下他们的任务 ，然后用他们的方式去做，对。 您知道、计算可能需要三 天时间才能恢复计算。 网络耗时一周、存储 耗时一两天。 对。 然后，我们，你知道，回来，然后，你知道， 有点像手工组合在一起，你知道， 交叉的手指。 希望一切都能正常运行。 这就是我们交付应用程序的方式。 结果是、 交付相对简单的应用程序需要数周甚至数月的时间 、因为我们必须手动与所有 这些团队建立联系。 因此、必须手动正确地完成工作。 很明显、那里还有改进的空间。 所以我们从那时开始做的就是 我所说的自动化和孤岛。 因此、存储团队可以 使用WFA来自动执行存储、然后网络团队和计算团队可以使用 HPO或AnsStorage来自动执行计算机网络。 对。 然后、存储可能会使用脚本来 自动构建存储。 对。 但我们仍处于几乎手动的模式中、对吧？ 大家走到一起，我们都坐 下来，讨论我们需要什么。 但是、我们实现了一些自动化和孤岛、最终 帮助我们更快地交付数据。 嗯、但是 交付 完整产品还需要几天或几周的时间、因为我们 当时没有以一种连贯的方式来解决这个问题。 我们注意到、许多应用程序 团队都要迁移到公共云、对吧？ 他们这样做的原因有几个，对 吗？ 一是容易，二是比较便宜。 对。 您知道、他们不必 为了计算、 网络和存储而将房间里的每个人都聚集在一起。 嗯、他们只需 刷信用卡、 亚马逊就能满足他们的需求。 但 从商业角度来看、这是正确的。 因为现在我们有了所谓的影子IT。 有些人可能是操作应用程序的， 你知道， 没有监管，没有设置安全指南边界， 你知道，这种事情。 对。 所以、您知道、我们注意到、人们想要 一种更简单的方式来交付应用程序、 但同时也注意到、企业需要 围绕该流程提供某种防护和监管。 我们从NetApp和云开始。 这是一种以IaaS为重点的方式。 再次强调、如果您想到亚马逊、 您会获得您的信息板、 您可以像部署EC2实例那样非常 简单、然后设置负载平衡器、非常简单、所有这些都可以。 所以、我们仍然希望 将重点放在IaaS上、对吧？ 但是、 我们已经在孤岛中实现了一些自动化。 对。 并使其更具凝聚力。 这仍然是非常有重点的、对吧？ 这就像，你知道，这是你的计算机， 这是你的网络。 您知道、部署该应用程序是您的决定。 对吗？ 因此、这仍然需要大量的手动操作。 嗯、但至少我们能够 更快地交付IaaS。 对。 但您知道、很明显、您知道、基础架构 不仅仅是为了基础架构、对吗？ 我们希望在此基础上部署应用程序。 因此、随着这一认识的实现、我们开始 将更多的情况整合在一起。 这导致了我们称之为NDQ的结果。 对。 而这更多的是一种综合性的 整体方法、 不仅是基础架构交付、还包括 整体应用程序交付。 然后、这种情况转变为我们现在拥有的 NetApp混合云。 对吗？ 所以，你再次知道，一切都是自助服务。 我们 一如既往地提供基础架构即服务。 但现在、我们更加关注 开发运营即服务。 对吗？ 但是、我们的目标是将 基础架构、应用程序、安全性真正整合在一起、 集成到一个自助服务门户中、使应用程序 开发人员能够快速准确地获得所需的内容。 对。 所以、您知道、我们为什么要这样做？ 对。 你知道， 这是一个十年的旅程，对吗？ 答案其实很简单，对吧？ 应用程序开发人员的期望 随着时间的推移发生了变化、对吧？ 您知道、早已过去、就像 2014年我所说的那样、 我们都在一个房间里讨论、每个人都 各自走自己的方式、然后返回各自的 部分、您知道、您知道、 最终您将获得应用程序环境。 你知道，现在事情需要更紧密的团结。 他们需要自助服务。 嗯、您知道、但同时、您知道、它 需要不仅仅是基础架构、对吗？ 我们意识到、基础架构 只是战斗的一半、对吧？ 我们需要 实现应用程序自动化、 自动化应用程序部署以及 基础架构部署。 对。 我们需要给人们简单的选择、对。 所以、我们有一个服务目录、 请选择X作为您的应用程序堆栈。 对。 您的应用程序堆栈大小不一。 是大型 应用程序。 它是一个小型应用程序。 您知道、简化这些选择、然后 准备好使用与之相配的样本。 对。 所以，你知道，呃，确保人们 不仅拥有，你知道，所有的， 所有的基础设施和他们需要的东西，而且 他们有一些简单的，比如，你好，世界代码，对吗？ 无论我们的应用 程序产品组合中有什么应用程序、他们都可以从我们的自助 服务门户中选择。 嗯、我们 还希望简化开发人员体验、让 他们摆脱基础架构的管理。 这样、他们就 不必担心IT会为他们实现自动化。 这样、他们就可以专注于应用程序。 最终形成的是一个 范式、应用程序开发人员可以通过这种范式提高 速度并最终提高可靠性 、因为他们不必担心将所有 组件整合在一起。 我们正在为他们做这项工作。 我们正在以自动化方式实现这一目标。 对。 所有 这些都是通过服务门户实现的自助服务。 所以你知道这个门户是什么样子的， 它 真正带来了什么，嗯，真的是一个一站式商店，对吗？ 应用程序开发人员可以从何处访问自助服务门户？ 如果他们希望、或者如果他们 拥有自己的容器、而他们只是想部署 一些容器、他们在 侧面构建了一些容器、但仍然利用我们的CD流程、他们可以订购IaaS、对吗？ 容器即服务。 但是、如果您希望 今天我们将讨论这个问题。 对。 此外、我们还支持应用程序开发人员 根据需要随时随地订购这些资源、对吗？ 您知道、它可能是、您知道、云提供商。 它可能位于本系统中。 这真的无关紧要。 您知道、所有这些都是作为 一个选项和自助服务门户呈现给他们的。 而且、我们已经从 监管角度制定了所有的防护措施、以确保 在他们快速完成任务的同时、我们仍然满足 合规性和监管规范要求。 今天、我们将再次讨论DevOps。 开发运营是一项正确的服务。 所以我们来谈谈这意味着什么 ，因为我已经提到过一次。 开发运营即服务是一种端到端产品 、我们不仅提供了一个 可以托管应用程序开发人员代码的平台、而且还为他们提供 了一种不受云限制的方式 、可以通过CI和CD管道来部署应用程序。 因此、我们为他们创建了管道。 我们 为他们的Docker映像创建了所有的工厂存储库。 对。 嗯、我们给他们一个git repo、嗯、 我们给他们一个安全工具、 所有的日志记录和指标。 所以、我们已经 为他们捆绑了所有这些内容、所以、就好像 他们真的不需要考虑这一点一样、对。 所以、如果您考虑一下IaaS、 您只需获得一个 计算资源、然后您就可以 自己计算出所有其他资源。 我们希望让开发人员不必 担心这一点。 他们可以专注于代码、最终交付 能够 更快地为业务和客户带来价值的应用程序。 因此 、我们的自助服务门户是ServiceNOW。 在ServiceNow中、如果您选择开发运营、 您会得到一个类似于服务目录的服务 、您可以 在其中选择不同的部分、部件、我们精心策划的应用程序堆栈、我们有一个 称为Boilerplates的应用程序、您可以从中进行选择。 例如、如果您有一个应用程序、 您知道、 Spring Boot和MongoDB或Nginx和MariaDB、或者、 您知道、无论这种组合是什么、对吗？ 您知道、我们 在自助服务门户中为您提供了这种选择。 此外，我们还将其与 基础架构和项目基本功能相结合，例如， 自动构建Docker映像、 自动创建Helm图表、以及 自动部署到Kubbernetes、 甚至一天都可以自动启动。 对。 您知道、设置、您的、您的、您的、您的、您的、 以及您最终要部署到的目标。 然后、我们还会为您提供选择。 您是希望部署到私有云还是希望 部署到公共云？ 对。 这就是自助服务。 开发人员可以自由选择。 最终结果是、 他们在30分钟或更短时间内即可准备好代码。 这就像一个自动化的入职流程。 我们再次从ServiceNow门户开始。 借助自助服务目录、您可以 从该目录中选择想要的内容。 正如我刚才提到的、选择应用程序 组件大小您的项目就是这样、您知道、 大型项目是一个小项目。 无论情况如何、您都知道。 完成这些步骤并 从服务目录中选择所需内容后、这就是我想要的应用程序。 这是我希望它位于的云中。 发生的事情很少。 首先、我们更新了CMDB、 这是一种记录、嘿、我们有这个应用程序、这是一个入职。 下面是 该应用程序的一些属性， 如它是什么层。 等等 等等。 同时、我们还 在Red Hat Automation Ans得 自动化平台上启动了Day One自动化。 在这方面、我们 将推出可正确完成多项任务的Ansight操作手册。 首先、您知道、它为应用程序 所有者提供了一个Docker注册表。 嗯、它通过 一个我们称为NEAT的工具来设置LDAP组。 然后、我们将使用这些LDAP组 在Kubbernetes环境中设置基于角色的访问控制。 然后、Day One自动化还会设置防护栏 。 因此、我们设置了一个配额限制范围。 当然，我刚才谈到的RBAC ，以及所有这些。 最后、这个Day One自动化可以 在Azure DevOps中提供他们真正需要的一切 。 Hello world代码。 嗯，你知道，非常快，嗯 ，所以这包括一个git repo和hello world代码。 RBAC可以说、 谁可以访问 代码、在哪个级别、谁可以提交、谁是只读的。 等等我们设置了CI CD管道、其中 包括所有安全扫描和其他内容。 对。 因此、我们为他们提供了这种端到端体验、 最终形成了我们所称的DevOps工作空间。 对吗？ 因此、一旦您将所有的本初项都放在中间位置、 您就可以将其部署到工作空间中。 从本质上说、工作空间是 一个开发空间、对。 现在您已经获得了Hello world代码、 您可以开始使用了。 您可以 对Hello world代码和进行任何更改、 并将更改交付到您的工作空间、然后 立即查看结果。 对。 第一天自动化的整个过程 需要20到30分钟。 这比我们 在2014年看到的要好得多。 我们讨论的是几天、几周、 甚至几个月、 对。 这在 帮助应用程序开发人员快速为 业务和最终为客户提供价值方面有着明显的优势。 当您对开发 领域的代码感到满意后，您可以将其部署到主机空间， 您可以在主机空间中暂存主机空间 或生产主机空间。 对。 所有这些都在CDC管道中逐步完成， 我们稍后会看到。 但这有点让人质疑 Trident是从哪里来的？ 对。 您知道、Trident有什么作用？ 如果您考虑一下Kubbernetes的功能、对吧、 Kubbernetes是定义您的应用程序 外观的一种方式、不仅 是因为、我的应用程序就是这个 存储库中的Docker映像、是的 、我们通过Day One自动化为他们设置的。 对。 嗯、它也包含 我所需要的计算资源。 所以我需要，呃，我需要四个CPU和八 GB RAM或者任何可能的。 对。 所以、您从应用程序的 角度、从网络等方面来说明您的需求。 我想通过 主机名、API、我的company.com来公开我的API。对。 那么、您要声明自己的网络需求、您要声明自己的计算 需求、对吗？ 但是、您的应用程序也需要存储。 Trident所做的就是、它允许人们 在Kubnetes中声明他们的存储要求、 然后Trident出来并满足这些要求。 对。 所有这些都是自动发生的。 无需手动干预。 应用程序开发人员只需 在Kubelnetes清单中声明所需内容、 然后Kubelnetes和Trident便 可自动完成此操作。 无需手动干预。 我们来谈谈第二天。 我们已经讨论了 第一天应用程序的部署。 他们有自己的Hello World代码。 他们拥有 Docker存储库、 您知道、有些 图表可以用来说明所有计算 、网络和存储需求。 对。 所以他们从Hello world代码开始， 他们说，嘿，我想做一个改变。 我想让它成为一个真正的API、对吧？ 所以他们对他们的git repo进行了更改，然后 他们把这种更改推送到git repo。 这将启动CI CD流程。 第一站是构建映像。 现在、您已将代码签入Azure DevOps Git repo、映像构建便开始了。 映像构建完成后、该映像会被推 送到 此时、我们会进行多次安全扫描、 不仅在管道中、而且还会 持续进行安全扫描、 使用各种工具 确保没有未完成的CVS或、您知道。 等等。 安全扫描完成并通过后、 我们会将图像与这些Kubbernetes清单相结合 、这些清单定义了我们的网络需求、 计算需求以及存储需求。 然后、合适的Kubnetes和Trident可以 在开发工作空间中满足这些需求。 因此、您可以获得存储、计算和 网络。 所有这些都符合开发人员的规范。 因此、一旦他们对事物和发展感到满意、 这看起来很好。 让我们来宣传一下。 让我们进入暂存环境。 这是暂存主机库。 同样、我们还会将Docker映像与我们的 Kubbernetes清单相结合、以定义我们的计算、 存储和网络需求。 然后、 QA团队或 准备在暂存中检查最终输出的人员。 最终他们会说，嘿，这看起来不错。 对。 这就像质量检查一样。 对吗？ 所以、如果您有像QA团队 这样需要像 应用程序性能基准一样运行的LMP团队、那么他们 在这一步就能做到这一点、对吗？ 看看暂存主机群。 一旦他们满意、您就会再次认识到、 将Docker repo中的所有项目与Kubarnetes 清单相结合、定义了存储、 计算、 网络需求也是如此。 然后、我们部署了产品。 如果返回幻灯片、您知道、如果您 只是、您知道、您只需检查一下、 检查。 从开发到生产的整个过程 只需20分钟。 所以，与过去的大改变， 你知道，它需要几天、几周或几个月。 对。 因此、 从应用程序角度来看、我们已将这一数据缩减到几分钟。 您知道、 尤其是当他们请求存储时。 对。 我们已从这些存储后端中抽象出来。 同样、在Kubnetes中、您可以定义自己的需求。 在这种情况下、Trident可以满足这些需求。 对。 因此、如果您需要一个只读写一次的50大容量卷、其中 只有一个POD可以与该卷进行通信。 试用。 它将进行配置。 如果是在内部部署、 我们会在全闪存FAS上配置它。 对。 嗯、如果同一个请求得到满足、而且它是 在云中、那么它来自FSx、对吧？ 应用程序开发人员不知道 它的来源、也不关心它。 嗯、他们知道的是、他们有一定的需求。 他们已经量化了在 清单中找到该需求的需求、并将其应用于Kubnetes。 在Kubnetes和Trident之间、这一需求会 自动满足。 无需手动干预。 所以， 我们做了很多工作。 这就像 从我们所处的位置到我们所处的位置长达十年的路程。 这里的实际投资回报是多少？ 嗯、 看看我们当前的生产环境、对吧。 您知道、截至我汇总这张幻灯片时、我们 总共提供了532个卷和98 TB容量。 对吗？ 如果我们仅计算存储管理员的平均时间、如果他们专门负责此任务。 对。 因此、无需对印版执行其他操作。 无论什么。 对。 嗯、 他们必须手动执行此操作。 嗯、如果我们假定需要15分钟来创建卷、请 设置导出策略。 我们节省了五天半的时间。 假设 他们没有做任何错误的事情、对吧？ 因为，你知道，人类会犯错误。 这就是我们实现自动化的原因。 嗯，但是，我们已经节省了五天半的 时间， 对于这么长的旅程来说，这似乎不是一个可怕的时间。 但我们要实事求是。 这 不是应用程序开发人员的观点、对吧？ 您知道、通常在 旧的做事方式中、 您会通过任何 服务单系统、BMC补救措施或ServiceNOW或 你知道，无论你使用什么。 对。 存储 工程师将收到请求。 也许他们的盘子上还有其他东西。 他们在做数据保护工作，或者 审计工作或处理他人的请求。 所以现实地说，这是基于过去几次的 经历，你知道，你在说， 大约一天来得到你所要求的，对吗？ 有些 组织更好，有些组织更差。 但是，你知道，我只是 根据我的个人经验计算了一天的时间。 因此、从开发人员的角度来看、 节省的时间实际上为532天。 如果我们假设在 您提出要求和获得所需之间的周转时间就像一天、 对吗？ 这是一笔巨大的节省、对吧？ 这就像一年半。 所以，嗯，你知道，这是一个巨大的投资回报。 嗯、如果我们把所有这些都拿过来、你知道、我们 在这里谈到的是关键要点、对吧？ 首先、您必须实现自动化、并 实现自助服务。 您知道、将 一个域架构师和一个庞大团队整合在一起的日子早已过去。 大家都是手工完成的， 几周或几个月后，大家都在一起，希望一切都能正常运行。 对。 应用程序开发人员现在需要一些东西。 对。 因此、自动化和自助服务是 实现这一目标的关键、这样他们就可以为 业务、最终快速为客户创造价值。 对。 第二个要点：尝试让我们 在Kubbernetes环境中自行配置存储。 您也知道、 我们希望让 最终用户真正轻松地配置存储。 第三个问题是、当 我们将 Trident与Kubbernetes结合使用时、 最终用户可以通过 这样可以提高开发人员的整体速度 并最终提高可靠性 、因为现在您可以快速交付代码和更新、从而 可以 在更短的时间内提高应用程序的可靠性。 这是我的演示文稿、介绍了我们如何 将Kubbernetes和Trident结合使用。 所以如果有人有任何疑问， 你可以自由地问。 大卫、我、是的、 这里有几个问题。 首先，我想说 的是，在调查中有三个简短的问题，我们希望得到您的反馈。 嗯、就问题而言、 第一个问题、也就是Trident之前的问题、 您如何为容器化工作负载提供存储？ 是的、这是 Kubbernetes之前一个非常有趣的时刻。 嗯、一个四个。 因此、 在 Trident这样的动态卷配置程序概念问世之前、我们一直在生产环境中使用Kubnetes。 我们要做的是、在 集群之前、我们会配置各种类型的存储。 对。 我们会有10个千兆位卷、 100千兆位卷、 1 TB卷。 对吗？ 然后， 希望 人们使用它的方式与我们 打算使用它的方式相同。 对。 嗯、 这种方法有一些问题。 嗯、一个。 嗯、您已经过度配置了存储、对吧？ 嗯、 希望大家能使用它。 嗯、如果有人 提出了一个50 GB的卷请求、而您只拥有10 GB、100 GB和1 TB的卷、 他们 将获得100 GB的卷、对吧？ 因此、他们已经获得了比他们所需要的更多的东西。 因此、您实际上在两个方面过度配置。 第二个问题是、您似乎总是会 先用尽某种类型的存储、然后再用尽其他存储。 现在、他们有了一个永久性卷声明 、它不受限制、因为 他们找不到任何内容。 你知道、 这是合适的。 对。 因此我们必须不断检查， 确保我们之前有 所以，恩，你知道，它比我们 正在做的事情要好，但仍然不理想，因为 人们不一定能 准确地得到他们所需要的，而且在他们要求的时间内。 好的。 那么第二个问题是， 您 在生产环境中运行的应用程序大约有多少？ 现在、我们在 六个不同的应用程序上运行大约60个应用程序、 Kubnetes环境。 当然、我们也有 开发Kubennetes环境。 回到我之前谈到的工作空间。 总共有七个集群、对吧？ 嗯、这是我们的案例 中的一个组合、 因此、他们可以选择在何处运行或执行任何操作。 但是，呃，你知道，到 我上次看的时候，总共大约有60个。 这些应用程序包括大型应用程序、例如 我们的小型应用程序支持站点、 例如我们的员工、例如员工查找目录、对吗？ 这就像一堆东西的大骗局。 嗯，还有一个问题，嗯， 您使用哪些存储协议向Kubnetes提供存储？ 好的。 是的。 今天是一个很好的问题。 我们 严格使用NFS。 对。 但是、Trident并不限制您仅使用NFS。 如果您 希望使用块存储、Trident将提供iSCSI。 嗯、但不要引用我的话。 自从 我查看该文档以来、已经有很长时间了、但在我们的用例中、 我们发现NFS确实是一 种首选协议。 这也是我们 在公有云和内部环境中使用的位置。 嗯，我们 在聊天中有一个问题。 嗯、Trident是开放源代码吗？ 嗯、。 是的、有一个适用于Trident的GitHub repo。 所以我认为它是开源的。 嗯、对于不同的人来说、开放源代码意味着不同的东西。 我不知道许可证是什么、所以我很 确定它不像Agplv3、但是、您知道、 GitHub上提供了代码。 我看的最后一个。 NetApp Trident根据Apache许可证2.0获得许可。 好的、很棒。 很棒。 是的。 这就 像一个开放源代码许可证。 嗯、好的。 嗯，这就是我们所有的问题。 嗯、 感谢大家的加入。 再次强调，如果你能抽出时间来回答这 三个投票问题，那会非常有帮助 。 并确保这些网络研讨会有益。 David，非常感谢您抽出宝贵的时间，谢谢您的专业知识。 感谢大家的参与。