翻译

翻译

所有你想要知道的 DevOps 基础知识都在这里

明远 发表了文章 • 0 个评论 • 394 次浏览 • 2019-05-21 18:12 • 来自相关话题

在当前的 IT 实践中,为了支持高效和快捷的软件开发,出现了巨大的转变:在单体应用的软件架构正在逐渐被微服务架构取代的情况下,开发、 QA 和运维团队为了摆脱了之前相互孤立的状况,开始相互关联并融合统一,我们将其称为DevOps。 当 ...查看全部
在当前的 IT 实践中,为了支持高效和快捷的软件开发,出现了巨大的转变:在单体应用的软件架构正在逐渐被微服务架构取代的情况下,开发、 QA 和运维团队为了摆脱了之前相互孤立的状况,开始相互关联并融合统一,我们将其称为DevOps。

当今如果一个技术驱动型企业想要以客户为导向来进行快速的软件迭代,那么他们需要更快速的软件开发和交付周期。而这些需求直接导致了 DevOps 文化的核心 CI/CD 实践的诞生。

* CI 持续集成:一种专注于使发布更容易的软件开发实践。
* CD 持续交付:是持续集成的延伸,以确保您可以以可持续的方式快速向客户发布新的更改。

早期整个 SDLC 都是线性和顺序的,这拉长了产品的发布周期。但随着快速变化的市场动态、激烈的竞争和多变的客户需求,这些都会导致公司无法继续使用原先开发流程。他们必须更贴近客户,需要不断创新以保持他们的参与。而 DevOps 为此提供了解决方案,并被技术驱动的公司广泛采用,用来改进其快速交付的流程和实践。如果你想和更多 DevOps 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

那么让我们试着了解什么是 DevOps ?
#DevOps 定义
提到 DevOps 我经常引用 w.r.t 的话:

任何公司在学会使用最佳 DevOps 实践进行协作、统一和自动化所有开发和运维流程之前,都将无法扩展和维持。这是一种将每个人联系在一起实现共同目标的文化。



是时候让所有团队成员与他们的部门密切合作,采用工具和实践来高效地交付软件产品。

Atlassian 将 DevOps 定义为

DevOps 是一组软件开发和运维团队之间的自动化流程实践,以便他们可以快速、可靠地构建,测试和发布软件。DevOps 的概念建立在为过去相对孤立的团队之间建立合作文化的基础上。其带来的好处包括更加可靠、更快的软件发布,快速解决关键问题的能力,以及更好地管理计划外的工作。



Amazon 将 DevOps 定义为:

文化理念、实践和工具的结合,提高了团队的高速交付应用程序和服务的能力:与使用单体应用的软件开发架构管理流程的团队相比,以更快的速度开发和改进产品。这种速度使团队能够更好地为客户服务,并在市场竞争中占据有利地位。



Microsoft 以更简化的方式定义 DevOps:

DevOps 可以为我们的终端客户持续提供价值的人员,流程和产品的结合。



我认为 DevOps 的最佳解释为:它是一种文化,是一种将人放在首位团队理念,为他们提供适宜的环境,使他们能够蓬勃发展,因此无论他们属于什么部门,都可以通过明确的流程进行协作和沟通,从而实现目标。
# DevOps 是如何工作的?
如上所述,DevOps 没有任何固定的规则和实践,但它更像是通过来自不同部门具有不同的技能的团队在一起以实现预期的结果的文化。那么它实际上是如何工作的,让我通过下图简要解释一下:
1.png

因此,开发人员,QA 和运维团队使用 CI/CD 实践来实现客户的预期目标。开发人员编写代码并将其提交到 GitHub 等源码控制工具。DevOps 工程师使用 CI 工具来提取代码,来进行自动化测试,并通过 CD 工具部署到处理生产或测试服务器。

开发和运维人员一起工作,并使用各种工具进行 CI/CD 和监控,以快速响应客户需求并修复问题和错误。
# DevOps工具在DevOps周期的各个阶段
2.png

DevOps 工程师可以使用多种工具在整个 DevOps 生命周期的每个阶段获取期望的结果。
## 计划
您可以使用 JiraAzure DevOps Board 以敏捷方式管理和规划您的工作。
## 开发
对于代码管理, Git 以分布式方式管理代码版本历史、分支、推送和拉取机制的首要工具。您还可以使用 Microsoft TFVC(Team Foundation Version Control),这是一个集中版本控制系统。
## 测试
要进行自动化测试,您可以使用 SeleniumJUnitApache JMeter
## 集成
Jenkins 是目前最受欢迎的 CI 工具之一,它可以做到无缝地集成开发和运维流程。

其他 CI 工具还有 TravisBamboo
## 部署和配置管理
Docker 是最受欢迎和广泛使用的持续部署工具之一。它也是软件容器化工具。

其他部署和配置管理工具还有 KubernetesChefAnsiblePuppet

Kubernetes 是一个开源容器管理(编排)工具。其容器管理职责包括容器部署,容器扩展和伸缩以及容器的负载均衡。
## 监控
将产品部署到正确的位置后,持续的监控就变得至关重要。 NagiosSplunkNew Relics 是广泛使用的持续监控工具。
# DevOps 最佳实践
正如文章开头所讨论的那样,为了使技术驱动的公司变得更加以客户为导向,他们需要将自己从单体应用的软件开发实践转变为为客户发布产品的敏捷方式。让我们试着了解他们需要采用的最佳 DevOps 实践:

  • 持续集成
  • 持续交付
  • 微服务
  • 基础设施即代码
  • 监控和日志
  • 沟通与协作
