2017年9月

历经了 4 年半的开发,著名的 Sublime Text 编辑器的作者 Jon Skinner 宣布:Sublime Text 3.0 正式版终于发布了!

与上一个 beta 版本相比,3.0 带来了崭新的 UI 主题,新的颜色主题以及新的图标。此外,在格式高亮方面有较大改进,也支持 Windows 上的触摸板输入、支持 macOS 的 Touch Bar,以及为 Linux 提供了软件包仓库支持!

相对于 Sublime Text 2 而言,几乎在这个编辑器的每一个方面都有所变化,所以即便是主要变更列表也显得太长了,具体你可以关注下这个页面,希望你有耐心读完。

在 3.0 当中一些大的功能有:定义跳转、新的格式高亮引擎、新的用户界面和丰富的 API。在数百个改进当中,拼写检查得到了改进,自动缩进也更完善,自动换行能也更好的处理源代码,对高分屏支持更好,任意跳转也更加智能。

在 Sublime Text 3 中最令人骄傲的一点是性能:它比历史上发布过的任何一个 Sublime Text 2 版本都要快得多,启动快、打开文件快、甚至内容滚动都快。虽然它的体积比 2 要大,但是却更轻快。

下载地址

在 Windows 和 OS X 平台上,Sublime Text 3 提供了自动更新机制,而针对 Linux 的各个发行版,Sublime Text 3 提供了软件仓库,通过它支持自动更新。

在 Linux 上安装

apt

安装 GPG 公钥:

wget -qO - https://download.sublimetext.com/sublimehq-pub.gpg | sudo apt-key add -

选择使用的频道:

Stable

echo "deb https://download.sublimetext.com/ apt/stable/" | sudo tee /etc/apt/sources.list.d/sublime-text.list

Dev

echo "deb https://download.sublimetext.com/ apt/dev/" | sudo tee /etc/apt/sources.list.d/sublime-text.list

更新 apt 源并安装 Sublime Text:

sudo apt-get update
sudo apt-get install sublime-text

pacman

安装 GPG 公钥:

curl -O https://download.sublimetext.com/sublimehq-pub.gpg && sudo pacman-key --add sublimehq-pub.gpg && sudo pacman-key --lsign-key 8A8F901A && rm sublimehq-pub.gpg

选择要使用的频道:

Stable

echo -e "\n[sublime-text]\nServer = https://download.sublimetext.com/arch/stable/x86_64" | sudo tee -a /etc/pacman.conf

Dev

echo -e "\n[sublime-text]\nServer = https://download.sublimetext.com/arch/dev/x86_64" | sudo tee -a /etc/pacman.conf

更新 pacman 并安装 Sublime Text:

sudo pacman -Syu sublime-text

yum

安装 GPG 公钥:

sudo rpm -v --import https://download.sublimetext.com/sublimehq-rpm-pub.gpg

选择要使用的频道:

Stable

sudo yum-config-manager --add-repo https://download.sublimetext.com/rpm/stable/x86_64/sublime-text.repo

Dev

sudo yum-config-manager --add-repo https://download.sublimetext.com/rpm/dev/x86_64/sublime-text.repo

更新 yum 并安装 Sublime Text:

sudo yum install sublime-text

dnf

安装 GPG 公钥:

sudo rpm -v --import https://download.sublimetext.com/sublimehq-rpm-pub.gpg

选择要使用的频道:

Stable

sudo dnf config-manager --add-repo https://download.sublimetext.com/rpm/stable/x86_64/sublime-text.repo

Dev

sudo dnf config-manager --add-repo https://download.sublimetext.com/rpm/dev/x86_64/sublime-text.repo

更新 dnf 并安装 Sublime Text:

sudo dnf install sublime-text

zypper

安装 GPG 公钥:

sudo rpm -v --import https://download.sublimetext.com/sublimehq-rpm-pub.gpg

选择要使用的频道:

Stable

sudo zypper addrepo -g -f https://download.sublimetext.com/rpm/stable/x86_64/sublime-text.repo

Dev

sudo zypper addrepo -g -f https://download.sublimetext.com/rpm/dev/x86_64/sublime-text.repo

更新zypper 并安装 Sublime Text:

sudo zypper install sublime-text

购买

需要说明的是,Sublime Text 不是自由软件,也不是免费软件,而是试用软件,虽然你可以一直试用下去,但是其是需要购买的。单个许可证的费用是 $80 美金

介绍

想在笔记本电脑上尝试 MongoDB?只需执行一个命令,你就会有一个轻量级的、独立的沙箱。完成后可以删除你所做的所有痕迹。

想在多个环境中使用相同的 程序栈 application stack 副本?构建你自己的容器镜像,让你的开发、测试、运维和支持团队使用相同的环境克隆。

