加入收藏 | 设为首页 | 会员中心 | 我要投稿 湖南网 (https://www.hunanwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 建站 > 正文

神话还是现实?Docker 和 Kubernetes 架构

发布时间:2019-09-13 16:08:40 所属栏目:建站 来源:Linux中国
导读:在 Docker 和 Kubernetes 期间,软件开拓的天下产生了奈何的变革?有也许行使这些技能一劳永逸地构建一个放之四海而皆准的架构吗?当全部对象都打包在容器中时,有也许同一开拓和集成的进程吗?这些决定有什么要求?它们会带来什么限定?它们会闪开拓职员的糊口
副问题[/!--empirenews.page--]

在 Docker 和 Kubernetes 期间,软件开拓的天下产生了奈何的变革?有也许行使这些技能一劳永逸地构建一个放之四海而皆准的架构吗?当全部对象都“打包”在容器中时,有也许同一开拓和集成的进程吗?这些决定有什么要求?它们会带来什么限定?它们会闪开拓职员的糊口变得更轻松,照旧会增进不须要的伟大性?

神话照旧实际?Docker 和 Kubernetes 架构

是时辰接头和阐发这些(以及其余一些)题目了!(在本文和原创插图中)

本文将带你踏上从实际到开拓进程到架构再回到实际的路程,在沿途的每一站答复最重要的题目。我们将实行确定一些应该成为系统架构一部门的组件和原则,并在不外多深入实现细节的环境下展示一些示例。

这篇文章的结论也许会让你不兴奋或兴奋。这完全取决于你的小我私人履历,你对这个分为三章的故事的观点,乃至也许取决于你阅读时的神色。请在文末颁发评述或提出题目,让我知道你的设法!

一、从实际到开拓流程

神话照旧实际?Docker 和 Kubernetes 架构

在很洪流平上,我所见过或有幸参加成立的全部开拓进程都处事于一个简朴的方针 —— 低落将一个设法酿成实际、并交支付产的时刻,同时保持必然水平的代码质量。

这个设法是好是坏并不重要。坏主意来往复去,你也许只是实行一下,然后拒绝它们,让它们自生自灭。值得一提的是,从一个坏主意中 回退(rolling back)的责任落在将你的开拓流程自动化的呆板人肩上。

一连集成和交付(CI/CD)好像是软件开拓天下中的一根救命稻草。事实,尚有什么比这更简朴的呢?你有设法,你有代码,以是去做吧!假如不是存在一个小题目的话,这将会是十全十美的 —— 假如与贵公司特有的技能和营业流程相疏散,集成和交付流程将很难正规化。

然而,尽量这个使命看起来很伟大,糊口照旧在不绝引入优越的设法,让我们(虽然是我本身)更靠近于成立一个险些在任何场所都有效的美满机制。对我来说,实现这种机制的最近一步是 Docker 和 Kubernetes,它们的抽象条理和意识形态要领让我以为现有题目中的 80% 都可以通过险些沟通的要领来办理。

剩下的 20% 我们也无法忽视。可是这正是你可以把你内涵的缔造性天才齐集于其上的风趣的事变,而不是用于处理赏罚一再性的一般使命。专注于 “架构框架”(architectural framework)可以让你健忘那 80% 已包办理掉的题目。

全部这些意味着什么,Docker 是怎样办理开拓流程中的题目的?让我们来看一个简朴的流程,这对付大大都事变情形来说也是足够的:

神话照旧实际?Docker 和 Kubernetes 架构

通过恰当的要领,你可以自动化和同一以下序列中的全部内容,并在将来几个月内遗忘它。

成立开拓情形

神话照旧实际?Docker 和 Kubernetes 架构

一个项目应该包括一个 docker-compose.yml 文件,这样你就不消思量在当地呆板上运行应用措施/处事必要做什么和怎么做了。一个简朴的 docker-compose up 呼吁就能启动你的应用措施及其全部依靠项、用预制数据填凑数据库、上传当地代码到容器内、启用代码跟踪以便动态编译,并最终在预期的端口开始吸取和相应哀求。纵然是在配置新处事时,你也不必担忧怎样启动、向那边提交接码变动或行使哪些框架。全部这些都应该在尺度声名中预先描写,并由差异设置的处事模板抉择: frontend、backend 和 worker。

自动化测试

神话照旧实际?Docker 和 Kubernetes 架构

关于“黑盒”你只必要知道,全部该有的对象都已经打包到内里了。是或否,1 或 0。更多关于我为什么将容器称为黑盒的信息,将在本文的后头先容。有了数目有限的可以在容器内执行的呼吁,以及描写其全部依靠相关的 docker-compose.yml,你就可以轻松地自动化和同一测试事变,而无需过多存眷实现细节。

譬喻, 像这样 !

在这里,测试不只意味着单位测试,还意味着成果测试、集成测试、搜查代码气魄威风凛凛和一再代码、搜查过期的依靠相关、也许行使违背容许证的软件包以及很多其他工作。要害是全部这些都应该封装在你的 Docker 镜像中。

体系交付

神话照旧实际?Docker 和 Kubernetes 架构

你想在何时何地安装项目并不重要。功效,就像安装进程一样,应该老是沟通的。至于你将安装整个生态体系中的哪个部门,可能从哪个 git 代码库中获代替码,也没有任何区别。这里最重要的构成部门是 幂等性(idempotence)。独一应该指定的是节制安装的变量。

以下是在我看来办理这个题目很是有用的算法:

从你全部的 Dockerfile 中网络镜像(譬喻,像 这样 )

行使一个元项目,通过 Kube API 接口将这些镜像转达给 Kubernetes。启动交付进程凡是必要如下几个输入参数:

  • Kube API 的 会见进口(endpoint)
  • 一个 Secret 工具,因差异的上下文而异(local/showroom/staging/production)
  • 要表现的体系的名称和这些体系的 Docker 镜像的标签(在前面的步调中得到)

作为一个包括全部体系和处事的元项目标例子(换句话说,一个描写生态体系是怎样布置的以及更新是怎样转达给它的项目),我更喜好行使 Ansible 脚本与 这个模块 同 Kube API 举办集成。然而,伟大的 自念头(automators)可以引用其他选项,我将在后头详述我本身的选择。可是,你必需思量一种齐集/同一的架构打点要领。拥有一个这样的要领可以让你利便和同一地打点全部处事/体系,中和即将到来的执行相同成果的技能和体系森林也许带给你的任何伟大性。

(编辑:湖南网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读