让我简要解释一下:##持续集成Amazon 将 CI 定义为:DevOps 软件开发实践,开发人员定期将代码修改合并到中央存储库,然后运行自动构建和测试。持续集成通常是指软件发布过程的构建或集成阶段,并且需要自动化组件(例如,CI 或构建服务)。持续集成的目的是更快地发现和解决问题,提高软件质量,并减少验证和发布新软件更新所需的时间。##持续交付持续交付是一种软件开发实践,其中开发人员完成的任何代码更改都会自动为发布到生产环境做好准备。通过在构建阶段之后将所有的代码更改部署到测试环境或生产环境,持续交付可在持续集成时进行扩展。## 微服务:敏捷开发的架构这是一种新的软件设计方法,您可以将单个应用程序拆分为一组小型服务/模块。与单体应用架构将所有前端和后端代码库以及数据库都全部部署在同一个服务器地址中相比,基于微服务架构的应用程序被分解为服务,其中每个服务器都在其中运行使用基于 HTTP 的应用程序编程接口(API),通过定义良好的接口使自己与其他服务进行通信。按照 Amazon 的介绍:微服务是围绕业务能力构建的; 每项服务的范围都是一个简单的用途。您可以使用不同的框架或编程语言来编写微服务并将它们作为单个服务或一组服务独立部署。## 基础设施即代码:IaC是通过机器可读定义文件(代码库)管理和配置计算机数据中心的过程,而不是物理硬件配置或交互式配置工具。
3.jpeg
Amazon 定义 IaC 为:作为使用代码和软件开发技术(例如版本控制和持续集成)来配置和管理基础架构的实践。云服务的 API 驱动模型使开发人员和系统管理员能够以编程方式大规模地与基础架构交互,而不需要手动设置和配置资源。因此,开发人员可以使用基于代码的工具与基础架构进行交互,使其更像应用程序。这使得可以使用标准化模式快速部署基础架构和服务器,使用最新的补丁和版本进行更新,或以副本的方式进行复制部署。传统的服务(生命周期)自动化和配置管理工具用于完成IaC。现在企业也在使用连续配置自动化工具或独立的 IaC 框架,例如 Microsoft 的 PowerShell DSCAWS CloudFormation。## 监控与日志公司可以通过监控指标和日志,来了解其应用程序和基础架构的运行情况。APM(Application performance management 应用程序性能管理)将 IT 指标转换为有意义的业务指标,致力于检测和诊断复杂的应用程序性能问题,以维持预期的服务等级。通过捕获、分类、分析应用程序和基础架构生成的数据和日志,团队可以了解更新是如何影响用户的,从而深入了解问题或报错的根本原因。wiki 中介绍:密切监控两组性能指标。第一组性能指标定义了应用程序终端用户所体验的性能。性能的一个示例是峰值负载下的平均响应时间,包括加载和响应时间。
  • 负载是应用程序处理的事务量,例如,每秒事务数(tps)、每秒请求数、每秒页数。在没有被计算机的搜索、计算、传输等需求加载的情况下,大多数应用程序都足够快,这就是开发人员在开发过程中可能无法捕获性能问题的原因。
  • 响应时间是应用程序在此类负载下响应用户操作所需的时间。

##沟通与协作
在我看来:

团队中的 DevOps 作为一种实践取得成功,需要2个基本支柱:沟通和协作,才能非常有效地工作。如果没有这种感觉并理解紧密结合团队工作的重要性,那么采用 DevOps 最佳实践将非常困难。

增加团队中的沟通和协作是 DevOps文化 的关键方面之一。有了这种文化,团队就会以良好的态度和动力聚集在一起,围绕信息共享建立强有力的文化规范,并通过沟通工具和应用促进沟通,使团队的所有部门能够更加紧密地协调共同的目标。
# 为何选择DevOps?它的好处是什么?

要了解 DevOps 提升的价值已经其如何被公司所采用:

让我们看看由 veritis 带给您的以下信息图表。
4.jpeg

以上给出的图表清楚地阐述了 DevOps 实践的主要好处:
## 速度
DevOps 促进团队的高速开发,以便您可以更快地为客户进行创新,更好地适应不断变化的市场,并在推动业务成果方面提高效率。
## 快速交付
通过基于 CI/CD 的 DevOps 文化,缩短了应用程序发布周期,允许更快的客户反馈和有意义的创新在团队内的蓬勃发展。您可以更快地发布新功能并修复错误,更快地响应客户的需求并建立竞争优势。
## 可靠性
DevOps 使您能够通过持续集成和持续交付等实践不断提高您的软件质量,以测试每项变更的功能和安全性。这造就了可靠和经过测试的应用程序和强大的基础设施的开发。DevOps 持续监控和记录实践可以帮助您实时了解软件的性能。
## 文化
DevOps 培养了一种伟大的工作文化,在其文化模式下建立更有效的团队,强调所有权和责任等价值观。
## 安全
通过采用 DevOps 模型,组织可以使用基础架即代码和策略即代码,在不牺牲安全性的情况下大规模定义和跟踪合规性。他们可以在保持控制和合规性的同时快速进步。
# DevOps 的挑战
在团队中实施 DevOps 文化并不容易。没有标准的规则可以参考,它更像是改变个人和团队的心态的游戏。这就像要求人们离开他们的舒适区。

“当你试图在团队中带来任何相当大的变化时,一开始可能看起来很难,但当你有足够大的意愿时,就会发生变化,并渐进达成目标。”



因此,让我们看看采用 DevOps 作为文化的一些常见挑战。
##Dev Vs Ops 心态
由于长期的开发和运维团队一直在孤立地工作,完成不同的任务。所以他们经过精心调整,以不同的方式思考和行动。开发人员试图尽快创新并做出改变,运维人员则试图保持 100% 的服务可用性。他们的目标和优先事项是不同的,所以如果我们必须将 DevOps 作为团队中的文化实践,那么如果他们的心态还是两个孤立的部分,那么 DevOps 必将黯然失色。

DevOps 的实践就是将团队整合在一起,打破 IT 组织内部的孤岛。因此,将它们整合为统一单元以实现共同目标是任何公司在采用 DevOps 实践时需要克服的第一个障碍。
##从传统基础设施转向微服务架构
5.png