容器正在彻底改变整个软件生命周期:从最早的技术性实验和概念证明,贯穿了开发、测试、部署和支持。

编排工具用来管理如何创建、升级多个容器,并使之高可用。编排还控制容器如何连接,以从多个微服务容器构建复杂的应用程序。

丰富的功能、简单的工具和强大的 API 使容器和编排功能成为 DevOps 团队的首选,将其集成到连续集成(CI) 和连续交付 (CD) 的工作流程中。

这篇文章探讨了在容器中运行和编排 MongoDB 时遇到的额外挑战,并说明了如何克服这些挑战。

MongoDB 的注意事项

使用容器和编排运行 MongoDB 有一些额外的注意事项:

  • MongoDB 数据库节点是有状态的。如果容器发生故障并被重新编排,数据则会丢失(能够从副本集的其他节点恢复,但这需要时间),这是不合需要的。为了解决这个问题,可以使用诸如 Kubernetes 中的 数据卷 volume 抽象等功能来将容器中临时的 MongoDB 数据目录映射到持久位置,以便数据在容器故障和重新编排过程中存留。
  • 一个副本集中的 MongoDB 数据库节点必须能够相互通信 - 包括重新编排后。副本集中的所有节点必须知道其所有对等节点的地址,但是当重新编排容器时,可能会使用不同的 IP 地址重新启动。例如,Kubernetes Pod 中的所有容器共享一个 IP 地址,当重新编排 pod 时,IP 地址会发生变化。使用 Kubernetes,可以通过将 Kubernetes 服务与每个 MongoDB 节点相关联来处理,该节点使用 Kubernetes DNS 服务提供“主机名”,以保持服务在重新编排中保持不变。
  • 一旦每个单独的 MongoDB 节点运行起来(每个都在自己的容器中),则必须初始化副本集,并添加每个节点到其中。这可能需要在编排工具之外提供一些额外的处理。具体来说,必须使用目标副本集中的一个 MongoDB 节点来执行 rs.initiaters.add 命令。
  • 如果编排框架提供了容器的自动化重新编排(如 Kubernetes),那么这将增加 MongoDB 的弹性,因为这可以自动重新创建失败的副本集成员,从而在没有人为干预的情况下恢复完全的冗余级别。
  • 应该注意的是,虽然编排框架可能监控容器的状态,但是不太可能监视容器内运行的应用程序或备份其数据。这意味着使用 MongoDB Enterprise AdvancedMongoDB Professional 中包含的 MongoDB Cloud Manager 等强大的监控和备份解决方案非常重要。可以考虑创建自己的镜像,其中包含你首选的 MongoDB 版本和 MongoDB Automation Agent

使用 Docker 和 Kubernetes 实现 MongoDB 副本集

如上节所述,分布式数据库(如 MongoDB)在使用编排框架(如 Kubernetes)进行部署时,需要稍加注意。本节将介绍详细介绍如何实现。

我们首先在单个 Kubernetes 集群中创建整个 MongoDB 副本集(通常在一个数据中心内,这显然不能提供地理冗余)。实际上,很少有必要改变成跨多个集群运行,这些步骤将在后面描述。

副本集的每个成员将作为自己的 pod 运行,并提供一个公开 IP 地址和端口的服务。这个“固定”的 IP 地址非常重要,因为外部应用程序和其他副本集成员都可以依赖于它在重新编排 pod 的情况下保持不变。

下图说明了其中一个 pod 以及相关的复制控制器和服务。

图 1:MongoDB 副本集成员被配置为 Kubernetes Pod 并作为服务公开

逐步介绍该配置中描述的资源:

  • 从核心开始,有一个名为 mongo-node1 的容器。mongo-node1 包含一个名为 mongo 的镜像,这是一个在 Docker Hub 上托管的一个公开可用的 MongoDB 容器镜像。容器在集群中暴露端口 27107
  • Kubernetes 的数据卷功能用于将连接器中的 /data/db 目录映射到名为 mongo-persistent-storage1 的永久存储上,这又被映射到在 Google Cloud 中创建的名为 mongodb-disk1 的磁盘中。这是 MongoDB 存储其数据的地方,这样它可以在容器重新编排后保留。
  • 容器保存在一个 pod 中,该 pod 中有标签命名为 mongo-node,并提供一个名为 rod 的(任意)示例。
  • 配置 mongo-node1 复制控制器以确保 mongo-node1 pod 的单个实例始终运行。
  • 名为 mongo-svc-a负载均衡 服务给外部开放了一个 IP 地址以及 27017 端口,它被映射到容器相同的端口号上。该服务使用选择器来匹配 pod 标签来确定正确的 pod。外部 IP 地址和端口将用于应用程序以及副本集成员之间的通信。每个容器也有本地 IP 地址,但是当容器移动或重新启动时,这些 IP 地址会变化,因此不会用于副本集。

