分类 技术 下的文章

1、概述

现在能够在 Windows 10 和 Windows 服务器上运行 Docker 容器了,它是以 Ubuntu 作为宿主基础的。

想象一下,使用你喜欢的 Linux 发行版——比如 Ubuntu——在 Windows 上运行你自己的 Linux 应用。

现在,借助 Docker 技术和 Windows 上的 Hyper-V 虚拟化的力量,这一切成为了可能。

2、前置需求

你需要一个 8GB 内存的 64 位 x86 PC,运行 Windows 10 或 Windows Server。

只有加入了 Windows 预览体验计划(Insider),才能运行带有 Hyper-V 支持的 Linux 容器。该计划可以让你测试预发布软件和即将发布的 Windows。

如果你特别在意稳定性和隐私(Windows 预览体验计划允许微软收集使用信息),你可以考虑等待 2017 年 10 月发布的Windows 10 Fall Creator update,这个版本可以让你无需 Windows 预览体验身份即可使用带有 Hyper-V 支持的 Docker 技术。

你也需要最新版本的 Docker,它可以从 http://dockerproject.org 下载得到。

最后,你还需要确认你安装了 XZ 工具,解压 Ubuntu 宿主容器镜像时需要它。

3、加入 Windows 预览体验计划(Insider)

如果你已经是 Windows 预览体验计划(Insider)成员,你可以跳过此步。否则在浏览器中打开如下链接:

https://insider.windows.com/zh-cn/getting-started/

要注册该计划,使用你在 Windows 10 中的微软个人账户登录,并在预览体验计划首页点击“注册”,接受条款并完成注册。

然后你需要打开 Windows 开始菜单中的“更新和安全”菜单,并在菜单左侧选择“Windows 预览体验计划”。

如果需要的话,在 Windows 提示“你的 Windows 预览体验计划账户需要关注”时,点击“修复”按钮。

4、 Windows 预览体验(Insider)的内容

从 Windows 预览体验计划面板,选择“开始使用”。如果你的微软账户没有关联到你的 Windows 10 系统,当提示时使用你要关联的账户进行登录。

然后你可以选择你希望从 Windows 预览体验计划中收到何种内容。要得到 Docker 技术所需要的 Hyper-V 隔离功能,你需要加入“快圈”,两次确认后,重启 Windows。重启后,你需要等待你的机器安装各种更新后才能进行下一步。

5、安装 Docker for Windows

Docker Store 下载 Docker for Windows。

下载完成后,安装,并在需要时重启。

重启后,Docker 就已经启动了。Docker 要求启用 Hyper-V 功能,因此它会提示你启用并重启。点击“OK”来为 Docker 启用它并重启系统。

6、下载 Ubuntu 容器镜像

Canonical 合作伙伴镜像网站下载用于 Windows 的最新的 Ubuntu 容器镜像。

下载后,使用 XZ 工具解压:

C:\Users\mathi\> .\xz.exe -d xenial-container-hyper-v.vhdx.xz
C:\Users\mathi\>

7、准备容器环境

首先创建两个目录:

创建 C:\lcow它将用于 Docker 准备容器时的临时空间。

再创建一个 C:\Program Files\Linux Containers ,这是存放 Ubuntu 容器镜像的地方。

你需要给这个目录额外的权限以允许 Docker 在其中使用镜像。在管理员权限的 Powershell 窗口中运行如下 Powershell 脚本:

param(
[string] $Root
)
# Give the virtual machines group full control
$acl = Get-Acl -Path $Root
$vmGroupRule = new-object System.Security.AccessControl.FileSystemAccessRule("NT VIRTUAL MACHINE\Virtual Machines", "FullControl","ContainerInherit,ObjectInherit", "None", "Allow")
$acl.SetAccessRule($vmGroupRule)
Set-Acl -AclObject $acl -Path $Root

将其保存为set_perms.ps1并运行它。

提示,你也许需要运行 Set-ExecutionPolicy -Scope process unrestricted 来允许运行未签名的 Powershell 脚本。

C:\Users\mathi\> .\set_perms.ps1 "C:\Program Files\Linux Containers"
C:\Users\mathi\>

现在,将上一步解压得到的 Ubuntu 容器镜像(.vhdx)复制到 C:\Program Files\Linux Containers 下的 uvm.vhdx

8、更多的 Docker 准备工作

