DevOps教程

现代应用程序通常由大量微服务组成，这些微服务在本地和云中分布的容器中运行。在这种情况下，服务网格是解决这些分布式微服务的安全性、连接性和可观察性挑战的基础设施层。但是，额外的组件层（来自 Mesh 基础设施）拦截所有流量对延迟的影响又如何呢？ 在本

弹性有点像安全性：它有助于在某些事情没有按预期进行时不至于损失钱财。它也有一个概率成分：因为意外事件和失败只发生在一定的概率下。它也有一个间接的组成部分：如果你的IT系统过于频繁地出现故障，将会导致次要的影响，如失去恼人的客户。这意味着，你的损失不仅是故障的直接影响，

SignNoz是一个开源应用性能监控（APM）和可观测性工具，它帮助开发人员监控他们的应用程序和解决问题，是DataDog、NewRelic等的开源替代品。监视你的应用，并可排查已部署应用中的问题，这是一个开源的可替代DataDog、NewRelic的方案SigNoz帮助开发

Apache Airflow 给我留下了深刻的印象。引擎快如闪电，编写管道真的很容易。另一个很棒的功能是它与源代码控制同步。这样，我就知道在环境中执行了哪些内容。一个好的提示：拥有从主分支读取的暂存环境和从发布分支读取的生产环境很有用。

微服务架构更难维护、更难部署、更难监控、更难调试，也更难测试? 1、当您没有团队结构来支持它时，当您缺少管理它的关键系统时，微服务比单体服务带来更多的复杂性。 你是否能够为快速构建测试和发布CI-CD而自动对它们进行单独测试？

Sarah莎拉于 2021 年初离开英国《金融时报》，现在写一本关于微服务的书，以传授她在微服务方面的经验和专业知识。具体来说，关于如何成功实施微服务及其组织文化、构建和运营方面。 持续交付：微服务好于单体

微服务通常使用发送或回复心跳/健康检查的模型作为向报告、调度或编排服务提供状态信息的一种方式。这些不仅在应用程序的正常生命周期中很重要，而且在新版本推出期间也很重要。我们将看看如何使用不同的库和抽象来实现健康检查，但首先，让我们就在检查应用程序的健康时要考虑的内容达成一致。

此存储库包含一个完全可部署的环境，用于使用 Apache Airflow、MLFlow 和 KServe 执行 MLOps。 我们假设您具有以下条件： 访问具有至少 4 个 CPU 内核和 20Gb 的 Kubernetes 1.2

请注意，这些不是准确的数字。它们基于一些在线基准（Jeff Dean 的延迟数字 + 一些其他来源）。 L1 和 L2 高速缓存：1 ns、10 ns例如：它们通常内置在微处理器芯片上。除非您直接使用硬件，否则您可能不需要担心它们。 RAM 访问：100 ns例如：从内存中读

在运行或多或少真实的软件系统时，可以（并且应该）收集大量不同的指标，特别是根据微服务架构原则设计的。在这种情况下，收集和存储此类状态数据的过程通常称为监控。 源代码：

Knavite Serving是构成Knative的组件之一。Knative支持在 Kubernetes 上构建serverless无服务器、事件驱动的应用程序。Knative 由两个组件组成：Serving和Eventing 。 Serv

构建最小的 Docker 镜像来部署 Rust 带来了很多好处：它不仅有利于安全性（减少攻击面），而且可以缩短部署时间、降低成本（减少带宽和存储），并降低依赖冲突的风险。 我们的 "应用程序 "相当简单：我们将建立一个命令行工具，调用https:/

CI/CD部署管道可以帮助开发软件和组织架构来促进快速流动，从而提高业务敏捷性。 任何软件交付工作的核心都应该是部署管道，Je

在本文中，您将学习如何使用Datree和 Argo CD 在您的持续交付过程中验证 Kubernetes 清单。我已经在我之前的一篇关于 Tekton 的 CI/CD 的文章中

在过去的十年中，我们看到了软件系统架构可视化的 "复兴"，其形式是通过部署系统的工件自动生成可视化。这些方法为团队提供了对团队工作范围内和跨团队的运行软件系统的更多认识。这些为组织打开了大门，以更好地理解、浏览和设计如何发展他们的产品，因为它们提供了前所未有的认识。这样的发展也允许我称之为

重点介绍围绕在 Kubernetes 上运行 Spring（以及更广泛的 Java）应用程序所形成的一些学习和最佳实践。本文档并非完全基于第一手经验，而是我在社区中以及与客户合作时确定的结论和最佳实践的集合。 为了在 Kubernetes 中运行