下一个图显示了副本集的第二个成员的配置。

图 2:第二个 MongoDB 副本集成员配置为 Kubernetes Pod

90% 的配置是一样的,只有这些变化:

  • 磁盘和卷名必须是唯一的,因此使用的是 mongodb-disk2mongo-persistent-storage2
  • Pod 被分配了一个 instance: janename: mongo-node2 的标签,以便新的服务可以使用选择器与图 1 所示的 rod Pod 相区分。
  • 复制控制器命名为 mongo-rc2
  • 该服务名为mongo-svc-b,并获得了一个唯一的外部 IP 地址(在这种情况下,Kubernetes 分配了 104.1.4.5

第三个副本成员的配置遵循相同的模式,下图展示了完整的副本集:

图 3:配置为 Kubernetes 服务的完整副本集成员

请注意,即使在三个或更多节点的 Kubernetes 群集上运行图 3 所示的配置,Kubernetes 可能(并且经常会)在同一主机上编排两个或多个 MongoDB 副本集成员。这是因为 Kubernetes 将三个 pod 视为属于三个独立的服务。

为了在区域内增加冗余,可以创建一个附加的 headless 服务。新服务不向外界提供任何功能(甚至不会有 IP 地址),但是它可以让 Kubernetes 通知三个 MongoDB pod 形成一个服务,所以 Kubernetes 会尝试在不同的节点上编排它们。

图 4:避免同一 MongoDB 副本集成员的 Headless 服务

配置和启动 MongoDB 副本集所需的实际配置文件和命令可以在白皮书《启用微服务:阐述容器和编排》中找到。特别的是,需要一些本文中描述的特殊步骤来将三个 MongoDB 实例组合成具备功能的、健壮的副本集。

多个可用区 MongoDB 副本集

上面创建的副本集存在风险,因为所有内容都在相同的 GCE 集群中运行,因此都在相同的 可用区 availability zone 中。如果有一个重大事件使可用区离线,那么 MongoDB 副本集将不可用。如果需要地理冗余,则三个 pod 应该在三个不同的可用区或地区中运行。

令人惊奇的是,为了创建在三个区域之间分割的类似的副本集(需要三个集群),几乎不需要改变。每个集群都需要自己的 Kubernetes YAML 文件,该文件仅为该副本集中的一个成员定义了 pod、复制控制器和服务。那么为每个区域创建一个集群,永久存储和 MongoDB 节点是一件很简单的事情。

图 5:在多个可用区域上运行的副本集

下一步

要了解有关容器和编排的更多信息 - 所涉及的技术和所提供的业务优势 - 请阅读白皮书《启用微服务:阐述容器和编排》。该文件提供了获取本文中描述的副本集,并在 Google Container Engine 中的 Docker 和 Kubernetes 上运行的完整的说明。


作者简介:

Andrew 是 MongoDB 的产品营销总经理。他在去年夏天离开 Oracle 加入 MongoDB,在 Oracle 他花了 6 年多的时间在产品管理上,专注于高可用性。他可以通过 @andrewmorgan 或者在他的博客(clusterdb.com)评论联系他。


via: https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes

作者:Andrew Morgan 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

我们最近探讨了那些世界银行定义为高收入的富裕国家是如何倾向于使用与世界上其它地区不同的技术。这其中我们看到的最大的差异在于 Python 编程语言。就高收入国家而言,Python 的增长甚至要比 Stack Overflow Trends 等工具展现的或其他针对全球的软件开发的排名更高。

在本文中,我们将探讨在过去五年中 Python 编程语言的非凡增长,就如在高收入国家的 Stack Overflow 流量所示那样。“增长最快”一词很难准确定义,但是我们认为 Python 确实可以称得上增长最快的主流编程语言。

这篇文章中讨论的所有数字都是针对高收入国家的。它们一般指的是美国、英国、德国、加拿大等国家的趋势,他们加起来占了 Stack Overflow 大约 64% 的流量。许多其他国家,如印度、巴西、俄罗斯和中国,也为全球软件开发生态系统做出了巨大贡献,尽管我们也将看到 Python 在这方面有所增长,但本文对这些经济体的描述较少。

值得强调的是,一种语言的用户数量并不能衡量语言的品质:我们是在描述开发人员使用的语言,但没有规定任何东西。(完全披露:我曾经主要使用 Python 编程,尽管我已经完全切换到 R 了)。

Python 在高收入国家的增长

你可以在 Stack Overflow Trends 中看到,Python 在过去几年中一直在快速增长。但是对于本文,我们将重点关注高收入国家,考虑的是问题的浏览量而不是提出的问题数量(这基本上结果是类似的,但是每个月都有所波动,特别是对于较小的标签分类)。

我们有关于 Stack Overflow 问题的查看数据可以追溯到 2011 年底,在这段时间内,我们可以研究下 Python 相对于其他五种主要编程语言的增长。(请注意,这比 Stack Overflow Trends 的时间范围更短,它可追溯到 2008 年)。这些目前是高收入国家里十大访问最高的 Stack Overflow 标签中的六个。我们没有包括的四个是 CSS、HTML、Android 和 JQuery。

2017 年 6 月,Python 是成为高收入国家里 Stack Overflow 访问量最高的标签的第一个月。这也是美国和英国最受欢迎的标签,以及几乎所有其他高收入国家的前两名(接着就是 Java 或 JavaScript)。这是特别令人印象深刻的,因为在 2012 年,它比其他 5 种语言的访问量小,比当时增长了 2.5 倍。

部分原因是因为 Java 流量的季节性。由于它在本科课程中有很多课程,Java 流量在秋季和春季会上升,夏季则下降。到年底,它会再次赶上 Python 吗?我们可以尝试用一个叫做 “STL” 的模型来预测未来两年的增长, 它将增长与季节性趋势结合起来,来预测将来的变化。

根据这个模型,Python 可能会在秋季保持领先地位或被 Java 取代(大致在模型预测的变化范围之内),但是 Python 显然会在 2018 年成为浏览最多的标签。STL 还表明,与过去两年一样,JavaScript 和 Java 在高收入国家中的流量水平将保持相似水平。

什么标签整体上增长最快?

上面只看了六个最受欢迎的编程语言。在其他重大技术中,哪些是目前在高收入国家中增长最快的技术?

我们以 2017 年至 2016 年流量的比例来定义增长率。在此分析中,我们决定仅考虑编程语言(如 Java 和 Python)和平台(如 iOS、Android、Windows 和 Linux),而不考虑像 AngularTensorFlow 这样的框架(虽然其中许多有显著的增长,可能在未来的文章中分析)。

xkcd - Fastest-Growing

由于上面这个漫画中所描述的“最快增长”定义的激励,我们将增长与平均差异图中的整体平均值进行比较。

Python 以 27% 的年增长率成为了规模大、增长快的标签。下一个类似增长的最大标签是 R。我们看到,大多数其他大型标签的流量在高收入国家中保持稳定,浏览 Android、iOS 和 PHP 则略有下降。我们以前在 Flash 之死这篇文章中审查过一些正在衰减的标签,如 Objective-C、Perl 和 Ruby。我们还注意到,在函数式编程语言中,Scala 是最大的并且不断增长的,而 F# 和 Clojure 较小并且正在衰减,Haskell 则保持稳定。

上面的图表中有一个重要的遗漏:去年,有关 TypeScript 的问题流量增长了惊人的 142%,这使得我们需要去除它以避免压扁比例尺。你还可以看到,其他一些较小的语言的增长速度与 Python 类似或更快(例如 R、Go 和 Rust),而且还有许多标签,如 Swift 和 Scala,这些标签也显示出惊人的增长。它们随着时间的流量相比 Python 如何?

像 R 和 Swift 这样的语言的发展确实令人印象深刻,而 TypeScript 在更短的时间内显示出特别快速的扩张。这些较小的语言中,有许多从很少的流量成为软件生态系统中引人注目的存在。但是如图所示,当标签开始相对较小时,显示出快速增长更容易。

请注意,我们并不是说这些语言与 Python “竞争”。相反,这只是解释了为什么我们要把它们的增长分成一个单独的类别,这些是始于较低流量的标签。Python 是一个不寻常的案例,既是 Stack Overflow 中最受欢迎的标签之一,也是增长最快的其中之一。(顺便说一下,它也在加速!自 2013 年以来,每年的增长速度都会更快)。

世界其他地区

在这篇文章中,我们一直在分析高收入国家的趋势。Python 在世界其他地区,如印度、巴西、俄罗斯和中国等国家的增长情况是否类似?

确实如此。

在高收入国家之外,Python 仍旧是增长最快的主要编程语言。它从较低的水平开始,两年后才开始增长(2014 年而不是 2012 年)。事实上,非高收入国家的 Python 同比增长率高于高收入国家。我们不会在这里研究它,但是 R (其它语言的使用与 GDP 正相关) 在这些国家也在增长。

在这篇文章中,许多关于高收入国家标签 (相对于绝对排名) 的增长和下降的结论,对世界其他地区都是正确的。两个部分增长率之间有一个 0.979 Spearman 相关性。在某些情况下,你可以看到类似于 Python 上发生的 “滞后” 现象,其中一个技术在高收入国家被广泛采用,一年或两年才能在世界其他地区扩大。(这是一个有趣的现象,这可能是未来文章的主题!)

下一次

我们不打算为任何“语言战争”提供弹药。一种语言的用户数量并不意味着它的质量,而且肯定不会让你知道哪种语言更适合某种特定情况。不过,考虑到这点,我们认为值得了解什么语言构成了开发者生态系统,以及生态系统会如何变化。

本文表明 Python 在过去五年中,特别是在高收入国家,显示出惊人的增长。在我们的下一篇文章中,我们将开始研究“为什么”。我们将按国家和行业划分增长情况,并研究有哪些其他技术与 Python 一起使用(例如,估计多少增长是由于 Python 用于 Web 开发而不是数据科学)。

在此期间,如果你使用 Python 工作,并希望你的职业生涯中进入下一阶段,那么在 Stack Overflow Jobs 上有些公司正在招聘 Python 开发


via: https://stackoverflow.blog/2017/09/06/incredible-growth-python/

作者:David Robinson 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

构建一个健壮的系统需要为故障而设计。作为 GitHub 的网站可靠性工程师(SRE),我们一直在寻求通过冗余来帮助缓解问题,今天将讨论最近我们所做的工作,以便支持你通过 DNS 来查找我们的服务器。

大型 DNS 提供商在其服务中构建了多级冗余,出现导致中断的问题时,可以采取措施来减轻其影响。最佳选择之一是把你的 区域 zone 的权威服务分割到多个服务提供商中。启用 分割权威 split authority 很简单,你只需在域名注册商配置两套或多套你区域的名称服务器,然后 DNS 请求将分割到整个列表中。但是,你必须在多个提供商之间对这些区域的记录保持同步,并且,根据具体情况这可能要么设置复杂,要么是完全手动的过程。

$ dig NS github.com. @a.gtld-servers.net.

...

;; QUESTION SECTION:
;github.com.            IN  NS

;; AUTHORITY SECTION:
github.com.     172800  IN  NS  ns4.p16.dynect.net.
github.com.     172800  IN  NS  ns-520.awsdns-01.net.
github.com.     172800  IN  NS  ns1.p16.dynect.net.
github.com.     172800  IN  NS  ns3.p16.dynect.net.
github.com.     172800  IN  NS  ns-421.awsdns-52.com.
github.com.     172800  IN  NS  ns-1283.awsdns-32.org.
github.com.     172800  IN  NS  ns2.p16.dynect.net.
github.com.     172800  IN  NS  ns-1707.awsdns-21.co.uk.

...

上面的查询是向 TLD 名称服务器 询问 github.com.NS 记录。它返回了在我们在域名注册商中配置的值,在本例中,一共有两个 DNS 服务提供商,每个四条记录。如果其中一个提供商发生中断,那么其它的仍有希望可以服务请求。我们在各个地方同步记录,并且可以安全地修改它们,而不必担心数据陈旧或状态不正确。

完整地配置分割权威的最后一部分是在两个 DNS 服务提供商中将所有名称服务器作为顶层 NS 记录添加到区域的根中。

$ dig NS github.com. @ns1.p16.dynect.net.

...

;; QUESTION SECTION:
;github.com.            IN  NS

;; ANSWER SECTION:
github.com.     551 IN  NS  ns1.p16.dynect.net.
github.com.     551 IN  NS  ns2.p16.dynect.net.
github.com.     551 IN  NS  ns-520.awsdns-01.net.
github.com.     551 IN  NS  ns3.p16.dynect.net.
github.com.     551 IN  NS  ns-421.awsdns-52.com.
github.com.     551 IN  NS  ns4.p16.dynect.net.
github.com.     551 IN  NS  ns-1283.awsdns-32.org.
github.com.     551 IN  NS  ns-1707.awsdns-21.co.uk.

在 GitHub,我们有几十个区域和数千条记录,而大多数这些区域并没有关键到需要冗余,因此我们只需要处理一部分。我们希望有能够在多个 DNS 服务提供商中保持这些记录同步的方案,并且更一般地管理内部和外部的所有 DNS 记录。所以今天我们宣布了 OctoDNS

octoDNS logo

配置

OctoDNS 能够让我们重新打造我们的 DNS 工作流程。我们的区域和记录存储在 Git 仓库的配置文件中。对它们的变更使用 GitHub 流,并像个站点一样用分支部署。我们甚至可以做个 “空” 部署来预览哪些记录将在变更中修改。配置文件是 yaml 字典,每个区域一个,它的顶层的键名是记录名称,键值是 ttl、类型和类型特定的数据。例如,当包含在区域文件 github.com.yaml 中时,以下配置将创建 octodns.github.com.A 记录。

octodns:
  type: A
  values:
    - 1.2.3.4
    - 1.2.3.5

配置的第二部分将记录数据的源映射到 DNS 服务提供商。下面的代码片段告诉 OctoDNS 从 config 提供程序加载区域 github.com,并将其结果同步到 dynroute53

zones:
  github.com.:
    sources:
      - config
    targets:
      - dyn
      - route53

同步

一旦我们的配置完成,OctoDNS 就可以评估当前的状态,并建立一个计划,其中列出将需要将目标状态与源相匹配的一组更改。在下面的例子中,octodns.github.com 是一个新的记录,所以所需的操作是在两者中创建记录。

$ octodns-sync --config-file=./config/production.yaml
...
********************************************************************************
* github.com.
********************************************************************************
* route53 (Route53Provider)
*   Create <ARecord A 60, octodns.github.com., [u'1.2.3.4', '1.2.3.5']>
*   Summary: Creates=1, Updates=0, Deletes=0, Existing Records=0
* dyn (DynProvider)
*   Create <ARecord A 60, octodns.github.com., [u'1.2.3.4', '1.2.3.5']>
*   Summary: Creates=1, Updates=0, Deletes=0, Existing Records=0
********************************************************************************
...

默认情况下 octodns-sync 处于模拟运行模式,因此不会采取任何行动。一旦我们审阅了变更,并对它们感到满意,我们可以添加 `--doit' 标志并再次运行命令。OctoDNS 将继续它的处理流程,这一次将在 Route53 和 Dynect 中进行必要的更改,以便创建新的记录。

$ octodns-sync --config-file=./config/production.yaml --doit
...

此刻,在两个 DNS 服务提供商里我们有了相同的数据记录,并可以轻松地分割我们的 DNS 请求给它们,并知道它们将提供准确的结果。当我们直接运行上面的 OctoDNS 命令时,我们的内部工作流程依赖于部署脚本和 chatops。你可以在 README 的工作流程部分中找到更多信息。

总结

我们认为大多数网站可以从分割权威中受益,并且希望用 OctoDNS,其中最大的障碍已被扫除。即使对分割权威不感兴趣,OctoDNS 仍然值得一看,因为它将基础设施即代码的好处带给了 DNS。

想帮助 GitHub SRE 团队解决有趣的问题吗?我们很乐意加入我们。在这里申请


via: https://githubengineering.com/enabling-split-authority-dns-with-octodns/

作者:Ross McFarland 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

如果你想使用 Headless Chrome 进行自动化测试,那么就往下!这篇文章将让你完全使用 Karma 作为 运行器 runner ,并且使用 Mocha+Chai 来编撰测试。

这些东西是什么?

Karma、Mocha、Chai、Headless Chrome,哦,我的天哪!

Karma 是一个测试工具,可以和所有最流行的测试框架(JasmineMochaQUnit)配合使用。

Chai 是一个断言库,可以与 Node 和浏览器一起使用。这里我们需要后者。

Headless Chrome 是一种在没有浏览器用户界面的无需显示环境中运行 Chrome 浏览器的方法。使用 Headless Chrome(而不是直接在 Node 中测试) 的一个好处是 JavaScript 测试将在与你的网站用户相同的环境中执行。Headless Chrome 为你提供了真正的浏览器环境,却没有运行完整版本的 Chrome 一样的内存开销。

设置

安装

使用 yarn 安装 Karma、相关插件和测试用例:

yarn add --dev karma karma-chrome-launcher karma-mocha karma-chai
yarn add --dev mocha chai

或者使用 npm

npm i --save-dev karma karma-chrome-launcher karma-mocha karma-chai
npm i --save-dev mocha chai

在这篇文章中我使用 MochaChai,但是你也可以选择自己最喜欢的在浏览器中工作的断言库。

配置 Karma

创建一个使用 ChromeHeadless 启动器的 karma.config.js 文件。

karma.conf.js

module.exports = function(config) {
  config.set({
    frameworks: ['mocha', 'chai'],
    files: ['test/**/*.js'],
    reporters: ['progress'],
    port: 9876,  // karma web server port
    colors: true,
    logLevel: config.LOG_INFO,
    browsers: ['ChromeHeadless'],
    autoWatch: false,
    // singleRun: false, // Karma captures browsers, runs the tests and exits
    concurrency: Infinity
  })
}
注意: 运行 ./node_modules/karma/bin/karma init karma.conf.js 生成 Karma 的配置文件。

写一个测试

/test/test.js 中写一个测试:

/test/test.js

describe('Array', () => {
  describe('#indexOf()', () => {
    it('should return -1 when the value is not present', () => {
      assert.equal(-1, [1,2,3].indexOf(4));
    });
  });
});

运行你的测试

在我们设置好用于运行 Karma 的 package.json 中添加一个测试脚本。

package.json

"scripts": {
  "test": "karma start --single-run --browsers ChromeHeadless karma.conf.js"
}

当你运行你的测试(yarn test)时,Headless Chrome 会启动并将运行结果输出到终端:

创建你自己的 Headless Chrome 启动器

ChromeHeadless 启动器非常棒,因为它可以在 Headless Chrome 上进行测试。它包含了适合你的 Chrome 标志,并在端口 9222 上启动 Chrome 的远程调试版本。

但是,有时你可能希望将自定义的标志传递给 Chrome 或更改启动器使用的远程调试端口。要做到这一点,可以通过创建一个 customLaunchers 字段来扩展基础的 ChromeHeadless 启动器:

karma.conf.js

module.exports = function(config) {
  ...

  config.set({
    browsers: ['Chrome', 'ChromeHeadless', 'MyHeadlessChrome'],

    customLaunchers: {
      MyHeadlessChrome: {
        base: 'ChromeHeadless',
        flags: ['--disable-translate', '--disable-extensions', '--remote-debugging-port=9223']
      }
    },
  }
};

完全在 Travis CI 上运行它

在 Headless Chrome 中配置 Karma 运行测试是很困难的。而在 Travis 中持续集成就只有几种!

要在 Travis 中运行测试,请使用 dist: trusty 并安装稳定版 Chrome 插件:

.travis.yml

language: node_js
node_js:
  - "7"
dist: trusty # needs Ubuntu Trusty
sudo: false  # no need for virtualization.
addons:
  chrome: stable # have Travis install chrome stable.
cache:
  yarn: true
  directories:
    - node_modules
install:
  - yarn
script:
  - yarn test

作者简介

Eric Bidelman 谷歌工程师,Lighthouse 开发,Web 和 Web 组件开发,Chrome 开发


via: https://developers.google.com/web/updates/2017/06/headless-karma-mocha-chai

作者:Eric Bidelman 译者:firmianay 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Kubernetes,简称 k8s(k,8 个字符,s——明白了?)或者 “kube”,是一个开源的 Linux 容器自动化运维平台,它消除了容器化应用程序在部署、伸缩时涉及到的许多手动操作。换句话说,你可以将多台主机组合成集群来运行 Linux 容器,而 Kubernetes 可以帮助你简单高效地管理那些集群。构成这些集群的主机还可以跨越公有云私有云以及混合云。

Kubernetes 最开始是由 Google 的工程师设计开发的。Google 作为 Linux 容器技术的早期贡献者之一,曾公开演讲介绍 Google 如何将一切都运行于容器之中(这是 Google 的云服务背后的技术)。Google 一周内的容器部署超过 20 亿次,全部的工作都由内部平台 Borg 支撑。Borg 是 Kubernetes 的前身,几年来开发 Borg 的经验教训也成了影响 Kubernetes 中许多技术的主要因素。

趣闻: Kubernetes logo 中的七个辐条来源于项目原先的名称, “Seven of Nine 项目”(LCTT 译注:Borg 是「星际迷航」中的一个宇宙种族,Seven of Nine 是该种族的一名女性角色)。

红帽作为最早与 Google 合作开发 Kubernetes 的公司之一(甚至早于 Kubernetes 的发行),已经是 Kubernetes 上游项目的第二大贡献者。Google 在 2015 年把 Kubernetes 项目捐献给了新成立的 云计算基金会 Cloud Native Computing Foundation (CNCF)。

为什么你需要 Kubernetes ?

真实的生产环境应用会包含多个容器,而这些容器还很可能会跨越多个服务器主机部署。Kubernetes 提供了为那些工作负载大规模部署容器的编排与管理能力。Kubernetes 编排让你能够构建多容器的应用服务,在集群上调度或伸缩这些容器,以及管理它们随时间变化的健康状态。

Kubernetes 也需要与网络、存储、安全、监控等其它服务集成才能提供综合性的容器基础设施。

 title=

当然,这取决于你如何在你的环境中使用容器。一个初步的 Linux 容器应用程序把容器视作高效、快速的虚拟机。一旦把它部署到生产环境或者扩展为多个应用,很显然你需要许多组托管在相同位置的容器合作提供某个单一的服务。随着这些容器的累积,你的运行环境中容器的数量会急剧增加,复杂度也随之增长。

Kubernetes 通过将容器分类组成 “pod” 来解决了容器增殖带来的许多常见问题。pod 为容器分组提供了一层抽象,以此协助你调度工作负载以及为这些容器提供类似网络与存储这类必要的服务。Kubernetes 的其它组件帮助你对 pod 进行负载均衡,以保证有合适数量的容器支撑你的工作负载。

正确实施的 Kubernetes,结合类似 Atomic RegistryOpen vSwitchheapsterOAuthSELinux 的开源项目,让你可以管理你自己的整个容器基础设施。

Kubernetes 能做些什么?

在生产环境中使用 Kubernetes 的主要优势在于它提供了在物理机或虚拟机集群上调度和运行容器的平台。更宽泛地说,它能帮你在生产环境中实现可以依赖的基于容器的基础设施。而且,由于 Kubernetes 本质上就是运维任务的自动化平台,你可以执行一些其它应用程序平台或管理系统支持的操作,只不过操作对象变成了容器。

有了 Kubernetes,你可以:

  • 跨主机编排容器。
  • 更充分地利用硬件资源来最大化地满足企业应用的需求。
  • 控制与自动化应用的部署与升级。
  • 为有状态的应用程序挂载和添加存储器。
  • 线上扩展或裁剪容器化应用程序与它们的资源。
  • 声明式的容器管理,保证所部署的应用按照我们部署的方式运作。
  • 通过自动布局、自动重启、自动复制、自动伸缩实现应用的状态检查与自我修复。

然而 Kubernetes 依赖其它项目来提供完整的编排服务。结合其它开源项目作为其组件,你才能充分感受到 Kubernetes 的能力。这些必要组件包括:

  • 仓库:Atomic Registry、Docker Registry 等。
  • 网络:OpenvSwitch 和智能边缘路由等。
  • 监控:heapster、kibana、hawkular 和 elastic。
  • 安全:LDAP、SELinux、 RBAC 与 支持多租户的 OAUTH。
  • 自动化:通过 Ansible 的 playbook 进行集群的安装和生命周期管理。
  • 服务:大量事先创建好的常用应用模板。

红帽 OpenShift 为容器部署预先集成了上面这些组件。

Kubernetes 入门

和其它技术一样,大量的专有名词有可能成为入门的障碍。下面解释一些通用的术语,希望帮助你理解 Kubernetes。

  • Master(主节点): 控制 Kubernetes 节点的机器,也是创建作业任务的地方。
  • Node(节点): 这些机器在 Kubernetes 主节点的控制下执行被分配的任务。
  • Pod: 由一个或多个容器构成的集合,作为一个整体被部署到一个单一节点。同一个 pod 中的容器共享 IP 地址、进程间通讯(IPC)、主机名以及其它资源。Pod 将底层容器的网络和存储抽象出来,使得集群内的容器迁移更为便捷。
  • Replication controller(复制控制器): 控制一个 pod 在集群上运行的实例数量。
  • Service(服务): 将服务内容与具体的 pod 分离。Kubernetes 服务代理负责自动将服务请求分发到正确的 pod 处,不管 pod 移动到集群中的什么位置,甚至可以被替换掉。
  • Kubelet: 这个守护进程运行在各个工作节点上,负责获取容器列表,保证被声明的容器已经启动并且正常运行。
  • kubectl: 这是 Kubernetes 的命令行配置工具。

上面这些知识就足够了吗?不,这仅仅是一小部分,更多内容请查看 Kubernetes 术语表。

生产环境中使用 Kubernetes

Kubernetes 是开源的,所以没有正式的技术支持机构为你的商业业务提供支持。如果在生产环境使用 Kubernetes 时遇到问题,你恐怕不会太愉快,当然你的客户也不会太高兴。

这就是红帽 OpenShift 要解决的问题。OpenShift 是为企业提供的 Kubernetes ——并且集成了更多的组件。OpenShift 包含了强化 Kubernetes 功能、使其更适用于企业场景的额外部件,包括仓库、网络、监控、安全、自动化和服务在内。OpenShift 使得开发者能够在具有伸缩性、控制和编排能力的云端开发、托管和部署容器化的应用,快速便捷地把想法转变为业务。

而且,OpenShift 还是由头号开源领导公司红帽支持和开发的。

Kubernetes 如何适用于你的基础设施

 title=

Kubernetes 运行在操作系统(例如 Red Hat Enterprise Linux Atomic Host)之上,操作着该节点上运行的容器。Kubernetes 主节点(master)从管理员(或者 DevOps 团队)处接受命令,再把指令转交给附属的节点。这种带有大量服务的切换工作自动决定最适合该任务的节点,然后在该节点上分配资源并指派 pod 来完成任务请求。

所以从基础设施的角度,管理容器的方式发生了一点小小的变化。对容器的控制在更高的层次进行,提供了更佳的控制方式,而无需用户微观管理每个单独的容器或者节点。必要的工作则主要集中在如何指派 Kubernetes 主节点、定义节点和 pod 等问题上。

docker 在 Kubernetes 中的角色

Docker 技术依然执行它原本的任务。当 kubernetes 把 pod 调度到节点上,节点上的 kubelet 会指示 docker 启动特定的容器。接着,kubelet 会通过 docker 持续地收集容器的信息,然后提交到主节点上。Docker 如往常一样拉取容器镜像、启动或停止容器。不同点仅仅在于这是由自动化系统控制而非管理员在每个节点上手动操作的。


via: https://www.redhat.com/en/containers/what-is-kubernetes

作者:www.redhat.com 译者:haoqixu 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出