多年来,这些公司一直存在遗留的基础设施,但如果他们必须快速创新,他们必须摆脱这种方法并采用更具可扩展性的微服务架构。将基础设施即代码与微服务一起使用是迈向持续创新未来的又一步。

然而,将架构变为微服务架构系统存在很大的障碍。采用微服务架构需要采用最佳的 DevOps 实践以及 CI/CD 实践。这为团队带来了巨大的工作量和运维挑战,同时也增加了成本因素。

确实,将开发与部署转变为现代的软件开发方案可能会很痛苦,但一旦采用就可以使您的团队变得更加高效与可扩展。
## 开发和运维工具集的冲突
6.jpeg

开发团队的目标和指标完全不同,因此他们可能需要一个运维团队可能不需要的工具集。因此,必须将两个团队聚集在一起,以了解他们两者可以合作的位置,并整合对他们两者都有意义的工具,并统一他们可以监控的目标和指标。

一些团队可能不愿意使用传统工具,这些工具不仅技术上较差,而且由于兼容性问题也会降低整个基础架构的速度。因此,请确保正在使用的工具与公司的产品愿景保持一致。
# 总结
无论我们在公司方面与个人方面有多么不同,我们都必须摒弃差异并作为一个整体来实现客户需求和解决客户的问题。如果我们能够在我们团队的工作文化中吸收这种理念,那么 DevOps 将成为重视过程和收益的宝贵实践。

原文链接:All About DevOps Fundamentals You Ever Wanted To Know !(翻译:郭旭东)

Kustomize:无需模板定制你的 Kubernetes 配置

明远 发表了文章 • 0 个评论 • 782 次浏览 • 2019-04-16 15:23 • 来自相关话题

【编者的话】随着 Kubernetes 1.14 的发布,kustomize 被集成到 `kubectl` 中,用户可以利用 `kubectl apply -k dir/` 将指定目录的 `kustomization.yaml` 提交到集群中。 ...查看全部
【编者的话】随着 Kubernetes 1.14 的发布,kustomize 被集成到 `kubectl` 中,用户可以利用 `kubectl apply -k dir/` 将指定目录的 `kustomization.yaml` 提交到集群中。

如果你在运行 Kubernetes 集群,你可能会拷贝一些包含 Kubernetes API 对象的 YAML 文件,并且根据你的需求来修改这些文件,通过这些 YAML 文件来定义你的 Kubernetes 配置。

但是这种方法存在很难找到配置的源头并对其进行改进。今天 Google 宣布推出 Kustomize ,一个作为 SIG-CLI 子项目的命令行工具。这个工具提供了一个全新的、纯粹的声明式的方法来定制 kubernetes 配置,遵循并利用我们熟悉且精心设计的 Kubernetes API。

有这样一个常见的场景,在互联网上可以看到别人的 CMS(content management system,内容管理系统)的 kubernetes 配置,这个配置是一组包括 Kubernetes API 对象的 YAML 描述文件。然后,在您自己公司的某个角落,您找到一个你非常了解的数据库,希望用它来该 CMS 的数据。

你希望同时使用它们,此外,你希望自定义配置文件以便你的资源实例在集群中显示,并通过添加一个标签来区分在同一集群中做同样事情的其他资源。同时也希望为其配置适当的 CPU 、内存和副本数。

此外,你还想要配置整个配置的多种变化:一个专门用于测试和实验的小服务实例(就计算资源而言),或更大的用于对外提供服务的生产级别的服务实例。同时,其他的团队也希望拥有他们自己的服务实例。
# 定制就是复用
kubernetes 的配置并不是代码(是使用 YAML 描述的 API 对象,严格来说应该是数据),但是配置的生命周期与代码的生命周期有许多相似之处。

你需要在版本控制中保留配置。所有者的配置不必与使用者的配置相同。配置可以作为整体的一部分。而用户希望为在不同的情况下复用这些配置。

与代码复用相同,一种复用配置的方法是简单的全部拷贝并进行自定义。像代码一样,切断与源代码的联系使得从改进变的十分困难。许多团队和环境都使用这种方法,每个团队和环境都拥有自己的配置,这使得简单的升级变得十分棘手。

另一种复用方法是将源代码抽象为参数化模板。使用一个通过执行脚本来替换所需参数的模板处理工具生成配置,通过为同一模板设置不同的值来达到复用的目的。而这种方式面临的问题是模板和参数文件并不在 kubernetes API 资源的规范中,这种方式必定是一种包装了 kubernetes API 的新东西、新语言。虽然这种方式很强大,但是也带来了学习成本和安装工具的成本。不同的团队需要不同的更改,因此几乎所有可以包含在 YAML 文件中的规范都会需要抽象成参数。
# 自定义配置的新选择
kustomize 中工具的声明与规范是由名为 ```kustomization.yaml``` 的文件定义。

kustomize 将会读取声明文件和 Kubernetes API 资源文件,将其组合然后将完整的资源进行标准化的输出。输出的文本可以被其他工具进一步处理,或者直接通过 kubectl 应用于集群。

例如,如果 ```kustomization.yaml``` 文件包括:
commonLabels:
app: hello
resources:
- deployment.yaml
- configMap.yaml
- service.yaml

确保这三个文件与 ```kustomization.yaml``` 位于同一目录下,然后运行:
kustomize build

将创建包含三个资源的 YAML 流,其中 ```app: hello``` 为每个资源共同的标签。

同样的,你可以使用 commonAnnotations 字段给所有资源添加注释, namePrefix 字段为所有的资源添加共同的前缀名。这些琐碎而有常见的定制只是一个开始。

一个更常见的例子是,你需要为一组相同资源设置不同的参数。例如:开发、演示和生产的参数。

为此,Kustomize 允许用户以一个应用描述文件 (YAML 文件)为基础(Base YAML),然后通过 Overlay 的方式生成最终部署应用所需的描述文件。两者都是由 kustomization 文件表示。基础(Base)声明了共享的内容(资源和常见的资源配置),Overlay 则声明了差异。

