标签 编排 下的文章

Swarm,听起来像是一个朋克摇滚乐队。但它确实是个新的编排机制,抑或者是,一个 Docker 现有编排体制的改进。简单来讲,如果你在用一个旧版本的 Docker,你必须手动配置 Swarm 来创建 Docker 集群。从 1.12 版开始,Docker 引擎集成了一个原生的实现(LCTT 译注:见下文)来支持无缝的集群设置。也就是为什么会有这篇文章。

在这篇教程中,我将带你体验一下编排后的 Docker 将能做的事情。这篇文章并不是包含所有细节(如 BnB 一般)或是让你对其全知全能,但它能带你踏上你的集群之路。在我的带领下开始吧。

Teaser

技术概要

如果把 Docker 详细而又好用的文档照搬到这里那将太丢人了,所以我将简要概括下这个技术的概要。我们已经有了 Docker,对吧。现在,你想要更多的服务器作为 Docker 主机,但同时你希望它们属于同一个逻辑上的实体。也就是说,你想建立一个集群。

我们先从一个主机组成的集群开始。当你在一个主机上初始化一个 Swarm 集群,这台主机将成为这个集群的 管理者 manager 。从技术角度来讲,它成为了 共识组 consensus group 中的一个 节点 node 。其背后的数学逻辑建立在 Raft 算法之上。 管理者 manager 负责调度任务。而具体的任务则会委任给各个加入了 Swarm 集群的 工作者 worker 节点。这些操作将由 Node API 所管理。虽说我讨厌 API 这个词汇,但我必须在这里用到它。

Service API 是这个实现中的第二个组件。它允许 管理者 manager 节点在所有的 Swarm 集群节点上创建一个分布式的服务。这个服务可以 被复制 replicated ,也就是说它们(LCTT 译注:指这些服务)会由平衡机制被分配到集群中(LCTT 译注:指 replicated 模式,多个容器实例将会自动调度任务到集群中的一些满足条件的节点),或者可以分配给全局(LCTT 译注:指 global 模式),也就是说每个节点都会运行一个容器实例。

此外还有更多的功课需要做,但这些信息已经足够你上路了。现在,我们开始整些实际的。我们的目标平台是 CentOS 7.2,有趣的是在我写这篇教程的时候,它的软件仓库中只有 1.10 版的 Docker,也就是说我必须手动更新以使用 Swarm。我们将在另一篇教程中讨论这个问题。接下来我们还有一个跟进的指南,其中涵盖了如何将新的节点加入我们现有的集群(LCTT 译注:指刚刚建立的单节点集群),并且我们将使用 Fedora 进行一个非对称的配置。至此,请确保正确的配置已经就位,并有一个工作的集群启动并正在运行(LCTT 译注:指第一个节点的 Docker 已经安装并已进入 Swarm 模式,但到这里笔者并没有介绍如何初始化 Swarm 集群,不过别担心下章会讲)。

配置镜像和服务

我将尝试配置一个负载均衡的 Apache 服务,并使用多个容器实例通过唯一的 IP 地址提供页面内容。挺标准的吧(LCTT 译注:指这个负载均衡的网页服务器)。这个例子同时也突出了你想要使用集群的大多数原因:可用性、冗余、横向扩展以及性能。当然,你同时需要考虑网络储存这两块,但它们超出了这篇指南所涉及的范围了。

这个 Dockerfile 模板其实可以在官方镜像仓库里的 httpd 下找到。你只需一个最简单的设置来起步。至于如何下载或创建自己的镜像,请参考我的入门指南,链接可以在这篇教程的顶部可以找到。

docker build -t my-apache2 .
Sending build context to Docker daemon 2.048 kB
Step 1 : FROM httpd:2.4
Trying to pull repository docker.io/library/httpd ...
2.4: Pulling from docker.io/library/httpd

8ad8b3f87b37: Pull complete
c95e1f92326d: Pull complete
96e8046a7a4e: Pull complete
00a0d292c371: Pull complete
3f7586acab34: Pull complete
Digest: sha256:3ad4d7c4f1815bd1c16788a57f81b413...a915e50a0d3a4
Status: Downloaded newer image for docker.io/httpd:2.4
 ---> fe3336dd034d
