标签 Linux 下的文章

理解Unikernels

Docker, Inc在今年年初宣布收购Unikernel Systems公司时,Unikernel对大多数技术人员来说还是很陌生的。直到今天,知名问答类网站知乎上也没有以Unikernel为名字的子话题。国内搜索引擎中关于Unikernel的内容很少,实践相关的内容就更少了。Docker收购Unikernel Systems,显然不是为了将这个其未来潜在的竞争对手干掉,而是嗅到了Unikernel身上的某些技术潜质。和关注Docker一样,本博客后续将持续关注Unikernel的最新发展和优秀实践,并将一些国外的优秀资料搬(翻)移(译)过来供国内Unikernel爱好者和研究人员参考。

本文翻译自BSD Magazine2016年第3期中Russell Pavlicek的文章《Understanding Unikernels》,译文全文如下。

当我们描述一台机器(物理的或虚拟的)上的操作系统内核时,我们通常所指的是运行在特定处理器模式(内核模式)下且所使用的地址空间有别于机器上其他软件运行地址空间的一段特定的软件代码。操作系统内核通常用于提供一些关键的底层函数,这些函数被操作系统中其他软件所使用。内核通常是一段通用的代码,(有需要时)一般会被做适当裁剪以适配支持机器上的应用软件栈。这个通用的内核通常会提供各种功能丰富的函数,但很多功能和函数并不是内核支持的特定应用程序所需要的。

事实上,如果看看今天大多数机器上运行的整体软件栈,我们会发现很难弄清楚到底哪些应用程序运行在那台机器上了。你可能会发现即便没有上千,也会有成百计的低级别实用程序(译注:主要是指系统引导起来后,常驻后台的一些系统服务程序),外加许多数据库程序,一两个Web服务程序,以及一些指定的应用程序。这台机器可能实际上只承担运行一个单独的应用程序,或者它也可能被用于同时运行许多应用。通过对系统启动脚本的细致分析来确定最终运行程序的集合是一个思路,但还远非精准。因为任何一个具有适当特权的用户都可以去启动系统中已有应用程序中的任何一个。

Unikernel的不同之处

基于Unikernel的机器的覆盖面(footprint)是完全不同的。在物理机器(或虚拟机映像)中,Unikernel扮演的角色与其他内核是相似的,但实现特征显著不同。

例如,对一个基于Unikernel的机器的代码进行分析就不会受到大多数其他软件栈的模糊性的影响。当你考虑分析一个Unikernel系统时,你会发现系统中只存在一个且只有一个应用程序。那种标准的多应用程序软件栈不见了,前面提到的过多的通用实用程序和支持函数也不见了。不过裁剪并未到此打住。不仅应用软件栈被裁剪到了最低限度,操作系统功能也同样被剪裁了。例如,多用户支持、多进程支持以及高级内存管理也都不见了。

认为这很激进?想想看:如果整个独立的操作系统层也不见了呢!内核不再有独立的地址空间,应用程序也不再有独立的地址空间了。为什么?因为内核的功能函数和应用程序现在都成为了同一个程序的一部分。事实上,整个软件栈是由一个单独的软件程序构成的,这个程序负责提供应用程序所需的所有代码以及操作系统的功能函数。如果这还不够的话,只需在Unikernel中提供应用所需的那些功能函数即可,所有其他应用程序所不需要的操作系统功能函数都会被整体移除掉。

一个反映新世纪现实的软件栈

Unikernel的出现,其背后的目的在于对这个行业的彻底的反思。几十年来,在这个行业里我们的工作一直伴随着这样一个理念:机器的最好架构是基于一个通用多用户操作系统启动,加载一系列有用的实用工具程序,添加我们可能需要使用的应用程序。最后,再使用一些包管理软件来管理这种混乱的情况。

35年前,这种做法是合乎情理的。那个时候,硬件很昂贵,虚拟化的选择非常有限甚至是不可用。安全仅局限于保证计算中心坐在你身旁的人没有在偷看你输密码。一台机器需要同时处理许多用户运行的许多应用程序以保证较高的成本效益。当我还在大学(1、2千年前。 译注:作者开玩笑,强调那时的古老^_^)时,在个人计算机出现之前,学校计算机中心有一个超级昂贵的机器(以今天的标准来看) – 一台DEC PDP-11/34a,配置了248K字节的内存和25M磁盘,为全校的计算机科学、工程以及数学专业的学生使用。这台机器必须服务于几百名学生每个学期想出的每个功能。

对比计算机历史上那个远古时代的恐龙和现代的智能手机,你会发现手机拥有的计算能力高出那台机器几个数量级。这样一来,我们为什么还要用在计算机石器时代所使用的那些原则去创建机器内核映像呢?重新思考与新的计算现实相匹配的软件栈难道不是很有意义吗?

在现代世界,硬件十分便宜。虚拟化无处不在且运行效率很高。几乎所有计算设备都连接在一个巨大的、世界范围的且存在潜在恶意黑客的网络中。想想看:一台DNS服务器真的不需要上千兆的字节去完成它的工作;一台应用服务器也真的不需要为刚刚利用一个漏洞获得虚拟命令行访问权的黑客准备数千实用工具程序。 一个Web服务器并不需要验证500个不同的分时用户的命令行登录。那么为什么我们现在仍然在使用支持这些不需要的场景的过时的软件栈概念呢?

Unikernel的美丽新世界

那么一个现代软件栈应该是什么样子的呢?下面这个怎么样:单一应用映像,虚拟化的,高度安全的,超轻量的,具有超快启动速度。这些正是Unikernel所能提供的。我们逐一来说:

单一映像

叠加在一个通用内核上的数以百计的实用工具程序和大量应用程序被一个可执行体所替代。这个可执行体将所有需要的应用程序和操作系统代码放置在一个单一的映像中。它只包含它所需要的。

虚拟化的

就在几年前,你可以很幸运地在一台服务器上启动少量虚拟机。硬件的内存限制以及守旧的、吃内存的软件栈不允许你在一台服务器上同时启动太多虚机。今天我们有了配置了数千兆内存的高性能服务器,我们不再满足于每台机器仅能启动少量虚机了。如果每个虚机映像足够小,我们可以在一个服务器上同事运行数百个,甚至上千个虚机应用。

安全