这里是一个目录树,用于管理集群应用程序的 演示生产 配置参数:
 someapp/
├── base/
│ ├── kustomization.yaml
│ ├── deployment.yaml
│ ├── configMap.yaml
│ └── service.yaml
└── overlays/
├── production/
│ └── kustomization.yaml
│ ├── replica_count.yaml
└── staging/
├── kustomization.yaml
└── cpu_count.yaml

```someapp/base/kustomization.yaml``` 文件指定了公共资源和常见自定义配置(例如,它们一些相同的标签,名称前缀和注释)。

```someapp/overlays/production/kustomization.yaml``` 文件的内容可能是:
commonLabels:
env: production
bases:
- ../../base
patches:
- replica_count.yaml

这个 kustomization 指定了一个 patch 文件 ```replica_count.yaml``` ,其内容可能是:

apiVersion: apps/v1
kind: Deployment
metadata:
name: the-deployment
spec:
replicas: 100

patch 是部分的资源声明,在这个例子中是 Deployment 的补丁 ```someapp/base/deployment.yaml``` ,仅修改了副本数用以处理生产流量。

该补丁不仅仅是一个无上下文 {parameter name,value} 元组。其作为部分 deployment spec,可以通过验证,即使与其余配置隔离读取,也具有明确的上下文和用途。

要为生产环境创建资源,请运行:
kustomize build someapp/overlays/production

运行结果将作为一组完整资源打印到标准输出,并准备应用于集群。可以用类似的命令定义演示环境的配置。
# 综上所述
使用 kustomize ,您可以仅使用 Kubernetes API 资源文件就可以管理任意数量的 Kubernetes 定制配置。kustomize 的每个产物都是纯 YAML 的,每个都可以进行验证和运行的。kustomize 鼓励通过 fork/modify/rebase 这样的工作流来管理海量的应用描述文件。

尝试hello world示例,开始使用 kustomize 吧!有关的反馈与讨论,可以通过加入邮件列表或提 issue,欢迎提交PR。

原文链接:Introducing kustomize; Template-free Configuration Customization for Kubernetes

编配和编排的定义之争现在是什么结论?

回复

wffger 发起了问题 • 1 人关注 • 0 个回复 • 1571 次浏览 • 2017-12-19 22:03 • 来自相关话题

DockerOne翻译列表

BeAGoodUncleDon 回复了问题 • 14 人关注 • 6 个回复 • 4482 次浏览 • 2016-05-02 21:01 • 来自相关话题

Kustomize:无需模板定制你的 Kubernetes 配置

明远 发表了文章 • 0 个评论 • 782 次浏览 • 2019-04-16 15:23 • 来自相关话题

【编者的话】随着 Kubernetes 1.14 的发布,kustomize 被集成到 `kubectl` 中,用户可以利用 `kubectl apply -k dir/` 将指定目录的 `kustomization.yaml` 提交到集群中。 ...查看全部
【编者的话】随着 Kubernetes 1.14 的发布,kustomize 被集成到 `kubectl` 中,用户可以利用 `kubectl apply -k dir/` 将指定目录的 `kustomization.yaml` 提交到集群中。

如果你在运行 Kubernetes 集群,你可能会拷贝一些包含 Kubernetes API 对象的 YAML 文件,并且根据你的需求来修改这些文件,通过这些 YAML 文件来定义你的 Kubernetes 配置。

但是这种方法存在很难找到配置的源头并对其进行改进。今天 Google 宣布推出 Kustomize ,一个作为 SIG-CLI 子项目的命令行工具。这个工具提供了一个全新的、纯粹的声明式的方法来定制 kubernetes 配置,遵循并利用我们熟悉且精心设计的 Kubernetes API。

有这样一个常见的场景,在互联网上可以看到别人的 CMS(content management system,内容管理系统)的 kubernetes 配置,这个配置是一组包括 Kubernetes API 对象的 YAML 描述文件。然后,在您自己公司的某个角落,您找到一个你非常了解的数据库,希望用它来该 CMS 的数据。

你希望同时使用它们,此外,你希望自定义配置文件以便你的资源实例在集群中显示,并通过添加一个标签来区分在同一集群中做同样事情的其他资源。同时也希望为其配置适当的 CPU 、内存和副本数。

此外,你还想要配置整个配置的多种变化:一个专门用于测试和实验的小服务实例(就计算资源而言),或更大的用于对外提供服务的生产级别的服务实例。同时,其他的团队也希望拥有他们自己的服务实例。
# 定制就是复用
kubernetes 的配置并不是代码(是使用 YAML 描述的 API 对象,严格来说应该是数据),但是配置的生命周期与代码的生命周期有许多相似之处。

你需要在版本控制中保留配置。所有者的配置不必与使用者的配置相同。配置可以作为整体的一部分。而用户希望为在不同的情况下复用这些配置。

与代码复用相同,一种复用配置的方法是简单的全部拷贝并进行自定义。像代码一样,切断与源代码的联系使得从改进变的十分困难。许多团队和环境都使用这种方法,每个团队和环境都拥有自己的配置,这使得简单的升级变得十分棘手。

另一种复用方法是将源代码抽象为参数化模板。使用一个通过执行脚本来替换所需参数的模板处理工具生成配置,通过为同一模板设置不同的值来达到复用的目的。而这种方式面临的问题是模板和参数文件并不在 kubernetes API 资源的规范中,这种方式必定是一种包装了 kubernetes API 的新东西、新语言。虽然这种方式很强大,但是也带来了学习成本和安装工具的成本。不同的团队需要不同的更改,因此几乎所有可以包含在 YAML 文件中的规范都会需要抽象成参数。
# 自定义配置的新选择
kustomize 中工具的声明与规范是由名为 ```kustomization.yaml``` 的文件定义。