Step 2 : COPY ../public-html/ /usr/local/apache2/htdocs/
...

Image created

在你继续下面的步骤之前,你应该确保你能无错误的启动一个容器实例并能链接到这个网页服务器上(LCTT 译注:使用下面的命令)。一旦你确保你能连上,我们就可以开始着手创建一个分布式的服务。

docker run -dit --name my-running-app my-apache2

将这个 IP 地址输入浏览器,看看会出现什么。

Swarm 初始化和配置

下一步就是启动 Swarm 集群了。你将需要这些最基础的命令来开始,它们与 Docker 博客中的例子非常相似:

docker service create --name frontend --replicas 5 -p 80:80/tcp my-apache2:latest

这里我们做了什么?我们创建了一个叫做 frontent 的服务,它有五个容器实例。同时我们还将主机的 80 端口和这些容器的 80 端口相绑定。我们将使用刚刚新创建的 Apache 镜像来做这个测试。然而,当你在自己的电脑上直接键入上面的指令时,你将看到下面的错误:

docker service create --name frontend --replicas 5 -p 80:80/tcp my-apache2:latest
Error response from daemon: This node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again.

这意味着你没有将你的主机(节点)配置成一个 Swarm 管理者 manager 。你可以在这台主机上初始化 Swarm 集群或是让它加入一个现有的集群。由于我们目前还没有一个现成的集群,我们将初始化它(LCTT 译注:指初始化 Swarm 集群并使当前节点成为 manager):

docker swarm init
Swarm initialized: current node (dm58mmsczqemiikazbfyfwqpd) is now a manager.

为了向这个 Swarm 集群添加一个 工作者 worker ,请执行下面的指令:

docker swarm join \
--token SWMTKN-1-4ofd46a2nfyvrqwu8w5oeetukrbylyznxla
9srf9vxkxysj4p8-eu5d68pu5f1ci66s7w4wjps1u \
10.0.2.15:2377

为了向这个 Swarm 集群添加一个 管理者 manager ,请执行 docker swarm join-token manager 并按照指示操作。

操作后的输出不用解释已经很清楚明了。我们成功的创建了一个 Swarm 集群。新的节点们将需要正确的 令牌 token 来加入这个 Swarm 集群。如果你需要配置防火墙,你还需找到它的 IP 地址和端口(LCTT 译注:指 Docker 的 Swarm 模式通讯所需的端口,默认 2377)。此外,你还可以向 Swarm 集群中添加管理者节点。现在,重新执行刚刚的服务创建指令:

docker service create --name frontend --replicas 5 -p 80:80/tcp my-apache2:latest
6lrx1vhxsar2i50is8arh4ud1

测试连通性

现在,我们来验证下我们的服务是否真的工作了。从某些方面讲,这很像我们在 VagrantcoreOS 中做的事情那样。毕竟它们的原理几乎相同。相同指导思想的不同实现罢了(LCTT 译注:笔者观点,无法苟同)。首先需要确保 docker ps 能够给出正确的输出。你应该能看到所创建服务的多个容器副本。

docker ps
CONTAINER ID        IMAGE               COMMAND              CREATED             STATUS              PORTS              
NAMES
cda532f67d55        my-apache2:latest   "httpd-foreground"  
2 minutes ago       Up 2 minutes        80/tcp              frontend.1.2sobjfchdyucschtu2xw6ms9a
75fe6e0aa77b        my-apache2:latest   "httpd-foreground"  
2 minutes ago       Up 2 minutes        80/tcp              frontend.4.ag77qtdeby9fyvif5v6c4zcpc
3ce824d3151f        my-apache2:latest   "httpd-foreground"  
2 minutes ago       Up 2 minutes        80/tcp              frontend.2.b6fqg6sf4hkeqs86ps4zjyq65
eda01569181d        my-apache2:latest   "httpd-foreground"  
2 minutes ago       Up 2 minutes        80/tcp              frontend.5.0rmei3zeeh8usagg7fn3olsp4
497ef904e381        my-apache2:latest   "httpd-foreground"  
2 minutes ago       Up 2 minutes        80/tcp              frontend.3.7m83qsilli5dk8rncw3u10g5a