在云计算时代,我们发现恶意黑客可以例行公事般入侵各地的服务器,即便是那些知名大公司和政府机构的服务器也不例外。这些违规行为常常是利用了某个网络服务的缺陷并进入了软件栈的更低层。从那开始,恶意入侵者可以利用系统中已有的实用程序或其他应用程序来实施他们的邪恶行为。在Unikernel栈中,没有其他软件可以协助这些恶意的黑客。黑客必须足够聪明才能入侵其中的应用程序,但接下来还是没有驻留的工具可以用来协助做坏事。虽然Unikernel栈不会使得软件彻底完全的变安全,但是它确能显著提升软件的安全级别。并且这是云计算时代长期未兑现的一种进步。

超轻量

一个正常的VM仅仅是为了能在网络中提供少量的服务就要占用千兆的磁盘和内存空间。若使用Unikernel,我们可以不再纠结于这些资源需求。例如,使用MirageOS(一个非常流行的Unikernel系统),我们可以构建出一个具备DNS服务功能的VM映像,其占用的磁盘空间仅仅为449K – 是的,还不到半兆。使用ClickOS,一个来自NEC实验室的网络应用Unikernel系统制作的网络设备仅仅使用6兆内存却可以成功达到每秒5百万包的处理能力。这些绝不是基于Unikernel的设备的非典型例子。鉴于Unikernels的小巧精简,在单主机服务器上启动数百或数千这类微小虚拟机的想法似乎不再遥不可及。

快速启动