kustomize 将会读取声明文件和 Kubernetes API 资源文件,将其组合然后将完整的资源进行标准化的输出。输出的文本可以被其他工具进一步处理,或者直接通过 kubectl 应用于集群。

例如,如果 ```kustomization.yaml``` 文件包括:
commonLabels:
app: hello
resources:
- deployment.yaml
- configMap.yaml
- service.yaml

确保这三个文件与 ```kustomization.yaml``` 位于同一目录下,然后运行:
kustomize build

将创建包含三个资源的 YAML 流,其中 ```app: hello``` 为每个资源共同的标签。

同样的,你可以使用 commonAnnotations 字段给所有资源添加注释, namePrefix 字段为所有的资源添加共同的前缀名。这些琐碎而有常见的定制只是一个开始。

一个更常见的例子是,你需要为一组相同资源设置不同的参数。例如:开发、演示和生产的参数。

为此,Kustomize 允许用户以一个应用描述文件 (YAML 文件)为基础(Base YAML),然后通过 Overlay 的方式生成最终部署应用所需的描述文件。两者都是由 kustomization 文件表示。基础(Base)声明了共享的内容(资源和常见的资源配置),Overlay 则声明了差异。

这里是一个目录树,用于管理集群应用程序的 演示生产 配置参数:
 someapp/
├── base/
│ ├── kustomization.yaml
│ ├── deployment.yaml
│ ├── configMap.yaml
│ └── service.yaml
└── overlays/
├── production/
│ └── kustomization.yaml
│ ├── replica_count.yaml
└── staging/
├── kustomization.yaml
└── cpu_count.yaml

```someapp/base/kustomization.yaml``` 文件指定了公共资源和常见自定义配置(例如,它们一些相同的标签,名称前缀和注释)。

```someapp/overlays/production/kustomization.yaml``` 文件的内容可能是:
commonLabels:
env: production
bases:
- ../../base
patches:
- replica_count.yaml

这个 kustomization 指定了一个 patch 文件 ```replica_count.yaml``` ,其内容可能是:

apiVersion: apps/v1
kind: Deployment
metadata:
name: the-deployment
spec:
replicas: 100

patch 是部分的资源声明,在这个例子中是 Deployment 的补丁 ```someapp/base/deployment.yaml``` ,仅修改了副本数用以处理生产流量。

该补丁不仅仅是一个无上下文 {parameter name,value} 元组。其作为部分 deployment spec,可以通过验证,即使与其余配置隔离读取,也具有明确的上下文和用途。

要为生产环境创建资源,请运行:
kustomize build someapp/overlays/production

运行结果将作为一组完整资源打印到标准输出,并准备应用于集群。可以用类似的命令定义演示环境的配置。
# 综上所述
使用 kustomize ,您可以仅使用 Kubernetes API 资源文件就可以管理任意数量的 Kubernetes 定制配置。kustomize 的每个产物都是纯 YAML 的,每个都可以进行验证和运行的。kustomize 鼓励通过 fork/modify/rebase 这样的工作流来管理海量的应用描述文件。

尝试hello world示例,开始使用 kustomize 吧!有关的反馈与讨论,可以通过加入邮件列表或提 issue,欢迎提交PR。

原文链接:Introducing kustomize; Template-free Configuration Customization for Kubernetes

编配和编排的定义之争现在是什么结论?

回复

wffger 发起了问题 • 1 人关注 • 0 个回复 • 1571 次浏览 • 2017-12-19 22:03 • 来自相关话题

DockerOne翻译列表

回复

BeAGoodUncleDon 回复了问题 • 14 人关注 • 6 个回复 • 4482 次浏览 • 2016-05-02 21:01 • 来自相关话题

所有你想要知道的 DevOps 基础知识都在这里

明远 发表了文章 • 0 个评论 • 394 次浏览 • 2019-05-21 18:12 • 来自相关话题

在当前的 IT 实践中,为了支持高效和快捷的软件开发,出现了巨大的转变:在单体应用的软件架构正在逐渐被微服务架构取代的情况下,开发、 QA 和运维团队为了摆脱了之前相互孤立的状况,开始相互关联并融合统一,我们将其称为DevOps。 当 ...查看全部
在当前的 IT 实践中,为了支持高效和快捷的软件开发,出现了巨大的转变:在单体应用的软件架构正在逐渐被微服务架构取代的情况下,开发、 QA 和运维团队为了摆脱了之前相互孤立的状况,开始相互关联并融合统一,我们将其称为DevOps。

当今如果一个技术驱动型企业想要以客户为导向来进行快速的软件迭代,那么他们需要更快速的软件开发和交付周期。而这些需求直接导致了 DevOps 文化的核心 CI/CD 实践的诞生。

* CI 持续集成:一种专注于使发布更容易的软件开发实践。
* CD 持续交付:是持续集成的延伸,以确保您可以以可持续的方式快速向客户发布新的更改。

早期整个 SDLC 都是线性和顺序的,这拉长了产品的发布周期。但随着快速变化的市场动态、激烈的竞争和多变的客户需求,这些都会导致公司无法继续使用原先开发流程。他们必须更贴近客户,需要不断创新以保持他们的参与。而 DevOps 为此提供了解决方案,并被技术驱动的公司广泛采用,用来改进其快速交付的流程和实践。如果你想和更多 DevOps 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

那么让我们试着了解什么是 DevOps ?
#DevOps 定义
提到 DevOps 我经常引用 w.r.t 的话:

任何公司在学会使用最佳 DevOps 实践进行协作、统一和自动化所有开发和运维流程之前,都将无法扩展和维持。这是一种将每个人联系在一起实现共同目标的文化。



是时候让所有团队成员与他们的部门密切合作,采用工具和实践来高效地交付软件产品。

Atlassian 将 DevOps 定义为