Docker for Windows 要求一些预发布的功能才能与 Hyper-V 隔离相配合工作。这些功能在之前的 Docker CE 版本中还不可用,这些所需的文件可以从 master.dockerproject.org 下载。

master.dockerproject.org 下载 dockerd.exedocker.exe,并将其放到安全的地方,比如你自己的文件夹中。它们用于在下一步中启动 Ubuntu 容器。

9、 在 Hyper-V 上运行 Ubuntu 容器

你现在已经准备好启动你的容器了。首先以管理员身份打开命令行(cmd.exe),然后以正确的环境变量启动 dockerd.exe

C:\Users\mathi\> set LCOW_SUPPORTED=1
C:\Users\mathi\> .\dockerd.exe -D --data-root C:\lcow

然后,以管理员身份启动 Powershell 窗口,并运行 docker.exe 为你的容器拉取镜像:

C:\Users\mathi\> .\docker.exe pull ubuntu

现在你终于启动了容器,再次运行 docker.exe,让它运行这个新镜像:

C:\Users\mathi\> .\docker.exe run -it ubuntu

恭喜你!你已经成功地在 Windows 上让你的系统运行了带有 Hyper-V 隔离的容器,并且跑的是你非常喜欢的 Ubuntu 容器。

10、获取帮助

如果你需要一些 Hyper-V Ubuntu 容器的起步指导,或者你遇到一些问题,你可以在这里寻求帮助:

今天我在 libcurl 内部又做了一个小改动,使其做更少的 malloc。这一次,泛型链表函数被转换成更少的 malloc (这才是链表函数应有的方式,真的)。

研究 malloc

几周前我开始研究内存分配。这很容易,因为多年前我们 curl 中就已经有内存调试和日志记录系统了。使用 curl 的调试版本,并在我的构建目录中运行此脚本:

#!/bin/sh
export CURL_MEMDEBUG=$HOME/tmp/curlmem.log
./src/curl http://localhost
./tests/memanalyze.pl -v $HOME/tmp/curlmem.log

对于 curl 7.53.1,这大约有 115 次内存分配。这算多还是少?

内存日志非常基础。为了让你有所了解,这是一个示例片段:

MEM getinfo.c:70 free((nil))
MEM getinfo.c:73 free((nil))
MEM url.c:294 free((nil))
MEM url.c:297 strdup(0x559e7150d616) (24) = 0x559e73760f98
MEM url.c:294 free((nil))
MEM url.c:297 strdup(0x559e7150d62e) (22) = 0x559e73760fc8
MEM multi.c:302 calloc(1,480) = 0x559e73760ff8
MEM hash.c:75 malloc(224) = 0x559e737611f8
MEM hash.c:75 malloc(29152) = 0x559e737a2bc8
MEM hash.c:75 malloc(3104) = 0x559e737a9dc8

检查日志

然后,我对日志进行了更深入的研究,我意识到在相同的代码行做了许多小内存分配。我们显然有一些相当愚蠢的代码模式,我们分配一个结构体,然后将该结构添加到链表或哈希,然后该代码随后再添加另一个小结构体,如此这般,而且经常在循环中执行。(我在这里说的是我们,不是为了责怪某个人,当然大部分的责任是我自己……)

这两种分配操作将总是成对地出现,并被同时释放。我决定解决这些问题。做非常小的(小于 32 字节)的分配也是浪费的,因为非常多的数据将被用于(在 malloc 系统内)跟踪那个微小的内存区域。更不用说堆碎片了。

因此,将该哈希和链表代码修复为不使用 malloc 是快速且简单的方法,对于最简单的 “curl http://localhost” 传输,它可以消除 20% 以上的 malloc。

此时,我根据大小对所有的内存分配操作进行排序,并检查所有最小的分配操作。一个突出的部分是在 curl_multi_wait() 中,它是一个典型的在 curl 传输主循环中被反复调用的函数。对于大多数典型情况,我将其转换为使用堆栈。在大量重复的调用函数中避免 malloc 是一件好事。

重新计数

现在,如上面的脚本所示,同样的 curl localhost 命令从 curl 7.53.1 的 115 次分配操作下降到 80 个分配操作,而没有牺牲任何东西。轻松地有 26% 的改善。一点也不差!

由于我修改了 curl_multi_wait(),我也想看看它实际上是如何改进一些稍微更高级一些的传输。我使用了 multi-double.c 示例代码,添加了初始化内存记录的调用,让它使用 curl_multi_wait(),并且并行下载了这两个 URL:

http://www.example.com/
http://localhost/512M

第二个文件是 512 兆字节的零,第一个文件是一个 600 字节的公共 html 页面。这是 count-malloc.c 代码

首先,我使用 7.53.1 来测试上面的例子,并使用 memanalyze 脚本检查:

Mallocs: 33901
Reallocs: 5
Callocs: 24
Strdups: 31
Wcsdups: 0
Frees: 33956
Allocations: 33961
Maximum allocated: 160385

好了,所以它总共使用了 160KB 的内存,分配操作次数超过 33900 次。而它下载超过 512 兆字节的数据,所以它每 15KB 数据有一次 malloc。是好是坏?

回到 git master,现在是 7.54.1-DEV 的版本 - 因为我们不太确定当我们发布下一个版本时会变成哪个版本号。它可能是 7.54.1 或 7.55.0,它还尚未确定。我离题了,我再次运行相同修改的 multi-double.c 示例,再次对内存日志运行 memanalyze,报告来了:

Mallocs: 69
Reallocs: 5
Callocs: 24
Strdups: 31
Wcsdups: 0
Frees: 124
Allocations: 129
Maximum allocated: 153247

我不敢置信地反复看了两遍。发生什么了吗?为了仔细检查,我最好再运行一次。无论我运行多少次,结果还是一样的。

33961 vs 129

在典型的传输中 curl_multi_wait() 被调用了很多次,并且在传输过程中至少要正常进行一次内存分配操作,因此删除那个单一的微小分配操作对计数器有非常大的影响。正常的传输也会做一些将数据移入或移出链表和散列操作,但是它们现在也大都是无 malloc 的。简单地说:剩余的分配操作不会在传输循环中执行,所以它们的重要性不大。

以前的 curl 是当前示例分配操作数量的 263 倍。换句话说:新的是旧的分配操作数量的 0.37% 。

另外还有一点好处,新的内存分配量更少,总共减少了 7KB(4.3%)。

malloc 重要吗?

在几个 G 内存的时代里,在传输中有几个 malloc 真的对于普通人有显著的区别吗?对 512MB 数据进行的 33832 个额外的 malloc 有什么影响?

为了衡量这些变化的影响,我决定比较 localhost 的 HTTP 传输,看看是否可以看到任何速度差异。localhost 对于这个测试是很好的,因为没有网络速度限制,更快的 curl 下载也越快。服务器端也会相同的快/慢,因为我将使用相同的测试集进行这两个测试。

我相同方式构建了 curl 7.53.1 和 curl 7.54.1-DEV,并运行这个命令:

curl http://localhost/80GB -o /dev/null

下载的 80GB 的数据会尽可能快地写到空设备中。

我获得的确切数字可能不是很有用,因为它将取决于机器中的 CPU、使用的 HTTP 服务器、构建 curl 时的优化级别等,但是相对数字仍然应该是高度相关的。新代码对决旧代码!

7.54.1-DEV 反复地表现出更快 30%!我的早期版本是 2200MB/秒增加到当前版本的超过 2900 MB/秒。

这里的要点当然不是说它很容易在我的机器上使用单一内核以超过 20GB/秒的速度来进行 HTTP 传输,因为实际上很少有用户可以通过 curl 做到这样快速的传输。关键在于 curl 现在每个字节的传输使用更少的 CPU,这将使更多的 CPU 转移到系统的其余部分来执行任何需要做的事情。或者如果设备是便携式设备,那么可以省电。

关于 malloc 的成本:512MB 测试中,我使用旧代码发生了 33832 次或更多的分配。旧代码以大约 2200MB/秒的速率进行 HTTP 传输。这等于每秒 145827 次 malloc - 现在它们被消除了!600 MB/秒的改进意味着每秒钟 curl 中每个减少的 malloc 操作能额外换来多传输 4300 字节。

去掉这些 malloc 难吗?

一点也不难,非常简单。然而,有趣的是,在这个旧项目中,仍然有这样的改进空间。我有这个想法已经好几年了,我很高兴我终于花点时间来实现。感谢我们的测试套件,我可以有相当大的信心做这个“激烈的”内部变化,而不会引入太可怕的回归问题。由于我们的 API 很好地隐藏了内部,所以这种变化可以完全不改变任何旧的或新的应用程序……