普通VM的引导启动消耗较长时间。在现代硬件上启动一个完整操作系统以及软件栈直到服务上线需要花费一分钟甚至更多的时间。但是对于基于Unikernel的VM来说,这种情况却不适用。绝大多数的Unikernel VM引导启动时间少于十分之一秒。例如,ClickOS网络VM文档中记录的引导启动时间在30毫秒以下。这个速度快到足以在服务请求到达网络时再启动一个用于处理该请求的VM了(这正是Jitsu项目所要做的事情,参见http://unikernel.org/files/2015-nsdi-jitsu.pdf)。

但是,容器不已经做到这一点了吗?

在创建轻量级,快速启动的VM方面,容器已经走出了很远。但在幕后容器依然依赖着一个共享的、健壮的操作系统。从安全的角度来看,容器还有很多要锁定的地方。很明显我们需要加强我们在云中的安全,但不是去追求这些相同的、陈旧的、在云中就会快速变得漏洞百出的安全方法。除此之外,Unikernel的最终覆盖面仍然要比容器能提供的小得很多。因此容器走在了正确的方向上,而Unikernel则设法在这个未来云所需要的方向上走的更远。

Unikernels是如何工作的?

正如之前提到的,传统机器自底向上构建:你选择一个通用的操作系统内核,添加大量实用工具程序,最后添加应用程序。Unikernel正好相反:它们是自底向上构建的。聚焦在你要运行的应用程序上,恰到好处地添加使其刚好能运行的操作系统函数。大多数Unikernel系统依靠一个编译链接系统,这个系统编译应用程序源码并将应用程序所需的操作系统函数库链接进来,形成一个单独的编译映像。无需其他软件,这个映像就可以运行在VM中。

如何对结果进行调试?

由于在最终的成品中没有操作系统或实用工具程序,绝大多数Unikernel系统使用了一种分阶段的方法来开发。通常,在开发阶段一次编译会生成一个适合在Linux或类Unix操作系统上进行测试的可执行程序。这个可执行程序可以运行和被调试,就像任何一个标准程序那样。一旦你对测试结果感到满意,你可以重新编译,打开开关,创建独立运行在VM中的最终映像。

在生产环境机器上缺少调试工具并没有最初想象的那样糟糕。绝大多数组织不允许开发人员在生产机器上调试,相反,他们收集日志和其他信息,在开发平台重现失败场景,修正问题并重新部署。这个事实让调试生产映像的限制也有所缓和。在Unikernel世界中,这个操作顺序也已具备。你只需要保证你的生产环境映像可以输出足够多的日志以方便重构失败场景。你的标准应用程序可能正在做这些事情了。

有哪些可用的Unikernel系统?

现在有很多Unikernel可供选择,它们支持多种编程语言,并且Unikernel项目还在持续增加中。一些较受欢迎的Unikernel系统包括:

  • MirageOS:最早的Unikernels系统之一,它使用Ocaml语言;
  • HaLVM:另外一个早期Unikernels系统,由Haskell语言实现;
  • LING:历史悠久的项目,使用Erlang实现;
  • ClickOS:为网络应用优化的系统,支持C、C++和Python;
  • OSv:稍有不同的Unikernel系统,它基于Java,并支持其他一些编程语言。支持绝大多数JAR文件部署和运行。
  • Rumprun:使用了来自NetBSD项目的模块代码,目标定位于任何符合POSIX标准的、不需要Fork的应用程序,特别适合将现有程序移植到Unikernel世界。

Unikernel是灵丹妙药吗?

Unikernel远非万能的。由于他们是单一进程实体,运行在单一地址空间,没有高级内存管理,很多程序无法很容易地迁移到Unikernel世界。不过,运行于世界各地数据中心中的大量服务很适合该方案。将这些服务转换为轻量级Unikernel,我们可以重新分配服务器能力,任务较重的服务可以从额外的资源中受益。

转换成Unikernel的任务数量比你想象的要多。在2015年,Martin Lucina宣布成功创建了一个”RAMP”栈 – LAMP栈(Linux、Apache、MySQL和PHP/Python)的变种。RAMP栈使用了NGINX,MySQL和PHP,它们都构建在Rumprun之上。Rumprun是Rump内核的一个实例,而Rump内核则是基于NetBSD工程模块化操作系统功能函数集合的一个Unikernel系统。所以这种常见的解决方案堆栈可以成功地转化迁移到Unikernels世界中。

更多信息

要想学习更多有关Unikernels方面的内容,可以访问http://www.unikernel.org或观看2015年我在Southeast Linuxfest的演讲视频

部署devstack

新公司是一家数据与基础设施提供商(to B)。初来乍到,和这里的同事了解了一些云计算平台和大数据平台的技术栈。对于“新鲜”(only to me)的技术栈,自己总有一种折腾的冲动,于是就有了这一篇备忘性质的文章,记录一下自己部署devstack的步骤、遇到的问题和解决方法。

和诸多国内提供公有云的厂商一样,公司的云产品也是基于成熟的OpenStack云计算平台框架和组件搭建的,并做了一些定制。长久以来,我一直以为OpenStack等都是Java技术栈的,对Java技术栈出品的东西总有一种莫名的恐惧感,现在我才发现原来OpenStack是Python系(那个汗汗汗啊)。而OpenStack的另外一个竞争对手:CloudStack才是正经八百的Java系。

OpenStack是一堆云计算平台组件(诸如存储、网络、镜像管理等)的合称,十分庞大且十分复杂,入门门槛不低,即便是为开发目的而进行的OpenStack部署也会让你折腾许久,甚至始终无法搭建成功。为此OpenStack为入门者和开发者推出了一个OpenStack开发环境:devstack。通过devstack,你可以在一个主机节点上部署一个“五脏俱全”的OpenStack Cloud。

一、安装devstack

建议将devstack部署在物理机上,这样可以屏蔽掉许多在虚拟机上部署devstack的问题(具体不详,很多书籍都推荐这么做^_^)。这里讲devstack部署在一台ubuntu 14.04.1的刀片服务器上。

1、下载devstack源码

$ git clone https://github.com/openstack-dev/devstack.git ./devstack
Cloning into './devstack'...
remote: Counting objects: 33686, done.
remote: Compressing objects: 100% (10/10), done.
Receiving objects:   1% (337/33686), 92.01 KiB | 35.00 KiB/s
Receiving objects:   4% (1457/33686), 452.01 KiB | 62.00 KiB/s
... ...

这里直接用trunk上的最新revision:

devstack版本 revision:
commit 96ffde28b6e2f55f95997464aec47ae2c6cf91d3
Merge: c4a0d21 e3a04dd
Author: Jenkins <jenkins@review.openstack.org>
Date:   Tue Apr 26 10:21:16 2016 +0000

2、创建stack账户

$cd devstack/tools
~/devstack/tools$ sudo ./create-stack-user.sh
[sudo] password for baiming:
Creating a group called stack
Creating a user called stack
Giving stack user passwordless sudo privileges

$ cat /etc/passwd|grep stack
stack:x:1006:1006::/opt/stack:/bin/bash

修改devstack目录的owner和group权限:

$ sudo chown -R stack:stack ./devstack/

切换到stack用户下:

baiming@baiming:~$ sudo -i -u stack
stack@baiming:~$ cd /home/baiming/devstack
stack@baiming:/home/baiming/devstack$ ls
clean.sh  exerciserc   extras.d   functions-common  HACKING.rst  LICENSE          openrc     run_tests.sh  setup.py  tests    unstack.sh
data      exercises    files      FUTURE.rst        inc          MAINTAINERS.rst  pkg        samples       stackrc   tools
doc       exercise.sh  functions  gate              lib          Makefile         README.md  setup.cfg     stack.sh  tox.ini

二、启动devstack

我们在devstack目录下创建配置文件:local.conf

# Credentials
ADMIN_PASSWORD=devstack
MYSQL_PASSWORD=devstack
RABBIT_PASSWORD=devstack
SERVICE_PASSWORD=devstack
SERVICE_TOKEN=token
#Enable/Disable Services
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
enable_service neutron
enable_service tempest
HOST_IP=10.10.105.71

#NEUTRON CONFIG
#Q_USE_DEBUG_COMMAND=True
#CINDER CONFIG
VOLUME_BACKING_FILE_SIZE=102400M
#GENERAL CONFIG
API_RATE_LIMIT=False
# Output
LOGFILE=/home/baiming/devstack/logs/stack.sh.log
VERBOSE=True
LOG_COLOR=False
SCREEN_LOGDIR=/home/baiming/devstack/logs

执行devstack下的stack.sh来启动各OpenStack组件,stack.sh是devstack“一键安装”的总控脚本,stack.sh执行ok了,devstack也就部署OK了:

$>./stack.sh

但问题接踵而至!

三、问题与解决方法

stack.sh的执行过程是漫长的,且问题也是多多。

1、git协议 or https协议

stack.sh执行后会去openstack官方库下载一些东西,于是遇到了第一个错误:

+functions-common:git_timed:599            timeout -s SIGINT 0 git clone git://git.openstack.org/openstack/requirements.git /opt/stack/requirements
Cloning into '/opt/stack/requirements'...
fatal: unable to connect to git.openstack.org:
git.openstack.org[0: 104.130.246.128]: errno=Connection timed out
git.openstack.org[1: 2001:4800:7819:103:be76:4eff:fe06:63c]: errno=Network is unreachable

+functions-common:git_timed:602            [[ 128 -ne 124 ]]
+functions-common:git_timed:603            die 603 'git call failed: [git clone' git://git.openstack.org/openstack/requirements.git '/opt/stack/requirements]'
+functions-common:die:186                  local exitcode=0
+functions-common:die:187                  set +o xtrace
[Call Trace]
./stack.sh:708:git_clone
/home/baiming/devstack/functions-common:536:git_timed
/home/baiming/devstack/functions-common:603:die
[ERROR] /home/baiming/devstack/functions-common:603 git call failed: [git clone git://git.openstack.org/openstack/requirements.git /opt/stack/requirements]
Error on exit
./stack.sh: line 488: generate-subunit: command not found

stack.sh尝试用git clone git://xxxx,但由于我的主机在代理后面,因此git协议不能被支持,需要改为支持的协议类型,比如https。

解决方法:修改stackrc,更换git_base协议,并且增加http和https代理变量:

# Base GIT Repo URL
# Another option is https://git.openstack.org
GIT_BASE=${GIT_BASE:-https://git.openstack.org}

export http_proxy='http://10.10.126.187:3129'
export https_proxy='http://10.10.126.187:3129'

stackrc之于stack.sh类似.bashrc之于bash,在stack.sh执行时会对stackrc进行source,使其中的export环境变量生效。http_proxy等环境变量添加到stackrc中的效果就是:在stack.sh执行过程中会有类似如下语句出现:

sudo -H http_proxy=http://10.10.126.187:3129 https_proxy=http://10.10.126.187:3129 no_proxy= PIP_FIND_LINKS= /usr/local/bin/pip2.7 install -c /opt/stack/requirements/upper-constraints.txt -U virtualenv

2、重启stack.sh

解决完上述问题后,如果直接重新执行stack.sh,那么会收到“有另外一个stack.sh session在执行的”错误信息。

为此,每次重启stack.sh之前都要先执行:./unstack.sh,清理一下环境。

3、apt包下载错误

在stack.sh执行过程中,会更新ubuntu apt repository,并下载许多第三方包或工具:

Preconfiguring packages ...
(Reading database ... 123098 files and directories currently installed.)
Preparing to unpack .../libitm1_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libitm1:amd64 (4.8.4-2ubuntu1~14.04.1) over (4.8.4-2ubuntu1~14.04) ...
Preparing to unpack .../libgomp1_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libgomp1:amd64 (4.8.4-2ubuntu1~14.04.1) over (4.8.4-2ubuntu1~14.04) ...
Preparing to unpack .../libasan0_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libasan0:amd64 (4.8.4-2ubuntu1~14.04.1) over (4.8.4-2ubuntu1~14.04) ...
Preparing to unpack .../libatomic1_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libatomic1:amd64 (4.8.4-2ubuntu1~14.04.1) over (4.8.4-2ubuntu1~14.04) ...
Preparing to unpack .../libtsan0_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libtsan0:amd64 (4.8.4-2ubuntu1~14.04.1) over (4.8.4-2ubuntu1~14.04) ...
Preparing to unpack .../libquadmath0_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libquadmath0:amd64 (4.8.4-2ubuntu1~14.04.1) over (4.8.4-2ubuntu1~14.04) ...
Preparing to unpack .../libstdc++-4.8-dev_4.8.4-2ubuntu1~14.04.1_amd64.deb ...

.... ..... ....

Setting up libitm1:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Setting up libgomp1:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Setting up libasan0:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Setting up libatomic1:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Setting up libtsan0:amd64 (4.8.4-2ubuntu1~14.04.1) ...
.... .....

 * Setting sysfs variables...                  [ OK ]
Setting up vlan (1.9-3ubuntu10) ...
Processing triggers for libc-bin (2.19-0ubuntu6) ...
Processing triggers for ureadahead (0.100.0-16) ...
Processing triggers for initramfs-tools (0.103ubuntu4.2) ...
update-initramfs: Generating /boot/initrd.img-3.16.0-57-generic
.... ....

如果你的source.list中添加了一些不稳定的源,那么这个包更新过程很可能会失败,从而导致stack.sh执行失败。解决方法就是识别出哪些源导致的失败,将之注释掉!

4、MySQL access denied

继续执行stack.sh,我们遇到了如下MySQL访问错误:

+lib/databases/mysql:configure_database_mysql:91  sudo mysql -u root -p devstack -h 127.0.0.1 -e 'GRANT ALL PRIVILEGES ON *.* TO '\''root'\''@'\''%'\'' identified by '\''devstack'\'';'
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
+lib/databases/mysql:configure_database_mysql:1  exit_trap
+./stack.sh:exit_trap:474                  local r=1
++./stack.sh:exit_trap:475                  jobs -p
+./stack.sh:exit_trap:475                  jobs=
+./stack.sh:exit_trap:478                  [[ -n '' ]]
+./stack.sh:exit_trap:484                  kill_spinner
+./stack.sh:kill_spinner:370               '[' '!' -z '' ']'
+./stack.sh:exit_trap:486                  [[ 1 -ne 0 ]]
+./stack.sh:exit_trap:487                  echo 'Error on exit'
Error on exit
+./stack.sh:exit_trap:488                  generate-subunit 1461911655 5243 fail
+./stack.sh:exit_trap:489                  [[ -z /opt/stack/logs ]]
+./stack.sh:exit_trap:492                  /home/baiming/devstack/tools/worlddump.py -d /opt/stack/logs
World dumping... see /opt/stack/logs/worlddump-2016-04-29-080139.txt for details

这个问题浪费了我不少时间,遍历了许多网上资料,最终下面这个方法解决了问题:

查看/etc/mysql/debian.cnf文件:

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host     = localhost
user     = debian-sys-maint
password = WY9OFagMxMb4YmyV
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = WY9OFagMxMb4YmyV
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

修改mysql root密码:

$ [root@localhost ~]# mysql -u debian-sys-maint - p

输入密码: WY9OFagMxMb4YmyV  ,进入到mysql数据库

mysql>use mysql  ;
mysql>update user set password=password("你的新密码") where user="root";
mysql>flush privileges;
mysql>exit

然后尝试使用新密码登录,如果登录成功,说明密码修改ok。再执行stack.sh就不会出现MySQL相关错误了。

5、openvswitch/db.sock权限问题

接下来我们遇到的问题是openvswitch/db.sock权限问题,错误日志如下:

+lib/keystone:create_keystone_accounts:368  local admin_project
++lib/keystone:create_keystone_accounts:369  openstack project show admin -f value -c id
Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL.
Could not determine a suitable URL for the plugin
+lib/keystone:create_keystone_accounts:369  admin_project=
+lib/keystone:create_keystone_accounts:1   exit_trap
+./stack.sh:exit_trap:474                  local r=1
++./stack.sh:exit_trap:475                  jobs -p
+./stack.sh:exit_trap:475                  jobs=
+./stack.sh:exit_trap:478                  [[ -n '' ]]
+./stack.sh:exit_trap:484                  kill_spinner
+./stack.sh:kill_spinner:370               '[' '!' -z '' ']'
+./stack.sh:exit_trap:486                  [[ 1 -ne 0 ]]
+./stack.sh:exit_trap:487                  echo 'Error on exit'
Error on exit
+./stack.sh:exit_trap:488                  generate-subunit 1461920296 413 fail
+./stack.sh:exit_trap:489                  [[ -z /opt/stack/logs ]]
+./stack.sh:exit_trap:492                  /home/baiming/devstack/tools/worlddump.py -d /opt/stack/logs
World dumping... see /opt/stack/logs/worlddump-2016-04-29-090510.txt for details
2016-04-29T09:05:10Z|00001|reconnect|WARN|unix:/var/run/openvswitch/db.sock: connection attempt failed (Permission denied)
ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed (Permission denied)
+./stack.sh:exit_trap:498                  exit 1

我们手工执行ovs-vsctl命令:

$ sudo service openvswitch-switch status
openvswitch-switch start/running

 $ ovs-vsctl show
2016-04-29T09:44:19Z|00001|reconnect|WARN|unix:/var/run/openvswitch/db.sock: connection attempt failed (Permission denied)
ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed (Permission denied)

同样的错误。这个问题在网上似乎也没有很好的答案,这里做了一个权限更改处理:

$>chmod 777 /var/run/openvswitch/db.sock

问题解决了!

6、http proxy问题

我们接下来停在了这里:

++lib/keystone:create_keystone_accounts:369  openstack project show admin -f value -c id
Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL.
Could not determine a suitable URL for the plugin

还是停在这里,但这回不是/var/run/openvswitch /db.sock权限问题了。似乎是stack.sh想访问某个url获得一些version信息,但没有获取到。我开始怀疑是代理设置的问题:这个环境是有代理设置的,一旦走代理访问自己,那么肯定什么信息都得不到。但代理还不能去掉,因此很多组件下载都需要使用到代理访问外网。为此我们需要在stackrc中加上no_proxy环境变量:

export no_proxy='10.10.105.71'

再执行stack.sh,至少这个问题是pass了。

四、devstack部署ok

在经过很不耐烦的漫长等待后,devstack终于算是部署成功了!stack.sh打印出了下面信息后成功退出了:

=========================
DevStack Component Timing
=========================
Total runtime         2574

run_process            57
apt-get-update        120
pip_install           859
restart_apache_server  11
wait_for_service       32
apt-get                14
=========================
This is your host IP address: 10.10.105.71
This is your host IPv6 address: ::1
Horizon is now available at http://10.10.105.71/dashboard
Keystone is serving at http://10.10.105.71:5000/
The default users are: admin and demo
The password: devstack
2016-05-03 08:01:03.667 | stack.sh completed in 2574 seconds.

我们看devstack究竟运行了哪些组件:

$ ps -ef|grep python
stack     1464  1461  0 15:24 pts/5    00:00:14 /usr/bin/python /usr/bin/dstat -tcmndrylpg --output /opt/stack/logs/dstat-csv.log
stack     1465  1461  6 15:24 pts/5    00:03:01 /usr/bin/python /usr/bin/dstat -tcmndrylpg --top-cpu-adv --top-io-adv --swap
stack    11641 11490  0 15:48 pts/10   00:00:03 /usr/bin/python /usr/local/bin/glance-registry --config-file=/etc/glance/glance-registry.conf
stack    11899 11641  0 15:48 pts/10   00:00:00 /usr/bin/python /usr/local/bin/glance-registry --config-file=/etc/glance/glance-registry.conf
stack    11900 11641  0 15:48 pts/10   00:00:00 /usr/bin/python /usr/local/bin/glance-registry --config-file=/etc/glance/glance-registry.conf
stack    11978 11821  1 15:48 pts/11   00:00:24 /usr/bin/python /usr/local/bin/glance-api --config-file=/etc/glance/glance-api.conf
stack    12105 11978  1 15:48 pts/11   00:00:30 /usr/bin/python /usr/local/bin/glance-api --config-file=/etc/glance/glance-api.conf
stack    12106 11978  1 15:48 pts/11   00:00:30 /usr/bin/python /usr/local/bin/glance-api --config-file=/etc/glance/glance-api.conf
stack    13411 13262  2 15:51 pts/12   00:00:29 /usr/bin/python /usr/local/bin/nova-api
stack    13551 13411  0 15:52 pts/12   00:00:03 /usr/bin/python /usr/local/bin/nova-api
stack    13552 13411  0 15:52 pts/12   00:00:03 /usr/bin/python /usr/local/bin/nova-api
stack    13823 13411  0 15:52 pts/12   00:00:00 /usr/bin/python /usr/local/bin/nova-api
stack    13824 13411  0 15:52 pts/12   00:00:00 /usr/bin/python /usr/local/bin/nova-api
stack    14309 14159  1 15:52 pts/13   00:00:25 /usr/bin/python /usr/local/bin/nova-conductor --config-file /etc/nova/nova.conf
stack    15092 14941  3 15:52 pts/14   00:00:39 /usr/bin/python /usr/local/bin/nova-network --config-file /etc/nova/nova.conf
stack    15352 14309  2 15:52 pts/13   00:00:38 /usr/bin/python /usr/local/bin/nova-conductor --config-file /etc/nova/nova.conf
stack    15353 14309  2 15:52 pts/13   00:00:38 /usr/bin/python /usr/local/bin/nova-conductor --config-file /etc/nova/nova.conf
stack    15432 15274  1 15:52 pts/15   00:00:14 /usr/bin/python /usr/local/bin/nova-scheduler --config-file /etc/nova/nova.conf
stack    15920 15768  0 15:52 pts/16   00:00:05 /usr/bin/python /usr/local/bin/nova-novncproxy --config-file /etc/nova/nova.conf --web /opt/stack/noVNC
stack    16571 16415  1 15:52 pts/17   00:00:13 /usr/bin/python /usr/local/bin/nova-consoleauth --config-file /etc/nova/nova.conf
stack    17134 17131  3 15:53 pts/18   00:00:46 /usr/bin/python /usr/local/bin/nova-compute --config-file /etc/nova/nova.conf
stack    17890 17740  1 15:54 pts/19   00:00:23 /usr/bin/python /usr/local/bin/cinder-api --config-file /etc/cinder/cinder.conf
stack    18027 17890  0 15:54 pts/19   00:00:00 /usr/bin/python /usr/local/bin/cinder-api --config-file /etc/cinder/cinder.conf
stack    18028 17890  0 15:54 pts/19   00:00:01 /usr/bin/python /usr/local/bin/cinder-api --config-file /etc/cinder/cinder.conf
stack    18363 18212  2 15:54 pts/20   00:00:33 /usr/bin/python /usr/local/bin/cinder-scheduler --config-file /etc/cinder/cinder.conf
stack    18853 18699  1 15:54 pts/21   00:00:22 /usr/bin/python /usr/local/bin/cinder-volume --config-file /etc/cinder/cinder.conf
stack    19060 18853  2 15:54 pts/21   00:00:28 /usr/bin/python /usr/local/bin/cinder-volume --config-file /etc/cinder/cinder.conf

果然很复杂。devstack的安装体验比OpenStack似乎也好不到那里去。stack.sh执行的时间足够编译10次linux os内核了。好多依赖,好多download。

在devstack目录下,我们还可以执行一下devstack的测试,./exercise.sh会执行这些测试:

*********************************************************************
SUCCESS: End DevStack Exercise: /home/baiming/devstack/exercises/volumes.sh
*********************************************************************
=====================================================================
SKIP neutron-adv-test
SKIP swift
PASS aggregates
PASS client-args
PASS client-env
PASS sec_groups
PASS volumes
FAILED boot_from_volume
FAILED floating_ips
=====================================================================

此刻访问 http://10.10.105.71/dashboard,我们可以看到devstack horizon的首页:

img{512x368}

不过由于是通过SecureCRT端口映射访问到的主页,不知为何,登录后始终无法显示dashboard的页面。但通过后台horizon的日志来看,登录(admin/devstack)是成功的。我们仅能探索cli操作devstack的方式了。

五、CLI方式操作devstack

devstack提供了CLI方式对虚拟机、存储和网络等组件进行操作,其功能还要超过GUI所能提供的。在使用cli工具前,我们需要设置一些cli所需的用户变量,放在shell文件中(比如.bashrc):

export OS_USERNAME=admin
export OS_PASSWORD=devstack
export OS_TENANT_NAME=admin
export OS_AUTH_URL=http://10.10.105.71:5000/v2.0

上述变量生效后,我们就可以通过cli来hack devstack了:

nova位置和nova版本:

$ which nova
/usr/local/bin/nova

$ nova --version
4.0.0

当前image列表:

$ nova image-list
WARNING: Command image-list is deprecated and will be removed after Nova 15.0.0 is released. Use python-glanceclient or openstackclient instead.
+--------------------------------------+---------------------------------+--------+--------+
| ID                                   | Name                            | Status | Server |
+--------------------------------------+---------------------------------+--------+--------+
| b3f25af2-b5e1-43fe-8648-842fe48ed380 | cirros-0.3.4-x86_64-uec         | ACTIVE |        |
| d6bcc064-e2aa-4550-89e7-fd2f6a454758 | cirros-0.3.4-x86_64-uec-kernel  | ACTIVE |        |
| 788dec66-8989-4e84-8722-d9f4c9ee5ab0 | cirros-0.3.4-x86_64-uec-ramdisk | ACTIVE |        |
+--------------------------------------+---------------------------------+--------+--------+

虚拟机规格列表:

$ nova flavor-list
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name      | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| 1  | m1.tiny   | 512       | 1    | 0         |      | 1     | 1.0         | True      |
| 2  | m1.small  | 2048      | 20   | 0         |      | 1     | 1.0         | True      |
| 3  | m1.medium | 4096      | 40   | 0         |      | 2     | 1.0         | True      |
| 4  | m1.large  | 8192      | 80   | 0         |      | 4     | 1.0         | True      |
| 42 | m1.nano   | 64        | 0    | 0         |      | 1     | 1.0         | True      |
| 5  | m1.xlarge | 16384     | 160  | 0         |      | 8     | 1.0         | True      |
| 84 | m1.micro  | 128       | 0    | 0         |      | 1     | 1.0         | True      |
| c1 | cirros256 | 256       | 0    | 0         |      | 1     | 1.0         | True      |
| d1 | ds512M    | 512       | 5    | 0         |      | 1     | 1.0         | True      |
| d2 | ds1G      | 1024      | 10   | 0         |      | 1     | 1.0         | True      |
| d3 | ds2G      | 2048      | 10   | 0         |      | 2     | 1.0         | True      |
| d4 | ds4G      | 4096      | 20   | 0         |      | 4     | 1.0         | True      |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+

启动一个虚拟机:

$ nova boot --flavor 1 --image b3f25af2-b5e1-43fe-8648-842fe48ed380 devstack_instance_1
+--------------------------------------+----------------------------------------------------------------+
| Property                             | Value                                                          |
+--------------------------------------+----------------------------------------------------------------+
| OS-DCF:diskConfig                    | MANUAL                                                         |
| OS-EXT-AZ:availability_zone          |                                                                |
| OS-EXT-SRV-ATTR:host                 | -                                                              |
| OS-EXT-SRV-ATTR:hostname             | devstack-instance-1                                            |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | -                                                              |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000005                                              |
| OS-EXT-SRV-ATTR:kernel_id            | d6bcc064-e2aa-4550-89e7-fd2f6a454758                           |
| OS-EXT-SRV-ATTR:launch_index         | 0                                                              |
| OS-EXT-SRV-ATTR:ramdisk_id           | 788dec66-8989-4e84-8722-d9f4c9ee5ab0                           |
| OS-EXT-SRV-ATTR:reservation_id       | r-3rpqat0r                                                     |
| OS-EXT-SRV-ATTR:root_device_name     | -                                                              |
| OS-EXT-SRV-ATTR:user_data            | -                                                              |
| OS-EXT-STS:power_state               | 0                                                              |
| OS-EXT-STS:task_state                | scheduling                                                     |
| OS-EXT-STS:vm_state                  | building                                                       |
| OS-SRV-USG:launched_at               | -                                                              |
| OS-SRV-USG:terminated_at             | -                                                              |
| accessIPv4                           |                                                                |
| accessIPv6                           |                                                                |
| adminPass                            | dGBd6vj55vP2                                                   |
| config_drive                         |                                                                |
| created                              | 2016-05-03T09:00:33Z                                           |
| description                          | -                                                              |
| flavor                               | m1.tiny (1)                                                    |
| hostId                               |                                                                |
| host_status                          |                                                                |
| id                                   | bdb93a06-0c4f-434f-a1b5-ae2ca9293c58                           |
| image                                | cirros-0.3.4-x86_64-uec (b3f25af2-b5e1-43fe-8648-842fe48ed380) |
| key_name                             | -                                                              |
| locked                               | False                                                          |
| metadata                             | {}                                                             |
| name                                 | devstack_instance_1                                            |
| os-extended-volumes:volumes_attached | []                                                             |
| progress                             | 0                                                              |
| security_groups                      | default                                                        |
| status                               | BUILD                                                          |
| tenant_id                            | ce19134da8774d509bfa15daaca83665                               |
| updated                              | 2016-05-03T09:00:34Z                                           |
| user_id                              | 45436c9a744b4f41921edb3c368ce5f7                               |
+--------------------------------------+----------------------------------------------------------------+

通过nova list可以查看到当前主机上的虚拟机详情:

$ nova list
+--------------------------------------+---------------------+--------+------------+-------------+------------------+
| ID                                   | Name                | Status | Task State | Power State | Networks         |
+--------------------------------------+---------------------+--------+------------+-------------+------------------+
| bdb93a06-0c4f-434f-a1b5-ae2ca9293c58 | devstack_instance_1 | ACTIVE | -          | Running     | private=10.0.0.5 |
+--------------------------------------+---------------------+--------+------------+-------------+------------------+

在host上ping该虚拟机实例,可以ping通:

$ ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=0.935 ms
64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=0.982 ms
^C
--- 10.0.0.5 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.935/0.958/0.982/0.038 ms

通过网桥工具查看网桥设备,看到多出一个br100的网桥,eth0、vnet0~vnet2均连接在该网桥上:

$ brctl show
bridge name    bridge id        STP enabled    interfaces
br100        8000.0017a447a8a9    no        eth0
                            vnet0
                            vnet1
                            vnet2

挂起虚拟机:

$ nova suspend bdb93a06-0c4f-434f-a1b5-ae2ca9293c58
$ nova list
+--------------------------------------+---------------------+-----------+------------+-------------+------------------+
| ID                                   | Name                | Status    | Task State | Power State | Networks         |
+--------------------------------------+---------------------+-----------+------------+-------------+------------------+
| bdb93a06-0c4f-434f-a1b5-ae2ca9293c58 | devstack_instance_1 | SUSPENDED | -          | Shutdown    | private=10.0.0.5 |
+--------------------------------------+---------------------+-----------+------------+-------------+------------------+

六、小结

devstack号称是为开发准备的,已经“一键化”,但从实际效果来看,体验依旧不佳。由此也可以估计出OpenStack的部署难度和坎坷度了:)。

现代企业应用架构-使用Docker CaaS交付敏捷的、可移植的、受控的应用

年初,火得发烫的独角兽IT公司Docker发布了一款新的企业级产品 Docker Datacenter (简称:DDC)。作 为拥有原生Docker容器技术的公司,其每个市场动作都会让轻量级容器生态圈内的公司不敢小觑。而要揣度Docker对商业改变的理解、对容器 技术栈应用的理解以及对新产品和服务在生态圈中的定位,就有必要对Docker的这款产品做一些比较深刻的了解。而其技术白皮书 恰是我们了解 Docker该产品的入口。这里我就基于自己对容器相关技术栈的粗浅理解,翻译一下这篇篇幅不长的技术白皮书,希望能给大家带来些许帮助。

标题:现代企业应用架构-使用Docker CaaS交付敏捷的、可移植的、受控的应用

译文全文如下:

摘要

开发人员不接受被锁住的平台。就像《金发小女孩和三只熊》 故事那样,开发人员们一直在为其开发环境寻找一种可以在自由和约束之间拥 有最佳平衡的权力。在这个过程中,他们发现“平台即服务”(PaaS)模型层次太高、过于抽象以及约束过多,并且为了实现一个完全锁定的、黑盒的 环境而牺牲了灵活性;同时,他们也发现“基础设施即服务”(IaaS)模型提供的各自的容器服务也是不够的,因为那种服务仅驻留在各自的基础设施 中,缺乏远见。在寻求适当方案的过程中,一些组织开始提供基于Docker的“容器即服务”(CaaS)的环境,这种模型为开发团队提供了敏捷 性;为运维团队提供了控制力;为应用程序提供了跨基础设施的可移植性 — 从本地数据中心到公有云,横跨诸多网络和存储设备供应商。

Docker平台为基础设施无关的CaaS模型提供了一套集成套件。使用这个方案,IT运维团队既可以对基础设施,也可以对基础应用内容进行安全 保护、配置和管理;同时开发人员也能够以自助的方式来构建和部署他们的应用。

在本白皮书中,我们将讨论新软件模型的驱动力,Docker平台的能力,细化CaaS的需求,以及详细说明在构建、交付(运输)和运行应用程序过 程中解决核心问题的重要性。

重要结论包括:

• 云、数据和微服务是如何改变商业的
• 理解Docker的发展历程
• Docker CaaS模型的能力与优势

一、通过软件改变商业

运行成品软件的私有数据中心以及一年更新一次的巨大单一代码库的时代已经离我们远去了。一切都在变化。不管是迁移到云上,在云间移植,用现代化的 方法改造遗留程序,还是构建新的应用和数据结构,我们想要的结果都是相同的 – 速度。你动作的越快,你的公司将会越成功。

软件是定义你的公司的关键IP(知识产权),即便你的公司实际出售的商品可能只是一件T恤、一辆车或复利(compounding interest)。软件就是你如何接洽客户,如何吸引新用户,如何理解他们的数据,如何推广你的产品或服务以及如何处理他们的订单。

要做好这些,当今的软件正趋向定制化。为一个非常具体的工作而设计的软件片段被称为微服务(microservice)。微服务的设计目标是让 每一个由必要组件构建出来的服务在适当类型的底层基础设施资源上运行一个特定的工作(job)。接下来,这些服务松耦合在一起,可以随时被修改, 无需担心服 务运行的先后次序。

这种方法,虽然对持续改进十分有利,但在达成最终结果的过程中也提出了许多挑战。首先,它创建了一个新的、不断膨胀的服务、依赖和基础设施矩阵, 让它自身很难于管理。此外,它没有考虑到眼前大量已经存在的遗留程序,完全异构的应用程序栈以及实际中必须保证运行起来的进程。

二、Docker的发展历程以及AND的力量

2013年,Docker以具备构建、交付、到处运行的应用容器而出现在大众视野当中。与今天集装箱的运输类似,软件容器就是一个软件的标准单 元,不管容器内存放的代码和依赖是什么,容器外部看起来都相同。这使得开发人员和系统管理员可以跨基础设施和各种各样环境传输容器,而无需做任何 修改和考虑不同环境下的不同配置。Docker的历程就从此时开始了。

敏捷性: Docker的速度和简洁让Docker一经推出便大受开发者欢迎,同时也使得其开源项目的热度以流星般速度蹿升。现在开发者能很容易地将软件以及其依赖 打包到一个容器中。开发者可以使用任何语言、版本和工具,因为这些都被打包到一个容器中,容器将所有异质性标准化了,并且无需付出任何代价。

可移植性: Docker技术的本质让那批开发者意识到他们的应用容器现在可移植了,而且是以在以前不可能的方式。他们可以将应用从开发环境直接交付到测试和产品环境 且代码总是按设计那样正常工作。环境中的任何差异都不会影响到容器里面的应用。应用也无需修改就可以正常工作在生产环境中。这同样也是IT运维团 队的一个福音,因为现在他们可以跨数据中心迁移应用来避免厂商的平台锁定了。

控制: 当应用程序沿着通往生产环境的生命周期前进时,关于安全性、可管理性以及伸缩性等新问题需要进一步得到解答。Docker标准化了你的环境,同时维护着你 的业务所需的异质性。Docker提供了设置适当控制级别的能力以及维护服务级别、性能以及监管的灵活性。IT运维组能够通过供应、安全加固、监 控和伸缩基础设施和应用来保持峰值服务水平。没有两个程序或业务是一样的,Docker允许你决定如何去控制你的应用环境。

Docker成长历程的核心是AND的力量。Docker是唯一一个可以跨应用生命周期所有阶段,为开发者和IT运维团队在提供敏捷性、可移植性 和控制的方案。从这些核心原则来看,CaaS的脱颖而出正是由于由其构建的新应用又好又快。

三、Docker Containers as a Service(CaaS)

容器即服务(CaaS)是什么?它是基于基础设施和内容的一个IT受控的、安全的应用环境,利用它开发人员可以以自助的方式构建和部署应用。

img{512x368}

在上面的CaaS图示中,开发和IT运维团队通过registry相互协作。registry服务用于维护一个安全的、经过签名的映像仓库。左边 的开发者通过registry服务可以将软件拉(pull)到本地,按自己的步伐构建软件。当软件通过集成测试,开发者将其内容推回(push back)registry以保存最新版本。部署步骤因内部过程的不同而异,既可以通过工具自动进行,也可以是人工部署。

上图中右侧的IT运维组为生产环境基础设施管理着不同供应商的合同,诸如:计算、网络和存储。这些团队负责提供应用所需的计算资源,使用 Docker Universal Control Plane随时随地监控集群和应用。他们能在云间迁移应用,或伸缩服务来维持峰值服务水平。

四、关键特性和考量

Docker CaaS为组织提供了一套框架用于统一他们环境中的各种系统、语言和工具,并为业务提供所需的控制、安全或特权级别。由于是一种支持全部Docker API的Docker原生方案,Docker CaaS能够无缝地将应用从本地开发环境部署到生产环境,而无需改变代码或简化部署周期。

以下特性组成了组织应用环境的最低需求。在这个范式中,开发和运维团队被授权使用各自最佳的工具,而无需担心对系统、其他人的工作流或锁定状态造 成破坏。

1、开发者和运维的需求。 许多工具仅能解决针对一个团队的功能需求,但CaaS打破了持续改进的周期。为了获得从开发到生产环境运行的真正加速,你需要在一个连续周期内同时满足两类用户的需求。Docker为每个团队都提供了独特的能力,同时还提供了横跨整个平台的一致的API,保证了从一个团队到另外一个团队的无缝过渡。

2、应用程序生命周期的所有阶段。 从持续集成到持续交付以及开发运维(devops),这些实践都是为了消除瀑布开发方法以及其带来的滞后的周期。通过给开发和运维团队提供工具,Docker可以无缝的支持应用从构建、测试到部署到生产环境运行的所有阶段。

3、任何语言。开发者敏捷性意味着开发者在构建他们的应用的时候可以自由选择使用任何应用特性需要的编程语言、版本和工具。同时,在同一时间运行一个语言的多个版本的能力也为开发者提供了极大的灵活性。Docker让你的团队更加关注于构建应用程序本身,而不是思考如何构建一个可以在Docker中运行的应用。

4、任何操作系统。 绝大多数的组织拥有不止一款操作系统。一些工具在Linux上工作的更好,而另外一些可能在Windows上运行的更优异。应用平台需要考虑和支持这种多样性。否则,只能算是解决了部分问题而已。Docker起初是为Linux社区量身打造的,但Docker和微软公司正着手在Windows Server上实现Docker,以支持数百万现存企业应用以及未来企业应用。

5、任何基础设施。 谈到基础设施,组织想要的是选择、备份和杠杆作用。这是否意味着你需要拥有多个私有数据中心,一个混合云或者多个云提供商呢,其实关键点在于具备将应用负荷在不同环境间迁移而又不出问题的能力。Docker技术架构将基础设施与应用分离,使得应用容器可以在横跨基础设施在任意基础设施上运行。

6、Open API,插件式架构和生态系统。 一个平台不能算作是一个真正的平台,如果它只是一个封闭的孤岛。如果你想首先改良更新你现有的环境,通过实现新技术一般是不可行的。Docker的一个基本指导原则就是一个开放的平台。开放意味着API和插件可以让你利用上你已有的投资并让Docker适应你的环境和过程。开放性可以让生态系统更加活跃,且当你的CaaS增加特定功能时,它可以给你提供更多的灵活性和更多的选择。

虽然CaaS具有许多特性,但上述这些特性却是关键的,因为这种新的定制化应用范式只是为你的技术架构引入了更多异质性。Docker CaaS平台根本上就是为了支持这种多样性而设计的,并且针对任意规模提供相应的控制能力。

五、Docker CaaS

平台组件: Docker CaaS平台由一系列集成软件方案以及一个灵活的部署模型组成,以满足你的业务需求。

img{512x368}

本地数据中心/虚拟私有云(VPC): 对于那些要使用自己网络的组织,Docker Trusted Registry和Docker Universal Control Plan可以被部署在本地数据中心或虚拟私有云中,并且可以连接你已有的基础设施以及系统,比如存储、Active Directory/LDAP以及监控与日志解决方案。映像文件存储在你自己的存储架构中,Trusted Registry提供存储和管理服务能力,并且同时提供基于角色的对映像的基本访问控制。Universal Control Plane提供对Docker环境的可视化管理,包括Swarm集群、Trusted Registry仓库,容器以及多容器应用。

在云中: 对于那些接受使用SaaS方案的组织来说,Docker Hub和Docker Cloud提供了基于Docker上运行和管理的registry和control plane服务。Hub是一个云Registry服务,用于存储和管理映像文件以及用户权限。Docker Cloud供应和管理部署集群,同时也监控和管理已部署应用。使用Docker Cloud连接到你选择的云基础设施或使用你自己的物理节点来部署你的应用吧。

你的Docker CaaS可以设计成集中控制和管理,也可以设计成分布式管理以授权给各自应用团队。这种灵活性使得你可以建立一个最适合你的业务的模型,就像你选择基础设施和内容实现过程那样。CaaS是构建、交付和运行应用理念的一个延伸。

事实上由于CaaS统一了跨环境的本质,加速了许多IT倡议被接纳的过程。每个组织都有其自己采纳的倡议:从容器化,包括对已有应用的改造和迁移,到微服务,再到持续集成、持续交付和devops以及对各类云的接纳、迁移、混合及支持多种云。在每个场景中,Docker CaaS都能带来敏捷性、可移植性和控制,使得组织能接受那些用例。

六、AND的力量

总之,云、应用和数据的变化已经将技术和商业之间的对话,从“你如何帮我削减成本”换成了“你如何加速我的商业”。当你踏上你的旅途时,Docker提供了额外的灵活性帮你选择在哪里存储你的应用内容以及在哪里部署你的控制台。让你的CaaS适配你的业务需求,不管是部署在本地数据中心或虚拟私有云上,还是作为云服务被平滑地消费。无论你的业务是什么,Docker CaaS平台都会提供敏捷性、可移植性和控制力,尽可能又快又好的构建最好的应用,以最优的代价提供峰值性能的服务,并且不会被平台锁定。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多