DevOps 是一组软件开发和运维团队之间的自动化流程实践,以便他们可以快速、可靠地构建,测试和发布软件。DevOps 的概念建立在为过去相对孤立的团队之间建立合作文化的基础上。其带来的好处包括更加可靠、更快的软件发布,快速解决关键问题的能力,以及更好地管理计划外的工作。



Amazon 将 DevOps 定义为:

文化理念、实践和工具的结合,提高了团队的高速交付应用程序和服务的能力:与使用单体应用的软件开发架构管理流程的团队相比,以更快的速度开发和改进产品。这种速度使团队能够更好地为客户服务,并在市场竞争中占据有利地位。



Microsoft 以更简化的方式定义 DevOps:

DevOps 可以为我们的终端客户持续提供价值的人员,流程和产品的结合。



我认为 DevOps 的最佳解释为:它是一种文化,是一种将人放在首位团队理念,为他们提供适宜的环境,使他们能够蓬勃发展,因此无论他们属于什么部门,都可以通过明确的流程进行协作和沟通,从而实现目标。
# DevOps 是如何工作的?
如上所述,DevOps 没有任何固定的规则和实践,但它更像是通过来自不同部门具有不同的技能的团队在一起以实现预期的结果的文化。那么它实际上是如何工作的,让我通过下图简要解释一下:
1.png

因此,开发人员,QA 和运维团队使用 CI/CD 实践来实现客户的预期目标。开发人员编写代码并将其提交到 GitHub 等源码控制工具。DevOps 工程师使用 CI 工具来提取代码,来进行自动化测试,并通过 CD 工具部署到处理生产或测试服务器。

开发和运维人员一起工作,并使用各种工具进行 CI/CD 和监控,以快速响应客户需求并修复问题和错误。
# DevOps工具在DevOps周期的各个阶段
2.png

DevOps 工程师可以使用多种工具在整个 DevOps 生命周期的每个阶段获取期望的结果。
## 计划
您可以使用 JiraAzure DevOps Board 以敏捷方式管理和规划您的工作。
## 开发
对于代码管理, Git 以分布式方式管理代码版本历史、分支、推送和拉取机制的首要工具。您还可以使用 Microsoft TFVC(Team Foundation Version Control),这是一个集中版本控制系统。
## 测试
要进行自动化测试,您可以使用 SeleniumJUnitApache JMeter
## 集成
Jenkins 是目前最受欢迎的 CI 工具之一,它可以做到无缝地集成开发和运维流程。

其他 CI 工具还有 TravisBamboo
## 部署和配置管理
Docker 是最受欢迎和广泛使用的持续部署工具之一。它也是软件容器化工具。

其他部署和配置管理工具还有 KubernetesChefAnsiblePuppet

Kubernetes 是一个开源容器管理(编排)工具。其容器管理职责包括容器部署,容器扩展和伸缩以及容器的负载均衡。
## 监控
将产品部署到正确的位置后,持续的监控就变得至关重要。 NagiosSplunkNew Relics 是广泛使用的持续监控工具。
# DevOps 最佳实践
正如文章开头所讨论的那样,为了使技术驱动的公司变得更加以客户为导向,他们需要将自己从单体应用的软件开发实践转变为为客户发布产品的敏捷方式。让我们试着了解他们需要采用的最佳 DevOps 实践:

  • 持续集成
  • 持续交付
  • 微服务
  • 基础设施即代码
  • 监控和日志
  • 沟通与协作
让我简要解释一下:##持续集成Amazon 将 CI 定义为:DevOps 软件开发实践,开发人员定期将代码修改合并到中央存储库,然后运行自动构建和测试。持续集成通常是指软件发布过程的构建或集成阶段,并且需要自动化组件(例如,CI 或构建服务)。持续集成的目的是更快地发现和解决问题,提高软件质量,并减少验证和发布新软件更新所需的时间。##持续交付持续交付是一种软件开发实践,其中开发人员完成的任何代码更改都会自动为发布到生产环境做好准备。通过在构建阶段之后将所有的代码更改部署到测试环境或生产环境,持续交付可在持续集成时进行扩展。## 微服务:敏捷开发的架构这是一种新的软件设计方法,您可以将单个应用程序拆分为一组小型服务/模块。与单体应用架构将所有前端和后端代码库以及数据库都全部部署在同一个服务器地址中相比,基于微服务架构的应用程序被分解为服务,其中每个服务器都在其中运行使用基于 HTTP 的应用程序编程接口(API),通过定义良好的接口使自己与其他服务进行通信。按照 Amazon 的介绍:微服务是围绕业务能力构建的; 每项服务的范围都是一个简单的用途。您可以使用不同的框架或编程语言来编写微服务并将它们作为单个服务或一组服务独立部署。## 基础设施即代码:IaC是通过机器可读定义文件(代码库)管理和配置计算机数据中心的过程,而不是物理硬件配置或交互式配置工具。
3.jpeg
Amazon 定义 IaC 为:作为使用代码和软件开发技术(例如版本控制和持续集成)来配置和管理基础架构的实践。云服务的 API 驱动模型使开发人员和系统管理员能够以编程方式大规模地与基础架构交互,而不需要手动设置和配置资源。因此,开发人员可以使用基于代码的工具与基础架构进行交互,使其更像应用程序。这使得可以使用标准化模式快速部署基础架构和服务器,使用最新的补丁和版本进行更新,或以副本的方式进行复制部署。传统的服务(生命周期)自动化和配置管理工具用于完成IaC。现在企业也在使用连续配置自动化工具或独立的 IaC 框架,例如 Microsoft 的 PowerShell DSCAWS CloudFormation。## 监控与日志公司可以通过监控指标和日志,来了解其应用程序和基础架构的运行情况。APM(Application performance management 应用程序性能管理)将 IT 指标转换为有意义的业务指标,致力于检测和诊断复杂的应用程序性能问题,以维持预期的服务等级。通过捕获、分类、分析应用程序和基础架构生成的数据和日志,团队可以了解更新是如何影响用户的,从而深入了解问题或报错的根本原因。wiki 中介绍:密切监控两组性能指标。第一组性能指标定义了应用程序终端用户所体验的性能。性能的一个示例是峰值负载下的平均响应时间,包括加载和响应时间。
  • 负载是应用程序处理的事务量,例如,每秒事务数(tps)、每秒请求数、每秒页数。在没有被计算机的搜索、计算、传输等需求加载的情况下,大多数应用程序都足够快,这就是开发人员在开发过程中可能无法捕获性能问题的原因。
  • 响应时间是应用程序在此类负载下响应用户操作所需的时间。