(是的,我还没在版本中发布该变更,所以这还有风险,我有点后悔我的“这很容易”的声明……)

注意数字

curl 的 git 仓库从 7.53.1 到今天已经有 213 个提交。即使我没有别的想法,可能还会有一次或多次的提交,而不仅仅是内存分配对性能的影响。

还有吗?

还有其他类似的情况么?

也许。我们不会做很多性能测量或比较,所以谁知道呢,我们也许会做更多的愚蠢事情,我们可以收手并做得更好。有一个事情是我一直想做,但是从来没有做,就是添加所使用的内存/malloc 和 curl 执行速度的每日“监视” ,以便更好地跟踪我们在这些方面不知不觉的回归问题。

补遗,4/23

(关于我在 hacker news、Reddit 和其它地方读到的关于这篇文章的评论)

有些人让我再次运行那个 80GB 的下载,给出时间。我运行了三次新代码和旧代码,其运行“中值”如下:

旧代码:

real    0m36.705s
user    0m20.176s
sys     0m16.072s

新代码:

real    0m29.032s
user    0m12.196s
sys     0m12.820s

承载这个 80GB 文件的服务器是标准的 Apache 2.4.25,文件存储在 SSD 上,我的机器的 CPU 是 i7 3770K 3.50GHz 。

有些人也提到 alloca() 作为该补丁之一也是个解决方案,但是 alloca() 移植性不够,只能作为一个孤立的解决方案,这意味着如果我们要使用它的话,需要写一堆丑陋的 #ifdef


via: https://daniel.haxx.se/blog/2017/04/22/fewer-mallocs-in-curl/

作者:DANIEL STENBERG 译者:geekpi 校对:wxy

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

我们来解释函数式编程的什么,它的优点是哪些,并且给出一些函数式编程的学习资源。

 title=

这要看您问的是谁, 函数式编程 functional programming (FP)要么是一种理念先进的、应该广泛传播的程序设计方法;要么是一种偏学术性的、实际用途不多的编程方式。在这篇文章中我将讲解函数式编程,探究其优点,并推荐学习函数式编程的资源。

语法入门

本文的代码示例使用的是 Haskell 编程语言。在这篇文章中你只需要了解的基本函数语法:

even :: Int -> Bool
even = ...    -- 具体的实现放在这里

上述示例定义了含有一个参数的函数 even ,第一行是 类型声明,具体来说就是 even 函数接受一个 Int 类型的参数,返回一个 Bool 类型的值,其实现跟在后面,由一个或多个等式组成。在这里我们将忽略具体实现方法(名称和类型已经足够了):

map :: (a -> b) -> [a] -> [b]
map = ...

这个示例,map 是一个有两个参数的函数:

  1. (a -> b) :将 a 转换成 b 的函数
  2. [a]:一个 a 的列表,并返回一个 b 的列表。(LCTT 译注: 将函数作用到 [a] (List 序列对应于其它语言的数组)的每一个元素上,将每次所得结果放到另一个 [b] ,最后返回这个结果 [b]。)

同样我们不去关心要如何实现,我们只感兴趣它的定义类型。ab 是任何一种的的 类型变量 type variable 。就像上一个示例中, aInt 类型, bBool 类型:

map even [1,2,3]

这个是一个 Bool 类型的序列:

[False,True,False]

如果你看到你不理解的其他语法,不要惊慌;对语法的充分理解不是必要的。

函数式编程的误区