我也测试了不同的、非常规的端口,它们都能正常工作。对于你如何连接服务器和收取请求你将会有很多可配置的余地。你可以使用 localhost 或者 Docker 网络接口(笔者注:应该是指 Docker 的默认网桥 docker0,其网关为 172.17.0.1) 的 IP 地址的正确端口去访问。下面的例子使用了端口 1080:

Replicated Web service works

至此,这是一个非常粗略、简单的开始。真正的挑战是创建一个优化过的、可扩展的服务,但是它们需要一个准确的技术用例。此外,你还会用到 docker infodocker service(还有 inspectps)命令来详细了解你的集群是如何工作的。

可能会遇到的问题

你可能会在把玩 Docker 和 Swarm 时遇到一些小的问题(也许没那么小)。比如 SELinux 也许会抱怨你正在执行一些非法的操作(LCTT 译注:指在强制访问控制策略中没有权限的操作)。然而,这些错误和警告应该不会对你造成太多阻碍。

SELinux alert

  • docker service 不是一条命令(docker service is not a docker command

当你尝试执行必须的命令去创建一个 复制模式 replicated 的服务时,你可能会遇到一条错误说 docker: 'service' is not a docker command(LCTT 译注:见下面的例子)。这表示你的 Docker 版本不对(使用 -v 选项来检查)。我们将在将来的教程讨论如何修复这个问题。

docker service create --name frontend --replicas 5 -p 80:80/tcp my-apache2:latest
docker: 'service' is not a docker command.
  • docker tag 无法识别(docker tag not recognized

你也许会看到下面的错误:

docker service create -name frontend -replicas 5 -p 80:80/tcp my-apache2:latest
Error response from daemon: rpc error: code = 3 desc = ContainerSpec: "-name" is not a valid repository/tag

关于这个错误已经有多个相关的讨论帖子了。其实这个错误也许相当无辜。你也许是从浏览器粘贴的命令,在浏览器中的横线也许没被正确解析(笔者注:应该用 --name 而不是 -name)。就是这么简单的原因所导致的。

扩展阅读

关于这个话题还有很多可谈的,包含 1.12 版之前的 Swarm 集群实现(笔者注:旧的 Swarm 集群实现,下文亦作独立版本,需要 Consul 等应用提供服务发现),以及当前的 Docker 版本提供的(笔者注:新的 Swarm 集群实现,亦被称为 Docker 引擎的 Swarm 模式)。也就是说,请别偷懒花些时间阅读以下内容:

  • Docker Swarm 概述(独立版本的 Swarm 集群安装)
  • 构建一个生产环境的 Swarm 集群(独立版本安装)
  • 安装并创建一个 Docker Swarm 集群(独立版本安装)
  • Docker 引擎 Swarm 概述(对于 1.12 版)
  • Swarm 模式入门(对于 1.12 版)

总结

你总算看到这里了。到这里仍然无法保证你学到了什么,但我相信你还是会觉得这篇文章有些用的。它涵盖了一些基础的概念,以及一个 Swarm 集群模式是如何工作的以及它能做什么的概述,与此同时我们也成功的下载了并创建了我们的网页服务器的镜像,并且在之后基于它运行了多个集群式的容器实例。虽然我们目前只在单一节点做了以上实验,但是我们会在将来解释清楚(LCTT 译注:以便解释清楚多节点的 Swarm 集群操作)。并且我们解决了一些常见的问题。

我希望你能认为这篇指南足够有趣。结合着我过去所写的关于 Docker 的文章,这些文章应该能给你一个像样的解释,包括:怎么样操作镜像、网络栈、储存、以及现在的集群。就当热身吧。的确,请享受并期待在新的 Docker 教程中与你见面。我控几不住我记几啊。

祝你愉快。


via: http://www.dedoimedo.com/computers/docker-swarm-intro.html

作者:Dedoimedo 译者:Viz 校对:wxy

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

有无数的文章、讨论、以及很多社区喋喋不休地比较 Docker、Kubernetes 和 Mesos。如果你只是听信了只言片语,你可能会认为这三个开源项目正为了称霸容器界而殊死搏斗。你可能还相信从他们中选出一个如宗教信仰般神圣——真正的信徒会忠于他们的信仰,而且会烧死那些敢于考虑替代方案的异教徒。

那都是废话。

虽然所有这三种技术都使得使用容器来部署、管理和伸缩应用成为可能,但实际上它们各自解决了不同的问题,并且根植于迥异的上下文环境中。事实上,这三种被广泛采用的工具链,都是有差别的。

让我们重新审视每个项目的原始任务、技术架构,以及它们是如何相互补充和交互的,而不是纠结于比较这些快速迭代的技术之间重叠的特性。

让我们从 Docker 开始……

Docker 公司,始于名为 dotCloud 的平台即服务(PaaS)供应商。dotCloud 团队发现,在许多应用和客户之间管理依赖和二进制文件时需要付出大量的工作。因此他们将 Linux 的 cgroups 和 namespace 的一些功能合并成一个单一且易于使用的软件包,以便于应用程序可以一致地运行在任何基础设施上。这个软件包就是所谓的 Docker 镜像,它提供了如下的功能:

  • 将应用程序和依赖库封装在一个软件包(即 Docker 镜像)中,因此应用可以被一致地部署在各个环境上;
  • 提供类似 Git 的语义,例如 docker pushdocker commit 等命令让应用开发者可以快速接受这门新的技术,并将其融入到现有的工作流中;
  • 定义 Docker 镜像为不可变的层,支持不可变的基础设施。新提交的变更被分别保存为只读层,让复用镜像和追踪变更记录变得十分简单。层还通过只传输更新而不是整个镜像来节省磁盘空间和网络流量;
  • 通过实例化不可变的镜像和读写层来运行 Docker 容器,读写层可以临时地存储运行时变更,从而轻松部署和扩展应用程序的多个实例。

Docker 变得越来越受欢迎,开发者们开始从在笔记本电脑上运行容器转而在生产环境中运行容器。跨多个机器之间协调这些容器需要额外的工具,这称之为 容器编排 container orchestration 。有趣的是,第一个支持 Docker 镜像的容器编排工具(2014 年 6月)是 Apache Mesos 的 Marathon(后面会有详细介绍) 。那年,Docker 的创始人兼首席技术官 Solomon Hykes 将 Mesos 推荐为“生产集群的黄金标准”。不久之后,除了 Mesos 的 Marathon 之外,还出现了许多的容器编排技术:NomadKubernetes,不出所料还有 Docker Swarm (它如今是 Docker 引擎的一部分)。

随着 Docker 开始商业化其开源的文件格式(LCTT 译注:指 Docker 镜像的 dockerfile 文件格式),该公司还开始引入工具来完善其核心的 Docker 文件格式和运行时引擎,包括:

  • 为公开存储 Docker 镜像的而生的 Docker hub;
  • 存储私有镜像的 Docker 仓库(Docker registry);
  • Docker cloud,用于构建和运行容器的管理性服务;
  • Docker 数据中心作为一种商业产品体现了许多 Docker 技术;

Docker

来源: www.docker.com

Docker 将软件及其依赖关系封装在一个软件包中的洞察力改变了软件行业的游戏规则,正如 mp3 的出现重塑了音乐行业一般。Docker 文件格式成为行业标准,领先的容器技术供应商(包括 Docker、Google、Pivotal、Mesosphere 等) 组建了 云计算基金会 Cloud Native Computing Foundation (CNCF) 开放容器推进联盟 Open Container Initiative (OCI)。如今,CNCF 和 OCI 旨在确保容器技术之间的互操性和标准化接口,并确保使用任何工具构建的任何 Docker 容器都可以在任何运行时或基础架构上运行。

进入 Kubernetes

Google 很早就认识到了 Docker 的潜力,并试图在 Google Cloud Platform (GCP)上提供容器编排“即服务”。 Google 在容器方面拥有丰富的经验(是他们在 Linux 中引入了 cgroups),但现有的内部容器和 Borg 等分布式计算工具直接与其基础架构相耦合。所以,Google 没有使用原有系统的任何代码,而是从头开始设计 Kubernetes (K8S)来编排 Docker 容器。 Kubernetes 于 2015 年 2 月发布,其目标和考虑如下:

  • 为应用程序开发人员提供编排 Docker 容器的强大工具,而无需与底层基础设施交互;
  • 提供标准部署接口和原语,以实现云端一致的应用部署体验和 API;
  • 基于模块化 API 核心,允许供应商围绕 Kubernetes 的核心技术集成其系统。

2016 年 3 月,Google 将 Kubernetes 捐赠给了 CNCF,并且直到今天仍然是该项目的主要贡献者(其次是Redhat,CoreOS 等)。

Kubernetes

来源: wikipedia

Kubernetes 对应用程序开发人员非常有吸引力,因为它减轻了对基础架构和运营团队的依赖程度。供应商也喜欢 Kubernetes,因为它提供了一个容易的方式来拥抱容器化运动,并为客户部署自己的 Kubernetes(这仍然是一个值得重视的挑战)提供商业解决方案。 Kubernetes 也是有吸引力的,因为它是 CNCF 旗下的开源项目,与 Docker Swarm 相反,Docker Swarm 尽管是开源的,但是被 Docker 公司紧紧地掌控着。

Kubernetes 的核心优势是为应用程序开发人员提供了用于编排无状态 Docker 容器的强大工具。 虽然有多个扩大项目范围的提议,以提供更多的功能(例如分析和有状态数据服务),但这些提议仍处于非常早期的阶段,它们能取得多大的成功还有待观察。

Apache Mesos

Apache Mesos 始于 加州大学伯克利分校 UC Berkeley 的下一代容器集群管理器项目,并应用了从云计算级别的分布式基础架构(如 Google 的 BorgFacebook 的 Tupperware)中习得的经验和教训。 虽然 Borg 和 Tupperware 具有单一的架构,并且是与物理基础架构紧密结合的闭源专有技术,但 Mesos 推出了一种模块化架构,一种开源的开发方法,旨在完全独立于基础架构。Mesos 迅速被 TwitterApple(Siri 中)YelpUberNetflix 和许多领先的技术公司采用,支持从微服务、大数据和实时分析到弹性扩展的一切。

作为集群管理器,Mesos 被设计用来解决一系列不同的挑战:

  • 将数据中心资源抽象为单个池来简化资源分配,同时在私有云或公有云中提供一致的应用和运维体验;
  • 在相同的基础架构上协调多个工作负载,如分析、无状态微服务、分布式数据服务和传统应用程序,以提高利用率,降低成本和台面空间;
  • 为应用程序特定的任务(如部署、自我修复、扩展和升级),自动执行第二天的操作;提供高度可用的容错基础设施;
  • 提供持久的可扩展性来运行新的应用程序和技术,而无需修改集群管理器或其上构建的任何现有应用程序;
  • 弹性扩展可以将应用程序和底层基础设施从少量扩展到数十到数万个节点。

Mesos 独有的独立管理各种工作负载的能力 —— 包括 Java 这样的传统应用程序、无状态 Docker 微服务、批处理作业、实时分析和有状态的分布式数据服务。Mesos 广泛的工作负载覆盖来自于其两级架构,从而实现了“应用感知”调度。通过将应用程序特定的操作逻辑封装在“Mesos 框架”(类似于操作中的运行手册)中来实现应用程序感知调度。资源管理器 Mesos Master 提供了这些框架基础架构的部分,同时保持隔离。这种方法允许每个工作负载都有自己的专门构建的应用程序调度程序,可以了解其部署、扩展和升级的特定操作要求。应用程序调度程序也是独立开发、管理和更新的,这让 Mesos 拥有高度可扩展的能力,支持新的工作负载或随着时间的推移而增加更多的操作功能。

Mesos two-level scheduler

举一个团队如何管理应用软件升级的例子。无状态应用程序可以从“蓝/绿”部署方案中受益;当新版本的应用运行起来时,原先旧版本的软件依然还正常运转着,然后当旧应用被销毁时流量将会切换到新的应用上。但是升级数据工作负载例如 HDFS 或者 Cassandra 要求节点停机一次,此时需要持久化本地数据卷以防止数据丢失,并且按照特定的顺序执行原位升级,在升级之前和升级完成之后,都要在每一个节点类型上执行特定的检查和命令。任何这些步骤都是应用程序或服务特定的,甚至可能是版本特定的。这让使用常规容器编排调度程序来管理数据服务变得非常困难。

Mesos 以每一个工作负载所需的特定方式管理各种工作负载,使得许多公司将 Mesos 作为一个统一的平台,将微服务和数据服务结合在一起。数据密集型应用程序的通用参考架构是 “SMACK 家族”(LCTT 译注:SMACK 即 Spark、Mesos、Akka、Cassandra、Kafka)。

是时候搞清楚这些了

请注意,我们尚未对 Apache Mesos 的容器编排有任何描述。所以为什么人们会自动地将 Mesos 和容器编排联系起来呢?容器编排是可以在 Mesos 的模块化架构上运行的工作负载的一个例子,它是通过一个专门的编排“框架”来完成的,这个框架就 Marathon,一个构建于 Mesos 之上的工具。 Marathon 最初是为了在 cgroup 容器中编排应用归档(如 JAR、tarball、ZIP 文件)而开发的,是 2014 年最先支持 Docker 容器的编排工具之一。

所以当人们将 Docker 和 Kubernetes 与 Mesos 进行比较时,他们实际上是将 Kubernetes 和 Docker Swarm 与在 Mesos 上运行的 Marathon 进行比较。

为什么搞清楚这一点很重要? 因为 Mesos 坦率地讲并不在乎它上面运行了什么。 Mesos 可以在共享的基础设施上弹性地为 Java 应用服务器提供集群服务、Docker 容器编排、Jenkins 持续集成任务、Apache Spark 分析、Apache Kafka 流,以及更多其他的服务。Mesos 甚至可以运行 Kubernetes 或者其他的容器编排工具,即使公共的集成目前还不可用。

Mesos Workloads

来源: Apache Mesos 2016 调查问卷

Mesos 的另一个考虑因素(也是为什么它对许多企业架构师来说如此有吸引力)是运行关键任务工作负载的成熟度。 Mesos 已经在大规模生产环境下(成千上万台服务器)运行了超过 7 年的时间,这就是为什么它比市场上许多其他的容器技术更具有生产上的可行性和扩展上的可靠性。

我所说的这些什么意思?

总而言之,所有这三种技术都与 Docker 容器有关,可以让你在容器编排上实现应用程序的可移植性和扩展性。那么你在它们之间如何选择呢? 归根到底是为工作选择合适的工具(也可能是为不同的工作选择不同的工具)。如果您是一个应用开发人员,正在寻找现代化的方式来构建和打包你的应用程序,或者想加速你的微服务计划,Docker 容器和开发工具就是最好的选择。

如果你们是一个开发人员或者 DevOps 的团队,并希望构建一个专门用于 Docker 容器编排的系统,而且愿意花时间折腾集成解决方案与底层基础设施(或依靠公共云基础架构,如 Google 容器引擎(GCE)或 Azure 容器服务(ACS)),Kubernetes 是一个可以考虑的好技术。

如果你们想要建立一个运行多个关键任务工作负载的可靠平台,包括 Docker 容器、传统应用程序(例如 Java)和分布式数据服务(例如 Spark、Kafka、Cassandra、Elastic),并希望所有这些可依移植到云端提供商或者数据中心,那么 Mesos(或我们自己的 Mesos 发行版,Mesosphere DC/OS)更适合你们的需求。

无论您选择什么,您都将拥抱一套可以更有效地利用服务器资源的工具,简化应用程序的可移植性,并提高开发人员的敏捷性。你的选择真的不会有错。


via: https://mesosphere.com/blog/docker-vs-kubernetes-vs-apache-mesos/

作者:Amr Abdelrazik 译者:rieonke 校对:wxy

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