##沟通与协作
在我看来:

团队中的 DevOps 作为一种实践取得成功,需要2个基本支柱:沟通和协作,才能非常有效地工作。如果没有这种感觉并理解紧密结合团队工作的重要性,那么采用 DevOps 最佳实践将非常困难。

增加团队中的沟通和协作是 DevOps文化 的关键方面之一。有了这种文化,团队就会以良好的态度和动力聚集在一起,围绕信息共享建立强有力的文化规范,并通过沟通工具和应用促进沟通,使团队的所有部门能够更加紧密地协调共同的目标。
# 为何选择DevOps?它的好处是什么?

要了解 DevOps 提升的价值已经其如何被公司所采用:

让我们看看由 veritis 带给您的以下信息图表。
4.jpeg

以上给出的图表清楚地阐述了 DevOps 实践的主要好处:
## 速度
DevOps 促进团队的高速开发,以便您可以更快地为客户进行创新,更好地适应不断变化的市场,并在推动业务成果方面提高效率。
## 快速交付
通过基于 CI/CD 的 DevOps 文化,缩短了应用程序发布周期,允许更快的客户反馈和有意义的创新在团队内的蓬勃发展。您可以更快地发布新功能并修复错误,更快地响应客户的需求并建立竞争优势。
## 可靠性
DevOps 使您能够通过持续集成和持续交付等实践不断提高您的软件质量,以测试每项变更的功能和安全性。这造就了可靠和经过测试的应用程序和强大的基础设施的开发。DevOps 持续监控和记录实践可以帮助您实时了解软件的性能。
## 文化
DevOps 培养了一种伟大的工作文化,在其文化模式下建立更有效的团队,强调所有权和责任等价值观。
## 安全
通过采用 DevOps 模型,组织可以使用基础架即代码和策略即代码,在不牺牲安全性的情况下大规模定义和跟踪合规性。他们可以在保持控制和合规性的同时快速进步。
# DevOps 的挑战
在团队中实施 DevOps 文化并不容易。没有标准的规则可以参考,它更像是改变个人和团队的心态的游戏。这就像要求人们离开他们的舒适区。

“当你试图在团队中带来任何相当大的变化时,一开始可能看起来很难,但当你有足够大的意愿时,就会发生变化,并渐进达成目标。”



因此,让我们看看采用 DevOps 作为文化的一些常见挑战。
##Dev Vs Ops 心态
由于长期的开发和运维团队一直在孤立地工作,完成不同的任务。所以他们经过精心调整,以不同的方式思考和行动。开发人员试图尽快创新并做出改变,运维人员则试图保持 100% 的服务可用性。他们的目标和优先事项是不同的,所以如果我们必须将 DevOps 作为团队中的文化实践,那么如果他们的心态还是两个孤立的部分,那么 DevOps 必将黯然失色。

DevOps 的实践就是将团队整合在一起,打破 IT 组织内部的孤岛。因此,将它们整合为统一单元以实现共同目标是任何公司在采用 DevOps 实践时需要克服的第一个障碍。
##从传统基础设施转向微服务架构
5.png

多年来,这些公司一直存在遗留的基础设施,但如果他们必须快速创新,他们必须摆脱这种方法并采用更具可扩展性的微服务架构。将基础设施即代码与微服务一起使用是迈向持续创新未来的又一步。

然而,将架构变为微服务架构系统存在很大的障碍。采用微服务架构需要采用最佳的 DevOps 实践以及 CI/CD 实践。这为团队带来了巨大的工作量和运维挑战,同时也增加了成本因素。

确实,将开发与部署转变为现代的软件开发方案可能会很痛苦,但一旦采用就可以使您的团队变得更加高效与可扩展。
## 开发和运维工具集的冲突
6.jpeg

开发团队的目标和指标完全不同,因此他们可能需要一个运维团队可能不需要的工具集。因此,必须将两个团队聚集在一起,以了解他们两者可以合作的位置,并整合对他们两者都有意义的工具,并统一他们可以监控的目标和指标。

一些团队可能不愿意使用传统工具,这些工具不仅技术上较差,而且由于兼容性问题也会降低整个基础架构的速度。因此,请确保正在使用的工具与公司的产品愿景保持一致。
# 总结
无论我们在公司方面与个人方面有多么不同,我们都必须摒弃差异并作为一个整体来实现客户需求和解决客户的问题。如果我们能够在我们团队的工作文化中吸收这种理念,那么 DevOps 将成为重视过程和收益的宝贵实践。

原文链接:All About DevOps Fundamentals You Ever Wanted To Know !(翻译:郭旭东)

Kustomize:无需模板定制你的 Kubernetes 配置

明远 发表了文章 • 0 个评论 • 782 次浏览 • 2019-04-16 15:23 • 来自相关话题

【编者的话】随着 Kubernetes 1.14 的发布,kustomize 被集成到 `kubectl` 中,用户可以利用 `kubectl apply -k dir/` 将指定目录的 `kustomization.yaml` 提交到集群中。 ...查看全部
【编者的话】随着 Kubernetes 1.14 的发布,kustomize 被集成到 `kubectl` 中,用户可以利用 `kubectl apply -k dir/` 将指定目录的 `kustomization.yaml` 提交到集群中。