我们先来解释一下常见的误区:

  • 函数式编程不是命令行编程或者面向对象编程的竞争对手或对立面,这并不是非此即彼的。
  • 函数式编程不仅仅用在学术领域。这是真的,在函数式编程的历史中,如像 Haskell 和 OCaml 语言是最流行的研究语言。但是今天许多公司使用函数式编程来用于大型的系统、小型专业程序,以及种种不同场合。甚至还有一个面向函数式编程的商业用户[33的年度会议;以前的那些程序让我们了解了函数式编程在工业中的用途,以及谁在使用它。
  • 函数式编程与 monad 无关 ,也不是任何其他特殊的抽象。在这篇文章里面 monad 只是一个抽象的规定。有些是 monad,有些不是。
  • 函数式编程不是特别难学的。某些语言可能与您已经知道的语法或求值语义不同,但这些差异是浅显的。函数式编程中有大量的概念,但其他语言也是如此。

什么是函数式编程?

核心是函数式编程是只使用纯粹的数学函数编程,函数的结果仅取决于参数,而没有副作用,就像 I/O 或者状态转换这样。程序是通过 组合函数 function composition 的方法构建的:

(.) :: (b -> c) -> (a -> b) -> (a -> c)
(g . f) x = g (f x)

这个 中缀 infix 函数 (.) 表示的是二个函数组合成一个,将 g 作用到 f 上。我们将在下一个示例中看到它的使用。作为比较,我们看看在 Python 中同样的函数:

def compose(g, f):
  return lambda x: g(f(x))

函数式编程的优点在于:由于函数是确定的、没有副作用的,所以可以用结果替换函数,这种替代等价于使用使 等式推理 equational reasoning 。每个程序员都有使用自己代码和别人代码的理由,而等式推理就是解决这样问题不错的工具。来看一个示例。等你遇到这个问题:

map even . map (+1)

这段代码是做什么的?可以简化吗?通过等式推理,可以通过一系列替换来分析代码:

map even . map (+1)
map (even . (+1))         -- 来自 'map' 的定义
map (\x -> even (x + 1))  -- lambda 抽象
map odd                   -- 来自 'even' 的定义

我们可以使用等式推理来理解程序并优化可读性。Haskell 编译器使用等式推理进行多种程序优化。没有纯函数,等式推理是不可能的,或者需要程序员付出更多的努力。

函数式编程语言

你需要一种编程语言来做函数式编程吗?

在没有 高阶函数 higher-order function (传递函数作为参数和返回函数的能力)、lambdas (匿名函数)和 泛型 generics 的语言中进行有意义的函数式编程是困难的。 大多数现代语言都有这些,但在不同语言中支持函数式编程方面存在差异。 具有最佳支持的语言称为 函数式编程语言 functional programming language 。 这些包括静态类型的 HaskellOCamlF#Scala ,以及动态类型的 ErlangClojure

即使是在函数式语言里,可以在多大程度上利用函数编程有很大差异。有一个 类型系统 type system 会有很大的帮助,特别是它支持 类型推断 type inference 的话(这样你就不用总是必须键入类型)。这篇文章中没有详细介绍这部分,但足以说明,并非所有的类型系统都是平等的。

与所有语言一样,不同的函数的语言强调不同的概念、技术或用例。选择语言时,考虑它支持函数式编程的程度以及是否适合您的用例很重要。如果您使用某些非 FP 语言,你仍然会受益于在该语言支持的范围内的函数式编程。

不要打开陷阱之门

回想一下,函数的结果只取决于它的输入。但是,几乎所有的编程语言都有破坏这一原则的“功能”。空值、 实例类型 type case instanceof)、类型转换、异常、 边际效用 side-effect ,以及无尽循环的可能性都是陷阱,它打破等式推理,并削弱程序员对程序行为正确性的理解能力。(所有语言里面,没有任何陷阱的语言包括 Agda、Idris 和 Coq。)

幸运的是,作为程序员,我们可以选择避免这些陷阱,如果我们受到严格的规范,我们可以假装陷阱不存在。 这个方法叫做 轻率推理 fast and loose reasoning 。它不需要任何条件,几乎任何程序都可以在不使用陷阱的情况下进行编写,并且通过避免这些可以而获得等式推理、可组合性和可重用性。

让我们详细讨论一下。 这个陷阱破坏了等式推理,因为异常终止的可能性没有反映在类型中。(你可以庆幸文档中甚至没有提到能抛出的异常)。但是没有理由我们没有一个可以包含所有故障模式的返回类型。

避开陷阱是语言特征中出现很大差异的领域。为避免例外, 代数数据类型 algebraic data type 可用于模型错误的条件下,就像:

-- new data type for results of computations that can fail
--
data Result e a = Error e | Success a

-- new data type for three kinds of arithmetic errors
--
data ArithError = DivByZero | Overflow | Underflow

-- integer division, accounting for divide-by-zero
--
safeDiv :: Int -> Int -> Result ArithError Int
safeDiv x y =
  if y == 0
    then Error DivByZero
    else Success (div x y)

在这个例子中的权衡你现在必须使用 Result ArithError Int 类型,而不是以前的 Int 类型,但这也是解决这个问题的一种方式。你不再需要处理异常,而能够使用轻率推理 ,总体来说这是一个胜利。

自由定理

大多数现代静态类型语言具有 范型 generics (也称为 参数多态性 parametric polymorphism ),其中函数是通过一个或多个抽象类型定义的。 例如,看看这个 List(序列)函数:

f :: [a] -> [a]
f = ...

Java 中的相同函数如下所示:

static <A> List<A> f(List<A> xs) { ... }

该编译的程序证明了这个函数适用于类型 a任意选择。考虑到这一点,采用轻率推理的方法,你能够弄清楚该函数的作用吗?知道类型有什么帮助?

在这种情况下,该类型并不能告诉我们函数的功能(它可以逆转序列、删除第一个元素,或许多其它的操作),但它确实告诉了我们很多信息。只是从该类型,我们可以推演出该函数的定理:

  • 定理 1 :输出中的每个元素也出现于输入中;不可能在输入的序列 a 中添加值,因为你不知道 a 是什么,也不知道怎么构造一个。
  • 定理 2 :如果你映射某个函数到列表上,然后对其应用 f,其等同于对映射应用 f

定理 1 帮助我们了解代码的作用,定理 2 对于程序优化提供了帮助。我们从类型中学到了这一切!其结果,即从类型中获取有用的定理的能力,称之为 参数化 parametricity 。因此,类型是函数行为的部分(有时是完整的)规范,也是一种机器检查机制。

现在你可以利用参数化了。你可以从 map(.) 的类型或者下面的这些函数中发现什么呢?

  • foo :: a -> (a, a)
  • bar :: a -> a -> a
  • baz :: b -> a -> a

学习功能编程的资源

也许你已经相信函数式编程是编写软件不错的方式,你想知道如何开始?有几种学习功能编程的方法;这里有一些我推荐(我承认,我对 Haskell 偏爱):

  • UPenn 的 CIS 194: 介绍 Haskell 是函数式编程概念和 Haskell 实际开发的不错选择。有课程材料,但是没有讲座(您可以用几年前 Brisbane 函数式编程小组的 CIS 194 系列讲座
  • 不错的入门书籍有 《Scala 的函数式编程》 、 《Haskell 函数式编程思想》 , 和 《Haskell 编程原理》。
  • Data61 FP 课程 (即 NICTA 课程)通过 类型驱动开发 type-driven development 来教授基础的抽象概念和数据结构。这是十分困难,但收获也是丰富的,其起源于培训会,如果你有一名愿意引导你函数式编程的程序员,你可以尝试。
  • 在你的工作学习中使用函数式编程书写代码,写一些纯函数(避免不确定性和异常的出现),使用高阶函数和递归而不是循环,利用参数化来提高可读性和重用性。许多人从体验和实验各种语言的美妙之处,开始走上了函数式编程之旅。
  • 加入到你的地区中的一些函数式编程小组或者学习小组中,或者创建一个,也可以是参加一些函数式编程的会议(新的会议总是不断的出现)。

总结

在本文中,我讨论了函数式编程是什么以及不是什么,并了解到了函数式编程的优势,包括等式推理和参数化。我们了解到在大多数编程语言中都有一些函数式编程功能,但是语言的选择会影响受益的程度,而 Haskell 是函数式编程中语言最受欢迎的语言。我也推荐了一些学习函数式编程的资源。

函数式编程是一个丰富的领域,还有许多更深入(更神秘)的主题正在等待探索。我没有提到那些具有实际意义的事情,比如:

  • lenses 和 prisms (是一流的设置和获取值的方式;非常适合使用嵌套数据);
  • 定理证明(当你可以证明你的代码正确时,为什么还要测试你的代码?);
  • 延迟评估(让您处理潜在的无数的数据结构);
  • 分类理论(函数式编程中许多美丽实用的抽象的起源);

我希望你喜欢这个函数式编程的介绍,并且启发你走上这个有趣和实用的软件开发之路。

本文根据 CC BY 4.0 许可证发布。

(题图: opensource.com)


作者简介:

红帽软件工程师。对函数式编程,分类理论,数学感兴趣。Crazy about jalapeños.


via: https://opensource.com/article/17/4/introduction-functional-programming

作者:Fraser Tweedale 译者:MonkeyDEcho 校对:wxy

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

介绍

想在笔记本电脑上尝试 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中国 荣誉推出

构建一个健壮的系统需要为故障而设计。作为 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中国 荣誉推出