如果你在运行 Kubernetes 集群,你可能会拷贝一些包含 Kubernetes API 对象的 YAML 文件,并且根据你的需求来修改这些文件,通过这些 YAML 文件来定义你的 Kubernetes 配置。

但是这种方法存在很难找到配置的源头并对其进行改进。今天 Google 宣布推出 Kustomize ,一个作为 SIG-CLI 子项目的命令行工具。这个工具提供了一个全新的、纯粹的声明式的方法来定制 kubernetes 配置,遵循并利用我们熟悉且精心设计的 Kubernetes API。

有这样一个常见的场景,在互联网上可以看到别人的 CMS(content management system,内容管理系统)的 kubernetes 配置,这个配置是一组包括 Kubernetes API 对象的 YAML 描述文件。然后,在您自己公司的某个角落,您找到一个你非常了解的数据库,希望用它来该 CMS 的数据。

你希望同时使用它们,此外,你希望自定义配置文件以便你的资源实例在集群中显示,并通过添加一个标签来区分在同一集群中做同样事情的其他资源。同时也希望为其配置适当的 CPU 、内存和副本数。

此外,你还想要配置整个配置的多种变化:一个专门用于测试和实验的小服务实例(就计算资源而言),或更大的用于对外提供服务的生产级别的服务实例。同时,其他的团队也希望拥有他们自己的服务实例。
# 定制就是复用
kubernetes 的配置并不是代码(是使用 YAML 描述的 API 对象,严格来说应该是数据),但是配置的生命周期与代码的生命周期有许多相似之处。

你需要在版本控制中保留配置。所有者的配置不必与使用者的配置相同。配置可以作为整体的一部分。而用户希望为在不同的情况下复用这些配置。

与代码复用相同,一种复用配置的方法是简单的全部拷贝并进行自定义。像代码一样,切断与源代码的联系使得从改进变的十分困难。许多团队和环境都使用这种方法,每个团队和环境都拥有自己的配置,这使得简单的升级变得十分棘手。

另一种复用方法是将源代码抽象为参数化模板。使用一个通过执行脚本来替换所需参数的模板处理工具生成配置,通过为同一模板设置不同的值来达到复用的目的。而这种方式面临的问题是模板和参数文件并不在 kubernetes API 资源的规范中,这种方式必定是一种包装了 kubernetes API 的新东西、新语言。虽然这种方式很强大,但是也带来了学习成本和安装工具的成本。不同的团队需要不同的更改,因此几乎所有可以包含在 YAML 文件中的规范都会需要抽象成参数。
# 自定义配置的新选择
kustomize 中工具的声明与规范是由名为 ```kustomization.yaml``` 的文件定义。

kustomize 将会读取声明文件和 Kubernetes API 资源文件,将其组合然后将完整的资源进行标准化的输出。输出的文本可以被其他工具进一步处理,或者直接通过 kubectl 应用于集群。

例如,如果 ```kustomization.yaml``` 文件包括:
commonLabels:
app: hello
resources:
- deployment.yaml
- configMap.yaml
- service.yaml

确保这三个文件与 ```kustomization.yaml``` 位于同一目录下,然后运行:
kustomize build

将创建包含三个资源的 YAML 流,其中 ```app: hello``` 为每个资源共同的标签。

同样的,你可以使用 commonAnnotations 字段给所有资源添加注释, namePrefix 字段为所有的资源添加共同的前缀名。这些琐碎而有常见的定制只是一个开始。

一个更常见的例子是,你需要为一组相同资源设置不同的参数。例如:开发、演示和生产的参数。

为此,Kustomize 允许用户以一个应用描述文件 (YAML 文件)为基础(Base YAML),然后通过 Overlay 的方式生成最终部署应用所需的描述文件。两者都是由 kustomization 文件表示。基础(Base)声明了共享的内容(资源和常见的资源配置),Overlay 则声明了差异。

这里是一个目录树,用于管理集群应用程序的 演示生产 配置参数:
 someapp/
├── base/
│ ├── kustomization.yaml
│ ├── deployment.yaml
│ ├── configMap.yaml
│ └── service.yaml
└── overlays/
├── production/
│ └── kustomization.yaml
│ ├── replica_count.yaml
└── staging/
├── kustomization.yaml
└── cpu_count.yaml

```someapp/base/kustomization.yaml``` 文件指定了公共资源和常见自定义配置(例如,它们一些相同的标签,名称前缀和注释)。

```someapp/overlays/production/kustomization.yaml``` 文件的内容可能是:
commonLabels:
env: production
bases:
- ../../base
patches:
- replica_count.yaml

这个 kustomization 指定了一个 patch 文件 ```replica_count.yaml``` ,其内容可能是:

apiVersion: apps/v1
kind: Deployment
metadata:
name: the-deployment
spec:
replicas: 100

patch 是部分的资源声明,在这个例子中是 Deployment 的补丁 ```someapp/base/deployment.yaml``` ,仅修改了副本数用以处理生产流量。

该补丁不仅仅是一个无上下文 {parameter name,value} 元组。其作为部分 deployment spec,可以通过验证,即使与其余配置隔离读取,也具有明确的上下文和用途。

要为生产环境创建资源,请运行:
kustomize build someapp/overlays/production

运行结果将作为一组完整资源打印到标准输出,并准备应用于集群。可以用类似的命令定义演示环境的配置。
# 综上所述
使用 kustomize ,您可以仅使用 Kubernetes API 资源文件就可以管理任意数量的 Kubernetes 定制配置。kustomize 的每个产物都是纯 YAML 的,每个都可以进行验证和运行的。kustomize 鼓励通过 fork/modify/rebase 这样的工作流来管理海量的应用描述文件。

尝试hello world示例,开始使用 kustomize 吧!有关的反馈与讨论,可以通过加入邮件列表或提 issue,欢迎提交PR。

原文链接:Introducing kustomize; Template-free Configuration Customization for Kubernetes