Docker

Docker

五个小技巧,快速创建Docker镜像

宁静胡同 发表了文章 • 0 个评论 • 420 次浏览 • 2017-01-06 14:51 • 来自相关话题

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——


1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html 查看全部

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——




1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html

DevOps:谁说我只是自动化工具?

宁静胡同 发表了文章 • 0 个评论 • 291 次浏览 • 2016-12-13 16:31 • 来自相关话题

关于DevOps,每个人都有不同的认识。有人坚持它是一种方法论,然而在实践中为了脱离缓慢的手工作业,自动化工具必不可少。从职责传递到自助服务,DevOps为满足业务的快速交付而生,却存在学习上的瓶颈。
然后谢天谢地,容器来了……

参加了大大小小许多DevOps和软件工程的会议。每当”DevOps究竟意味着什么”这个话题被提起时,总是会有一个这样的论点出现:

DevOps不是一系列可以连贯起来的工具,你用了它们就可以说自己做的是DevOps。DevOps是一种方法论,让开发和运维团队能够更紧密工作的一套过程。最终的目标是消除在软件发布的过程中手动作业和耗费时间的部分,实现更多成功的部署和更频繁的发布。

它完全正确。然而,话虽如此,祝不使用自动化工具的DevOps或者持续交付……好运。

为什么自动化工具是先决条件

假设这样一个场景:你处在一个研发工作室,创业公司甚至是大型企业。你有很多开发人员,他们中的少数一些被称为“Ops小组”“DevOps魔法师”或者“云运维”,在企业中他们可能被称为“基础设施运营专家”(如果你们有更有趣的名字也可以在下方留言)。但不管怎样,他们的人使用开发团队所写的代码,并确保它们能够在生产级别的环境上可靠运行。
开发写代码并添加新特性从开发到运维,一个传递发生了现在它是运维的麻烦了……运维挥动服务器魔法,把问题解决了!

听着很耳熟?主要的问题是什么呢?运维和开发的分离这件事在整个发布过程中发生得过早了。它随着传递发生,从此变成了一个问题。在技术团队中有服务器魔法师当然很棒,因为开发人员不用再担心如何处理服务器问题,但是它确实是一个把你从DevOps的喜悦中拉下来的瓶颈。

自助服务:开发人员需要它,运维也是

DevOps的目的是团队紧密工作,缩短反馈回路。

做一些改变,让它们在测试环境中提交、合并、站住脚来确保一切都如预期那样。看起来不错?然后让新功能平滑地上生产,交到用户的手里。出现了问题?回滚一下,迅速地修复它,然后在不停机的情况下发布更新。

然而写代码的开发人员和理解及维护云平台的运维人员减慢了反馈回路,经常慢如爬行动物。

写代码的开发人员最适合做发布(在他们的计划中方便的时候),测试,监控性能,以及解决任何突然出现的问题。可是为什么没有工作流程是默认如此的呢?

很多情况下,服务器魔法师或者运维团队是唯一理解云平台所有事物的人。没有为开发者或者试图了解幕后情况的人提供的自助服务。

听起来运维团队处在一个非常强大的位置,但实际上它是非常痛苦和充满压力的。在给用户提供软件后你多少会明白,发布和维护是你职责所在,如果出错了要在第一线调试它,通常一忙就是一天24小时。

那为什么这是一个如此常见的场景呢?(提示,通常和工具有关)。

你选择的工具可能重要,也可能无关紧要

在一天结束的时候,运维人员、开发人员、安全保障人员、项目经理等等都对新软件发布的过程很满意,它实现了快速交付满足了业务需求。你可以通过很多方式到达这个目标。如果你是通过类似自助的方式,那么恭喜。

讲个故事。

在之前的一份工作里,我们采用了一种配置管理工具,插在Jenkins上,集成了很多开源系统,很高兴地自动化了一个大型、多区、遵从PCI并且流畅跑在AWS上的服务器。我们让非技术人员添加和部署新项目成为可能,可以为每个变化进行完整测试。一切看起来都很好,除了一个大问题:我们构建了类似自助服务的东西,但是它对公司95%的人来说是一个黑盒。开发把他们的代码给我们,他们可以检查日志,查看图表,看各项性能,但是当碰到钉子的时候,就是我们的职责了。
 
所以怎样才能让更多的人能够明白我们搭建的主机系统如何工作?我们用来连接一切的工具和用户配置让学习的复杂度大大提高。

然后……容器来了。

为什么容器可以帮上忙

你知道我一定会提容器的,对不对?在过去几年的DevOps大会上,容器和其应用基本是一个必谈的话题。

容器改变了开发和运维之间的分离境地,改进了他们之间的传递进程。开发人员能够更接近项目来确保他们的更新在传递给本地镜像创建人员之前可以成功部署。标准变得更加成熟和有意义,让更多人专注于应用程序而不是服务器。

容器已经催生了很多颇有竞争力的解决方案,提供一个平台来代替自助服务。因此运维团队和开发团队可以把关注点放在生产更多高效的进程和结果。所以在实践中它是什么样的?

当容器和DevOps碰撞

每一个软件公司如果着手开发一个改变游戏规则的产品,在前进的道路上,不管是从基础架构、还是人员管理和软件发布的角度,都会不可避免遇到可伸缩性的问题。随着团队的成长,和服务器的扩展,公司不仅需要关注产品线路图的执行,还需要变成云计算自动化领域的专家。能够最快速地执行新想法就会有显著的优势。如果你仍然手动登录服务器或者尝试再造一个云平台的车轮,那么就是在伤害你的公司。

而最近的一些容器技术或者容器服务平台可以帮助你从别人的硬件中解放出来,让公司更加专注于产品——
 
开发者能够通过友好的用户界面管理自己的服务器硬件需求开发者可以减少一个数量级的反馈回路时间,这意味着更多的代码更快的发布运维不用再尝试将一堆工具拢在一起做一个内部的PaaS,它很难做,很难管理,很难修补,很难保证安全运维可以更进一步地专注在应用监控、性能表现上,给予开发一些有价值的反馈来快速提升产品业务可以更灵活地延伸到全球范围,根据业务需求进行扩展,更新用户平台不需要时间和成本上的花费更多的资金可以用来雇佣人才专注于产品研发

所以,拥有了容器技术的DevOps,是否有了新的定义?

当然小数要补充一句,容器不是万能的,用在适合的地方最好。


文章作者:Phil Dougherty
原文链接:https://blog.containership.io/ ... isite 查看全部

关于DevOps,每个人都有不同的认识。有人坚持它是一种方法论,然而在实践中为了脱离缓慢的手工作业,自动化工具必不可少。从职责传递到自助服务,DevOps为满足业务的快速交付而生,却存在学习上的瓶颈。
然后谢天谢地,容器来了……



参加了大大小小许多DevOps和软件工程的会议。每当”DevOps究竟意味着什么”这个话题被提起时,总是会有一个这样的论点出现:

DevOps不是一系列可以连贯起来的工具,你用了它们就可以说自己做的是DevOps。DevOps是一种方法论,让开发和运维团队能够更紧密工作的一套过程。最终的目标是消除在软件发布的过程中手动作业和耗费时间的部分,实现更多成功的部署和更频繁的发布。

它完全正确。然而,话虽如此,祝不使用自动化工具的DevOps或者持续交付……好运。

为什么自动化工具是先决条件

假设这样一个场景:你处在一个研发工作室,创业公司甚至是大型企业。你有很多开发人员,他们中的少数一些被称为“Ops小组”“DevOps魔法师”或者“云运维”,在企业中他们可能被称为“基础设施运营专家”(如果你们有更有趣的名字也可以在下方留言)。但不管怎样,他们的人使用开发团队所写的代码,并确保它们能够在生产级别的环境上可靠运行。
  • 开发写代码并添加新特性
  • 从开发到运维,一个传递发生了
  • 现在它是运维的麻烦了……
  • 运维挥动服务器魔法,把问题解决了!


听着很耳熟?主要的问题是什么呢?运维和开发的分离这件事在整个发布过程中发生得过早了。它随着传递发生,从此变成了一个问题。在技术团队中有服务器魔法师当然很棒,因为开发人员不用再担心如何处理服务器问题,但是它确实是一个把你从DevOps的喜悦中拉下来的瓶颈。

自助服务:开发人员需要它,运维也是

DevOps的目的是团队紧密工作,缩短反馈回路。

做一些改变,让它们在测试环境中提交、合并、站住脚来确保一切都如预期那样。看起来不错?然后让新功能平滑地上生产,交到用户的手里。出现了问题?回滚一下,迅速地修复它,然后在不停机的情况下发布更新。

然而写代码的开发人员和理解及维护云平台的运维人员减慢了反馈回路,经常慢如爬行动物。

写代码的开发人员最适合做发布(在他们的计划中方便的时候),测试,监控性能,以及解决任何突然出现的问题。可是为什么没有工作流程是默认如此的呢?

很多情况下,服务器魔法师或者运维团队是唯一理解云平台所有事物的人。没有为开发者或者试图了解幕后情况的人提供的自助服务。

听起来运维团队处在一个非常强大的位置,但实际上它是非常痛苦和充满压力的。在给用户提供软件后你多少会明白,发布和维护是你职责所在,如果出错了要在第一线调试它,通常一忙就是一天24小时。

那为什么这是一个如此常见的场景呢?(提示,通常和工具有关)。

你选择的工具可能重要,也可能无关紧要

在一天结束的时候,运维人员、开发人员、安全保障人员、项目经理等等都对新软件发布的过程很满意,它实现了快速交付满足了业务需求。你可以通过很多方式到达这个目标。如果你是通过类似自助的方式,那么恭喜。

讲个故事。

在之前的一份工作里,我们采用了一种配置管理工具,插在Jenkins上,集成了很多开源系统,很高兴地自动化了一个大型、多区、遵从PCI并且流畅跑在AWS上的服务器。我们让非技术人员添加和部署新项目成为可能,可以为每个变化进行完整测试。一切看起来都很好,除了一个大问题:我们构建了类似自助服务的东西,但是它对公司95%的人来说是一个黑盒。开发把他们的代码给我们,他们可以检查日志,查看图表,看各项性能,但是当碰到钉子的时候,就是我们的职责了。
 
所以怎样才能让更多的人能够明白我们搭建的主机系统如何工作?我们用来连接一切的工具和用户配置让学习的复杂度大大提高。

然后……容器来了。

为什么容器可以帮上忙

你知道我一定会提容器的,对不对?在过去几年的DevOps大会上,容器和其应用基本是一个必谈的话题。

容器改变了开发和运维之间的分离境地,改进了他们之间的传递进程。开发人员能够更接近项目来确保他们的更新在传递给本地镜像创建人员之前可以成功部署。标准变得更加成熟和有意义,让更多人专注于应用程序而不是服务器。

容器已经催生了很多颇有竞争力的解决方案,提供一个平台来代替自助服务。因此运维团队和开发团队可以把关注点放在生产更多高效的进程和结果。所以在实践中它是什么样的?

当容器和DevOps碰撞

每一个软件公司如果着手开发一个改变游戏规则的产品,在前进的道路上,不管是从基础架构、还是人员管理和软件发布的角度,都会不可避免遇到可伸缩性的问题。随着团队的成长,和服务器的扩展,公司不仅需要关注产品线路图的执行,还需要变成云计算自动化领域的专家。能够最快速地执行新想法就会有显著的优势。如果你仍然手动登录服务器或者尝试再造一个云平台的车轮,那么就是在伤害你的公司。

而最近的一些容器技术或者容器服务平台可以帮助你从别人的硬件中解放出来,让公司更加专注于产品——
 
  • 开发者能够通过友好的用户界面管理自己的服务器硬件需求
  • 开发者可以减少一个数量级的反馈回路时间,这意味着更多的代码更快的发布
  • 运维不用再尝试将一堆工具拢在一起做一个内部的PaaS,它很难做,很难管理,很难修补,很难保证安全
  • 运维可以更进一步地专注在应用监控、性能表现上,给予开发一些有价值的反馈来快速提升产品
  • 业务可以更灵活地延伸到全球范围,根据业务需求进行扩展,更新用户平台不需要时间和成本上的花费
  • 更多的资金可以用来雇佣人才专注于产品研发


所以,拥有了容器技术的DevOps,是否有了新的定义?

当然小数要补充一句,容器不是万能的,用在适合的地方最好。


文章作者:Phil Dougherty
原文链接:https://blog.containership.io/ ... isite

Marathon如何跑docker container -d

xds2000 回复了问题 • 2 人关注 • 1 个回复 • 481 次浏览 • 2016-10-17 16:42 • 来自相关话题

数人云CTO解读Docker 1.12和金融业容器化

宁静胡同 发表了文章 • 0 个评论 • 684 次浏览 • 2016-08-03 10:24 • 来自相关话题

7月29日数人云在上海举办金融沙龙,邀请上交所和近二十家来自银行、保险、证券的IT技术专家一同探讨容器技术在金融业中的最佳实践。数人云CTO肖德时在会上将传统金融行业通过容器可以解决的四大问题做了逐一解读。


以下是演讲实录:

容器技术基本上是2013年出来的,2014年开始在中国传播。在2016年,大家可以感觉到Docker技术的发展加速,在生产环境中也有很多的成功案例。在DockerCon 2016上我们发现,Docker已经从原来的一个工具变成一个真正的生态圈,Docker已经具备整套的解决方案,同时上下游生态也已经非常完备。这都在告诉大家,你能想到的、和你需要的一些最佳实践,Docker基本上都能提供。目前,基本上是大公司在不断的追求Docker的技术,因为小公司用Docker技术解决问题产生的收益比还比较不明显,而大公司原来冗余的架构通过使用Docker确实可以产生效益,所以一些传统企业对Docker会比较关注。

容器技术发展加速

最新的资料显示,现在是应用Docker技术的比较好的时机。全球雇员超过500人的公司中73%已使用Docker技术。国内的很多公司也都在关注这项技术,尤其是金融行业,因为金融业的IT发展的比较成熟,他们对新技术比较关注,Docker已经有很多生产应用在里面产生。
 







用Docker能干什么是大家比较关心的问题。第一个比较常见的场景是DevOps,DevOps实际上就是提高生产力。原来,开发能做运维的事,运维能做开发的事。但实际上从真实的场景里,术业有专攻,在创业公司可以这么干,但传统公司做不了。Docker可以帮助企业进行业务的转型,提供标准的接口,这样开发提供标准运维能知道,运维提供标准开发也能知道。传统企业的开发流程不像创业公司,一个人要干很多事,传统企业强调的是标准化,是业务的转型,而在原有的老的制度下很难实现这种标准,用Docker技术可以加快转型。

第二个场景,云化。2016年云计算开始了新的增长,云计算发展到了新的技术点,老的虚拟化技术已经不能满足企业对动态资源和快速响应的需求,不能起到资源复用的作用。Docker可以应用在物理机上,也可以应用在虚拟机上,可以快速构建应用管理平台,或者构建IaaS、PaaS,或者service都可以。原来部门做不了,因为没有技术栈的改变,仍然要用老设施,那些老设施都是为大企业设计的。但是Docker出来的时候就是为开发者服务的,它是一个工具,一个人也可以做一个私有云。从这个点来看,在云端的转变这个场景里Docker是目前比较推荐的技术栈,它能够快速构建应用管理平台,可以有很好的基础。

另外,用了Docker一定要无状态,这只是表象,以前的应用架构和原来的状态是不是就一定不能满足现在的需求?不是的,原来的单体仍然可以用,为什么要做微服务?因为业务里有多个Function,其中有一个Function是特别热的,这时候怎么能抽出来?最简单的办法就是重构,因为想把它抽出来,抽出来以后,如果没有一些工具怎么做后面的工作?这都是限制问题。Docker公司提供的方案就是用Docker把它包裹一下,成为一个标准的小组件,然后利用分布式的概念,把它scale out,scale out以后再进行后面的工作。在现代的应用中,用了云,资源更容易获得,所以客户想快速地创造一些环境,这些环境里面的资源利用率解决了,但是应用的复杂度仍然存在。如何动态的分配,就是刚才上交所介绍的一些治理的方法。在Modern APP之上会面临一些问题,但是如何快速响应,这个情况是需要一些工具的,这些工具我们认为Docker是可以做到。
 







大背景,之前IOE的架构存在,不是说不好,从技术层面来讲,我并不认为IOE有什么不好,只是我加了一些策略做这件事,它比较拥堵,但不代表它不好。还有“十三五”规划,自主可控的要求,这些背景让企业对开源工具的需求变得会越来越多,数人云这种开源公司也是应势而生,我们给企业提供的解决方案就是自主可控,把开源、透明的技术交给客户。

在2015年,当时去跟客户说我们上一个Docker,人家说你的Docker和VM比有什么好处?VM用的多好,为什么要上Docker?当时我们是无言以对的,因为安全性,还有各种生态圈的工具链也不成熟。但是慢慢的,我们在做这件事的时候发现,其实这是需要和企业一起成长,我们也总结一些步骤。

金融行业拥抱容器四大步
 






总结一下我们想解决的问题,首先,Docker能不能解决快速发布的问题,实际上用Docker以后,管理起来是更复杂的。所以才会有数人云这种PaaS的存在,把复杂的东西用计算机的方式管理,因为用个人的方式是没法管理那么多资源的和实例的;二是原来多套环境相互隔离,客户需要的是多套环境多租户的分发,真正的隔离,因为是内部系统,对于隔离的要求还是可以分级的。环境的快速搭建涉及编排,怎么把DB分成两个,上面分成多个,然后都能访问DB,还有如何将手工操作变成自动的;三是大版本升级回滚,很难做这种升级回滚,怎么去做;四是各种设备,有的CPU,有的是VM,有的在物理机上,这么多设备怎么统一的管理起来。这是我们现实的一些场景,我们怎么解决这些问题是我今天想和大家一起探讨的问题。
 







第一个问题是快速部署,还有缓慢的升级,基本上就是用容器和微服务解。微服务是一个框架,如果把现有的服务拆成微服务,一定是一个统一的架构,那这个架构里面一定是包含这样的元素:首先,一定要有一个API网关的Server,微服务里面的API网关不涉及Nginx,因为Nginx没法动态的改配置,得手动去改,这是满足不了需求的,因为底下的应用无数,所以上面一定要构建自己的API网关,这个网关可以解决所有的问题,要不然下面每个API的服务,它的服务请求SLA都是可以经过网关控制的,这也是新型微服务架构里面经常不被人提起的,被忽略的地方。但是这是非常重要的一点,因为底下的服务特别多。发到集群里,怎么管控这些服务的质量,就是API的请求,出错怎么办,怎么来控制?这些都要通过API网关来控制,所以这个一定要去注意一下。
 







另外是几个大块的认证,如果你的内部认证没有统一的认证,就没法做标准化的双向通行,而且API网关也没有办法给下面的应用下发东西,因为没法认证。还有Configuration server一定要加上,Service Discovery单纯靠容器解决不了,需要PaaS的容器平台解决。做端口、应用的发现,方便其他应用访问它。还有监控、报警,然后就是常规的日志分析,这就是常规的需求。这些需求里面最特殊的就是容器,因为很多个要做逐一监控,没有一个平台是不行的。对日志也是一样,每个容器起来以后就死掉了,怎么知道这个容器是应用呢?一般都是要通过容器的ID来标识,然后收集回来。

还有一个API网关里面最大的特点,快速的熔断,什么意思呢?就是底下的服务很可能出问题。微服务架构里都打散,上面挂一个Nginx,如果业务量大了,如何快速关闭某个API呢?没有可编程的接口是做不到的。但是要采取微服务解决,这个架构的的组织形式就是这样。微服务里面承载的这些组件特别复杂,需要一个标准的组件来封装起来,这个封装组件的方式用Docker是比较合适的。微服务的架构确实可以解决这个问题,因为每个组件的升级很快,如果把整个组件升级一下,还有一些其他的东西,会很麻烦。我们会想到能给一个这样的架构,微服务架构里面统一管理服务。
 







环境之间的隔离,Docker做的目录级别的隔离已经完全可以满足需求了,原来为什么做不到这点?是因为手工的操作特别多,用别的方法隔离也是没有问题的。但是我们觉得,原来的架构里面,CICD的架构已经很成熟了,能不能把它自动化?因为完全可以用Docker来交付整个环境,手工部署没有问题。我们再往前走一步,怎么走?Jenkins可以调一个集群系统,然后分发集群,刚才说的微服务发到这里面,然后快速的部署。这是一个自动化的过程。这里面涉及到一个问题,原来咱们经常会听到的是持续构建,也就是把原码先构建成镜像,然后镜像再发到集群里面,这个操作觉得很顺,但实际上这里面真正的挑战在于,因为每个业务组件的依赖,还有他们之间的配置怎么抽离出来,这都是需要比以前更复杂的。所以,用容器确实解决了持续集成的一部分问题,但它对你的技术要求会越来越高。原来是手工做,而现在需要自动化。对于基础人员的架构改造,其实是抽象层更高一点,对大家的要求也会更高一点。
 







大版本升级不可回滚。大版本的升级困难点在哪儿?原来都是单体服务根本没法拆,动又不能动,刚才说了微服务基本上能够解决它。第二个情况是每个版本的版本控制怎么解决?基本上配置中心可以把配置做出来,然后建仓库,做版本控制。要做这个最好是滚动更新,也就是在不停机的情况下,一点点把业务迁到新的应用上面,然后将老的流量在处理完业务之后慢慢的退掉,这是一种办法。服务的时候,原来指向老的服务进程,自动地切到新的服务进程里面,这样产生流量尽快切到新的服务里面,所以这是需要服务发现的。
 







我们这边会构建一个集群,我们用的ZooKeeper去保证调度器,在正常运行的情况下,我们给Marathon发指令,让它把应用一个一个更新。起一个服务,保证老服务不停机,这时再把域名切换,进来的新流量就到新的应用里面了,老的应用在没有流量的时候自动退出,保证用户访问的时候没有宕机的感觉。这是集群环境里面做升级的常见案例。
 







还有各种异构设备,硬件资源利用率比较低,解法是数人云的应用集群。它是容器的集群,我们的系统会运行在独立的环境里远程控制集群系统,保证系统里面运行的只有容器,然后有相应的Agent来管理应用的服务。
 







这张图比较清晰一点,数人云本身就是微服务的架构,这里面针对的情况,大家都知道Nginx性能是最好的,我们可能在这上面写一个新的API网关对接整个系统,这套系统是数人云系统架构里面的一部分。我们业务管理用Marathon调度器会进行升级,因为Mesos本身是集群管理的调度。对于这些组件,比如镜像,我们采用的方式是跟VMware合作的一个开源项目叫Harbor镜像管理仓库,这是我们和他们一起合作开发的软件。持续集成我们和Jenkins做集成,通过自动配置能够把我们这个小本下发给Jenkins,然后和它构建镜像。监控报警,大家会觉得容器的监控报警不好做,容器目前为止基本上都是接口,现在新的容器把日志和报警,所谓的报警的实现都要按照流程的方式提供API接口,只要接上就收走日志,在本地不落盘。日志也是一样,它现在提供plugin方式和日志系统对接,不用担心落到盘里面收上来是不是把硬盘撑爆,现在都可以配的。这里对于我们现在新加的网络模块,就容器发展到现在其实对于网络都是成熟的,大家都在用host模式去管,虽然容器很轻,但并不比VM先进到哪里去,只是说它更轻量一些。客户希望VM有的东西它也有,这块最后也提供了这种对于IP的管理。所以也是刚刚在上的一种新的成熟架构,也就是说一容器一IP,现在是刚刚才开始支持,这是我们最新配套的。

容器圈新方向预览
 







讲完这些方案之后,今天会有些容器圈的新东西给大家讲讲。

首先是Docker1.12,昨天它正式发布了,这是一个新版本的发布,最重要的发布。这个发布先是内置了自己的工具,再就是对网络的增强,达到了更容易商用的阶段。第二个是我们现在用的Mesos,也发布了1.0,可以给大家介绍一下特性。
 







Docker1.12它有一个重要的特点,一般在集群系统里面,因为容器是很碎的,用户希望知道这个服务到底是run还是不run,原来的方式是Docker run的时候把端口打开,然后通过一个脚本去查。这等于是第三方去做,现在提供的功能是可以在构建镜像的时候就把Healthcheck打开,通过Docker Daemon的内容给这台主机上运行的容器定期的检查,通过Docker知道这个容器是不是健康的。当然这个功能并不是为咱们准备的,是为自己内置的Swarm编排工具做准备的,因为Docker公司做集群管理的工具也在想这个事情。还有一个情况是咱们最常用的CentOS系列,原来对于安全Docker公司一直在回避,它现在默认把这个组件打开了,打开以后跑出来更安全。Linux可以打标签、做监控,但是这个东西因为刚出来,所以只是一个信号,也就是Docker越来越安全了,原来是做不到,现在是越来越方便了,可以做到这样。Docker内置了一个IPVS,干什么用?就是想替代HaProxy提供IP给网络里面。这是比较新的技术,目前我们认为处于实验阶段,它利用IPVS的模块来提供网络的接口,只是一个信号,目前是没有采用这种方案的,因为太新了,还要测试。最后是内置Swarm的组件,这是很轻量的编排工具,也就是说装几台机器,必须要组成一个网,怎么去做?可以用Swarm做这个事。这个网IP怎么做,用IPVS,这就是最新的Docker的发展,非常快。
 







目前为止,一容器一IP技术理论已经落地。每台机器要装一个小的路由器,然后小路由器给你的容器。这个路由器可以想象成家里的无线路由器,因为是个屋子,一台主机里面都有屋子,任何终端设备都可以向路由器调IP,这个IP是假的都可以。当然Docker里面现在有了网络的插件,就相当于类似有了一个驱动,就可以找路由器要一个IP,实现了路由器有IP。大家注意到这个IP和底下的IP不一样,他们之间通过IPtable 做包头的转换,通过转换就可以双向通信了。但是这里面192.168的网段和10网段的管控,如果只做一次转发,那就控制不了这些IP之间的东西,我们用的方案把这些规则都记录在一个键值库里面,这样的好处在于,可以控制这个IP和这个IP的通信,把它记录下来就可以了,如果删掉,默认不让它通信也是可以的。虽然一台主机有三台服务器,但是他们之间是否能通信是你可以控制的,这样更安全。也就是说,用户有一个应用,这个应用是1.1和0.9,放在这两个容器上,然后1.10是另外一个APP,不希望他们之间互相通信就可以通过IPtable写进去,然后把他们隔开,他们通信的时候,一看规则没有就把他们删掉了,路由器就不会给它分。

还有一个情况,都是容器里面的IP,那外网的IP之间能不能通信?因为内网有一个路由器,路由器给它分了一个IP,也想给容器分一个同样网段的IP,需要一个网关来转换为可用的IP,转换给它,就是改包头改完包头转进去。它请求的时候再转出去,两个路由器之间再转一下,是这样的过程。它有一个缺点,就是主机的数量不能太大,毕竟是虚拟的IP网络,主机的数量不是容器的数量,基本上在200台左右是一个推荐的方式。
 







性能对比,跟主机、物理机再和calico的解决方案对比,基本上会在1024、2048、4096这块,如果用普通的overlay方案性能就很低,目前Docker overlay自己的原生方案性能就很低,但是它在提升,因为它刚刚出来。上面这套方案,因为calico的方案只是在包的包头上做了篡改,欺骗主机转发数据包,所以它的性能和host主机之间,有时候从数据表里面看到它传输的效率,吞吐量比host还快,但是这个数有假像,因为改了包头,但是基本上可以肯定,和原生的host的网卡里面性能是差不多的,是这样的情况。
 






最后说Mesos现在新产品,就是1.0技术开源的组件,1.0以后,我们基本上就会有新的HTTP API,原来的API都是Google的协议,现在有新的HTTP API更方便数人云和它做深度整合,我们也希望不断的前进,给客户提供更好的产品。第二个情况,大家现在遇到的情况,那就是Docker有各种各样的bug,这个问题没有很好的解决办法,因为Docker公司的产品是开源的,它的商业产品也到不了中国。Mesos解决了这个问题,Mesos拥有给Twitter、苹果等都部署过几万台的节点的经验。他发现安装Docker Daemon以后,Docker是很不稳定的,尤其在大规模集群方面很不稳定,所以他们推荐另外一个方式,就是用原生的容器框架解包镜像。客户在本地用Docker,但是把镜像发给我,我用另外的方式把这种镜像给起起来,用户是透明的,就认为它是Docker room,但它不用了Docker Daemon,因为把Docker Daemon关掉以后容器就死掉了,但是把Docker Daemon去掉以后,容器还要通过原生的方式运行起来,这就满足了企业的各种需求,这是新的技术点。还有云原生APP架构里面,对于网络需要一个标准,现在提供了一个类似的架构,Mesos提供了这个标准。另外就是支持GPU。还有Mesos在和微软合作,开始接管Windows的一些信息,这也是比较大的亮点。这个生态圈还是比较活跃的,这也是数人云关注和考虑的。 查看全部
7月29日数人云在上海举办金融沙龙,邀请上交所和近二十家来自银行、保险、证券的IT技术专家一同探讨容器技术在金融业中的最佳实践。数人云CTO肖德时在会上将传统金融行业通过容器可以解决的四大问题做了逐一解读。


以下是演讲实录:

容器技术基本上是2013年出来的,2014年开始在中国传播。在2016年,大家可以感觉到Docker技术的发展加速,在生产环境中也有很多的成功案例。在DockerCon 2016上我们发现,Docker已经从原来的一个工具变成一个真正的生态圈,Docker已经具备整套的解决方案,同时上下游生态也已经非常完备。这都在告诉大家,你能想到的、和你需要的一些最佳实践,Docker基本上都能提供。目前,基本上是大公司在不断的追求Docker的技术,因为小公司用Docker技术解决问题产生的收益比还比较不明显,而大公司原来冗余的架构通过使用Docker确实可以产生效益,所以一些传统企业对Docker会比较关注。

容器技术发展加速

最新的资料显示,现在是应用Docker技术的比较好的时机。全球雇员超过500人的公司中73%已使用Docker技术。国内的很多公司也都在关注这项技术,尤其是金融行业,因为金融业的IT发展的比较成熟,他们对新技术比较关注,Docker已经有很多生产应用在里面产生。
 


1.png


用Docker能干什么是大家比较关心的问题。第一个比较常见的场景是DevOps,DevOps实际上就是提高生产力。原来,开发能做运维的事,运维能做开发的事。但实际上从真实的场景里,术业有专攻,在创业公司可以这么干,但传统公司做不了。Docker可以帮助企业进行业务的转型,提供标准的接口,这样开发提供标准运维能知道,运维提供标准开发也能知道。传统企业的开发流程不像创业公司,一个人要干很多事,传统企业强调的是标准化,是业务的转型,而在原有的老的制度下很难实现这种标准,用Docker技术可以加快转型。

第二个场景,云化。2016年云计算开始了新的增长,云计算发展到了新的技术点,老的虚拟化技术已经不能满足企业对动态资源和快速响应的需求,不能起到资源复用的作用。Docker可以应用在物理机上,也可以应用在虚拟机上,可以快速构建应用管理平台,或者构建IaaS、PaaS,或者service都可以。原来部门做不了,因为没有技术栈的改变,仍然要用老设施,那些老设施都是为大企业设计的。但是Docker出来的时候就是为开发者服务的,它是一个工具,一个人也可以做一个私有云。从这个点来看,在云端的转变这个场景里Docker是目前比较推荐的技术栈,它能够快速构建应用管理平台,可以有很好的基础。

另外,用了Docker一定要无状态,这只是表象,以前的应用架构和原来的状态是不是就一定不能满足现在的需求?不是的,原来的单体仍然可以用,为什么要做微服务?因为业务里有多个Function,其中有一个Function是特别热的,这时候怎么能抽出来?最简单的办法就是重构,因为想把它抽出来,抽出来以后,如果没有一些工具怎么做后面的工作?这都是限制问题。Docker公司提供的方案就是用Docker把它包裹一下,成为一个标准的小组件,然后利用分布式的概念,把它scale out,scale out以后再进行后面的工作。在现代的应用中,用了云,资源更容易获得,所以客户想快速地创造一些环境,这些环境里面的资源利用率解决了,但是应用的复杂度仍然存在。如何动态的分配,就是刚才上交所介绍的一些治理的方法。在Modern APP之上会面临一些问题,但是如何快速响应,这个情况是需要一些工具的,这些工具我们认为Docker是可以做到。
 


2.png


大背景,之前IOE的架构存在,不是说不好,从技术层面来讲,我并不认为IOE有什么不好,只是我加了一些策略做这件事,它比较拥堵,但不代表它不好。还有“十三五”规划,自主可控的要求,这些背景让企业对开源工具的需求变得会越来越多,数人云这种开源公司也是应势而生,我们给企业提供的解决方案就是自主可控,把开源、透明的技术交给客户。

在2015年,当时去跟客户说我们上一个Docker,人家说你的Docker和VM比有什么好处?VM用的多好,为什么要上Docker?当时我们是无言以对的,因为安全性,还有各种生态圈的工具链也不成熟。但是慢慢的,我们在做这件事的时候发现,其实这是需要和企业一起成长,我们也总结一些步骤。

金融行业拥抱容器四大步
 

3.png


总结一下我们想解决的问题,首先,Docker能不能解决快速发布的问题,实际上用Docker以后,管理起来是更复杂的。所以才会有数人云这种PaaS的存在,把复杂的东西用计算机的方式管理,因为用个人的方式是没法管理那么多资源的和实例的;二是原来多套环境相互隔离,客户需要的是多套环境多租户的分发,真正的隔离,因为是内部系统,对于隔离的要求还是可以分级的。环境的快速搭建涉及编排,怎么把DB分成两个,上面分成多个,然后都能访问DB,还有如何将手工操作变成自动的;三是大版本升级回滚,很难做这种升级回滚,怎么去做;四是各种设备,有的CPU,有的是VM,有的在物理机上,这么多设备怎么统一的管理起来。这是我们现实的一些场景,我们怎么解决这些问题是我今天想和大家一起探讨的问题。
 


4.png


第一个问题是快速部署,还有缓慢的升级,基本上就是用容器和微服务解。微服务是一个框架,如果把现有的服务拆成微服务,一定是一个统一的架构,那这个架构里面一定是包含这样的元素:首先,一定要有一个API网关的Server,微服务里面的API网关不涉及Nginx,因为Nginx没法动态的改配置,得手动去改,这是满足不了需求的,因为底下的应用无数,所以上面一定要构建自己的API网关,这个网关可以解决所有的问题,要不然下面每个API的服务,它的服务请求SLA都是可以经过网关控制的,这也是新型微服务架构里面经常不被人提起的,被忽略的地方。但是这是非常重要的一点,因为底下的服务特别多。发到集群里,怎么管控这些服务的质量,就是API的请求,出错怎么办,怎么来控制?这些都要通过API网关来控制,所以这个一定要去注意一下。
 


5.png


另外是几个大块的认证,如果你的内部认证没有统一的认证,就没法做标准化的双向通行,而且API网关也没有办法给下面的应用下发东西,因为没法认证。还有Configuration server一定要加上,Service Discovery单纯靠容器解决不了,需要PaaS的容器平台解决。做端口、应用的发现,方便其他应用访问它。还有监控、报警,然后就是常规的日志分析,这就是常规的需求。这些需求里面最特殊的就是容器,因为很多个要做逐一监控,没有一个平台是不行的。对日志也是一样,每个容器起来以后就死掉了,怎么知道这个容器是应用呢?一般都是要通过容器的ID来标识,然后收集回来。

还有一个API网关里面最大的特点,快速的熔断,什么意思呢?就是底下的服务很可能出问题。微服务架构里都打散,上面挂一个Nginx,如果业务量大了,如何快速关闭某个API呢?没有可编程的接口是做不到的。但是要采取微服务解决,这个架构的的组织形式就是这样。微服务里面承载的这些组件特别复杂,需要一个标准的组件来封装起来,这个封装组件的方式用Docker是比较合适的。微服务的架构确实可以解决这个问题,因为每个组件的升级很快,如果把整个组件升级一下,还有一些其他的东西,会很麻烦。我们会想到能给一个这样的架构,微服务架构里面统一管理服务。
 


6.png


环境之间的隔离,Docker做的目录级别的隔离已经完全可以满足需求了,原来为什么做不到这点?是因为手工的操作特别多,用别的方法隔离也是没有问题的。但是我们觉得,原来的架构里面,CICD的架构已经很成熟了,能不能把它自动化?因为完全可以用Docker来交付整个环境,手工部署没有问题。我们再往前走一步,怎么走?Jenkins可以调一个集群系统,然后分发集群,刚才说的微服务发到这里面,然后快速的部署。这是一个自动化的过程。这里面涉及到一个问题,原来咱们经常会听到的是持续构建,也就是把原码先构建成镜像,然后镜像再发到集群里面,这个操作觉得很顺,但实际上这里面真正的挑战在于,因为每个业务组件的依赖,还有他们之间的配置怎么抽离出来,这都是需要比以前更复杂的。所以,用容器确实解决了持续集成的一部分问题,但它对你的技术要求会越来越高。原来是手工做,而现在需要自动化。对于基础人员的架构改造,其实是抽象层更高一点,对大家的要求也会更高一点。
 


7.png


大版本升级不可回滚。大版本的升级困难点在哪儿?原来都是单体服务根本没法拆,动又不能动,刚才说了微服务基本上能够解决它。第二个情况是每个版本的版本控制怎么解决?基本上配置中心可以把配置做出来,然后建仓库,做版本控制。要做这个最好是滚动更新,也就是在不停机的情况下,一点点把业务迁到新的应用上面,然后将老的流量在处理完业务之后慢慢的退掉,这是一种办法。服务的时候,原来指向老的服务进程,自动地切到新的服务进程里面,这样产生流量尽快切到新的服务里面,所以这是需要服务发现的。
 


8.png


我们这边会构建一个集群,我们用的ZooKeeper去保证调度器,在正常运行的情况下,我们给Marathon发指令,让它把应用一个一个更新。起一个服务,保证老服务不停机,这时再把域名切换,进来的新流量就到新的应用里面了,老的应用在没有流量的时候自动退出,保证用户访问的时候没有宕机的感觉。这是集群环境里面做升级的常见案例。
 


9.png


还有各种异构设备,硬件资源利用率比较低,解法是数人云的应用集群。它是容器的集群,我们的系统会运行在独立的环境里远程控制集群系统,保证系统里面运行的只有容器,然后有相应的Agent来管理应用的服务。
 


10.png


这张图比较清晰一点,数人云本身就是微服务的架构,这里面针对的情况,大家都知道Nginx性能是最好的,我们可能在这上面写一个新的API网关对接整个系统,这套系统是数人云系统架构里面的一部分。我们业务管理用Marathon调度器会进行升级,因为Mesos本身是集群管理的调度。对于这些组件,比如镜像,我们采用的方式是跟VMware合作的一个开源项目叫Harbor镜像管理仓库,这是我们和他们一起合作开发的软件。持续集成我们和Jenkins做集成,通过自动配置能够把我们这个小本下发给Jenkins,然后和它构建镜像。监控报警,大家会觉得容器的监控报警不好做,容器目前为止基本上都是接口,现在新的容器把日志和报警,所谓的报警的实现都要按照流程的方式提供API接口,只要接上就收走日志,在本地不落盘。日志也是一样,它现在提供plugin方式和日志系统对接,不用担心落到盘里面收上来是不是把硬盘撑爆,现在都可以配的。这里对于我们现在新加的网络模块,就容器发展到现在其实对于网络都是成熟的,大家都在用host模式去管,虽然容器很轻,但并不比VM先进到哪里去,只是说它更轻量一些。客户希望VM有的东西它也有,这块最后也提供了这种对于IP的管理。所以也是刚刚在上的一种新的成熟架构,也就是说一容器一IP,现在是刚刚才开始支持,这是我们最新配套的。

容器圈新方向预览
 


17.png


讲完这些方案之后,今天会有些容器圈的新东西给大家讲讲。

首先是Docker1.12,昨天它正式发布了,这是一个新版本的发布,最重要的发布。这个发布先是内置了自己的工具,再就是对网络的增强,达到了更容易商用的阶段。第二个是我们现在用的Mesos,也发布了1.0,可以给大家介绍一下特性。
 


18.png


Docker1.12它有一个重要的特点,一般在集群系统里面,因为容器是很碎的,用户希望知道这个服务到底是run还是不run,原来的方式是Docker run的时候把端口打开,然后通过一个脚本去查。这等于是第三方去做,现在提供的功能是可以在构建镜像的时候就把Healthcheck打开,通过Docker Daemon的内容给这台主机上运行的容器定期的检查,通过Docker知道这个容器是不是健康的。当然这个功能并不是为咱们准备的,是为自己内置的Swarm编排工具做准备的,因为Docker公司做集群管理的工具也在想这个事情。还有一个情况是咱们最常用的CentOS系列,原来对于安全Docker公司一直在回避,它现在默认把这个组件打开了,打开以后跑出来更安全。Linux可以打标签、做监控,但是这个东西因为刚出来,所以只是一个信号,也就是Docker越来越安全了,原来是做不到,现在是越来越方便了,可以做到这样。Docker内置了一个IPVS,干什么用?就是想替代HaProxy提供IP给网络里面。这是比较新的技术,目前我们认为处于实验阶段,它利用IPVS的模块来提供网络的接口,只是一个信号,目前是没有采用这种方案的,因为太新了,还要测试。最后是内置Swarm的组件,这是很轻量的编排工具,也就是说装几台机器,必须要组成一个网,怎么去做?可以用Swarm做这个事。这个网IP怎么做,用IPVS,这就是最新的Docker的发展,非常快。
 


19.png


目前为止,一容器一IP技术理论已经落地。每台机器要装一个小的路由器,然后小路由器给你的容器。这个路由器可以想象成家里的无线路由器,因为是个屋子,一台主机里面都有屋子,任何终端设备都可以向路由器调IP,这个IP是假的都可以。当然Docker里面现在有了网络的插件,就相当于类似有了一个驱动,就可以找路由器要一个IP,实现了路由器有IP。大家注意到这个IP和底下的IP不一样,他们之间通过IPtable 做包头的转换,通过转换就可以双向通信了。但是这里面192.168的网段和10网段的管控,如果只做一次转发,那就控制不了这些IP之间的东西,我们用的方案把这些规则都记录在一个键值库里面,这样的好处在于,可以控制这个IP和这个IP的通信,把它记录下来就可以了,如果删掉,默认不让它通信也是可以的。虽然一台主机有三台服务器,但是他们之间是否能通信是你可以控制的,这样更安全。也就是说,用户有一个应用,这个应用是1.1和0.9,放在这两个容器上,然后1.10是另外一个APP,不希望他们之间互相通信就可以通过IPtable写进去,然后把他们隔开,他们通信的时候,一看规则没有就把他们删掉了,路由器就不会给它分。

还有一个情况,都是容器里面的IP,那外网的IP之间能不能通信?因为内网有一个路由器,路由器给它分了一个IP,也想给容器分一个同样网段的IP,需要一个网关来转换为可用的IP,转换给它,就是改包头改完包头转进去。它请求的时候再转出去,两个路由器之间再转一下,是这样的过程。它有一个缺点,就是主机的数量不能太大,毕竟是虚拟的IP网络,主机的数量不是容器的数量,基本上在200台左右是一个推荐的方式。
 


20.png


性能对比,跟主机、物理机再和calico的解决方案对比,基本上会在1024、2048、4096这块,如果用普通的overlay方案性能就很低,目前Docker overlay自己的原生方案性能就很低,但是它在提升,因为它刚刚出来。上面这套方案,因为calico的方案只是在包的包头上做了篡改,欺骗主机转发数据包,所以它的性能和host主机之间,有时候从数据表里面看到它传输的效率,吞吐量比host还快,但是这个数有假像,因为改了包头,但是基本上可以肯定,和原生的host的网卡里面性能是差不多的,是这样的情况。
 

21.png


最后说Mesos现在新产品,就是1.0技术开源的组件,1.0以后,我们基本上就会有新的HTTP API,原来的API都是Google的协议,现在有新的HTTP API更方便数人云和它做深度整合,我们也希望不断的前进,给客户提供更好的产品。第二个情况,大家现在遇到的情况,那就是Docker有各种各样的bug,这个问题没有很好的解决办法,因为Docker公司的产品是开源的,它的商业产品也到不了中国。Mesos解决了这个问题,Mesos拥有给Twitter、苹果等都部署过几万台的节点的经验。他发现安装Docker Daemon以后,Docker是很不稳定的,尤其在大规模集群方面很不稳定,所以他们推荐另外一个方式,就是用原生的容器框架解包镜像。客户在本地用Docker,但是把镜像发给我,我用另外的方式把这种镜像给起起来,用户是透明的,就认为它是Docker room,但它不用了Docker Daemon,因为把Docker Daemon关掉以后容器就死掉了,但是把Docker Daemon去掉以后,容器还要通过原生的方式运行起来,这就满足了企业的各种需求,这是新的技术点。还有云原生APP架构里面,对于网络需要一个标准,现在提供了一个类似的架构,Mesos提供了这个标准。另外就是支持GPU。还有Mesos在和微软合作,开始接管Windows的一些信息,这也是比较大的亮点。这个生态圈还是比较活跃的,这也是数人云关注和考虑的。

代码篇 | Docker1.12+Swarm构建动态微服务应用

宁静胡同 发表了文章 • 0 个评论 • 682 次浏览 • 2016-07-21 12:00 • 来自相关话题

这次数人云与大家分享的文章里,主要介绍了Docker Swarm如何凭借革新对整体场景进一步加以简化。事实上,如今我们已经可以轻松且直观地构建起一套Docker Swarm集群,快来一起体验一下吧:)


下面先来看看各项具体的更新内容:

 我们在之前提到过一个示例,即一款由前端与多项后端服务共同构成的微服务应用。其中前端为Traefik HTTP代理,负责将各项请求路由至后端服务。而后端则非常简单,是一套基于Go的HTTP Web服务器,负责返回其运行所在的容器ID。





新的Docker Swarm不再需要为应用容器设置独立的HTTP代理。如上图所示的原有架构现在被精简为下图所示的形式:








移动部件更少了——赞!


另外,我们还为后端服务内置了负载均衡机制。我们甚至能够立足于集群内的任一节点访问这些服务。Docker Swarm还集成有一种内置网状路由机制,用于将各请求路由至适合的后端容器当中。

面对这些新功能,有些朋友可能认为Docker Swarm集群的设置过程会比原本更为复杂。事实上,整个流程反而更加简单。


仍然半信半疑?下面一起来看。

没错,这次我们仍然使用Raspberry Pi集群。我使用的是Docker 1.12内部版本,并将其安装在Raspberry Pi上。当Docker 1.12推出正式版后,我们会对内容做出针对性更新。


下面看看当前配置:
root@pi6 $ docker version
Client:
Version: 1.12.0-rc1
API version: 1.24
Go version: go1.6.2
Git commit: 1f136c1-unsupported
Built: Wed Jun 15 15:35:51 2016
OS/Arch: linux/arm

Server:
Version: 1.12.0-rc1
API version: 1.24
Go version: go1.6.2
Git commit: 1f136c1-unsupported
Built: Wed Jun 15 15:35:51 2016
OS/Arch: linux/arm
 
很好,Docker 1.12 RC1已经准备就绪。下面启动各项必要服务。


首先看看我们能否在Docker CLI中找到隐藏的各项新功能。
root@pi6 $ docker
Usage: docker [OPTIONS] COMMAND [arg...]
docker [ --help | -v | --version ]

A self-sufficient runtime for containers.
...
service Manage Docker services
...
stats Display a live stream of container(s) resource usage statistics
...
swarm Manage Docker Swarm
...
update Update configuration of one or more containers

Run 'docker COMMAND --help' for more information on a command.
我直接去掉了其中与上代版本完全一致的部分,而只留了不同之处。


现在我们可以使用docker swarm命令了。


查询其具体作用:
root@pi6 $ docker swarm
Usage: docker swarm COMMAND
Manage Docker Swarm
Options:
--help Print usage
Commands:
init Initialize a Swarm.
join Join a Swarm as a node and/or manager.
update update the Swarm.
leave Leave a Swarm.
inspect Inspect the Swarm
Run 'docker swarm COMMAND --help' for more information on a command.
就是说其用于“初始化一套Swarm”。看起来正是我们需要的。首先启动该命令。
root@pi6 $ docker swarm init
Swarm initialized: current node (1njlvzi9rk2syv3xojw217o0g) is now a manager.
现在我们的Swarm管理节点已经开始运行,接下来为集群添加更多节点。


前往集群中的另一节点并执行:
root@pi1 $ docker swarm join pi6:2377
This node joined a Swarm as a worker.
使用上述命令,我们在刚刚创建的初始Swarm集群中声明了应当加入该Swarm管理节点的各个新节点。Docker Swarm会在后台执行相关操作。


举例来说,其会为不同集群节点设置经过加密的彼此通信通道。我们不再需要自行管理TLS证书。


每位曾经设置过Docker Swarm集群的朋友,都会意识到新的流程有多么简单。

不过到这儿还没有结束。


Swarm管理节点中的一条“docker info”带来了一些有趣的提示。我仍然删去其中不必要的部分:
root@pi6 $ docker info
...
Swarm: active
NodeID: 1njlvzi9rk2syv3xojw217o0g
IsManager: Yes
Managers: 1
Nodes: 2
CACertHash: sha256:de4e2bff3b63700aad01df97bbe0397f131aabed5fabb7732283f044472323fc
...
Kernel Version: 4.4.10-hypriotos-v7+
Operating System: Raspbian GNU/Linux 8 (jessie)
OSType: linux
Architecture: armv7l
CPUs: 4
Total Memory: 925.4 MiB
Name: pi6
...
如大家所见,我们现在已经在“docker info”输出结果中有了新的“Swarm”部分,其告诉我们当前节点属于一套Swarm管理节点,且该集群由两个集群节点构成。


在第二个节点上,其输出结果与管理节点稍有不同:
Swarm: active
NodeID: 3fmwt4taurwxczr2icboojz8g
IsManager: No
到这里,我们已经拥有了一套有趣但仍然空空如也的Swarm集群。


我们还需要了解Docker 1.12中的service这项全新抽象定义。大家可能在前面的输出结果中注意到了docker service命令。所谓docker service,是指运行在容器当中且负责为外部世界提供运行在Swarm集群内的“service”的软件片段。

这样的一项服务可以由单一或者多套容器构成。在后一种情况下,我们可以确保服务拥有高可用性及/或负载均衡能力。

下面使用之前创建的“whoami”镜像建立这样一项服务。
root@pi6 $ docker service create --name whoami -p 80:8000 hypriot/rpi-whoami
buy0q65lw7nshm76kvy5imxk3
在“docker swarm ls”命令的帮助下,我们可以检查这项新服务的状态。
root@pi6 $ docker service ls
ID NAME SCALE IMAGE COMMAND
buy0q65lw7ns whoami 1 hypriot/rpi-whoami
下面检查我们是否能够通过curl命令向eth0网络接口发送l http命令,从而请求目录页面。
root@pi6 $ curl http://192.168.178.24
I'm 1b6df814c654
一切顺利,鼓掌!


有些朋友可能注意到,“docker swarm ls”命令的标题行中存在“SCALE”部分,这似乎意味着我们可以对服务进行扩展。
root@pi6 $ docker service scale whoami=5
whoami scaled to 5
那就来实际验证一下吧:
root@pi6 $ docker service ls
ID NAME SCALE IMAGE COMMAND
buy0q65lw7ns whoami 5 hypriot/rpi-whoami

root@pi6 $ for i in {1..5}; do curl http://192.168.178.24; done
I'm 8db1657e8517
I'm e1863a2be88d
I'm 1b6df814c654
I'm 8db1657e8517
I'm e1863a2be88d
非常简单。


但这种方式与原有Swarm其实差不多,只不过在使用感受上更便捷也更快速。请注意,我们使用的是Raspberry Pi而非强大的服务器,所以要对性能拥有较为保守的估计。


下面从单一Docker引擎的角度来看看目前的运行状态:
root@pi6 $ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e1863a2be88d hypriot/rpi-whoami:latest "/http" 2 minutes ago Up 2 minutes 8000/tcp whoami.4.0lg12zndbal72exqe08r9wvpg
8db1657e8517 hypriot/rpi-whoami:latest "/http" 2 minutes ago Up 2 minutes 8000/tcp whoami.5.5z6mvsrdy73m5w24icgsqc8i2
1b6df814c654 hypriot/rpi-whoami:latest "/http" 8 minutes ago Up 8 minutes 8000/tcp whoami.1.bg4qlpiye6h6uxyf8cmkwuh52
如大家所见,已经启动的容器有5套,其中3套驻留于“pi6”中。


下面看看是否能够找到其它容器:
root@pi1 docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db411a119c0a hypriot/rpi-whoami:latest "/http" 6 minutes ago Up 6 minutes 8000/tcp whoami.2.2tf7yhmx9haol7e2b7xib2emj
0a4bf32fa9c4 hypriot/rpi-whoami:latest "/http" 6 minutes ago Up 6 minutes 8000/tcp whoami.3.2r6mm091c2ybr0f9jz4qaxw9k
那么如果我们将这套Swarm集群驻留在“pi1”上,结果又会如何?
root@pi1 docker swarm leave
Node left the default swarm.
下面看看另一节点上的运行情况:docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
58620e3d533c hypriot/rpi-whoami:latest "/http" 46 seconds ago Up 43 seconds 8000/tcp whoami.2.cgc4e2ixulc2f3ehr4laoursg
acc9b523f434 hypriot/rpi-whoami:latest "/http" 46 seconds ago Up 43 seconds 8000/tcp whoami.3.67bhlo3nwgehthi3bg5bfdzue
e1863a2be88d hypriot/rpi-whoami:latest "/http" 8 minutes ago Up 8 minutes 8000/tcp whoami.4.0lg12zndbal72exqe08r9wvpg
8db1657e8517 hypriot/rpi-whoami:latest "/http" 8 minutes ago Up 8 minutes 8000/tcp whoami.5.5z6mvsrdy73m5w24icgsqc8i2
1b6df814c654 hypriot/rpi-whoami:latest "/http" 15 minutes ago Up 14 minutes 8000/tcp whoami.1.bg4qlpiye6h6uxyf8cmkwuh52
这里的情况相当于“pi1”节点发生故障,此时“pi1”中运行的全部容器都会被自动迁移至另一集群节点。这项机制在实际生产当中无疑非常重要。


那么下面我们回顾一下之前了解到的信息:


我们创建了一款小型动态微服务应用,完全由Docker构成。Docker Swarm现在被整合至Docker-Engine当中,而不再以独立软件形式存在。在多数情况下,这能够为应用后端服务建立起独立的代理机制。不再需要使用nginx、HAProxy或者Traefik。

尽管活动部件数量有所减少,但我们现在反而拥有了内置的高可用性与负载均衡功能。我非常期待未来Docker Swarm正式版本中会带来哪些新的惊喜,又如何与Docker Compose进行协作。 查看全部

这次数人云与大家分享的文章里,主要介绍了Docker Swarm如何凭借革新对整体场景进一步加以简化。事实上,如今我们已经可以轻松且直观地构建起一套Docker Swarm集群,快来一起体验一下吧:)


下面先来看看各项具体的更新内容:

 我们在之前提到过一个示例,即一款由前端与多项后端服务共同构成的微服务应用。其中前端为Traefik HTTP代理,负责将各项请求路由至后端服务。而后端则非常简单,是一套基于Go的HTTP Web服务器,负责返回其运行所在的容器ID。

1.jpg

新的Docker Swarm不再需要为应用容器设置独立的HTTP代理。如上图所示的原有架构现在被精简为下图所示的形式:


2.jpg



移动部件更少了——赞!


另外,我们还为后端服务内置了负载均衡机制。我们甚至能够立足于集群内的任一节点访问这些服务。Docker Swarm还集成有一种内置网状路由机制,用于将各请求路由至适合的后端容器当中。

面对这些新功能,有些朋友可能认为Docker Swarm集群的设置过程会比原本更为复杂。事实上,整个流程反而更加简单。


仍然半信半疑?下面一起来看。

没错,这次我们仍然使用Raspberry Pi集群。我使用的是Docker 1.12内部版本,并将其安装在Raspberry Pi上。当Docker 1.12推出正式版后,我们会对内容做出针对性更新。


下面看看当前配置:
root@pi6 $ docker version
Client:
Version: 1.12.0-rc1
API version: 1.24
Go version: go1.6.2
Git commit: 1f136c1-unsupported
Built: Wed Jun 15 15:35:51 2016
OS/Arch: linux/arm

Server:
Version: 1.12.0-rc1
API version: 1.24
Go version: go1.6.2
Git commit: 1f136c1-unsupported
Built: Wed Jun 15 15:35:51 2016
OS/Arch: linux/arm

 
很好,Docker 1.12 RC1已经准备就绪。下面启动各项必要服务。


首先看看我们能否在Docker CLI中找到隐藏的各项新功能。
root@pi6 $ docker
Usage: docker [OPTIONS] COMMAND [arg...]
docker [ --help | -v | --version ]

A self-sufficient runtime for containers.
...
service Manage Docker services
...
stats Display a live stream of container(s) resource usage statistics
...
swarm Manage Docker Swarm
...
update Update configuration of one or more containers

Run 'docker COMMAND --help' for more information on a command.

我直接去掉了其中与上代版本完全一致的部分,而只留了不同之处。


现在我们可以使用docker swarm命令了。


查询其具体作用:
root@pi6 $ docker swarm
Usage: docker swarm COMMAND
Manage Docker Swarm
Options:
--help Print usage
Commands:
init Initialize a Swarm.
join Join a Swarm as a node and/or manager.
update update the Swarm.
leave Leave a Swarm.
inspect Inspect the Swarm
Run 'docker swarm COMMAND --help' for more information on a command.

就是说其用于“初始化一套Swarm”。看起来正是我们需要的。首先启动该命令。
root@pi6 $ docker swarm init
Swarm initialized: current node (1njlvzi9rk2syv3xojw217o0g) is now a manager.

现在我们的Swarm管理节点已经开始运行,接下来为集群添加更多节点。


前往集群中的另一节点并执行:
root@pi1 $ docker swarm join pi6:2377
This node joined a Swarm as a worker.

使用上述命令,我们在刚刚创建的初始Swarm集群中声明了应当加入该Swarm管理节点的各个新节点。Docker Swarm会在后台执行相关操作。


举例来说,其会为不同集群节点设置经过加密的彼此通信通道。我们不再需要自行管理TLS证书。


每位曾经设置过Docker Swarm集群的朋友,都会意识到新的流程有多么简单。

不过到这儿还没有结束。


Swarm管理节点中的一条“docker info”带来了一些有趣的提示。我仍然删去其中不必要的部分:
root@pi6 $ docker info
...
Swarm: active
NodeID: 1njlvzi9rk2syv3xojw217o0g
IsManager: Yes
Managers: 1
Nodes: 2
CACertHash: sha256:de4e2bff3b63700aad01df97bbe0397f131aabed5fabb7732283f044472323fc
...
Kernel Version: 4.4.10-hypriotos-v7+
Operating System: Raspbian GNU/Linux 8 (jessie)
OSType: linux
Architecture: armv7l
CPUs: 4
Total Memory: 925.4 MiB
Name: pi6
...

如大家所见,我们现在已经在“docker info”输出结果中有了新的“Swarm”部分,其告诉我们当前节点属于一套Swarm管理节点,且该集群由两个集群节点构成。


在第二个节点上,其输出结果与管理节点稍有不同:
Swarm: active
NodeID: 3fmwt4taurwxczr2icboojz8g
IsManager: No

到这里,我们已经拥有了一套有趣但仍然空空如也的Swarm集群。


我们还需要了解Docker 1.12中的service这项全新抽象定义。大家可能在前面的输出结果中注意到了docker service命令。所谓docker service,是指运行在容器当中且负责为外部世界提供运行在Swarm集群内的“service”的软件片段。

这样的一项服务可以由单一或者多套容器构成。在后一种情况下,我们可以确保服务拥有高可用性及/或负载均衡能力。

下面使用之前创建的“whoami”镜像建立这样一项服务。
root@pi6 $ docker service create --name whoami -p 80:8000 hypriot/rpi-whoami
buy0q65lw7nshm76kvy5imxk3

在“docker swarm ls”命令的帮助下,我们可以检查这项新服务的状态。
root@pi6 $ docker service ls
ID NAME SCALE IMAGE COMMAND
buy0q65lw7ns whoami 1 hypriot/rpi-whoami

下面检查我们是否能够通过curl命令向eth0网络接口发送l http命令,从而请求目录页面。
root@pi6 $ curl http://192.168.178.24
I'm 1b6df814c654

一切顺利,鼓掌!


有些朋友可能注意到,“docker swarm ls”命令的标题行中存在“SCALE”部分,这似乎意味着我们可以对服务进行扩展。
root@pi6 $ docker service scale whoami=5
whoami scaled to 5

那就来实际验证一下吧:
root@pi6 $ docker service ls
ID NAME SCALE IMAGE COMMAND
buy0q65lw7ns whoami 5 hypriot/rpi-whoami

root@pi6 $ for i in {1..5}; do curl http://192.168.178.24; done
I'm 8db1657e8517
I'm e1863a2be88d
I'm 1b6df814c654
I'm 8db1657e8517
I'm e1863a2be88d

非常简单。


但这种方式与原有Swarm其实差不多,只不过在使用感受上更便捷也更快速。请注意,我们使用的是Raspberry Pi而非强大的服务器,所以要对性能拥有较为保守的估计。


下面从单一Docker引擎的角度来看看目前的运行状态:
root@pi6 $ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e1863a2be88d hypriot/rpi-whoami:latest "/http" 2 minutes ago Up 2 minutes 8000/tcp whoami.4.0lg12zndbal72exqe08r9wvpg
8db1657e8517 hypriot/rpi-whoami:latest "/http" 2 minutes ago Up 2 minutes 8000/tcp whoami.5.5z6mvsrdy73m5w24icgsqc8i2
1b6df814c654 hypriot/rpi-whoami:latest "/http" 8 minutes ago Up 8 minutes 8000/tcp whoami.1.bg4qlpiye6h6uxyf8cmkwuh52

如大家所见,已经启动的容器有5套,其中3套驻留于“pi6”中。


下面看看是否能够找到其它容器:
root@pi1 docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db411a119c0a hypriot/rpi-whoami:latest "/http" 6 minutes ago Up 6 minutes 8000/tcp whoami.2.2tf7yhmx9haol7e2b7xib2emj
0a4bf32fa9c4 hypriot/rpi-whoami:latest "/http" 6 minutes ago Up 6 minutes 8000/tcp whoami.3.2r6mm091c2ybr0f9jz4qaxw9k

那么如果我们将这套Swarm集群驻留在“pi1”上,结果又会如何?
root@pi1 docker swarm leave
Node left the default swarm.

下面看看另一节点上的运行情况:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
58620e3d533c hypriot/rpi-whoami:latest "/http" 46 seconds ago Up 43 seconds 8000/tcp whoami.2.cgc4e2ixulc2f3ehr4laoursg
acc9b523f434 hypriot/rpi-whoami:latest "/http" 46 seconds ago Up 43 seconds 8000/tcp whoami.3.67bhlo3nwgehthi3bg5bfdzue
e1863a2be88d hypriot/rpi-whoami:latest "/http" 8 minutes ago Up 8 minutes 8000/tcp whoami.4.0lg12zndbal72exqe08r9wvpg
8db1657e8517 hypriot/rpi-whoami:latest "/http" 8 minutes ago Up 8 minutes 8000/tcp whoami.5.5z6mvsrdy73m5w24icgsqc8i2
1b6df814c654 hypriot/rpi-whoami:latest "/http" 15 minutes ago Up 14 minutes 8000/tcp whoami.1.bg4qlpiye6h6uxyf8cmkwuh52

这里的情况相当于“pi1”节点发生故障,此时“pi1”中运行的全部容器都会被自动迁移至另一集群节点。这项机制在实际生产当中无疑非常重要。


那么下面我们回顾一下之前了解到的信息:


我们创建了一款小型动态微服务应用,完全由Docker构成。Docker Swarm现在被整合至Docker-Engine当中,而不再以独立软件形式存在。在多数情况下,这能够为应用后端服务建立起独立的代理机制。不再需要使用nginx、HAProxy或者Traefik。

尽管活动部件数量有所减少,但我们现在反而拥有了内置的高可用性与负载均衡功能。我非常期待未来Docker Swarm正式版本中会带来哪些新的惊喜,又如何与Docker Compose进行协作。

响应银监会十三五规划之拥抱容器系列(一):微服务化

宁静胡同 发表了文章 • 0 个评论 • 451 次浏览 • 2016-07-21 11:50 • 来自相关话题

中国银监会7月15日就《中国银行业信息科技“十三五”发展规划监管指导意见(征求意见稿)》(以下简称指导意见)公开征求意见。从提升信息科技治理水平,深化科技创新,推进互联网、大数据、云计算新技术应用等方面入手,指出健全产品研发管理机制,加强信息安全管理,提升信息科技风险管理水平,推进科技开发协作等方面重点工作任务。

指导意见同时指出,银行业应该适应互联网环境下计算资源弹性变化和快速部署等需求,开展云计算架构规划,制定云计算应用策略。探索构建私有云平台,采用成熟度高、开放性强的计算虚拟化、容器虚拟化、分布式存储、网络虚拟化等技术,建立资源池,形成资源弹性供给、灵活调度和动态计量的私有云平台。探索建立银行业金融公共服务行业云,构建私有云与行业云相结合的混合云应用。同步开展应用架构规划,构建与云计算基础设施相适应的应用架构,自主设计或推动应用开发商实施应用架构改造,并降低应用与基础架构的耦合度。稳步实施架构迁移,到“十三五”末期,面向互联网场景的主要信息系统尽可能迁移至云计算架构平台。

银行业拥抱云计算已经是必然趋势,而容器则是其中的关键技术。数人云推出了传统金融业Docker实践系列组图与文章,将一一为大家展现传统金融业的转型过程中的技术细节与实践心得,欢迎大家持续关注。







数人金融容器云

作为基于Docker的最轻量级PaaS平台,数人金融容器云致力于打造金融领域专属的云原生应用平台,实现秒级启停,帮助客户及时响应高并发等新型业务需求;同时,借助容器技术,使应用的交付变得标准,极大地消除技术部署的局限性,提高客户产品的交付及运维效率;数人金融容器云平台自身具备高可用能力,以最大程度保证对工作集群不间断管控,工作集群内的各组件也具备高可用特性,进一步保障了客户的容器化应用安全、可靠、稳定运行;提供从主机网络到应用容器实例的多级实时监控和告警机制,极大降低了金融IT运维风险。

目前,数人云在金融领域已有多家合作客户,帮助金融客户在互联网+时代下构建开放业务新形态,从平台转型、产品创新、服务交付等层面推进金融业信息化变革,激发创新活力。


  查看全部
中国银监会7月15日就《中国银行业信息科技“十三五”发展规划监管指导意见(征求意见稿)》(以下简称指导意见)公开征求意见。从提升信息科技治理水平,深化科技创新,推进互联网、大数据、云计算新技术应用等方面入手,指出健全产品研发管理机制,加强信息安全管理,提升信息科技风险管理水平,推进科技开发协作等方面重点工作任务。

指导意见同时指出,银行业应该适应互联网环境下计算资源弹性变化和快速部署等需求,开展云计算架构规划,制定云计算应用策略。探索构建私有云平台,采用成熟度高、开放性强的计算虚拟化、容器虚拟化、分布式存储、网络虚拟化等技术,建立资源池,形成资源弹性供给、灵活调度和动态计量的私有云平台。探索建立银行业金融公共服务行业云,构建私有云与行业云相结合的混合云应用。同步开展应用架构规划,构建与云计算基础设施相适应的应用架构,自主设计或推动应用开发商实施应用架构改造,并降低应用与基础架构的耦合度。稳步实施架构迁移,到“十三五”末期,面向互联网场景的主要信息系统尽可能迁移至云计算架构平台。

银行业拥抱云计算已经是必然趋势,而容器则是其中的关键技术。数人云推出了传统金融业Docker实践系列组图与文章,将一一为大家展现传统金融业的转型过程中的技术细节与实践心得,欢迎大家持续关注。


654082800374343878.png


数人金融容器云

作为基于Docker的最轻量级PaaS平台,数人金融容器云致力于打造金融领域专属的云原生应用平台,实现秒级启停,帮助客户及时响应高并发等新型业务需求;同时,借助容器技术,使应用的交付变得标准,极大地消除技术部署的局限性,提高客户产品的交付及运维效率;数人金融容器云平台自身具备高可用能力,以最大程度保证对工作集群不间断管控,工作集群内的各组件也具备高可用特性,进一步保障了客户的容器化应用安全、可靠、稳定运行;提供从主机网络到应用容器实例的多级实时监控和告警机制,极大降低了金融IT运维风险。

目前,数人云在金融领域已有多家合作客户,帮助金融客户在互联网+时代下构建开放业务新形态,从平台转型、产品创新、服务交付等层面推进金融业信息化变革,激发创新活力。


 

Docker 1.12实践:Docker Service、Stack与分布式应用捆绑包

宁静胡同 发表了文章 • 0 个评论 • 887 次浏览 • 2016-07-13 15:10 • 来自相关话题

在本文中数人云将带大家了解如何利用Docker Compose创建一套分布式应用捆绑包,并将其作为Docker Stack在Docker Swarm Mode中进行部署。


Docker 1.12的首套候选发行版于三周之前公布,而近期又有更多新功能计划被添加至该版本当中。


下面首先来看各项新的功能特性:
内置编排机制:通常来讲,应用利用一个Docker Compose文件进行定义。此定义由多个被部署在不同主机上的容器共同构成。这种作法除了能够避免单点故障(简称SPOF)之外,也能够让应用具备弹性。目前包括Docker Swarm、Kubernetes以及Mesos在内的多种编排框架都允许大家对此类应用进行编排。不过现在我们又有了新的选择——Docker Engine如今迎来了内置编排机制。更多细节内容将在后文中进行说明。Service:现在大家可以利用docker service create 命令轻松创建一项复制且分布式的负载均衡服务。该应用可实现“理想状态”,例如运行三套Couchbase容器,并具备自我修复能力。Docker引擎能够确保必要容器数量始终运行于集群当中。如果某容器发生故障,那么另一容器将旋即启动。如果某台节点发生故障,则该节点上的容器会在另一节点上启动。稍后我们将详细说明其作用。零配置安全性: Docker 1.12采用相互验证TLS,能够对swarm当中各节点间的通信内容进行验证、授权与加密。更多详尽内容将在后文中进行讨论。

Docker Stack与分布式应用捆绑包:分布式应用捆绑包,或者简称DAB,是一种多服务可分发镜像格式。在后文中我们会进一步讨论。


截至目前,大家已经可以选定一个Dockerfile,并利用docker build命令由此创建镜像。使用docker run命令则可启动容器。这条命令亦能够轻松同时启动多套容器。另外,大家也可以使用Docker Compose文件并利用docker-compose scale命令对容器进行规模扩展。









镜像属于单一容器的一种便携式格式。而Docker 1.12当中新推出的分布式应用捆绑包,或者简称DAB,则属于一种新的概念,其专门面向多套容器的迁移需求。每个捆绑包都可作为stack在运行时中进行部署。









感兴趣的朋友可以前往docker.com/dab了解更多与DAB相关的内容。为了简单起见,在这里我们利用类比来进行说明:


kerfile -> 镜像 -> 容器

Docker Compose -> 分布式应用捆绑包 -> Docker Stack

下面我们使用一个Docker Compose文件来创建DAB,并将其作为Docker Stack加以部署。


需要强调的是,这项实验性功能仅存在于1.12-RC2版本当中。


利用Docker Compose创建一个分布式应用捆绑包


Docker Compose CLI添加了一条新的bundle命令。下面来看其具体说明:docker-compose bundle --help
Generate a Docker bundle from the Compose file.

Local images will be pushed to a Docker registry, and remote images
will be pulled to fetch an image digest.

Usage: bundle [options]

Options:
-o, --output PATH Path to write the bundle file to.
Defaults to "<project name>.dsb".
现在,让我们选取一条Docker Compose定义并以此为基础创建DAB。以下为我们的Docker Compose定义内容:version: "2"
services:
db:
container_name: "db"
image: arungupta/oreilly-couchbase:latest
ports:
- 8091:8091
- 8092:8092
- 8093:8093
- 11210:11210
web:
image: arungupta/oreilly-wildfly:latest
depends_on:
- db
environment:
- COUCHBASE_URI=db
ports:
- 8080:8080

此Compose文件会启动WildFly与Couchbase服务器。其中WildFly服务器中已经预部署了一款Java EE应用,且接入Couchbase服务器并允许利用REST API执行CRUD操作。该文件的源代码来自:github.com/arun-gupta/oreilly-docker-book/blob/master/hello-javaee/docker-compose.yml。利用它生成一个应用捆绑包:docker-compose bundle
WARNING: Unsupported key 'depends_on' in services.web - ignoring
WARNING: Unsupported key 'container_name' in services.db - ignoring
Wrote bundle to hellojavaee.dsb


depends_on只负责创建两项服务之间的依赖性,并以特定顺序对二者进行启动。这能确保Docker容器首先启动,而运行在其中的应用则需要更长时间才能启动完成。因此,此属性只在一定程度上解决了这一问题。


container_name能够为该容器提供一个特定名称。对特定容器名称的依赖性为紧密耦合,且不允许我们对该容器进行规模伸缩。因此这里我们暂时忽略这两条警告。此命令会利用Compose项目名(也就是其目录名称)生成一个文件。因此在本示例中,生成的文件名为hellojavaee.dsb。此文件的扩展名在RC3中则为.dab。此生成的应用捆绑包内容如下所示:{
"services": {
"db": {
"Image": "arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8091,
"Protocol": "tcp"
},
{
"Port": 8092,
"Protocol": "tcp"
},
{
"Port": 8093,
"Protocol": "tcp"
},
{
"Port": 11210,
"Protocol": "tcp"
}
]
},
"web": {
"Env": [
"COUCHBASE_URI=db"
],
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8080,
"Protocol": "tcp"
}
]
}
},
"version": "0.1"
}


此文件为包含在应用内的各项服务提供完整的描述。当然,未来我们应该可以使用其它容器格式,例如Rkt或者VM等形式。不过就目前来讲,其还仅支持Docker这一种格式。


在Docker中进行Swarm Mode初始化


正如之前所提到,目前“理想状态”由Docker Swarm负责保持。而其现在已经被纳入Docker Engine当中。在本篇文章中,我们使用新增的一条命令,即docker swarm:docker swarm --help

Usage: docker swarm COMMAND

Manage Docker Swarm

Options:
--help Print usage

Commands:
init Initialize a Swarm
join Join a Swarm as a node and/or manager
update Update the Swarm
leave Leave a Swarm
inspect Inspect the Swarm

Run 'docker swarm COMMAND --help' for more information on a command.
在Docker Engine中对一个Swarm节点(作为工作节点)进行初始化:docker swarm init
Swarm initialized: current node (ek9p1k8r8ox7iiua5c247skci) is now a manager.

关于该节点的更多细节信息可利用docker swarm inspect命令进行查看。docker swarm inspect
[
{
"ID": "1rcvu7m9mv2c8hiaijr7an9zk",
"Version": {
"Index": 1895
},
"CreatedAt": "2016-07-01T23:52:38.074748177Z",
"UpdatedAt": "2016-07-02T04:54:32.79093117Z",
"Spec": {
"Name": "default",
"AcceptancePolicy":{
"Policies": [
{
"Role": "worker",
"Autoaccept": true
},
{
"Role": "manager",
"Autoaccept":false
}
]
},
"Orchestration": {
"TaskHistoryRetentionLimit":10
},
"Raft": {
"SnapshotInterval": 10000,
"LogEntriesForSlowFollowers":500,
"HeartbeatTick":1,
"ElectionTick":3
},
"Dispatcher": {
"HeartbeatPeriod": 5000000000
},
"CAConfig": {
"NodeCertExpiry": 7776000000000000
}
}
}
]
从输出结果中可以看到,该节点只属于工作节点而非管理节点。如果在单节点集群当中,这样的设置并无不妥。不过在多节点集群当中,则应至少存在一个管理节点。


部署Docker Stack


利用docker deploy命令创建一个stack:docker deploy -f hellojavaee.dsb hellojavaee
Loading bundle from hellojavaee.dsb
Creating network hellojavaee_default
Creating service hellojavaee_db
Creating service hellojavaee_web
下面来看各服务列表:docker service ls
ID NAME REPLICAS IMAGE COMMAND
2g8kmrimztes hellojavaee_web 1/1 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914
46xhlb15cc60 hellojavaee_db 1/1 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c

在输出结果中,我们可以看到正在运行的两项服务,分别为WildFly与Couchbase。 Service概念同样新增于Docker 1.12版本,其负责为我们提供“理想状态”,而具体实现则由Docker Engine负责。使用docker ps命令显示当前正在运行的容器列表:CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 3 seconds ago Up 1 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29
abf8703ed713 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 3 seconds ago Up 1 seconds 8080/tcp hellojavaee_web.1.70piloz6j4zt06co8htzisgyl

WildFly容器会在Couchbase容器启动并运行之前先行启动。这意味着Java EE应用会尝试接入Couchbase服务器但发生失败。因此,该应用将永远无法成功完成引导。


自我修复Docker Service


Docker Service负责保持应用的“理想状态”。在本示例中,我们的理想状态是确保特定服务有且只有一套容器与之对应且持续运行。如果我们移除该容器,而非服务,则该服务会自动重启容器。使用以下命令移除容器:docker rm -f abf8703ed713

请注意,这里之所以要使用-f,是因为该容器已经处于运行状态。Docker 1.12自我修复机制会介入并自动重启此容器。现在再次打开运行容器列表:CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db483ac27e41 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 1 seconds ago Up Less than a second 8080/tcp hellojavaee_web.1.ddvwdmojjysf46d4n3x4g8uv4
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 26 seconds ago Up 25 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29
结果显示新容器已经启动完成。检查WildFly服务:docker service inspect hellojavaee_web
[
{
"ID": "54otfi6dc9bis7z6gc6ubynwc",
"Version": {
"Index": 328
},
"CreatedAt": "2016-07-02T01:36:35.735767569Z",
"UpdatedAt": "2016-07-02T01:36:35.739240775Z",
"Spec": {
"Name": "hellojavaee_web",
"Labels": {
"com.docker.stack.namespace": "hellojavaee"
},
"TaskTemplate": {
"ContainerSpec": {
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Env": [
"COUCHBASE_URI=db"
]
}
},
"Mode": {
"Replicated": {
"Replicas": 1
}
},
"Networks": [
{
"Target": "epw57lz7txtfchmbf6u0cimis",
"Aliases": [
"web"
]
}
],
"EndpointSpec": {
"Mode": "vip",
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080
}
]
}
},
"Endpoint": {
"Spec": {},
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080,
"PublishedPort": 30004
}
],
"VirtualIPs": [
{
"NetworkID": "9lpz688ir3pzexubkcb828ikg",
"Addr": "10.255.0.5/16"
},
{
"NetworkID": "epw57lz7txtfchmbf6u0cimis",
"Addr": "10.0.0.4/24"
}
]
}
}
]




Swarm会将随机端口分配给该服务,我们也可以利用docker service update命令进行手动更新。在本示例中,容器的端口8080被映射至主机上的端口30004。



进行应用验证


下面检查该应用是否已经成功部署:curl http://localhost:30004/books/resources/book
[{"books":0}]


为该应用添加新的book:curl -v \
> -H "Content-Type: application/json" \
> -X POST -d '{
> "isbn": "978-1-4919-1889-0",
> "name": "Minecraft Modding with Forge",
> "cost": 29.99
> }' \
> http://localhost:30004/books/resources/book
* Trying ::1...
* Connected to localhost (::1) port 30004 (#0)
> POST /books/resources/book HTTP/1.1
> Host: localhost:30004
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 92
>
* upload completely sent off: 92 out of 92 bytes
< HTTP/1.1 200 OK
< Connection: keep-alive
< X-Powered-By: Undertow/1
< Server: WildFly/10
< Content-Type: application/octet-stream
< Content-Length: 88
< Date: Sat, 02 Jul 2016 01:39:49 GMT
<
* Connection #0 to host localhost left intact
{"name":"Minecraft Mhttp://localhost:30004/books/r ... ot%3B}



再次验证该book:curl http://localhost:30004/books/resources/book
[{"books":{"name":"Minecraft Modding with Forge","cost":29.99,"id":"1","isbn":"978-1-4919-1889-0"}}, {"books":1}]
欲了解更多与此Java应用相关的信息,请访问github.com/arun-gupta/oreilly-docker-book/tree/master/hello-javaee。 查看全部
在本文中数人云将带大家了解如何利用Docker Compose创建一套分布式应用捆绑包,并将其作为Docker Stack在Docker Swarm Mode中进行部署。


Docker 1.12的首套候选发行版于三周之前公布,而近期又有更多新功能计划被添加至该版本当中。


下面首先来看各项新的功能特性:
  • 内置编排机制:通常来讲,应用利用一个Docker Compose文件进行定义。此定义由多个被部署在不同主机上的容器共同构成。这种作法除了能够避免单点故障(简称SPOF)之外,也能够让应用具备弹性。目前包括Docker Swarm、Kubernetes以及Mesos在内的多种编排框架都允许大家对此类应用进行编排。不过现在我们又有了新的选择——Docker Engine如今迎来了内置编排机制。更多细节内容将在后文中进行说明。
  • Service:现在大家可以利用docker service create 命令轻松创建一项复制且分布式的负载均衡服务。该应用可实现“理想状态”,例如运行三套Couchbase容器,并具备自我修复能力。Docker引擎能够确保必要容器数量始终运行于集群当中。如果某容器发生故障,那么另一容器将旋即启动。如果某台节点发生故障,则该节点上的容器会在另一节点上启动。稍后我们将详细说明其作用。
  • 零配置安全性: Docker 1.12采用相互验证TLS,能够对swarm当中各节点间的通信内容进行验证、授权与加密。更多详尽内容将在后文中进行讨论。


Docker Stack与分布式应用捆绑包:分布式应用捆绑包,或者简称DAB,是一种多服务可分发镜像格式。在后文中我们会进一步讨论。


截至目前,大家已经可以选定一个Dockerfile,并利用docker build命令由此创建镜像。使用docker run命令则可启动容器。这条命令亦能够轻松同时启动多套容器。另外,大家也可以使用Docker Compose文件并利用docker-compose scale命令对容器进行规模扩展。



1.png



镜像属于单一容器的一种便携式格式。而Docker 1.12当中新推出的分布式应用捆绑包,或者简称DAB,则属于一种新的概念,其专门面向多套容器的迁移需求。每个捆绑包都可作为stack在运行时中进行部署。


2.png




感兴趣的朋友可以前往docker.com/dab了解更多与DAB相关的内容。为了简单起见,在这里我们利用类比来进行说明:


kerfile -> 镜像 -> 容器

Docker Compose -> 分布式应用捆绑包 -> Docker Stack

下面我们使用一个Docker Compose文件来创建DAB,并将其作为Docker Stack加以部署。


需要强调的是,这项实验性功能仅存在于1.12-RC2版本当中。


利用Docker Compose创建一个分布式应用捆绑包


Docker Compose CLI添加了一条新的bundle命令。下面来看其具体说明:
docker-compose bundle --help
Generate a Docker bundle from the Compose file.

Local images will be pushed to a Docker registry, and remote images
will be pulled to fetch an image digest.

Usage: bundle [options]

Options:
-o, --output PATH Path to write the bundle file to.
Defaults to "<project name>.dsb".

现在,让我们选取一条Docker Compose定义并以此为基础创建DAB。以下为我们的Docker Compose定义内容:
version: "2"
services:
db:
container_name: "db"
image: arungupta/oreilly-couchbase:latest
ports:
- 8091:8091
- 8092:8092
- 8093:8093
- 11210:11210
web:
image: arungupta/oreilly-wildfly:latest
depends_on:
- db
environment:
- COUCHBASE_URI=db
ports:
- 8080:8080


此Compose文件会启动WildFly与Couchbase服务器。其中WildFly服务器中已经预部署了一款Java EE应用,且接入Couchbase服务器并允许利用REST API执行CRUD操作。该文件的源代码来自:github.com/arun-gupta/oreilly-docker-book/blob/master/hello-javaee/docker-compose.yml。利用它生成一个应用捆绑包:
docker-compose bundle
WARNING: Unsupported key 'depends_on' in services.web - ignoring
WARNING: Unsupported key 'container_name' in services.db - ignoring
Wrote bundle to hellojavaee.dsb


depends_on只负责创建两项服务之间的依赖性,并以特定顺序对二者进行启动。这能确保Docker容器首先启动,而运行在其中的应用则需要更长时间才能启动完成。因此,此属性只在一定程度上解决了这一问题。


container_name能够为该容器提供一个特定名称。对特定容器名称的依赖性为紧密耦合,且不允许我们对该容器进行规模伸缩。因此这里我们暂时忽略这两条警告。此命令会利用Compose项目名(也就是其目录名称)生成一个文件。因此在本示例中,生成的文件名为hellojavaee.dsb。此文件的扩展名在RC3中则为.dab。此生成的应用捆绑包内容如下所示:
{
"services": {
"db": {
"Image": "arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8091,
"Protocol": "tcp"
},
{
"Port": 8092,
"Protocol": "tcp"
},
{
"Port": 8093,
"Protocol": "tcp"
},
{
"Port": 11210,
"Protocol": "tcp"
}
]
},
"web": {
"Env": [
"COUCHBASE_URI=db"
],
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8080,
"Protocol": "tcp"
}
]
}
},
"version": "0.1"
}


此文件为包含在应用内的各项服务提供完整的描述。当然,未来我们应该可以使用其它容器格式,例如Rkt或者VM等形式。不过就目前来讲,其还仅支持Docker这一种格式。


在Docker中进行Swarm Mode初始化


正如之前所提到,目前“理想状态”由Docker Swarm负责保持。而其现在已经被纳入Docker Engine当中。在本篇文章中,我们使用新增的一条命令,即docker swarm:
docker swarm --help

Usage: docker swarm COMMAND

Manage Docker Swarm

Options:
--help Print usage

Commands:
init Initialize a Swarm
join Join a Swarm as a node and/or manager
update Update the Swarm
leave Leave a Swarm
inspect Inspect the Swarm

Run 'docker swarm COMMAND --help' for more information on a command.

在Docker Engine中对一个Swarm节点(作为工作节点)进行初始化:
docker swarm init
Swarm initialized: current node (ek9p1k8r8ox7iiua5c247skci) is now a manager.


关于该节点的更多细节信息可利用docker swarm inspect命令进行查看。
docker swarm inspect
[
{
"ID": "1rcvu7m9mv2c8hiaijr7an9zk",
"Version": {
"Index": 1895
},
"CreatedAt": "2016-07-01T23:52:38.074748177Z",
"UpdatedAt": "2016-07-02T04:54:32.79093117Z",
"Spec": {
"Name": "default",
"AcceptancePolicy":{
"Policies": [
{
"Role": "worker",
"Autoaccept": true
},
{
"Role": "manager",
"Autoaccept":false
}
]
},
"Orchestration": {
"TaskHistoryRetentionLimit":10
},
"Raft": {
"SnapshotInterval": 10000,
"LogEntriesForSlowFollowers":500,
"HeartbeatTick":1,
"ElectionTick":3
},
"Dispatcher": {
"HeartbeatPeriod": 5000000000
},
"CAConfig": {
"NodeCertExpiry": 7776000000000000
}
}
}
]

从输出结果中可以看到,该节点只属于工作节点而非管理节点。如果在单节点集群当中,这样的设置并无不妥。不过在多节点集群当中,则应至少存在一个管理节点。


部署Docker Stack


利用docker deploy命令创建一个stack:
docker deploy -f hellojavaee.dsb hellojavaee
Loading bundle from hellojavaee.dsb
Creating network hellojavaee_default
Creating service hellojavaee_db
Creating service hellojavaee_web

下面来看各服务列表:
docker service ls
ID NAME REPLICAS IMAGE COMMAND
2g8kmrimztes hellojavaee_web 1/1 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914
46xhlb15cc60 hellojavaee_db 1/1 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c


在输出结果中,我们可以看到正在运行的两项服务,分别为WildFly与Couchbase。 Service概念同样新增于Docker 1.12版本,其负责为我们提供“理想状态”,而具体实现则由Docker Engine负责。使用docker ps命令显示当前正在运行的容器列表:
CONTAINER ID        IMAGE                                                                                                 COMMAND                  CREATED             STATUS              PORTS                                                        NAMES
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 3 seconds ago Up 1 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29
abf8703ed713 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 3 seconds ago Up 1 seconds 8080/tcp hellojavaee_web.1.70piloz6j4zt06co8htzisgyl


WildFly容器会在Couchbase容器启动并运行之前先行启动。这意味着Java EE应用会尝试接入Couchbase服务器但发生失败。因此,该应用将永远无法成功完成引导。


自我修复Docker Service


Docker Service负责保持应用的“理想状态”。在本示例中,我们的理想状态是确保特定服务有且只有一套容器与之对应且持续运行。如果我们移除该容器,而非服务,则该服务会自动重启容器。使用以下命令移除容器:
docker rm -f abf8703ed713


请注意,这里之所以要使用-f,是因为该容器已经处于运行状态。Docker 1.12自我修复机制会介入并自动重启此容器。现在再次打开运行容器列表:
CONTAINER ID        IMAGE                                                                                                 COMMAND                  CREATED             STATUS                  PORTS                                                        NAMES
db483ac27e41 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 1 seconds ago Up Less than a second 8080/tcp hellojavaee_web.1.ddvwdmojjysf46d4n3x4g8uv4
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 26 seconds ago Up 25 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29

结果显示新容器已经启动完成。检查WildFly服务:
docker service inspect hellojavaee_web
[
{
"ID": "54otfi6dc9bis7z6gc6ubynwc",
"Version": {
"Index": 328
},
"CreatedAt": "2016-07-02T01:36:35.735767569Z",
"UpdatedAt": "2016-07-02T01:36:35.739240775Z",
"Spec": {
"Name": "hellojavaee_web",
"Labels": {
"com.docker.stack.namespace": "hellojavaee"
},
"TaskTemplate": {
"ContainerSpec": {
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Env": [
"COUCHBASE_URI=db"
]
}
},
"Mode": {
"Replicated": {
"Replicas": 1
}
},
"Networks": [
{
"Target": "epw57lz7txtfchmbf6u0cimis",
"Aliases": [
"web"
]
}
],
"EndpointSpec": {
"Mode": "vip",
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080
}
]
}
},
"Endpoint": {
"Spec": {},
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080,
"PublishedPort": 30004
}
],
"VirtualIPs": [
{
"NetworkID": "9lpz688ir3pzexubkcb828ikg",
"Addr": "10.255.0.5/16"
},
{
"NetworkID": "epw57lz7txtfchmbf6u0cimis",
"Addr": "10.0.0.4/24"
}
]
}
}
]




Swarm会将随机端口分配给该服务,我们也可以利用docker service update命令进行手动更新。在本示例中,容器的端口8080被映射至主机上的端口30004。



进行应用验证


下面检查该应用是否已经成功部署:
curl http://localhost:30004/books/resources/book
[{"books":0}]


为该应用添加新的book:
curl -v \
> -H "Content-Type: application/json" \
> -X POST -d '{
> "isbn": "978-1-4919-1889-0",
> "name": "Minecraft Modding with Forge",
> "cost": 29.99
> }' \
> http://localhost:30004/books/resources/book
* Trying ::1...
* Connected to localhost (::1) port 30004 (#0)
> POST /books/resources/book HTTP/1.1
> Host: localhost:30004
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 92
>
* upload completely sent off: 92 out of 92 bytes
< HTTP/1.1 200 OK
< Connection: keep-alive
< X-Powered-By: Undertow/1
< Server: WildFly/10
< Content-Type: application/octet-stream
< Content-Length: 88
< Date: Sat, 02 Jul 2016 01:39:49 GMT
<
* Connection #0 to host localhost left intact
{"name":"Minecraft Mhttp://localhost:30004/books/r ... ot%3B}




再次验证该book:
curl http://localhost:30004/books/resources/book
[{"books":{"name":"Minecraft Modding with Forge","cost":29.99,"id":"1","isbn":"978-1-4919-1889-0"}}, {"books":1}]

欲了解更多与此Java应用相关的信息,请访问github.com/arun-gupta/oreilly-docker-book/tree/master/hello-javaee。

中国开源云联盟容器工作组第一次会议召开

宁静胡同 发表了文章 • 0 个评论 • 486 次浏览 • 2016-07-08 16:24 • 来自相关话题

7月7日,中国开源云联盟WG11容器工作组第一次会议在京召开,会议的主题为“容器技术与标准交流会”。此次会议由中国电子技术标准化研究院主办,参与方包括中国开源云联盟容器工作组组长单位数人云,副组长单位CNTV,以及Hyper,去哪儿网,VMware,Intel,中国移动。







中国开源云联盟容器工作组第一次会议召开


会议上,参会单位首先围绕容器生态圈展开了讨论,数人云CTO肖德时和Hyper CTO王旭对容器生态圈以及容器发展趋势进行了分享,吕晓旭分享了去哪儿网使用Mesos+Docker技术在集群、日志收集等场景下的应用情况;张海宁分享了VMware针对容器研究情况,包括容器和虚拟化技术融合的研究以及纯容器数据中心的研究情况;杨剑浩分享了中国移动研究院容器技术在CRM等方面的应用情况;何钦钦分享了CNTV使用容器技术实现快速交付和资源回收的应用案例。此外,参会专家还针对容器在应用情况面临的问题和遇到的挑战展开了讨论。最后,中国电子技术标准化研究院高级工程师陈志峰介绍了我国云计算综合标准化指南、标准体系框架以及云计算标准化白皮书情况,为实现容器领域开展标准化工作提供借鉴。

后续容器工作组将开展我国容器应用和标准化白皮书的编制工作,白皮书编制工作的开展将有利于推动容器技术在国内的落地,并为建立符合中国本地化特征的容器标准奠定基础。


相关背景


中国开源云联盟由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟。作为领先的云计算创新技术实践者,数人云一直致力于推动开源技术的发展,并荣膺联盟挂靠中国电子技术标准化研究院后的首批成员单位。目前,联盟下设工作组工作范围从OpenStack逐渐向开源云计算生态圈的其他技术方向延伸,涉及我国云计算领域较热点的发展趋势,如混合云研究、千节点部署、Ceph开源技术、桌面云技术、容器技术等;同时,部分技术方向已开始探索标准化工作,开展开源标准研究,以及与国家标准、国际标准的配套方式的研究。


5月31日,中国开源云联盟2016年第一次理事会在京召开,会上中国开源云联盟Mesos工作组正式成立,为更好地推进容器及相关技术在中国的落地与实践,Mesos工作组现已正式更名为容器工作组。中国开源云联盟容器工作组旨在推动容器技术在国内的落地,提升容器技术在开源社区的贡献比例,并建立顺应国际技术发展趋势、符合中国本地化特征的容器标准体系。


关于数人云


数人云创始团队来自谷歌、红帽和惠普,在今年3月初公司完成A轮融资,由云启资本领投,思科、策源以及唯猎跟投。作为领先的云计算创新技术实践者,数人云致力于打造最轻量化的PaaS平台,将应用弹性做到极致。基于Docker + Mesos,数人云实现一站式的微服务架构集群系统,最大化地帮助客户实现应用业务在云端的快速部署,解决从客户到云资源的最后一公里。 查看全部
7月7日,中国开源云联盟WG11容器工作组第一次会议在京召开,会议的主题为“容器技术与标准交流会”。此次会议由中国电子技术标准化研究院主办,参与方包括中国开源云联盟容器工作组组长单位数人云,副组长单位CNTV,以及Hyper,去哪儿网,VMware,Intel,中国移动。


685425922798165313.jpg11_.jpg


中国开源云联盟容器工作组第一次会议召开


会议上,参会单位首先围绕容器生态圈展开了讨论,数人云CTO肖德时和Hyper CTO王旭对容器生态圈以及容器发展趋势进行了分享,吕晓旭分享了去哪儿网使用Mesos+Docker技术在集群、日志收集等场景下的应用情况;张海宁分享了VMware针对容器研究情况,包括容器和虚拟化技术融合的研究以及纯容器数据中心的研究情况;杨剑浩分享了中国移动研究院容器技术在CRM等方面的应用情况;何钦钦分享了CNTV使用容器技术实现快速交付和资源回收的应用案例。此外,参会专家还针对容器在应用情况面临的问题和遇到的挑战展开了讨论。最后,中国电子技术标准化研究院高级工程师陈志峰介绍了我国云计算综合标准化指南、标准体系框架以及云计算标准化白皮书情况,为实现容器领域开展标准化工作提供借鉴。

后续容器工作组将开展我国容器应用和标准化白皮书的编制工作,白皮书编制工作的开展将有利于推动容器技术在国内的落地,并为建立符合中国本地化特征的容器标准奠定基础。


相关背景


中国开源云联盟由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟。作为领先的云计算创新技术实践者,数人云一直致力于推动开源技术的发展,并荣膺联盟挂靠中国电子技术标准化研究院后的首批成员单位。目前,联盟下设工作组工作范围从OpenStack逐渐向开源云计算生态圈的其他技术方向延伸,涉及我国云计算领域较热点的发展趋势,如混合云研究、千节点部署、Ceph开源技术、桌面云技术、容器技术等;同时,部分技术方向已开始探索标准化工作,开展开源标准研究,以及与国家标准、国际标准的配套方式的研究。


5月31日,中国开源云联盟2016年第一次理事会在京召开,会上中国开源云联盟Mesos工作组正式成立,为更好地推进容器及相关技术在中国的落地与实践,Mesos工作组现已正式更名为容器工作组。中国开源云联盟容器工作组旨在推动容器技术在国内的落地,提升容器技术在开源社区的贡献比例,并建立顺应国际技术发展趋势、符合中国本地化特征的容器标准体系。


关于数人云


数人云创始团队来自谷歌、红帽和惠普,在今年3月初公司完成A轮融资,由云启资本领投,思科、策源以及唯猎跟投。作为领先的云计算创新技术实践者,数人云致力于打造最轻量化的PaaS平台,将应用弹性做到极致。基于Docker + Mesos,数人云实现一站式的微服务架构集群系统,最大化地帮助客户实现应用业务在云端的快速部署,解决从客户到云资源的最后一公里。

数人云 | 一场属于 Docker&Mesos 的夏日欢乐颂

宁静胡同 发表了文章 • 0 个评论 • 586 次浏览 • 2016-07-04 11:42 • 来自相关话题

上次畅谈容器技术的诗和远方还是 4 月份的春天, 如今,夏天已悄然而至。 在西雅图刚结束的 “DockerCon 2016” 大会上, Swarm 原生编排备受推崇, 有人不禁担心 Mesos 将何去何从? 7月份, 
让我们来一场属于 Docker&Mesos 的欢乐颂, 愉快地探讨一下这个“严肃”的话题:)

号外,论如何优雅的将开源技术进行到底, 中国开源云联盟成立了 WG11—容器工作组, 如果你是容器实践老司机, 欢迎加入开源云联盟, 现缺 2 枚副组长,点击 此处自荐

这次,我们邀请了......

Timothy Chen,硅谷 Mesos 专家【确认中】

分布式系统专家,专注于容器化和大数据框架。他是 Apache Drill 和 Apache Mesos 项目的 PMC/ 贡献者,对 Spark、Kafka 和 Docker 等开源项目亦有贡献。Tim 还有 Halo 上的大数据服务、CloudFoundry (PaaS) 和搜索引擎方面的经验。

《CNTV 容器技术探索与实践》 【已确认】

张航源,CNTV 技术中心-高级工程师

2009年加入CNTV,主要负责CNTV容器化的探索和平台搭建,存储平台的架构和运维,以及ELK平台的建设等工作。

《Containerizer Modularization Proposal for Mesos》【已确认】

黄浩松,Engineer @ Shopee

负责公司自动化运维平台建设。 业余时间在 Apache Mesos / Apache Hadoop / Apache HBase 打酱油。

《思科微服务管理框架 Mantl》【已确认】

谢军,思科大中华区解决方案和产品团队首席架构师

负责思科大中华区下一代数据中心和云体系架构及市场推广,专注混合云/微服务架构/分布式存储等。

议程,是这样安排的......

13:30 - 14:00 签到 
14:00 - 14:15 开场 
14:15 - 14:55 《CNTV容器技术探索与实践》张航源 
14:55 - 15:35 《Containerizer Modularization Proposal for Mesos》黄浩松 
15:35 - 16:15 Timothy Chen 
16:15 - 16:55 《思科微服务管理框架 Mantl》谢军 
16:55 - 17:10 《老肖有话说》肖德时

时间:7月23日 14:00 - 17:10 地点:P2 联合创业办公社—中关村 e 世界 A 座 B2

活动行报名链接:http://t.cn/R5QjqdF 查看全部
MESOS_5.jpg

上次畅谈容器技术的诗和远方还是 4 月份的春天, 如今,夏天已悄然而至。 在西雅图刚结束的 “DockerCon 2016” 大会上, Swarm 原生编排备受推崇, 有人不禁担心 Mesos 将何去何从? 7月份, 
让我们来一场属于 Docker&Mesos 的欢乐颂, 愉快地探讨一下这个“严肃”的话题:)

号外,论如何优雅的将开源技术进行到底, 中国开源云联盟成立了 WG11—容器工作组, 如果你是容器实践老司机, 欢迎加入开源云联盟, 现缺 2 枚副组长,点击 此处自荐

这次,我们邀请了......

Timothy Chen,硅谷 Mesos 专家【确认中】

分布式系统专家,专注于容器化和大数据框架。他是 Apache Drill 和 Apache Mesos 项目的 PMC/ 贡献者,对 Spark、Kafka 和 Docker 等开源项目亦有贡献。Tim 还有 Halo 上的大数据服务、CloudFoundry (PaaS) 和搜索引擎方面的经验。

《CNTV 容器技术探索与实践》 【已确认】

张航源,CNTV 技术中心-高级工程师

2009年加入CNTV,主要负责CNTV容器化的探索和平台搭建,存储平台的架构和运维,以及ELK平台的建设等工作。

《Containerizer Modularization Proposal for Mesos》【已确认】

黄浩松,Engineer @ Shopee

负责公司自动化运维平台建设。 业余时间在 Apache Mesos / Apache Hadoop / Apache HBase 打酱油。

《思科微服务管理框架 Mantl》【已确认】

谢军,思科大中华区解决方案和产品团队首席架构师

负责思科大中华区下一代数据中心和云体系架构及市场推广,专注混合云/微服务架构/分布式存储等。

议程,是这样安排的......

13:30 - 14:00 签到 
14:00 - 14:15 开场 
14:15 - 14:55 《CNTV容器技术探索与实践》张航源 
14:55 - 15:35 《Containerizer Modularization Proposal for Mesos》黄浩松 
15:35 - 16:15 Timothy Chen 
16:15 - 16:55 《思科微服务管理框架 Mantl》谢军 
16:55 - 17:10 《老肖有话说》肖德时

时间:7月23日 14:00 - 17:10 地点:P2 联合创业办公社—中关村 e 世界 A 座 B2

活动行报名链接:http://t.cn/R5QjqdF

关于Docker 1.12中的最新功能,你需要了解这些

宁静胡同 发表了文章 • 0 个评论 • 603 次浏览 • 2016-06-28 10:46 • 来自相关话题

DockerCon已然落幕,留下了无数激动人心的声音。随着Docker1.12版本的发布,众多新功能新提升的出现,无疑将对Docker为中心的生态圈产生不小的影响。今天小数与大家看一看新版本对于存储层面都有哪些影响——



新版本的发布对存储层面来说,最值得关注的自然是分卷驱动器支持能力的强化。这些变更不仅能够使我们对分卷进行标记,从而明确其属于本地抑或全局可访问对象,同时也能够提供与可用分卷相关的驱动器具体信息。另外,1.12版本中还出现了众多提升及修复机制。很明显,部分变更将帮助Docker Swarm更好地完成规模化使命,甚至可以说这一规模化发展思路正是本届DockerCon大会的主旨所在。


值得关注的变化


支持分卷范围(本地/全局)#22077


虽然这一变更谈不到什么飞跃,但如今使用docker分卷(例如swarm)的各服务已经能够将可用分卷识别为本地(特定主机)或全局(全部主机)。过去,当我们在swarm管理器中运行“docker volume ls”时,所有可用于全部swarm代理的全局分卷都会在各主机上被分别列出。这使得我们很难据此构建起可扩展的Docker Swarm集群。现在,新的调整让我们得以轻松区分全局分卷与本地分卷。








支持分卷状态 #21006


过去,每个Docker分卷只包含分卷名称、驱动器名称、安装位置以及基本标签(如果使用)等信息。








而在1.12版本中,我们能够获取更多来自驱动器的各分卷细节信息(嵌套于Status下)。








其它变化


支持ZFS分卷大小 #21946


在1.12版本之前,我们无法强制指定ZFS分卷的大小,但现在已经可以通过“-storage-opts”实现。


支持利用BTRFS实现磁盘配额 #19651


如果利用BTRFS取代devicemapper作为默认docker文件系统,我们将能够为各独立docker容器设置最大大小或容量配额。


分卷名称/驱动器过滤 #21015


新版本提供的增强过滤机制适用于“docker volume”命令/api请求。这意味着我们可以获取更为具体的特定分卷名称信息,或者可由特定分卷驱动器访问的全部分卷。


为分卷安装/卸载请求匹配惟一ID #21015


当分卷安装/卸载请求被发送至分卷驱动器时,系统会同时生成一条惟一ID以确保驱动器对各请求加以追踪。如此一来,分卷驱动器就能够更好地识别安装与卸载请求。


SELinux用户迎来小幅修复 #17262


如果大家在自己的docker主机上使用SELinux,则#17262能够修复将本地目录附加至新容器时z/Z权限选项的使用方式。在原有版本中,由于新容器中不存在启动所需要的文件夹,因此直接附加会导致失败。


本文源自:EMC {code},作者 Chris Duchesne 查看全部
DockerCon已然落幕,留下了无数激动人心的声音。随着Docker1.12版本的发布,众多新功能新提升的出现,无疑将对Docker为中心的生态圈产生不小的影响。今天小数与大家看一看新版本对于存储层面都有哪些影响——



新版本的发布对存储层面来说,最值得关注的自然是分卷驱动器支持能力的强化。这些变更不仅能够使我们对分卷进行标记,从而明确其属于本地抑或全局可访问对象,同时也能够提供与可用分卷相关的驱动器具体信息。另外,1.12版本中还出现了众多提升及修复机制。很明显,部分变更将帮助Docker Swarm更好地完成规模化使命,甚至可以说这一规模化发展思路正是本届DockerCon大会的主旨所在。


值得关注的变化


支持分卷范围(本地/全局)#22077


虽然这一变更谈不到什么飞跃,但如今使用docker分卷(例如swarm)的各服务已经能够将可用分卷识别为本地(特定主机)或全局(全部主机)。过去,当我们在swarm管理器中运行“docker volume ls”时,所有可用于全部swarm代理的全局分卷都会在各主机上被分别列出。这使得我们很难据此构建起可扩展的Docker Swarm集群。现在,新的调整让我们得以轻松区分全局分卷与本地分卷。


1.png



支持分卷状态 #21006


过去,每个Docker分卷只包含分卷名称、驱动器名称、安装位置以及基本标签(如果使用)等信息。



2.png


而在1.12版本中,我们能够获取更多来自驱动器的各分卷细节信息(嵌套于Status下)。


3.png



其它变化


支持ZFS分卷大小 #21946


在1.12版本之前,我们无法强制指定ZFS分卷的大小,但现在已经可以通过“-storage-opts”实现。


支持利用BTRFS实现磁盘配额 #19651


如果利用BTRFS取代devicemapper作为默认docker文件系统,我们将能够为各独立docker容器设置最大大小或容量配额。


分卷名称/驱动器过滤 #21015


新版本提供的增强过滤机制适用于“docker volume”命令/api请求。这意味着我们可以获取更为具体的特定分卷名称信息,或者可由特定分卷驱动器访问的全部分卷。


为分卷安装/卸载请求匹配惟一ID #21015


当分卷安装/卸载请求被发送至分卷驱动器时,系统会同时生成一条惟一ID以确保驱动器对各请求加以追踪。如此一来,分卷驱动器就能够更好地识别安装与卸载请求。


SELinux用户迎来小幅修复 #17262


如果大家在自己的docker主机上使用SELinux,则#17262能够修复将本地目录附加至新容器时z/Z权限选项的使用方式。在原有版本中,由于新容器中不存在启动所需要的文件夹,因此直接附加会导致失败。


本文源自:EMC {code},作者 Chris Duchesne

Marathon如何跑docker container -d

回复

xds2000 回复了问题 • 2 人关注 • 1 个回复 • 481 次浏览 • 2016-10-17 16:42 • 来自相关话题

五个小技巧,快速创建Docker镜像

宁静胡同 发表了文章 • 0 个评论 • 420 次浏览 • 2017-01-06 14:51 • 来自相关话题

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——


1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html 查看全部

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——




1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html

DevOps:谁说我只是自动化工具?

宁静胡同 发表了文章 • 0 个评论 • 291 次浏览 • 2016-12-13 16:31 • 来自相关话题

关于DevOps,每个人都有不同的认识。有人坚持它是一种方法论,然而在实践中为了脱离缓慢的手工作业,自动化工具必不可少。从职责传递到自助服务,DevOps为满足业务的快速交付而生,却存在学习上的瓶颈。
然后谢天谢地,容器来了……

参加了大大小小许多DevOps和软件工程的会议。每当”DevOps究竟意味着什么”这个话题被提起时,总是会有一个这样的论点出现:

DevOps不是一系列可以连贯起来的工具,你用了它们就可以说自己做的是DevOps。DevOps是一种方法论,让开发和运维团队能够更紧密工作的一套过程。最终的目标是消除在软件发布的过程中手动作业和耗费时间的部分,实现更多成功的部署和更频繁的发布。

它完全正确。然而,话虽如此,祝不使用自动化工具的DevOps或者持续交付……好运。

为什么自动化工具是先决条件

假设这样一个场景:你处在一个研发工作室,创业公司甚至是大型企业。你有很多开发人员,他们中的少数一些被称为“Ops小组”“DevOps魔法师”或者“云运维”,在企业中他们可能被称为“基础设施运营专家”(如果你们有更有趣的名字也可以在下方留言)。但不管怎样,他们的人使用开发团队所写的代码,并确保它们能够在生产级别的环境上可靠运行。
开发写代码并添加新特性从开发到运维,一个传递发生了现在它是运维的麻烦了……运维挥动服务器魔法,把问题解决了!

听着很耳熟?主要的问题是什么呢?运维和开发的分离这件事在整个发布过程中发生得过早了。它随着传递发生,从此变成了一个问题。在技术团队中有服务器魔法师当然很棒,因为开发人员不用再担心如何处理服务器问题,但是它确实是一个把你从DevOps的喜悦中拉下来的瓶颈。

自助服务:开发人员需要它,运维也是

DevOps的目的是团队紧密工作,缩短反馈回路。

做一些改变,让它们在测试环境中提交、合并、站住脚来确保一切都如预期那样。看起来不错?然后让新功能平滑地上生产,交到用户的手里。出现了问题?回滚一下,迅速地修复它,然后在不停机的情况下发布更新。

然而写代码的开发人员和理解及维护云平台的运维人员减慢了反馈回路,经常慢如爬行动物。

写代码的开发人员最适合做发布(在他们的计划中方便的时候),测试,监控性能,以及解决任何突然出现的问题。可是为什么没有工作流程是默认如此的呢?

很多情况下,服务器魔法师或者运维团队是唯一理解云平台所有事物的人。没有为开发者或者试图了解幕后情况的人提供的自助服务。

听起来运维团队处在一个非常强大的位置,但实际上它是非常痛苦和充满压力的。在给用户提供软件后你多少会明白,发布和维护是你职责所在,如果出错了要在第一线调试它,通常一忙就是一天24小时。

那为什么这是一个如此常见的场景呢?(提示,通常和工具有关)。

你选择的工具可能重要,也可能无关紧要

在一天结束的时候,运维人员、开发人员、安全保障人员、项目经理等等都对新软件发布的过程很满意,它实现了快速交付满足了业务需求。你可以通过很多方式到达这个目标。如果你是通过类似自助的方式,那么恭喜。

讲个故事。

在之前的一份工作里,我们采用了一种配置管理工具,插在Jenkins上,集成了很多开源系统,很高兴地自动化了一个大型、多区、遵从PCI并且流畅跑在AWS上的服务器。我们让非技术人员添加和部署新项目成为可能,可以为每个变化进行完整测试。一切看起来都很好,除了一个大问题:我们构建了类似自助服务的东西,但是它对公司95%的人来说是一个黑盒。开发把他们的代码给我们,他们可以检查日志,查看图表,看各项性能,但是当碰到钉子的时候,就是我们的职责了。
 
所以怎样才能让更多的人能够明白我们搭建的主机系统如何工作?我们用来连接一切的工具和用户配置让学习的复杂度大大提高。

然后……容器来了。

为什么容器可以帮上忙

你知道我一定会提容器的,对不对?在过去几年的DevOps大会上,容器和其应用基本是一个必谈的话题。

容器改变了开发和运维之间的分离境地,改进了他们之间的传递进程。开发人员能够更接近项目来确保他们的更新在传递给本地镜像创建人员之前可以成功部署。标准变得更加成熟和有意义,让更多人专注于应用程序而不是服务器。

容器已经催生了很多颇有竞争力的解决方案,提供一个平台来代替自助服务。因此运维团队和开发团队可以把关注点放在生产更多高效的进程和结果。所以在实践中它是什么样的?

当容器和DevOps碰撞

每一个软件公司如果着手开发一个改变游戏规则的产品,在前进的道路上,不管是从基础架构、还是人员管理和软件发布的角度,都会不可避免遇到可伸缩性的问题。随着团队的成长,和服务器的扩展,公司不仅需要关注产品线路图的执行,还需要变成云计算自动化领域的专家。能够最快速地执行新想法就会有显著的优势。如果你仍然手动登录服务器或者尝试再造一个云平台的车轮,那么就是在伤害你的公司。

而最近的一些容器技术或者容器服务平台可以帮助你从别人的硬件中解放出来,让公司更加专注于产品——
 
开发者能够通过友好的用户界面管理自己的服务器硬件需求开发者可以减少一个数量级的反馈回路时间,这意味着更多的代码更快的发布运维不用再尝试将一堆工具拢在一起做一个内部的PaaS,它很难做,很难管理,很难修补,很难保证安全运维可以更进一步地专注在应用监控、性能表现上,给予开发一些有价值的反馈来快速提升产品业务可以更灵活地延伸到全球范围,根据业务需求进行扩展,更新用户平台不需要时间和成本上的花费更多的资金可以用来雇佣人才专注于产品研发

所以,拥有了容器技术的DevOps,是否有了新的定义?

当然小数要补充一句,容器不是万能的,用在适合的地方最好。


文章作者:Phil Dougherty
原文链接:https://blog.containership.io/ ... isite 查看全部

关于DevOps,每个人都有不同的认识。有人坚持它是一种方法论,然而在实践中为了脱离缓慢的手工作业,自动化工具必不可少。从职责传递到自助服务,DevOps为满足业务的快速交付而生,却存在学习上的瓶颈。
然后谢天谢地,容器来了……



参加了大大小小许多DevOps和软件工程的会议。每当”DevOps究竟意味着什么”这个话题被提起时,总是会有一个这样的论点出现:

DevOps不是一系列可以连贯起来的工具,你用了它们就可以说自己做的是DevOps。DevOps是一种方法论,让开发和运维团队能够更紧密工作的一套过程。最终的目标是消除在软件发布的过程中手动作业和耗费时间的部分,实现更多成功的部署和更频繁的发布。

它完全正确。然而,话虽如此,祝不使用自动化工具的DevOps或者持续交付……好运。

为什么自动化工具是先决条件

假设这样一个场景:你处在一个研发工作室,创业公司甚至是大型企业。你有很多开发人员,他们中的少数一些被称为“Ops小组”“DevOps魔法师”或者“云运维”,在企业中他们可能被称为“基础设施运营专家”(如果你们有更有趣的名字也可以在下方留言)。但不管怎样,他们的人使用开发团队所写的代码,并确保它们能够在生产级别的环境上可靠运行。
  • 开发写代码并添加新特性
  • 从开发到运维,一个传递发生了
  • 现在它是运维的麻烦了……
  • 运维挥动服务器魔法,把问题解决了!


听着很耳熟?主要的问题是什么呢?运维和开发的分离这件事在整个发布过程中发生得过早了。它随着传递发生,从此变成了一个问题。在技术团队中有服务器魔法师当然很棒,因为开发人员不用再担心如何处理服务器问题,但是它确实是一个把你从DevOps的喜悦中拉下来的瓶颈。

自助服务:开发人员需要它,运维也是

DevOps的目的是团队紧密工作,缩短反馈回路。

做一些改变,让它们在测试环境中提交、合并、站住脚来确保一切都如预期那样。看起来不错?然后让新功能平滑地上生产,交到用户的手里。出现了问题?回滚一下,迅速地修复它,然后在不停机的情况下发布更新。

然而写代码的开发人员和理解及维护云平台的运维人员减慢了反馈回路,经常慢如爬行动物。

写代码的开发人员最适合做发布(在他们的计划中方便的时候),测试,监控性能,以及解决任何突然出现的问题。可是为什么没有工作流程是默认如此的呢?

很多情况下,服务器魔法师或者运维团队是唯一理解云平台所有事物的人。没有为开发者或者试图了解幕后情况的人提供的自助服务。

听起来运维团队处在一个非常强大的位置,但实际上它是非常痛苦和充满压力的。在给用户提供软件后你多少会明白,发布和维护是你职责所在,如果出错了要在第一线调试它,通常一忙就是一天24小时。

那为什么这是一个如此常见的场景呢?(提示,通常和工具有关)。

你选择的工具可能重要,也可能无关紧要

在一天结束的时候,运维人员、开发人员、安全保障人员、项目经理等等都对新软件发布的过程很满意,它实现了快速交付满足了业务需求。你可以通过很多方式到达这个目标。如果你是通过类似自助的方式,那么恭喜。

讲个故事。

在之前的一份工作里,我们采用了一种配置管理工具,插在Jenkins上,集成了很多开源系统,很高兴地自动化了一个大型、多区、遵从PCI并且流畅跑在AWS上的服务器。我们让非技术人员添加和部署新项目成为可能,可以为每个变化进行完整测试。一切看起来都很好,除了一个大问题:我们构建了类似自助服务的东西,但是它对公司95%的人来说是一个黑盒。开发把他们的代码给我们,他们可以检查日志,查看图表,看各项性能,但是当碰到钉子的时候,就是我们的职责了。
 
所以怎样才能让更多的人能够明白我们搭建的主机系统如何工作?我们用来连接一切的工具和用户配置让学习的复杂度大大提高。

然后……容器来了。

为什么容器可以帮上忙

你知道我一定会提容器的,对不对?在过去几年的DevOps大会上,容器和其应用基本是一个必谈的话题。

容器改变了开发和运维之间的分离境地,改进了他们之间的传递进程。开发人员能够更接近项目来确保他们的更新在传递给本地镜像创建人员之前可以成功部署。标准变得更加成熟和有意义,让更多人专注于应用程序而不是服务器。

容器已经催生了很多颇有竞争力的解决方案,提供一个平台来代替自助服务。因此运维团队和开发团队可以把关注点放在生产更多高效的进程和结果。所以在实践中它是什么样的?

当容器和DevOps碰撞

每一个软件公司如果着手开发一个改变游戏规则的产品,在前进的道路上,不管是从基础架构、还是人员管理和软件发布的角度,都会不可避免遇到可伸缩性的问题。随着团队的成长,和服务器的扩展,公司不仅需要关注产品线路图的执行,还需要变成云计算自动化领域的专家。能够最快速地执行新想法就会有显著的优势。如果你仍然手动登录服务器或者尝试再造一个云平台的车轮,那么就是在伤害你的公司。

而最近的一些容器技术或者容器服务平台可以帮助你从别人的硬件中解放出来,让公司更加专注于产品——
 
  • 开发者能够通过友好的用户界面管理自己的服务器硬件需求
  • 开发者可以减少一个数量级的反馈回路时间,这意味着更多的代码更快的发布
  • 运维不用再尝试将一堆工具拢在一起做一个内部的PaaS,它很难做,很难管理,很难修补,很难保证安全
  • 运维可以更进一步地专注在应用监控、性能表现上,给予开发一些有价值的反馈来快速提升产品
  • 业务可以更灵活地延伸到全球范围,根据业务需求进行扩展,更新用户平台不需要时间和成本上的花费
  • 更多的资金可以用来雇佣人才专注于产品研发


所以,拥有了容器技术的DevOps,是否有了新的定义?

当然小数要补充一句,容器不是万能的,用在适合的地方最好。


文章作者:Phil Dougherty
原文链接:https://blog.containership.io/ ... isite

数人云CTO解读Docker 1.12和金融业容器化

宁静胡同 发表了文章 • 0 个评论 • 684 次浏览 • 2016-08-03 10:24 • 来自相关话题

7月29日数人云在上海举办金融沙龙,邀请上交所和近二十家来自银行、保险、证券的IT技术专家一同探讨容器技术在金融业中的最佳实践。数人云CTO肖德时在会上将传统金融行业通过容器可以解决的四大问题做了逐一解读。


以下是演讲实录:

容器技术基本上是2013年出来的,2014年开始在中国传播。在2016年,大家可以感觉到Docker技术的发展加速,在生产环境中也有很多的成功案例。在DockerCon 2016上我们发现,Docker已经从原来的一个工具变成一个真正的生态圈,Docker已经具备整套的解决方案,同时上下游生态也已经非常完备。这都在告诉大家,你能想到的、和你需要的一些最佳实践,Docker基本上都能提供。目前,基本上是大公司在不断的追求Docker的技术,因为小公司用Docker技术解决问题产生的收益比还比较不明显,而大公司原来冗余的架构通过使用Docker确实可以产生效益,所以一些传统企业对Docker会比较关注。

容器技术发展加速

最新的资料显示,现在是应用Docker技术的比较好的时机。全球雇员超过500人的公司中73%已使用Docker技术。国内的很多公司也都在关注这项技术,尤其是金融行业,因为金融业的IT发展的比较成熟,他们对新技术比较关注,Docker已经有很多生产应用在里面产生。
 







用Docker能干什么是大家比较关心的问题。第一个比较常见的场景是DevOps,DevOps实际上就是提高生产力。原来,开发能做运维的事,运维能做开发的事。但实际上从真实的场景里,术业有专攻,在创业公司可以这么干,但传统公司做不了。Docker可以帮助企业进行业务的转型,提供标准的接口,这样开发提供标准运维能知道,运维提供标准开发也能知道。传统企业的开发流程不像创业公司,一个人要干很多事,传统企业强调的是标准化,是业务的转型,而在原有的老的制度下很难实现这种标准,用Docker技术可以加快转型。

第二个场景,云化。2016年云计算开始了新的增长,云计算发展到了新的技术点,老的虚拟化技术已经不能满足企业对动态资源和快速响应的需求,不能起到资源复用的作用。Docker可以应用在物理机上,也可以应用在虚拟机上,可以快速构建应用管理平台,或者构建IaaS、PaaS,或者service都可以。原来部门做不了,因为没有技术栈的改变,仍然要用老设施,那些老设施都是为大企业设计的。但是Docker出来的时候就是为开发者服务的,它是一个工具,一个人也可以做一个私有云。从这个点来看,在云端的转变这个场景里Docker是目前比较推荐的技术栈,它能够快速构建应用管理平台,可以有很好的基础。

另外,用了Docker一定要无状态,这只是表象,以前的应用架构和原来的状态是不是就一定不能满足现在的需求?不是的,原来的单体仍然可以用,为什么要做微服务?因为业务里有多个Function,其中有一个Function是特别热的,这时候怎么能抽出来?最简单的办法就是重构,因为想把它抽出来,抽出来以后,如果没有一些工具怎么做后面的工作?这都是限制问题。Docker公司提供的方案就是用Docker把它包裹一下,成为一个标准的小组件,然后利用分布式的概念,把它scale out,scale out以后再进行后面的工作。在现代的应用中,用了云,资源更容易获得,所以客户想快速地创造一些环境,这些环境里面的资源利用率解决了,但是应用的复杂度仍然存在。如何动态的分配,就是刚才上交所介绍的一些治理的方法。在Modern APP之上会面临一些问题,但是如何快速响应,这个情况是需要一些工具的,这些工具我们认为Docker是可以做到。
 







大背景,之前IOE的架构存在,不是说不好,从技术层面来讲,我并不认为IOE有什么不好,只是我加了一些策略做这件事,它比较拥堵,但不代表它不好。还有“十三五”规划,自主可控的要求,这些背景让企业对开源工具的需求变得会越来越多,数人云这种开源公司也是应势而生,我们给企业提供的解决方案就是自主可控,把开源、透明的技术交给客户。

在2015年,当时去跟客户说我们上一个Docker,人家说你的Docker和VM比有什么好处?VM用的多好,为什么要上Docker?当时我们是无言以对的,因为安全性,还有各种生态圈的工具链也不成熟。但是慢慢的,我们在做这件事的时候发现,其实这是需要和企业一起成长,我们也总结一些步骤。

金融行业拥抱容器四大步
 






总结一下我们想解决的问题,首先,Docker能不能解决快速发布的问题,实际上用Docker以后,管理起来是更复杂的。所以才会有数人云这种PaaS的存在,把复杂的东西用计算机的方式管理,因为用个人的方式是没法管理那么多资源的和实例的;二是原来多套环境相互隔离,客户需要的是多套环境多租户的分发,真正的隔离,因为是内部系统,对于隔离的要求还是可以分级的。环境的快速搭建涉及编排,怎么把DB分成两个,上面分成多个,然后都能访问DB,还有如何将手工操作变成自动的;三是大版本升级回滚,很难做这种升级回滚,怎么去做;四是各种设备,有的CPU,有的是VM,有的在物理机上,这么多设备怎么统一的管理起来。这是我们现实的一些场景,我们怎么解决这些问题是我今天想和大家一起探讨的问题。
 







第一个问题是快速部署,还有缓慢的升级,基本上就是用容器和微服务解。微服务是一个框架,如果把现有的服务拆成微服务,一定是一个统一的架构,那这个架构里面一定是包含这样的元素:首先,一定要有一个API网关的Server,微服务里面的API网关不涉及Nginx,因为Nginx没法动态的改配置,得手动去改,这是满足不了需求的,因为底下的应用无数,所以上面一定要构建自己的API网关,这个网关可以解决所有的问题,要不然下面每个API的服务,它的服务请求SLA都是可以经过网关控制的,这也是新型微服务架构里面经常不被人提起的,被忽略的地方。但是这是非常重要的一点,因为底下的服务特别多。发到集群里,怎么管控这些服务的质量,就是API的请求,出错怎么办,怎么来控制?这些都要通过API网关来控制,所以这个一定要去注意一下。
 







另外是几个大块的认证,如果你的内部认证没有统一的认证,就没法做标准化的双向通行,而且API网关也没有办法给下面的应用下发东西,因为没法认证。还有Configuration server一定要加上,Service Discovery单纯靠容器解决不了,需要PaaS的容器平台解决。做端口、应用的发现,方便其他应用访问它。还有监控、报警,然后就是常规的日志分析,这就是常规的需求。这些需求里面最特殊的就是容器,因为很多个要做逐一监控,没有一个平台是不行的。对日志也是一样,每个容器起来以后就死掉了,怎么知道这个容器是应用呢?一般都是要通过容器的ID来标识,然后收集回来。

还有一个API网关里面最大的特点,快速的熔断,什么意思呢?就是底下的服务很可能出问题。微服务架构里都打散,上面挂一个Nginx,如果业务量大了,如何快速关闭某个API呢?没有可编程的接口是做不到的。但是要采取微服务解决,这个架构的的组织形式就是这样。微服务里面承载的这些组件特别复杂,需要一个标准的组件来封装起来,这个封装组件的方式用Docker是比较合适的。微服务的架构确实可以解决这个问题,因为每个组件的升级很快,如果把整个组件升级一下,还有一些其他的东西,会很麻烦。我们会想到能给一个这样的架构,微服务架构里面统一管理服务。
 







环境之间的隔离,Docker做的目录级别的隔离已经完全可以满足需求了,原来为什么做不到这点?是因为手工的操作特别多,用别的方法隔离也是没有问题的。但是我们觉得,原来的架构里面,CICD的架构已经很成熟了,能不能把它自动化?因为完全可以用Docker来交付整个环境,手工部署没有问题。我们再往前走一步,怎么走?Jenkins可以调一个集群系统,然后分发集群,刚才说的微服务发到这里面,然后快速的部署。这是一个自动化的过程。这里面涉及到一个问题,原来咱们经常会听到的是持续构建,也就是把原码先构建成镜像,然后镜像再发到集群里面,这个操作觉得很顺,但实际上这里面真正的挑战在于,因为每个业务组件的依赖,还有他们之间的配置怎么抽离出来,这都是需要比以前更复杂的。所以,用容器确实解决了持续集成的一部分问题,但它对你的技术要求会越来越高。原来是手工做,而现在需要自动化。对于基础人员的架构改造,其实是抽象层更高一点,对大家的要求也会更高一点。
 







大版本升级不可回滚。大版本的升级困难点在哪儿?原来都是单体服务根本没法拆,动又不能动,刚才说了微服务基本上能够解决它。第二个情况是每个版本的版本控制怎么解决?基本上配置中心可以把配置做出来,然后建仓库,做版本控制。要做这个最好是滚动更新,也就是在不停机的情况下,一点点把业务迁到新的应用上面,然后将老的流量在处理完业务之后慢慢的退掉,这是一种办法。服务的时候,原来指向老的服务进程,自动地切到新的服务进程里面,这样产生流量尽快切到新的服务里面,所以这是需要服务发现的。
 







我们这边会构建一个集群,我们用的ZooKeeper去保证调度器,在正常运行的情况下,我们给Marathon发指令,让它把应用一个一个更新。起一个服务,保证老服务不停机,这时再把域名切换,进来的新流量就到新的应用里面了,老的应用在没有流量的时候自动退出,保证用户访问的时候没有宕机的感觉。这是集群环境里面做升级的常见案例。
 







还有各种异构设备,硬件资源利用率比较低,解法是数人云的应用集群。它是容器的集群,我们的系统会运行在独立的环境里远程控制集群系统,保证系统里面运行的只有容器,然后有相应的Agent来管理应用的服务。
 







这张图比较清晰一点,数人云本身就是微服务的架构,这里面针对的情况,大家都知道Nginx性能是最好的,我们可能在这上面写一个新的API网关对接整个系统,这套系统是数人云系统架构里面的一部分。我们业务管理用Marathon调度器会进行升级,因为Mesos本身是集群管理的调度。对于这些组件,比如镜像,我们采用的方式是跟VMware合作的一个开源项目叫Harbor镜像管理仓库,这是我们和他们一起合作开发的软件。持续集成我们和Jenkins做集成,通过自动配置能够把我们这个小本下发给Jenkins,然后和它构建镜像。监控报警,大家会觉得容器的监控报警不好做,容器目前为止基本上都是接口,现在新的容器把日志和报警,所谓的报警的实现都要按照流程的方式提供API接口,只要接上就收走日志,在本地不落盘。日志也是一样,它现在提供plugin方式和日志系统对接,不用担心落到盘里面收上来是不是把硬盘撑爆,现在都可以配的。这里对于我们现在新加的网络模块,就容器发展到现在其实对于网络都是成熟的,大家都在用host模式去管,虽然容器很轻,但并不比VM先进到哪里去,只是说它更轻量一些。客户希望VM有的东西它也有,这块最后也提供了这种对于IP的管理。所以也是刚刚在上的一种新的成熟架构,也就是说一容器一IP,现在是刚刚才开始支持,这是我们最新配套的。

容器圈新方向预览
 







讲完这些方案之后,今天会有些容器圈的新东西给大家讲讲。

首先是Docker1.12,昨天它正式发布了,这是一个新版本的发布,最重要的发布。这个发布先是内置了自己的工具,再就是对网络的增强,达到了更容易商用的阶段。第二个是我们现在用的Mesos,也发布了1.0,可以给大家介绍一下特性。
 







Docker1.12它有一个重要的特点,一般在集群系统里面,因为容器是很碎的,用户希望知道这个服务到底是run还是不run,原来的方式是Docker run的时候把端口打开,然后通过一个脚本去查。这等于是第三方去做,现在提供的功能是可以在构建镜像的时候就把Healthcheck打开,通过Docker Daemon的内容给这台主机上运行的容器定期的检查,通过Docker知道这个容器是不是健康的。当然这个功能并不是为咱们准备的,是为自己内置的Swarm编排工具做准备的,因为Docker公司做集群管理的工具也在想这个事情。还有一个情况是咱们最常用的CentOS系列,原来对于安全Docker公司一直在回避,它现在默认把这个组件打开了,打开以后跑出来更安全。Linux可以打标签、做监控,但是这个东西因为刚出来,所以只是一个信号,也就是Docker越来越安全了,原来是做不到,现在是越来越方便了,可以做到这样。Docker内置了一个IPVS,干什么用?就是想替代HaProxy提供IP给网络里面。这是比较新的技术,目前我们认为处于实验阶段,它利用IPVS的模块来提供网络的接口,只是一个信号,目前是没有采用这种方案的,因为太新了,还要测试。最后是内置Swarm的组件,这是很轻量的编排工具,也就是说装几台机器,必须要组成一个网,怎么去做?可以用Swarm做这个事。这个网IP怎么做,用IPVS,这就是最新的Docker的发展,非常快。
 







目前为止,一容器一IP技术理论已经落地。每台机器要装一个小的路由器,然后小路由器给你的容器。这个路由器可以想象成家里的无线路由器,因为是个屋子,一台主机里面都有屋子,任何终端设备都可以向路由器调IP,这个IP是假的都可以。当然Docker里面现在有了网络的插件,就相当于类似有了一个驱动,就可以找路由器要一个IP,实现了路由器有IP。大家注意到这个IP和底下的IP不一样,他们之间通过IPtable 做包头的转换,通过转换就可以双向通信了。但是这里面192.168的网段和10网段的管控,如果只做一次转发,那就控制不了这些IP之间的东西,我们用的方案把这些规则都记录在一个键值库里面,这样的好处在于,可以控制这个IP和这个IP的通信,把它记录下来就可以了,如果删掉,默认不让它通信也是可以的。虽然一台主机有三台服务器,但是他们之间是否能通信是你可以控制的,这样更安全。也就是说,用户有一个应用,这个应用是1.1和0.9,放在这两个容器上,然后1.10是另外一个APP,不希望他们之间互相通信就可以通过IPtable写进去,然后把他们隔开,他们通信的时候,一看规则没有就把他们删掉了,路由器就不会给它分。

还有一个情况,都是容器里面的IP,那外网的IP之间能不能通信?因为内网有一个路由器,路由器给它分了一个IP,也想给容器分一个同样网段的IP,需要一个网关来转换为可用的IP,转换给它,就是改包头改完包头转进去。它请求的时候再转出去,两个路由器之间再转一下,是这样的过程。它有一个缺点,就是主机的数量不能太大,毕竟是虚拟的IP网络,主机的数量不是容器的数量,基本上在200台左右是一个推荐的方式。
 







性能对比,跟主机、物理机再和calico的解决方案对比,基本上会在1024、2048、4096这块,如果用普通的overlay方案性能就很低,目前Docker overlay自己的原生方案性能就很低,但是它在提升,因为它刚刚出来。上面这套方案,因为calico的方案只是在包的包头上做了篡改,欺骗主机转发数据包,所以它的性能和host主机之间,有时候从数据表里面看到它传输的效率,吞吐量比host还快,但是这个数有假像,因为改了包头,但是基本上可以肯定,和原生的host的网卡里面性能是差不多的,是这样的情况。
 






最后说Mesos现在新产品,就是1.0技术开源的组件,1.0以后,我们基本上就会有新的HTTP API,原来的API都是Google的协议,现在有新的HTTP API更方便数人云和它做深度整合,我们也希望不断的前进,给客户提供更好的产品。第二个情况,大家现在遇到的情况,那就是Docker有各种各样的bug,这个问题没有很好的解决办法,因为Docker公司的产品是开源的,它的商业产品也到不了中国。Mesos解决了这个问题,Mesos拥有给Twitter、苹果等都部署过几万台的节点的经验。他发现安装Docker Daemon以后,Docker是很不稳定的,尤其在大规模集群方面很不稳定,所以他们推荐另外一个方式,就是用原生的容器框架解包镜像。客户在本地用Docker,但是把镜像发给我,我用另外的方式把这种镜像给起起来,用户是透明的,就认为它是Docker room,但它不用了Docker Daemon,因为把Docker Daemon关掉以后容器就死掉了,但是把Docker Daemon去掉以后,容器还要通过原生的方式运行起来,这就满足了企业的各种需求,这是新的技术点。还有云原生APP架构里面,对于网络需要一个标准,现在提供了一个类似的架构,Mesos提供了这个标准。另外就是支持GPU。还有Mesos在和微软合作,开始接管Windows的一些信息,这也是比较大的亮点。这个生态圈还是比较活跃的,这也是数人云关注和考虑的。 查看全部
7月29日数人云在上海举办金融沙龙,邀请上交所和近二十家来自银行、保险、证券的IT技术专家一同探讨容器技术在金融业中的最佳实践。数人云CTO肖德时在会上将传统金融行业通过容器可以解决的四大问题做了逐一解读。


以下是演讲实录:

容器技术基本上是2013年出来的,2014年开始在中国传播。在2016年,大家可以感觉到Docker技术的发展加速,在生产环境中也有很多的成功案例。在DockerCon 2016上我们发现,Docker已经从原来的一个工具变成一个真正的生态圈,Docker已经具备整套的解决方案,同时上下游生态也已经非常完备。这都在告诉大家,你能想到的、和你需要的一些最佳实践,Docker基本上都能提供。目前,基本上是大公司在不断的追求Docker的技术,因为小公司用Docker技术解决问题产生的收益比还比较不明显,而大公司原来冗余的架构通过使用Docker确实可以产生效益,所以一些传统企业对Docker会比较关注。

容器技术发展加速

最新的资料显示,现在是应用Docker技术的比较好的时机。全球雇员超过500人的公司中73%已使用Docker技术。国内的很多公司也都在关注这项技术,尤其是金融行业,因为金融业的IT发展的比较成熟,他们对新技术比较关注,Docker已经有很多生产应用在里面产生。
 


1.png


用Docker能干什么是大家比较关心的问题。第一个比较常见的场景是DevOps,DevOps实际上就是提高生产力。原来,开发能做运维的事,运维能做开发的事。但实际上从真实的场景里,术业有专攻,在创业公司可以这么干,但传统公司做不了。Docker可以帮助企业进行业务的转型,提供标准的接口,这样开发提供标准运维能知道,运维提供标准开发也能知道。传统企业的开发流程不像创业公司,一个人要干很多事,传统企业强调的是标准化,是业务的转型,而在原有的老的制度下很难实现这种标准,用Docker技术可以加快转型。

第二个场景,云化。2016年云计算开始了新的增长,云计算发展到了新的技术点,老的虚拟化技术已经不能满足企业对动态资源和快速响应的需求,不能起到资源复用的作用。Docker可以应用在物理机上,也可以应用在虚拟机上,可以快速构建应用管理平台,或者构建IaaS、PaaS,或者service都可以。原来部门做不了,因为没有技术栈的改变,仍然要用老设施,那些老设施都是为大企业设计的。但是Docker出来的时候就是为开发者服务的,它是一个工具,一个人也可以做一个私有云。从这个点来看,在云端的转变这个场景里Docker是目前比较推荐的技术栈,它能够快速构建应用管理平台,可以有很好的基础。

另外,用了Docker一定要无状态,这只是表象,以前的应用架构和原来的状态是不是就一定不能满足现在的需求?不是的,原来的单体仍然可以用,为什么要做微服务?因为业务里有多个Function,其中有一个Function是特别热的,这时候怎么能抽出来?最简单的办法就是重构,因为想把它抽出来,抽出来以后,如果没有一些工具怎么做后面的工作?这都是限制问题。Docker公司提供的方案就是用Docker把它包裹一下,成为一个标准的小组件,然后利用分布式的概念,把它scale out,scale out以后再进行后面的工作。在现代的应用中,用了云,资源更容易获得,所以客户想快速地创造一些环境,这些环境里面的资源利用率解决了,但是应用的复杂度仍然存在。如何动态的分配,就是刚才上交所介绍的一些治理的方法。在Modern APP之上会面临一些问题,但是如何快速响应,这个情况是需要一些工具的,这些工具我们认为Docker是可以做到。
 


2.png


大背景,之前IOE的架构存在,不是说不好,从技术层面来讲,我并不认为IOE有什么不好,只是我加了一些策略做这件事,它比较拥堵,但不代表它不好。还有“十三五”规划,自主可控的要求,这些背景让企业对开源工具的需求变得会越来越多,数人云这种开源公司也是应势而生,我们给企业提供的解决方案就是自主可控,把开源、透明的技术交给客户。

在2015年,当时去跟客户说我们上一个Docker,人家说你的Docker和VM比有什么好处?VM用的多好,为什么要上Docker?当时我们是无言以对的,因为安全性,还有各种生态圈的工具链也不成熟。但是慢慢的,我们在做这件事的时候发现,其实这是需要和企业一起成长,我们也总结一些步骤。

金融行业拥抱容器四大步
 

3.png


总结一下我们想解决的问题,首先,Docker能不能解决快速发布的问题,实际上用Docker以后,管理起来是更复杂的。所以才会有数人云这种PaaS的存在,把复杂的东西用计算机的方式管理,因为用个人的方式是没法管理那么多资源的和实例的;二是原来多套环境相互隔离,客户需要的是多套环境多租户的分发,真正的隔离,因为是内部系统,对于隔离的要求还是可以分级的。环境的快速搭建涉及编排,怎么把DB分成两个,上面分成多个,然后都能访问DB,还有如何将手工操作变成自动的;三是大版本升级回滚,很难做这种升级回滚,怎么去做;四是各种设备,有的CPU,有的是VM,有的在物理机上,这么多设备怎么统一的管理起来。这是我们现实的一些场景,我们怎么解决这些问题是我今天想和大家一起探讨的问题。
 


4.png


第一个问题是快速部署,还有缓慢的升级,基本上就是用容器和微服务解。微服务是一个框架,如果把现有的服务拆成微服务,一定是一个统一的架构,那这个架构里面一定是包含这样的元素:首先,一定要有一个API网关的Server,微服务里面的API网关不涉及Nginx,因为Nginx没法动态的改配置,得手动去改,这是满足不了需求的,因为底下的应用无数,所以上面一定要构建自己的API网关,这个网关可以解决所有的问题,要不然下面每个API的服务,它的服务请求SLA都是可以经过网关控制的,这也是新型微服务架构里面经常不被人提起的,被忽略的地方。但是这是非常重要的一点,因为底下的服务特别多。发到集群里,怎么管控这些服务的质量,就是API的请求,出错怎么办,怎么来控制?这些都要通过API网关来控制,所以这个一定要去注意一下。
 


5.png


另外是几个大块的认证,如果你的内部认证没有统一的认证,就没法做标准化的双向通行,而且API网关也没有办法给下面的应用下发东西,因为没法认证。还有Configuration server一定要加上,Service Discovery单纯靠容器解决不了,需要PaaS的容器平台解决。做端口、应用的发现,方便其他应用访问它。还有监控、报警,然后就是常规的日志分析,这就是常规的需求。这些需求里面最特殊的就是容器,因为很多个要做逐一监控,没有一个平台是不行的。对日志也是一样,每个容器起来以后就死掉了,怎么知道这个容器是应用呢?一般都是要通过容器的ID来标识,然后收集回来。

还有一个API网关里面最大的特点,快速的熔断,什么意思呢?就是底下的服务很可能出问题。微服务架构里都打散,上面挂一个Nginx,如果业务量大了,如何快速关闭某个API呢?没有可编程的接口是做不到的。但是要采取微服务解决,这个架构的的组织形式就是这样。微服务里面承载的这些组件特别复杂,需要一个标准的组件来封装起来,这个封装组件的方式用Docker是比较合适的。微服务的架构确实可以解决这个问题,因为每个组件的升级很快,如果把整个组件升级一下,还有一些其他的东西,会很麻烦。我们会想到能给一个这样的架构,微服务架构里面统一管理服务。
 


6.png


环境之间的隔离,Docker做的目录级别的隔离已经完全可以满足需求了,原来为什么做不到这点?是因为手工的操作特别多,用别的方法隔离也是没有问题的。但是我们觉得,原来的架构里面,CICD的架构已经很成熟了,能不能把它自动化?因为完全可以用Docker来交付整个环境,手工部署没有问题。我们再往前走一步,怎么走?Jenkins可以调一个集群系统,然后分发集群,刚才说的微服务发到这里面,然后快速的部署。这是一个自动化的过程。这里面涉及到一个问题,原来咱们经常会听到的是持续构建,也就是把原码先构建成镜像,然后镜像再发到集群里面,这个操作觉得很顺,但实际上这里面真正的挑战在于,因为每个业务组件的依赖,还有他们之间的配置怎么抽离出来,这都是需要比以前更复杂的。所以,用容器确实解决了持续集成的一部分问题,但它对你的技术要求会越来越高。原来是手工做,而现在需要自动化。对于基础人员的架构改造,其实是抽象层更高一点,对大家的要求也会更高一点。
 


7.png


大版本升级不可回滚。大版本的升级困难点在哪儿?原来都是单体服务根本没法拆,动又不能动,刚才说了微服务基本上能够解决它。第二个情况是每个版本的版本控制怎么解决?基本上配置中心可以把配置做出来,然后建仓库,做版本控制。要做这个最好是滚动更新,也就是在不停机的情况下,一点点把业务迁到新的应用上面,然后将老的流量在处理完业务之后慢慢的退掉,这是一种办法。服务的时候,原来指向老的服务进程,自动地切到新的服务进程里面,这样产生流量尽快切到新的服务里面,所以这是需要服务发现的。
 


8.png


我们这边会构建一个集群,我们用的ZooKeeper去保证调度器,在正常运行的情况下,我们给Marathon发指令,让它把应用一个一个更新。起一个服务,保证老服务不停机,这时再把域名切换,进来的新流量就到新的应用里面了,老的应用在没有流量的时候自动退出,保证用户访问的时候没有宕机的感觉。这是集群环境里面做升级的常见案例。
 


9.png


还有各种异构设备,硬件资源利用率比较低,解法是数人云的应用集群。它是容器的集群,我们的系统会运行在独立的环境里远程控制集群系统,保证系统里面运行的只有容器,然后有相应的Agent来管理应用的服务。
 


10.png


这张图比较清晰一点,数人云本身就是微服务的架构,这里面针对的情况,大家都知道Nginx性能是最好的,我们可能在这上面写一个新的API网关对接整个系统,这套系统是数人云系统架构里面的一部分。我们业务管理用Marathon调度器会进行升级,因为Mesos本身是集群管理的调度。对于这些组件,比如镜像,我们采用的方式是跟VMware合作的一个开源项目叫Harbor镜像管理仓库,这是我们和他们一起合作开发的软件。持续集成我们和Jenkins做集成,通过自动配置能够把我们这个小本下发给Jenkins,然后和它构建镜像。监控报警,大家会觉得容器的监控报警不好做,容器目前为止基本上都是接口,现在新的容器把日志和报警,所谓的报警的实现都要按照流程的方式提供API接口,只要接上就收走日志,在本地不落盘。日志也是一样,它现在提供plugin方式和日志系统对接,不用担心落到盘里面收上来是不是把硬盘撑爆,现在都可以配的。这里对于我们现在新加的网络模块,就容器发展到现在其实对于网络都是成熟的,大家都在用host模式去管,虽然容器很轻,但并不比VM先进到哪里去,只是说它更轻量一些。客户希望VM有的东西它也有,这块最后也提供了这种对于IP的管理。所以也是刚刚在上的一种新的成熟架构,也就是说一容器一IP,现在是刚刚才开始支持,这是我们最新配套的。

容器圈新方向预览
 


17.png


讲完这些方案之后,今天会有些容器圈的新东西给大家讲讲。

首先是Docker1.12,昨天它正式发布了,这是一个新版本的发布,最重要的发布。这个发布先是内置了自己的工具,再就是对网络的增强,达到了更容易商用的阶段。第二个是我们现在用的Mesos,也发布了1.0,可以给大家介绍一下特性。
 


18.png


Docker1.12它有一个重要的特点,一般在集群系统里面,因为容器是很碎的,用户希望知道这个服务到底是run还是不run,原来的方式是Docker run的时候把端口打开,然后通过一个脚本去查。这等于是第三方去做,现在提供的功能是可以在构建镜像的时候就把Healthcheck打开,通过Docker Daemon的内容给这台主机上运行的容器定期的检查,通过Docker知道这个容器是不是健康的。当然这个功能并不是为咱们准备的,是为自己内置的Swarm编排工具做准备的,因为Docker公司做集群管理的工具也在想这个事情。还有一个情况是咱们最常用的CentOS系列,原来对于安全Docker公司一直在回避,它现在默认把这个组件打开了,打开以后跑出来更安全。Linux可以打标签、做监控,但是这个东西因为刚出来,所以只是一个信号,也就是Docker越来越安全了,原来是做不到,现在是越来越方便了,可以做到这样。Docker内置了一个IPVS,干什么用?就是想替代HaProxy提供IP给网络里面。这是比较新的技术,目前我们认为处于实验阶段,它利用IPVS的模块来提供网络的接口,只是一个信号,目前是没有采用这种方案的,因为太新了,还要测试。最后是内置Swarm的组件,这是很轻量的编排工具,也就是说装几台机器,必须要组成一个网,怎么去做?可以用Swarm做这个事。这个网IP怎么做,用IPVS,这就是最新的Docker的发展,非常快。
 


19.png


目前为止,一容器一IP技术理论已经落地。每台机器要装一个小的路由器,然后小路由器给你的容器。这个路由器可以想象成家里的无线路由器,因为是个屋子,一台主机里面都有屋子,任何终端设备都可以向路由器调IP,这个IP是假的都可以。当然Docker里面现在有了网络的插件,就相当于类似有了一个驱动,就可以找路由器要一个IP,实现了路由器有IP。大家注意到这个IP和底下的IP不一样,他们之间通过IPtable 做包头的转换,通过转换就可以双向通信了。但是这里面192.168的网段和10网段的管控,如果只做一次转发,那就控制不了这些IP之间的东西,我们用的方案把这些规则都记录在一个键值库里面,这样的好处在于,可以控制这个IP和这个IP的通信,把它记录下来就可以了,如果删掉,默认不让它通信也是可以的。虽然一台主机有三台服务器,但是他们之间是否能通信是你可以控制的,这样更安全。也就是说,用户有一个应用,这个应用是1.1和0.9,放在这两个容器上,然后1.10是另外一个APP,不希望他们之间互相通信就可以通过IPtable写进去,然后把他们隔开,他们通信的时候,一看规则没有就把他们删掉了,路由器就不会给它分。

还有一个情况,都是容器里面的IP,那外网的IP之间能不能通信?因为内网有一个路由器,路由器给它分了一个IP,也想给容器分一个同样网段的IP,需要一个网关来转换为可用的IP,转换给它,就是改包头改完包头转进去。它请求的时候再转出去,两个路由器之间再转一下,是这样的过程。它有一个缺点,就是主机的数量不能太大,毕竟是虚拟的IP网络,主机的数量不是容器的数量,基本上在200台左右是一个推荐的方式。
 


20.png


性能对比,跟主机、物理机再和calico的解决方案对比,基本上会在1024、2048、4096这块,如果用普通的overlay方案性能就很低,目前Docker overlay自己的原生方案性能就很低,但是它在提升,因为它刚刚出来。上面这套方案,因为calico的方案只是在包的包头上做了篡改,欺骗主机转发数据包,所以它的性能和host主机之间,有时候从数据表里面看到它传输的效率,吞吐量比host还快,但是这个数有假像,因为改了包头,但是基本上可以肯定,和原生的host的网卡里面性能是差不多的,是这样的情况。
 

21.png


最后说Mesos现在新产品,就是1.0技术开源的组件,1.0以后,我们基本上就会有新的HTTP API,原来的API都是Google的协议,现在有新的HTTP API更方便数人云和它做深度整合,我们也希望不断的前进,给客户提供更好的产品。第二个情况,大家现在遇到的情况,那就是Docker有各种各样的bug,这个问题没有很好的解决办法,因为Docker公司的产品是开源的,它的商业产品也到不了中国。Mesos解决了这个问题,Mesos拥有给Twitter、苹果等都部署过几万台的节点的经验。他发现安装Docker Daemon以后,Docker是很不稳定的,尤其在大规模集群方面很不稳定,所以他们推荐另外一个方式,就是用原生的容器框架解包镜像。客户在本地用Docker,但是把镜像发给我,我用另外的方式把这种镜像给起起来,用户是透明的,就认为它是Docker room,但它不用了Docker Daemon,因为把Docker Daemon关掉以后容器就死掉了,但是把Docker Daemon去掉以后,容器还要通过原生的方式运行起来,这就满足了企业的各种需求,这是新的技术点。还有云原生APP架构里面,对于网络需要一个标准,现在提供了一个类似的架构,Mesos提供了这个标准。另外就是支持GPU。还有Mesos在和微软合作,开始接管Windows的一些信息,这也是比较大的亮点。这个生态圈还是比较活跃的,这也是数人云关注和考虑的。

代码篇 | Docker1.12+Swarm构建动态微服务应用

宁静胡同 发表了文章 • 0 个评论 • 682 次浏览 • 2016-07-21 12:00 • 来自相关话题

这次数人云与大家分享的文章里,主要介绍了Docker Swarm如何凭借革新对整体场景进一步加以简化。事实上,如今我们已经可以轻松且直观地构建起一套Docker Swarm集群,快来一起体验一下吧:)


下面先来看看各项具体的更新内容:

 我们在之前提到过一个示例,即一款由前端与多项后端服务共同构成的微服务应用。其中前端为Traefik HTTP代理,负责将各项请求路由至后端服务。而后端则非常简单,是一套基于Go的HTTP Web服务器,负责返回其运行所在的容器ID。





新的Docker Swarm不再需要为应用容器设置独立的HTTP代理。如上图所示的原有架构现在被精简为下图所示的形式:








移动部件更少了——赞!


另外,我们还为后端服务内置了负载均衡机制。我们甚至能够立足于集群内的任一节点访问这些服务。Docker Swarm还集成有一种内置网状路由机制,用于将各请求路由至适合的后端容器当中。

面对这些新功能,有些朋友可能认为Docker Swarm集群的设置过程会比原本更为复杂。事实上,整个流程反而更加简单。


仍然半信半疑?下面一起来看。

没错,这次我们仍然使用Raspberry Pi集群。我使用的是Docker 1.12内部版本,并将其安装在Raspberry Pi上。当Docker 1.12推出正式版后,我们会对内容做出针对性更新。


下面看看当前配置:
root@pi6 $ docker version
Client:
Version: 1.12.0-rc1
API version: 1.24
Go version: go1.6.2
Git commit: 1f136c1-unsupported
Built: Wed Jun 15 15:35:51 2016
OS/Arch: linux/arm

Server:
Version: 1.12.0-rc1
API version: 1.24
Go version: go1.6.2
Git commit: 1f136c1-unsupported
Built: Wed Jun 15 15:35:51 2016
OS/Arch: linux/arm
 
很好,Docker 1.12 RC1已经准备就绪。下面启动各项必要服务。


首先看看我们能否在Docker CLI中找到隐藏的各项新功能。
root@pi6 $ docker
Usage: docker [OPTIONS] COMMAND [arg...]
docker [ --help | -v | --version ]

A self-sufficient runtime for containers.
...
service Manage Docker services
...
stats Display a live stream of container(s) resource usage statistics
...
swarm Manage Docker Swarm
...
update Update configuration of one or more containers

Run 'docker COMMAND --help' for more information on a command.
我直接去掉了其中与上代版本完全一致的部分,而只留了不同之处。


现在我们可以使用docker swarm命令了。


查询其具体作用:
root@pi6 $ docker swarm
Usage: docker swarm COMMAND
Manage Docker Swarm
Options:
--help Print usage
Commands:
init Initialize a Swarm.
join Join a Swarm as a node and/or manager.
update update the Swarm.
leave Leave a Swarm.
inspect Inspect the Swarm
Run 'docker swarm COMMAND --help' for more information on a command.
就是说其用于“初始化一套Swarm”。看起来正是我们需要的。首先启动该命令。
root@pi6 $ docker swarm init
Swarm initialized: current node (1njlvzi9rk2syv3xojw217o0g) is now a manager.
现在我们的Swarm管理节点已经开始运行,接下来为集群添加更多节点。


前往集群中的另一节点并执行:
root@pi1 $ docker swarm join pi6:2377
This node joined a Swarm as a worker.
使用上述命令,我们在刚刚创建的初始Swarm集群中声明了应当加入该Swarm管理节点的各个新节点。Docker Swarm会在后台执行相关操作。


举例来说,其会为不同集群节点设置经过加密的彼此通信通道。我们不再需要自行管理TLS证书。


每位曾经设置过Docker Swarm集群的朋友,都会意识到新的流程有多么简单。

不过到这儿还没有结束。


Swarm管理节点中的一条“docker info”带来了一些有趣的提示。我仍然删去其中不必要的部分:
root@pi6 $ docker info
...
Swarm: active
NodeID: 1njlvzi9rk2syv3xojw217o0g
IsManager: Yes
Managers: 1
Nodes: 2
CACertHash: sha256:de4e2bff3b63700aad01df97bbe0397f131aabed5fabb7732283f044472323fc
...
Kernel Version: 4.4.10-hypriotos-v7+
Operating System: Raspbian GNU/Linux 8 (jessie)
OSType: linux
Architecture: armv7l
CPUs: 4
Total Memory: 925.4 MiB
Name: pi6
...
如大家所见,我们现在已经在“docker info”输出结果中有了新的“Swarm”部分,其告诉我们当前节点属于一套Swarm管理节点,且该集群由两个集群节点构成。


在第二个节点上,其输出结果与管理节点稍有不同:
Swarm: active
NodeID: 3fmwt4taurwxczr2icboojz8g
IsManager: No
到这里,我们已经拥有了一套有趣但仍然空空如也的Swarm集群。


我们还需要了解Docker 1.12中的service这项全新抽象定义。大家可能在前面的输出结果中注意到了docker service命令。所谓docker service,是指运行在容器当中且负责为外部世界提供运行在Swarm集群内的“service”的软件片段。

这样的一项服务可以由单一或者多套容器构成。在后一种情况下,我们可以确保服务拥有高可用性及/或负载均衡能力。

下面使用之前创建的“whoami”镜像建立这样一项服务。
root@pi6 $ docker service create --name whoami -p 80:8000 hypriot/rpi-whoami
buy0q65lw7nshm76kvy5imxk3
在“docker swarm ls”命令的帮助下,我们可以检查这项新服务的状态。
root@pi6 $ docker service ls
ID NAME SCALE IMAGE COMMAND
buy0q65lw7ns whoami 1 hypriot/rpi-whoami
下面检查我们是否能够通过curl命令向eth0网络接口发送l http命令,从而请求目录页面。
root@pi6 $ curl http://192.168.178.24
I'm 1b6df814c654
一切顺利,鼓掌!


有些朋友可能注意到,“docker swarm ls”命令的标题行中存在“SCALE”部分,这似乎意味着我们可以对服务进行扩展。
root@pi6 $ docker service scale whoami=5
whoami scaled to 5
那就来实际验证一下吧:
root@pi6 $ docker service ls
ID NAME SCALE IMAGE COMMAND
buy0q65lw7ns whoami 5 hypriot/rpi-whoami

root@pi6 $ for i in {1..5}; do curl http://192.168.178.24; done
I'm 8db1657e8517
I'm e1863a2be88d
I'm 1b6df814c654
I'm 8db1657e8517
I'm e1863a2be88d
非常简单。


但这种方式与原有Swarm其实差不多,只不过在使用感受上更便捷也更快速。请注意,我们使用的是Raspberry Pi而非强大的服务器,所以要对性能拥有较为保守的估计。


下面从单一Docker引擎的角度来看看目前的运行状态:
root@pi6 $ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e1863a2be88d hypriot/rpi-whoami:latest "/http" 2 minutes ago Up 2 minutes 8000/tcp whoami.4.0lg12zndbal72exqe08r9wvpg
8db1657e8517 hypriot/rpi-whoami:latest "/http" 2 minutes ago Up 2 minutes 8000/tcp whoami.5.5z6mvsrdy73m5w24icgsqc8i2
1b6df814c654 hypriot/rpi-whoami:latest "/http" 8 minutes ago Up 8 minutes 8000/tcp whoami.1.bg4qlpiye6h6uxyf8cmkwuh52
如大家所见,已经启动的容器有5套,其中3套驻留于“pi6”中。


下面看看是否能够找到其它容器:
root@pi1 docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db411a119c0a hypriot/rpi-whoami:latest "/http" 6 minutes ago Up 6 minutes 8000/tcp whoami.2.2tf7yhmx9haol7e2b7xib2emj
0a4bf32fa9c4 hypriot/rpi-whoami:latest "/http" 6 minutes ago Up 6 minutes 8000/tcp whoami.3.2r6mm091c2ybr0f9jz4qaxw9k
那么如果我们将这套Swarm集群驻留在“pi1”上,结果又会如何?
root@pi1 docker swarm leave
Node left the default swarm.
下面看看另一节点上的运行情况:docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
58620e3d533c hypriot/rpi-whoami:latest "/http" 46 seconds ago Up 43 seconds 8000/tcp whoami.2.cgc4e2ixulc2f3ehr4laoursg
acc9b523f434 hypriot/rpi-whoami:latest "/http" 46 seconds ago Up 43 seconds 8000/tcp whoami.3.67bhlo3nwgehthi3bg5bfdzue
e1863a2be88d hypriot/rpi-whoami:latest "/http" 8 minutes ago Up 8 minutes 8000/tcp whoami.4.0lg12zndbal72exqe08r9wvpg
8db1657e8517 hypriot/rpi-whoami:latest "/http" 8 minutes ago Up 8 minutes 8000/tcp whoami.5.5z6mvsrdy73m5w24icgsqc8i2
1b6df814c654 hypriot/rpi-whoami:latest "/http" 15 minutes ago Up 14 minutes 8000/tcp whoami.1.bg4qlpiye6h6uxyf8cmkwuh52
这里的情况相当于“pi1”节点发生故障,此时“pi1”中运行的全部容器都会被自动迁移至另一集群节点。这项机制在实际生产当中无疑非常重要。


那么下面我们回顾一下之前了解到的信息:


我们创建了一款小型动态微服务应用,完全由Docker构成。Docker Swarm现在被整合至Docker-Engine当中,而不再以独立软件形式存在。在多数情况下,这能够为应用后端服务建立起独立的代理机制。不再需要使用nginx、HAProxy或者Traefik。

尽管活动部件数量有所减少,但我们现在反而拥有了内置的高可用性与负载均衡功能。我非常期待未来Docker Swarm正式版本中会带来哪些新的惊喜,又如何与Docker Compose进行协作。 查看全部

这次数人云与大家分享的文章里,主要介绍了Docker Swarm如何凭借革新对整体场景进一步加以简化。事实上,如今我们已经可以轻松且直观地构建起一套Docker Swarm集群,快来一起体验一下吧:)


下面先来看看各项具体的更新内容:

 我们在之前提到过一个示例,即一款由前端与多项后端服务共同构成的微服务应用。其中前端为Traefik HTTP代理,负责将各项请求路由至后端服务。而后端则非常简单,是一套基于Go的HTTP Web服务器,负责返回其运行所在的容器ID。

1.jpg

新的Docker Swarm不再需要为应用容器设置独立的HTTP代理。如上图所示的原有架构现在被精简为下图所示的形式:


2.jpg



移动部件更少了——赞!


另外,我们还为后端服务内置了负载均衡机制。我们甚至能够立足于集群内的任一节点访问这些服务。Docker Swarm还集成有一种内置网状路由机制,用于将各请求路由至适合的后端容器当中。

面对这些新功能,有些朋友可能认为Docker Swarm集群的设置过程会比原本更为复杂。事实上,整个流程反而更加简单。


仍然半信半疑?下面一起来看。

没错,这次我们仍然使用Raspberry Pi集群。我使用的是Docker 1.12内部版本,并将其安装在Raspberry Pi上。当Docker 1.12推出正式版后,我们会对内容做出针对性更新。


下面看看当前配置:
root@pi6 $ docker version
Client:
Version: 1.12.0-rc1
API version: 1.24
Go version: go1.6.2
Git commit: 1f136c1-unsupported
Built: Wed Jun 15 15:35:51 2016
OS/Arch: linux/arm

Server:
Version: 1.12.0-rc1
API version: 1.24
Go version: go1.6.2
Git commit: 1f136c1-unsupported
Built: Wed Jun 15 15:35:51 2016
OS/Arch: linux/arm

 
很好,Docker 1.12 RC1已经准备就绪。下面启动各项必要服务。


首先看看我们能否在Docker CLI中找到隐藏的各项新功能。
root@pi6 $ docker
Usage: docker [OPTIONS] COMMAND [arg...]
docker [ --help | -v | --version ]

A self-sufficient runtime for containers.
...
service Manage Docker services
...
stats Display a live stream of container(s) resource usage statistics
...
swarm Manage Docker Swarm
...
update Update configuration of one or more containers

Run 'docker COMMAND --help' for more information on a command.

我直接去掉了其中与上代版本完全一致的部分,而只留了不同之处。


现在我们可以使用docker swarm命令了。


查询其具体作用:
root@pi6 $ docker swarm
Usage: docker swarm COMMAND
Manage Docker Swarm
Options:
--help Print usage
Commands:
init Initialize a Swarm.
join Join a Swarm as a node and/or manager.
update update the Swarm.
leave Leave a Swarm.
inspect Inspect the Swarm
Run 'docker swarm COMMAND --help' for more information on a command.

就是说其用于“初始化一套Swarm”。看起来正是我们需要的。首先启动该命令。
root@pi6 $ docker swarm init
Swarm initialized: current node (1njlvzi9rk2syv3xojw217o0g) is now a manager.

现在我们的Swarm管理节点已经开始运行,接下来为集群添加更多节点。


前往集群中的另一节点并执行:
root@pi1 $ docker swarm join pi6:2377
This node joined a Swarm as a worker.

使用上述命令,我们在刚刚创建的初始Swarm集群中声明了应当加入该Swarm管理节点的各个新节点。Docker Swarm会在后台执行相关操作。


举例来说,其会为不同集群节点设置经过加密的彼此通信通道。我们不再需要自行管理TLS证书。


每位曾经设置过Docker Swarm集群的朋友,都会意识到新的流程有多么简单。

不过到这儿还没有结束。


Swarm管理节点中的一条“docker info”带来了一些有趣的提示。我仍然删去其中不必要的部分:
root@pi6 $ docker info
...
Swarm: active
NodeID: 1njlvzi9rk2syv3xojw217o0g
IsManager: Yes
Managers: 1
Nodes: 2
CACertHash: sha256:de4e2bff3b63700aad01df97bbe0397f131aabed5fabb7732283f044472323fc
...
Kernel Version: 4.4.10-hypriotos-v7+
Operating System: Raspbian GNU/Linux 8 (jessie)
OSType: linux
Architecture: armv7l
CPUs: 4
Total Memory: 925.4 MiB
Name: pi6
...

如大家所见,我们现在已经在“docker info”输出结果中有了新的“Swarm”部分,其告诉我们当前节点属于一套Swarm管理节点,且该集群由两个集群节点构成。


在第二个节点上,其输出结果与管理节点稍有不同:
Swarm: active
NodeID: 3fmwt4taurwxczr2icboojz8g
IsManager: No

到这里,我们已经拥有了一套有趣但仍然空空如也的Swarm集群。


我们还需要了解Docker 1.12中的service这项全新抽象定义。大家可能在前面的输出结果中注意到了docker service命令。所谓docker service,是指运行在容器当中且负责为外部世界提供运行在Swarm集群内的“service”的软件片段。

这样的一项服务可以由单一或者多套容器构成。在后一种情况下,我们可以确保服务拥有高可用性及/或负载均衡能力。

下面使用之前创建的“whoami”镜像建立这样一项服务。
root@pi6 $ docker service create --name whoami -p 80:8000 hypriot/rpi-whoami
buy0q65lw7nshm76kvy5imxk3

在“docker swarm ls”命令的帮助下,我们可以检查这项新服务的状态。
root@pi6 $ docker service ls
ID NAME SCALE IMAGE COMMAND
buy0q65lw7ns whoami 1 hypriot/rpi-whoami

下面检查我们是否能够通过curl命令向eth0网络接口发送l http命令,从而请求目录页面。
root@pi6 $ curl http://192.168.178.24
I'm 1b6df814c654

一切顺利,鼓掌!


有些朋友可能注意到,“docker swarm ls”命令的标题行中存在“SCALE”部分,这似乎意味着我们可以对服务进行扩展。
root@pi6 $ docker service scale whoami=5
whoami scaled to 5

那就来实际验证一下吧:
root@pi6 $ docker service ls
ID NAME SCALE IMAGE COMMAND
buy0q65lw7ns whoami 5 hypriot/rpi-whoami

root@pi6 $ for i in {1..5}; do curl http://192.168.178.24; done
I'm 8db1657e8517
I'm e1863a2be88d
I'm 1b6df814c654
I'm 8db1657e8517
I'm e1863a2be88d

非常简单。


但这种方式与原有Swarm其实差不多,只不过在使用感受上更便捷也更快速。请注意,我们使用的是Raspberry Pi而非强大的服务器,所以要对性能拥有较为保守的估计。


下面从单一Docker引擎的角度来看看目前的运行状态:
root@pi6 $ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e1863a2be88d hypriot/rpi-whoami:latest "/http" 2 minutes ago Up 2 minutes 8000/tcp whoami.4.0lg12zndbal72exqe08r9wvpg
8db1657e8517 hypriot/rpi-whoami:latest "/http" 2 minutes ago Up 2 minutes 8000/tcp whoami.5.5z6mvsrdy73m5w24icgsqc8i2
1b6df814c654 hypriot/rpi-whoami:latest "/http" 8 minutes ago Up 8 minutes 8000/tcp whoami.1.bg4qlpiye6h6uxyf8cmkwuh52

如大家所见,已经启动的容器有5套,其中3套驻留于“pi6”中。


下面看看是否能够找到其它容器:
root@pi1 docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db411a119c0a hypriot/rpi-whoami:latest "/http" 6 minutes ago Up 6 minutes 8000/tcp whoami.2.2tf7yhmx9haol7e2b7xib2emj
0a4bf32fa9c4 hypriot/rpi-whoami:latest "/http" 6 minutes ago Up 6 minutes 8000/tcp whoami.3.2r6mm091c2ybr0f9jz4qaxw9k

那么如果我们将这套Swarm集群驻留在“pi1”上,结果又会如何?
root@pi1 docker swarm leave
Node left the default swarm.

下面看看另一节点上的运行情况:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
58620e3d533c hypriot/rpi-whoami:latest "/http" 46 seconds ago Up 43 seconds 8000/tcp whoami.2.cgc4e2ixulc2f3ehr4laoursg
acc9b523f434 hypriot/rpi-whoami:latest "/http" 46 seconds ago Up 43 seconds 8000/tcp whoami.3.67bhlo3nwgehthi3bg5bfdzue
e1863a2be88d hypriot/rpi-whoami:latest "/http" 8 minutes ago Up 8 minutes 8000/tcp whoami.4.0lg12zndbal72exqe08r9wvpg
8db1657e8517 hypriot/rpi-whoami:latest "/http" 8 minutes ago Up 8 minutes 8000/tcp whoami.5.5z6mvsrdy73m5w24icgsqc8i2
1b6df814c654 hypriot/rpi-whoami:latest "/http" 15 minutes ago Up 14 minutes 8000/tcp whoami.1.bg4qlpiye6h6uxyf8cmkwuh52

这里的情况相当于“pi1”节点发生故障,此时“pi1”中运行的全部容器都会被自动迁移至另一集群节点。这项机制在实际生产当中无疑非常重要。


那么下面我们回顾一下之前了解到的信息:


我们创建了一款小型动态微服务应用,完全由Docker构成。Docker Swarm现在被整合至Docker-Engine当中,而不再以独立软件形式存在。在多数情况下,这能够为应用后端服务建立起独立的代理机制。不再需要使用nginx、HAProxy或者Traefik。

尽管活动部件数量有所减少,但我们现在反而拥有了内置的高可用性与负载均衡功能。我非常期待未来Docker Swarm正式版本中会带来哪些新的惊喜,又如何与Docker Compose进行协作。

响应银监会十三五规划之拥抱容器系列(一):微服务化

宁静胡同 发表了文章 • 0 个评论 • 451 次浏览 • 2016-07-21 11:50 • 来自相关话题

中国银监会7月15日就《中国银行业信息科技“十三五”发展规划监管指导意见(征求意见稿)》(以下简称指导意见)公开征求意见。从提升信息科技治理水平,深化科技创新,推进互联网、大数据、云计算新技术应用等方面入手,指出健全产品研发管理机制,加强信息安全管理,提升信息科技风险管理水平,推进科技开发协作等方面重点工作任务。

指导意见同时指出,银行业应该适应互联网环境下计算资源弹性变化和快速部署等需求,开展云计算架构规划,制定云计算应用策略。探索构建私有云平台,采用成熟度高、开放性强的计算虚拟化、容器虚拟化、分布式存储、网络虚拟化等技术,建立资源池,形成资源弹性供给、灵活调度和动态计量的私有云平台。探索建立银行业金融公共服务行业云,构建私有云与行业云相结合的混合云应用。同步开展应用架构规划,构建与云计算基础设施相适应的应用架构,自主设计或推动应用开发商实施应用架构改造,并降低应用与基础架构的耦合度。稳步实施架构迁移,到“十三五”末期,面向互联网场景的主要信息系统尽可能迁移至云计算架构平台。

银行业拥抱云计算已经是必然趋势,而容器则是其中的关键技术。数人云推出了传统金融业Docker实践系列组图与文章,将一一为大家展现传统金融业的转型过程中的技术细节与实践心得,欢迎大家持续关注。







数人金融容器云

作为基于Docker的最轻量级PaaS平台,数人金融容器云致力于打造金融领域专属的云原生应用平台,实现秒级启停,帮助客户及时响应高并发等新型业务需求;同时,借助容器技术,使应用的交付变得标准,极大地消除技术部署的局限性,提高客户产品的交付及运维效率;数人金融容器云平台自身具备高可用能力,以最大程度保证对工作集群不间断管控,工作集群内的各组件也具备高可用特性,进一步保障了客户的容器化应用安全、可靠、稳定运行;提供从主机网络到应用容器实例的多级实时监控和告警机制,极大降低了金融IT运维风险。

目前,数人云在金融领域已有多家合作客户,帮助金融客户在互联网+时代下构建开放业务新形态,从平台转型、产品创新、服务交付等层面推进金融业信息化变革,激发创新活力。


  查看全部
中国银监会7月15日就《中国银行业信息科技“十三五”发展规划监管指导意见(征求意见稿)》(以下简称指导意见)公开征求意见。从提升信息科技治理水平,深化科技创新,推进互联网、大数据、云计算新技术应用等方面入手,指出健全产品研发管理机制,加强信息安全管理,提升信息科技风险管理水平,推进科技开发协作等方面重点工作任务。

指导意见同时指出,银行业应该适应互联网环境下计算资源弹性变化和快速部署等需求,开展云计算架构规划,制定云计算应用策略。探索构建私有云平台,采用成熟度高、开放性强的计算虚拟化、容器虚拟化、分布式存储、网络虚拟化等技术,建立资源池,形成资源弹性供给、灵活调度和动态计量的私有云平台。探索建立银行业金融公共服务行业云,构建私有云与行业云相结合的混合云应用。同步开展应用架构规划,构建与云计算基础设施相适应的应用架构,自主设计或推动应用开发商实施应用架构改造,并降低应用与基础架构的耦合度。稳步实施架构迁移,到“十三五”末期,面向互联网场景的主要信息系统尽可能迁移至云计算架构平台。

银行业拥抱云计算已经是必然趋势,而容器则是其中的关键技术。数人云推出了传统金融业Docker实践系列组图与文章,将一一为大家展现传统金融业的转型过程中的技术细节与实践心得,欢迎大家持续关注。


654082800374343878.png


数人金融容器云

作为基于Docker的最轻量级PaaS平台,数人金融容器云致力于打造金融领域专属的云原生应用平台,实现秒级启停,帮助客户及时响应高并发等新型业务需求;同时,借助容器技术,使应用的交付变得标准,极大地消除技术部署的局限性,提高客户产品的交付及运维效率;数人金融容器云平台自身具备高可用能力,以最大程度保证对工作集群不间断管控,工作集群内的各组件也具备高可用特性,进一步保障了客户的容器化应用安全、可靠、稳定运行;提供从主机网络到应用容器实例的多级实时监控和告警机制,极大降低了金融IT运维风险。

目前,数人云在金融领域已有多家合作客户,帮助金融客户在互联网+时代下构建开放业务新形态,从平台转型、产品创新、服务交付等层面推进金融业信息化变革,激发创新活力。


 

Docker 1.12实践:Docker Service、Stack与分布式应用捆绑包

宁静胡同 发表了文章 • 0 个评论 • 887 次浏览 • 2016-07-13 15:10 • 来自相关话题

在本文中数人云将带大家了解如何利用Docker Compose创建一套分布式应用捆绑包,并将其作为Docker Stack在Docker Swarm Mode中进行部署。


Docker 1.12的首套候选发行版于三周之前公布,而近期又有更多新功能计划被添加至该版本当中。


下面首先来看各项新的功能特性:
内置编排机制:通常来讲,应用利用一个Docker Compose文件进行定义。此定义由多个被部署在不同主机上的容器共同构成。这种作法除了能够避免单点故障(简称SPOF)之外,也能够让应用具备弹性。目前包括Docker Swarm、Kubernetes以及Mesos在内的多种编排框架都允许大家对此类应用进行编排。不过现在我们又有了新的选择——Docker Engine如今迎来了内置编排机制。更多细节内容将在后文中进行说明。Service:现在大家可以利用docker service create 命令轻松创建一项复制且分布式的负载均衡服务。该应用可实现“理想状态”,例如运行三套Couchbase容器,并具备自我修复能力。Docker引擎能够确保必要容器数量始终运行于集群当中。如果某容器发生故障,那么另一容器将旋即启动。如果某台节点发生故障,则该节点上的容器会在另一节点上启动。稍后我们将详细说明其作用。零配置安全性: Docker 1.12采用相互验证TLS,能够对swarm当中各节点间的通信内容进行验证、授权与加密。更多详尽内容将在后文中进行讨论。

Docker Stack与分布式应用捆绑包:分布式应用捆绑包,或者简称DAB,是一种多服务可分发镜像格式。在后文中我们会进一步讨论。


截至目前,大家已经可以选定一个Dockerfile,并利用docker build命令由此创建镜像。使用docker run命令则可启动容器。这条命令亦能够轻松同时启动多套容器。另外,大家也可以使用Docker Compose文件并利用docker-compose scale命令对容器进行规模扩展。









镜像属于单一容器的一种便携式格式。而Docker 1.12当中新推出的分布式应用捆绑包,或者简称DAB,则属于一种新的概念,其专门面向多套容器的迁移需求。每个捆绑包都可作为stack在运行时中进行部署。









感兴趣的朋友可以前往docker.com/dab了解更多与DAB相关的内容。为了简单起见,在这里我们利用类比来进行说明:


kerfile -> 镜像 -> 容器

Docker Compose -> 分布式应用捆绑包 -> Docker Stack

下面我们使用一个Docker Compose文件来创建DAB,并将其作为Docker Stack加以部署。


需要强调的是,这项实验性功能仅存在于1.12-RC2版本当中。


利用Docker Compose创建一个分布式应用捆绑包


Docker Compose CLI添加了一条新的bundle命令。下面来看其具体说明:docker-compose bundle --help
Generate a Docker bundle from the Compose file.

Local images will be pushed to a Docker registry, and remote images
will be pulled to fetch an image digest.

Usage: bundle [options]

Options:
-o, --output PATH Path to write the bundle file to.
Defaults to "<project name>.dsb".
现在,让我们选取一条Docker Compose定义并以此为基础创建DAB。以下为我们的Docker Compose定义内容:version: "2"
services:
db:
container_name: "db"
image: arungupta/oreilly-couchbase:latest
ports:
- 8091:8091
- 8092:8092
- 8093:8093
- 11210:11210
web:
image: arungupta/oreilly-wildfly:latest
depends_on:
- db
environment:
- COUCHBASE_URI=db
ports:
- 8080:8080

此Compose文件会启动WildFly与Couchbase服务器。其中WildFly服务器中已经预部署了一款Java EE应用,且接入Couchbase服务器并允许利用REST API执行CRUD操作。该文件的源代码来自:github.com/arun-gupta/oreilly-docker-book/blob/master/hello-javaee/docker-compose.yml。利用它生成一个应用捆绑包:docker-compose bundle
WARNING: Unsupported key 'depends_on' in services.web - ignoring
WARNING: Unsupported key 'container_name' in services.db - ignoring
Wrote bundle to hellojavaee.dsb


depends_on只负责创建两项服务之间的依赖性,并以特定顺序对二者进行启动。这能确保Docker容器首先启动,而运行在其中的应用则需要更长时间才能启动完成。因此,此属性只在一定程度上解决了这一问题。


container_name能够为该容器提供一个特定名称。对特定容器名称的依赖性为紧密耦合,且不允许我们对该容器进行规模伸缩。因此这里我们暂时忽略这两条警告。此命令会利用Compose项目名(也就是其目录名称)生成一个文件。因此在本示例中,生成的文件名为hellojavaee.dsb。此文件的扩展名在RC3中则为.dab。此生成的应用捆绑包内容如下所示:{
"services": {
"db": {
"Image": "arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8091,
"Protocol": "tcp"
},
{
"Port": 8092,
"Protocol": "tcp"
},
{
"Port": 8093,
"Protocol": "tcp"
},
{
"Port": 11210,
"Protocol": "tcp"
}
]
},
"web": {
"Env": [
"COUCHBASE_URI=db"
],
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8080,
"Protocol": "tcp"
}
]
}
},
"version": "0.1"
}


此文件为包含在应用内的各项服务提供完整的描述。当然,未来我们应该可以使用其它容器格式,例如Rkt或者VM等形式。不过就目前来讲,其还仅支持Docker这一种格式。


在Docker中进行Swarm Mode初始化


正如之前所提到,目前“理想状态”由Docker Swarm负责保持。而其现在已经被纳入Docker Engine当中。在本篇文章中,我们使用新增的一条命令,即docker swarm:docker swarm --help

Usage: docker swarm COMMAND

Manage Docker Swarm

Options:
--help Print usage

Commands:
init Initialize a Swarm
join Join a Swarm as a node and/or manager
update Update the Swarm
leave Leave a Swarm
inspect Inspect the Swarm

Run 'docker swarm COMMAND --help' for more information on a command.
在Docker Engine中对一个Swarm节点(作为工作节点)进行初始化:docker swarm init
Swarm initialized: current node (ek9p1k8r8ox7iiua5c247skci) is now a manager.

关于该节点的更多细节信息可利用docker swarm inspect命令进行查看。docker swarm inspect
[
{
"ID": "1rcvu7m9mv2c8hiaijr7an9zk",
"Version": {
"Index": 1895
},
"CreatedAt": "2016-07-01T23:52:38.074748177Z",
"UpdatedAt": "2016-07-02T04:54:32.79093117Z",
"Spec": {
"Name": "default",
"AcceptancePolicy":{
"Policies": [
{
"Role": "worker",
"Autoaccept": true
},
{
"Role": "manager",
"Autoaccept":false
}
]
},
"Orchestration": {
"TaskHistoryRetentionLimit":10
},
"Raft": {
"SnapshotInterval": 10000,
"LogEntriesForSlowFollowers":500,
"HeartbeatTick":1,
"ElectionTick":3
},
"Dispatcher": {
"HeartbeatPeriod": 5000000000
},
"CAConfig": {
"NodeCertExpiry": 7776000000000000
}
}
}
]
从输出结果中可以看到,该节点只属于工作节点而非管理节点。如果在单节点集群当中,这样的设置并无不妥。不过在多节点集群当中,则应至少存在一个管理节点。


部署Docker Stack


利用docker deploy命令创建一个stack:docker deploy -f hellojavaee.dsb hellojavaee
Loading bundle from hellojavaee.dsb
Creating network hellojavaee_default
Creating service hellojavaee_db
Creating service hellojavaee_web
下面来看各服务列表:docker service ls
ID NAME REPLICAS IMAGE COMMAND
2g8kmrimztes hellojavaee_web 1/1 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914
46xhlb15cc60 hellojavaee_db 1/1 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c

在输出结果中,我们可以看到正在运行的两项服务,分别为WildFly与Couchbase。 Service概念同样新增于Docker 1.12版本,其负责为我们提供“理想状态”,而具体实现则由Docker Engine负责。使用docker ps命令显示当前正在运行的容器列表:CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 3 seconds ago Up 1 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29
abf8703ed713 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 3 seconds ago Up 1 seconds 8080/tcp hellojavaee_web.1.70piloz6j4zt06co8htzisgyl

WildFly容器会在Couchbase容器启动并运行之前先行启动。这意味着Java EE应用会尝试接入Couchbase服务器但发生失败。因此,该应用将永远无法成功完成引导。


自我修复Docker Service


Docker Service负责保持应用的“理想状态”。在本示例中,我们的理想状态是确保特定服务有且只有一套容器与之对应且持续运行。如果我们移除该容器,而非服务,则该服务会自动重启容器。使用以下命令移除容器:docker rm -f abf8703ed713

请注意,这里之所以要使用-f,是因为该容器已经处于运行状态。Docker 1.12自我修复机制会介入并自动重启此容器。现在再次打开运行容器列表:CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db483ac27e41 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 1 seconds ago Up Less than a second 8080/tcp hellojavaee_web.1.ddvwdmojjysf46d4n3x4g8uv4
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 26 seconds ago Up 25 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29
结果显示新容器已经启动完成。检查WildFly服务:docker service inspect hellojavaee_web
[
{
"ID": "54otfi6dc9bis7z6gc6ubynwc",
"Version": {
"Index": 328
},
"CreatedAt": "2016-07-02T01:36:35.735767569Z",
"UpdatedAt": "2016-07-02T01:36:35.739240775Z",
"Spec": {
"Name": "hellojavaee_web",
"Labels": {
"com.docker.stack.namespace": "hellojavaee"
},
"TaskTemplate": {
"ContainerSpec": {
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Env": [
"COUCHBASE_URI=db"
]
}
},
"Mode": {
"Replicated": {
"Replicas": 1
}
},
"Networks": [
{
"Target": "epw57lz7txtfchmbf6u0cimis",
"Aliases": [
"web"
]
}
],
"EndpointSpec": {
"Mode": "vip",
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080
}
]
}
},
"Endpoint": {
"Spec": {},
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080,
"PublishedPort": 30004
}
],
"VirtualIPs": [
{
"NetworkID": "9lpz688ir3pzexubkcb828ikg",
"Addr": "10.255.0.5/16"
},
{
"NetworkID": "epw57lz7txtfchmbf6u0cimis",
"Addr": "10.0.0.4/24"
}
]
}
}
]




Swarm会将随机端口分配给该服务,我们也可以利用docker service update命令进行手动更新。在本示例中,容器的端口8080被映射至主机上的端口30004。



进行应用验证


下面检查该应用是否已经成功部署:curl http://localhost:30004/books/resources/book
[{"books":0}]


为该应用添加新的book:curl -v \
> -H "Content-Type: application/json" \
> -X POST -d '{
> "isbn": "978-1-4919-1889-0",
> "name": "Minecraft Modding with Forge",
> "cost": 29.99
> }' \
> http://localhost:30004/books/resources/book
* Trying ::1...
* Connected to localhost (::1) port 30004 (#0)
> POST /books/resources/book HTTP/1.1
> Host: localhost:30004
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 92
>
* upload completely sent off: 92 out of 92 bytes
< HTTP/1.1 200 OK
< Connection: keep-alive
< X-Powered-By: Undertow/1
< Server: WildFly/10
< Content-Type: application/octet-stream
< Content-Length: 88
< Date: Sat, 02 Jul 2016 01:39:49 GMT
<
* Connection #0 to host localhost left intact
{"name":"Minecraft Mhttp://localhost:30004/books/r ... ot%3B}



再次验证该book:curl http://localhost:30004/books/resources/book
[{"books":{"name":"Minecraft Modding with Forge","cost":29.99,"id":"1","isbn":"978-1-4919-1889-0"}}, {"books":1}]
欲了解更多与此Java应用相关的信息,请访问github.com/arun-gupta/oreilly-docker-book/tree/master/hello-javaee。 查看全部
在本文中数人云将带大家了解如何利用Docker Compose创建一套分布式应用捆绑包,并将其作为Docker Stack在Docker Swarm Mode中进行部署。


Docker 1.12的首套候选发行版于三周之前公布,而近期又有更多新功能计划被添加至该版本当中。


下面首先来看各项新的功能特性:
  • 内置编排机制:通常来讲,应用利用一个Docker Compose文件进行定义。此定义由多个被部署在不同主机上的容器共同构成。这种作法除了能够避免单点故障(简称SPOF)之外,也能够让应用具备弹性。目前包括Docker Swarm、Kubernetes以及Mesos在内的多种编排框架都允许大家对此类应用进行编排。不过现在我们又有了新的选择——Docker Engine如今迎来了内置编排机制。更多细节内容将在后文中进行说明。
  • Service:现在大家可以利用docker service create 命令轻松创建一项复制且分布式的负载均衡服务。该应用可实现“理想状态”,例如运行三套Couchbase容器,并具备自我修复能力。Docker引擎能够确保必要容器数量始终运行于集群当中。如果某容器发生故障,那么另一容器将旋即启动。如果某台节点发生故障,则该节点上的容器会在另一节点上启动。稍后我们将详细说明其作用。
  • 零配置安全性: Docker 1.12采用相互验证TLS,能够对swarm当中各节点间的通信内容进行验证、授权与加密。更多详尽内容将在后文中进行讨论。


Docker Stack与分布式应用捆绑包:分布式应用捆绑包,或者简称DAB,是一种多服务可分发镜像格式。在后文中我们会进一步讨论。


截至目前,大家已经可以选定一个Dockerfile,并利用docker build命令由此创建镜像。使用docker run命令则可启动容器。这条命令亦能够轻松同时启动多套容器。另外,大家也可以使用Docker Compose文件并利用docker-compose scale命令对容器进行规模扩展。



1.png



镜像属于单一容器的一种便携式格式。而Docker 1.12当中新推出的分布式应用捆绑包,或者简称DAB,则属于一种新的概念,其专门面向多套容器的迁移需求。每个捆绑包都可作为stack在运行时中进行部署。


2.png




感兴趣的朋友可以前往docker.com/dab了解更多与DAB相关的内容。为了简单起见,在这里我们利用类比来进行说明:


kerfile -> 镜像 -> 容器

Docker Compose -> 分布式应用捆绑包 -> Docker Stack

下面我们使用一个Docker Compose文件来创建DAB,并将其作为Docker Stack加以部署。


需要强调的是,这项实验性功能仅存在于1.12-RC2版本当中。


利用Docker Compose创建一个分布式应用捆绑包


Docker Compose CLI添加了一条新的bundle命令。下面来看其具体说明:
docker-compose bundle --help
Generate a Docker bundle from the Compose file.

Local images will be pushed to a Docker registry, and remote images
will be pulled to fetch an image digest.

Usage: bundle [options]

Options:
-o, --output PATH Path to write the bundle file to.
Defaults to "<project name>.dsb".

现在,让我们选取一条Docker Compose定义并以此为基础创建DAB。以下为我们的Docker Compose定义内容:
version: "2"
services:
db:
container_name: "db"
image: arungupta/oreilly-couchbase:latest
ports:
- 8091:8091
- 8092:8092
- 8093:8093
- 11210:11210
web:
image: arungupta/oreilly-wildfly:latest
depends_on:
- db
environment:
- COUCHBASE_URI=db
ports:
- 8080:8080


此Compose文件会启动WildFly与Couchbase服务器。其中WildFly服务器中已经预部署了一款Java EE应用,且接入Couchbase服务器并允许利用REST API执行CRUD操作。该文件的源代码来自:github.com/arun-gupta/oreilly-docker-book/blob/master/hello-javaee/docker-compose.yml。利用它生成一个应用捆绑包:
docker-compose bundle
WARNING: Unsupported key 'depends_on' in services.web - ignoring
WARNING: Unsupported key 'container_name' in services.db - ignoring
Wrote bundle to hellojavaee.dsb


depends_on只负责创建两项服务之间的依赖性,并以特定顺序对二者进行启动。这能确保Docker容器首先启动,而运行在其中的应用则需要更长时间才能启动完成。因此,此属性只在一定程度上解决了这一问题。


container_name能够为该容器提供一个特定名称。对特定容器名称的依赖性为紧密耦合,且不允许我们对该容器进行规模伸缩。因此这里我们暂时忽略这两条警告。此命令会利用Compose项目名(也就是其目录名称)生成一个文件。因此在本示例中,生成的文件名为hellojavaee.dsb。此文件的扩展名在RC3中则为.dab。此生成的应用捆绑包内容如下所示:
{
"services": {
"db": {
"Image": "arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8091,
"Protocol": "tcp"
},
{
"Port": 8092,
"Protocol": "tcp"
},
{
"Port": 8093,
"Protocol": "tcp"
},
{
"Port": 11210,
"Protocol": "tcp"
}
]
},
"web": {
"Env": [
"COUCHBASE_URI=db"
],
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8080,
"Protocol": "tcp"
}
]
}
},
"version": "0.1"
}


此文件为包含在应用内的各项服务提供完整的描述。当然,未来我们应该可以使用其它容器格式,例如Rkt或者VM等形式。不过就目前来讲,其还仅支持Docker这一种格式。


在Docker中进行Swarm Mode初始化


正如之前所提到,目前“理想状态”由Docker Swarm负责保持。而其现在已经被纳入Docker Engine当中。在本篇文章中,我们使用新增的一条命令,即docker swarm:
docker swarm --help

Usage: docker swarm COMMAND

Manage Docker Swarm

Options:
--help Print usage

Commands:
init Initialize a Swarm
join Join a Swarm as a node and/or manager
update Update the Swarm
leave Leave a Swarm
inspect Inspect the Swarm

Run 'docker swarm COMMAND --help' for more information on a command.

在Docker Engine中对一个Swarm节点(作为工作节点)进行初始化:
docker swarm init
Swarm initialized: current node (ek9p1k8r8ox7iiua5c247skci) is now a manager.


关于该节点的更多细节信息可利用docker swarm inspect命令进行查看。
docker swarm inspect
[
{
"ID": "1rcvu7m9mv2c8hiaijr7an9zk",
"Version": {
"Index": 1895
},
"CreatedAt": "2016-07-01T23:52:38.074748177Z",
"UpdatedAt": "2016-07-02T04:54:32.79093117Z",
"Spec": {
"Name": "default",
"AcceptancePolicy":{
"Policies": [
{
"Role": "worker",
"Autoaccept": true
},
{
"Role": "manager",
"Autoaccept":false
}
]
},
"Orchestration": {
"TaskHistoryRetentionLimit":10
},
"Raft": {
"SnapshotInterval": 10000,
"LogEntriesForSlowFollowers":500,
"HeartbeatTick":1,
"ElectionTick":3
},
"Dispatcher": {
"HeartbeatPeriod": 5000000000
},
"CAConfig": {
"NodeCertExpiry": 7776000000000000
}
}
}
]

从输出结果中可以看到,该节点只属于工作节点而非管理节点。如果在单节点集群当中,这样的设置并无不妥。不过在多节点集群当中,则应至少存在一个管理节点。


部署Docker Stack


利用docker deploy命令创建一个stack:
docker deploy -f hellojavaee.dsb hellojavaee
Loading bundle from hellojavaee.dsb
Creating network hellojavaee_default
Creating service hellojavaee_db
Creating service hellojavaee_web

下面来看各服务列表:
docker service ls
ID NAME REPLICAS IMAGE COMMAND
2g8kmrimztes hellojavaee_web 1/1 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914
46xhlb15cc60 hellojavaee_db 1/1 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c


在输出结果中,我们可以看到正在运行的两项服务,分别为WildFly与Couchbase。 Service概念同样新增于Docker 1.12版本,其负责为我们提供“理想状态”,而具体实现则由Docker Engine负责。使用docker ps命令显示当前正在运行的容器列表:
CONTAINER ID        IMAGE                                                                                                 COMMAND                  CREATED             STATUS              PORTS                                                        NAMES
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 3 seconds ago Up 1 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29
abf8703ed713 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 3 seconds ago Up 1 seconds 8080/tcp hellojavaee_web.1.70piloz6j4zt06co8htzisgyl


WildFly容器会在Couchbase容器启动并运行之前先行启动。这意味着Java EE应用会尝试接入Couchbase服务器但发生失败。因此,该应用将永远无法成功完成引导。


自我修复Docker Service


Docker Service负责保持应用的“理想状态”。在本示例中,我们的理想状态是确保特定服务有且只有一套容器与之对应且持续运行。如果我们移除该容器,而非服务,则该服务会自动重启容器。使用以下命令移除容器:
docker rm -f abf8703ed713


请注意,这里之所以要使用-f,是因为该容器已经处于运行状态。Docker 1.12自我修复机制会介入并自动重启此容器。现在再次打开运行容器列表:
CONTAINER ID        IMAGE                                                                                                 COMMAND                  CREATED             STATUS                  PORTS                                                        NAMES
db483ac27e41 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 1 seconds ago Up Less than a second 8080/tcp hellojavaee_web.1.ddvwdmojjysf46d4n3x4g8uv4
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 26 seconds ago Up 25 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29

结果显示新容器已经启动完成。检查WildFly服务:
docker service inspect hellojavaee_web
[
{
"ID": "54otfi6dc9bis7z6gc6ubynwc",
"Version": {
"Index": 328
},
"CreatedAt": "2016-07-02T01:36:35.735767569Z",
"UpdatedAt": "2016-07-02T01:36:35.739240775Z",
"Spec": {
"Name": "hellojavaee_web",
"Labels": {
"com.docker.stack.namespace": "hellojavaee"
},
"TaskTemplate": {
"ContainerSpec": {
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Env": [
"COUCHBASE_URI=db"
]
}
},
"Mode": {
"Replicated": {
"Replicas": 1
}
},
"Networks": [
{
"Target": "epw57lz7txtfchmbf6u0cimis",
"Aliases": [
"web"
]
}
],
"EndpointSpec": {
"Mode": "vip",
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080
}
]
}
},
"Endpoint": {
"Spec": {},
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080,
"PublishedPort": 30004
}
],
"VirtualIPs": [
{
"NetworkID": "9lpz688ir3pzexubkcb828ikg",
"Addr": "10.255.0.5/16"
},
{
"NetworkID": "epw57lz7txtfchmbf6u0cimis",
"Addr": "10.0.0.4/24"
}
]
}
}
]




Swarm会将随机端口分配给该服务,我们也可以利用docker service update命令进行手动更新。在本示例中,容器的端口8080被映射至主机上的端口30004。



进行应用验证


下面检查该应用是否已经成功部署:
curl http://localhost:30004/books/resources/book
[{"books":0}]


为该应用添加新的book:
curl -v \
> -H "Content-Type: application/json" \
> -X POST -d '{
> "isbn": "978-1-4919-1889-0",
> "name": "Minecraft Modding with Forge",
> "cost": 29.99
> }' \
> http://localhost:30004/books/resources/book
* Trying ::1...
* Connected to localhost (::1) port 30004 (#0)
> POST /books/resources/book HTTP/1.1
> Host: localhost:30004
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 92
>
* upload completely sent off: 92 out of 92 bytes
< HTTP/1.1 200 OK
< Connection: keep-alive
< X-Powered-By: Undertow/1
< Server: WildFly/10
< Content-Type: application/octet-stream
< Content-Length: 88
< Date: Sat, 02 Jul 2016 01:39:49 GMT
<
* Connection #0 to host localhost left intact
{"name":"Minecraft Mhttp://localhost:30004/books/r ... ot%3B}




再次验证该book:
curl http://localhost:30004/books/resources/book
[{"books":{"name":"Minecraft Modding with Forge","cost":29.99,"id":"1","isbn":"978-1-4919-1889-0"}}, {"books":1}]

欲了解更多与此Java应用相关的信息,请访问github.com/arun-gupta/oreilly-docker-book/tree/master/hello-javaee。

中国开源云联盟容器工作组第一次会议召开

宁静胡同 发表了文章 • 0 个评论 • 486 次浏览 • 2016-07-08 16:24 • 来自相关话题

7月7日,中国开源云联盟WG11容器工作组第一次会议在京召开,会议的主题为“容器技术与标准交流会”。此次会议由中国电子技术标准化研究院主办,参与方包括中国开源云联盟容器工作组组长单位数人云,副组长单位CNTV,以及Hyper,去哪儿网,VMware,Intel,中国移动。







中国开源云联盟容器工作组第一次会议召开


会议上,参会单位首先围绕容器生态圈展开了讨论,数人云CTO肖德时和Hyper CTO王旭对容器生态圈以及容器发展趋势进行了分享,吕晓旭分享了去哪儿网使用Mesos+Docker技术在集群、日志收集等场景下的应用情况;张海宁分享了VMware针对容器研究情况,包括容器和虚拟化技术融合的研究以及纯容器数据中心的研究情况;杨剑浩分享了中国移动研究院容器技术在CRM等方面的应用情况;何钦钦分享了CNTV使用容器技术实现快速交付和资源回收的应用案例。此外,参会专家还针对容器在应用情况面临的问题和遇到的挑战展开了讨论。最后,中国电子技术标准化研究院高级工程师陈志峰介绍了我国云计算综合标准化指南、标准体系框架以及云计算标准化白皮书情况,为实现容器领域开展标准化工作提供借鉴。

后续容器工作组将开展我国容器应用和标准化白皮书的编制工作,白皮书编制工作的开展将有利于推动容器技术在国内的落地,并为建立符合中国本地化特征的容器标准奠定基础。


相关背景


中国开源云联盟由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟。作为领先的云计算创新技术实践者,数人云一直致力于推动开源技术的发展,并荣膺联盟挂靠中国电子技术标准化研究院后的首批成员单位。目前,联盟下设工作组工作范围从OpenStack逐渐向开源云计算生态圈的其他技术方向延伸,涉及我国云计算领域较热点的发展趋势,如混合云研究、千节点部署、Ceph开源技术、桌面云技术、容器技术等;同时,部分技术方向已开始探索标准化工作,开展开源标准研究,以及与国家标准、国际标准的配套方式的研究。


5月31日,中国开源云联盟2016年第一次理事会在京召开,会上中国开源云联盟Mesos工作组正式成立,为更好地推进容器及相关技术在中国的落地与实践,Mesos工作组现已正式更名为容器工作组。中国开源云联盟容器工作组旨在推动容器技术在国内的落地,提升容器技术在开源社区的贡献比例,并建立顺应国际技术发展趋势、符合中国本地化特征的容器标准体系。


关于数人云


数人云创始团队来自谷歌、红帽和惠普,在今年3月初公司完成A轮融资,由云启资本领投,思科、策源以及唯猎跟投。作为领先的云计算创新技术实践者,数人云致力于打造最轻量化的PaaS平台,将应用弹性做到极致。基于Docker + Mesos,数人云实现一站式的微服务架构集群系统,最大化地帮助客户实现应用业务在云端的快速部署,解决从客户到云资源的最后一公里。 查看全部
7月7日,中国开源云联盟WG11容器工作组第一次会议在京召开,会议的主题为“容器技术与标准交流会”。此次会议由中国电子技术标准化研究院主办,参与方包括中国开源云联盟容器工作组组长单位数人云,副组长单位CNTV,以及Hyper,去哪儿网,VMware,Intel,中国移动。


685425922798165313.jpg11_.jpg


中国开源云联盟容器工作组第一次会议召开


会议上,参会单位首先围绕容器生态圈展开了讨论,数人云CTO肖德时和Hyper CTO王旭对容器生态圈以及容器发展趋势进行了分享,吕晓旭分享了去哪儿网使用Mesos+Docker技术在集群、日志收集等场景下的应用情况;张海宁分享了VMware针对容器研究情况,包括容器和虚拟化技术融合的研究以及纯容器数据中心的研究情况;杨剑浩分享了中国移动研究院容器技术在CRM等方面的应用情况;何钦钦分享了CNTV使用容器技术实现快速交付和资源回收的应用案例。此外,参会专家还针对容器在应用情况面临的问题和遇到的挑战展开了讨论。最后,中国电子技术标准化研究院高级工程师陈志峰介绍了我国云计算综合标准化指南、标准体系框架以及云计算标准化白皮书情况,为实现容器领域开展标准化工作提供借鉴。

后续容器工作组将开展我国容器应用和标准化白皮书的编制工作,白皮书编制工作的开展将有利于推动容器技术在国内的落地,并为建立符合中国本地化特征的容器标准奠定基础。


相关背景


中国开源云联盟由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟。作为领先的云计算创新技术实践者,数人云一直致力于推动开源技术的发展,并荣膺联盟挂靠中国电子技术标准化研究院后的首批成员单位。目前,联盟下设工作组工作范围从OpenStack逐渐向开源云计算生态圈的其他技术方向延伸,涉及我国云计算领域较热点的发展趋势,如混合云研究、千节点部署、Ceph开源技术、桌面云技术、容器技术等;同时,部分技术方向已开始探索标准化工作,开展开源标准研究,以及与国家标准、国际标准的配套方式的研究。


5月31日,中国开源云联盟2016年第一次理事会在京召开,会上中国开源云联盟Mesos工作组正式成立,为更好地推进容器及相关技术在中国的落地与实践,Mesos工作组现已正式更名为容器工作组。中国开源云联盟容器工作组旨在推动容器技术在国内的落地,提升容器技术在开源社区的贡献比例,并建立顺应国际技术发展趋势、符合中国本地化特征的容器标准体系。


关于数人云


数人云创始团队来自谷歌、红帽和惠普,在今年3月初公司完成A轮融资,由云启资本领投,思科、策源以及唯猎跟投。作为领先的云计算创新技术实践者,数人云致力于打造最轻量化的PaaS平台,将应用弹性做到极致。基于Docker + Mesos,数人云实现一站式的微服务架构集群系统,最大化地帮助客户实现应用业务在云端的快速部署,解决从客户到云资源的最后一公里。

数人云 | 一场属于 Docker&Mesos 的夏日欢乐颂

宁静胡同 发表了文章 • 0 个评论 • 586 次浏览 • 2016-07-04 11:42 • 来自相关话题

上次畅谈容器技术的诗和远方还是 4 月份的春天, 如今,夏天已悄然而至。 在西雅图刚结束的 “DockerCon 2016” 大会上, Swarm 原生编排备受推崇, 有人不禁担心 Mesos 将何去何从? 7月份, 
让我们来一场属于 Docker&Mesos 的欢乐颂, 愉快地探讨一下这个“严肃”的话题:)

号外,论如何优雅的将开源技术进行到底, 中国开源云联盟成立了 WG11—容器工作组, 如果你是容器实践老司机, 欢迎加入开源云联盟, 现缺 2 枚副组长,点击 此处自荐

这次,我们邀请了......

Timothy Chen,硅谷 Mesos 专家【确认中】

分布式系统专家,专注于容器化和大数据框架。他是 Apache Drill 和 Apache Mesos 项目的 PMC/ 贡献者,对 Spark、Kafka 和 Docker 等开源项目亦有贡献。Tim 还有 Halo 上的大数据服务、CloudFoundry (PaaS) 和搜索引擎方面的经验。

《CNTV 容器技术探索与实践》 【已确认】

张航源,CNTV 技术中心-高级工程师

2009年加入CNTV,主要负责CNTV容器化的探索和平台搭建,存储平台的架构和运维,以及ELK平台的建设等工作。

《Containerizer Modularization Proposal for Mesos》【已确认】

黄浩松,Engineer @ Shopee

负责公司自动化运维平台建设。 业余时间在 Apache Mesos / Apache Hadoop / Apache HBase 打酱油。

《思科微服务管理框架 Mantl》【已确认】

谢军,思科大中华区解决方案和产品团队首席架构师

负责思科大中华区下一代数据中心和云体系架构及市场推广,专注混合云/微服务架构/分布式存储等。

议程,是这样安排的......

13:30 - 14:00 签到 
14:00 - 14:15 开场 
14:15 - 14:55 《CNTV容器技术探索与实践》张航源 
14:55 - 15:35 《Containerizer Modularization Proposal for Mesos》黄浩松 
15:35 - 16:15 Timothy Chen 
16:15 - 16:55 《思科微服务管理框架 Mantl》谢军 
16:55 - 17:10 《老肖有话说》肖德时

时间:7月23日 14:00 - 17:10 地点:P2 联合创业办公社—中关村 e 世界 A 座 B2

活动行报名链接:http://t.cn/R5QjqdF 查看全部
MESOS_5.jpg

上次畅谈容器技术的诗和远方还是 4 月份的春天, 如今,夏天已悄然而至。 在西雅图刚结束的 “DockerCon 2016” 大会上, Swarm 原生编排备受推崇, 有人不禁担心 Mesos 将何去何从? 7月份, 
让我们来一场属于 Docker&Mesos 的欢乐颂, 愉快地探讨一下这个“严肃”的话题:)

号外,论如何优雅的将开源技术进行到底, 中国开源云联盟成立了 WG11—容器工作组, 如果你是容器实践老司机, 欢迎加入开源云联盟, 现缺 2 枚副组长,点击 此处自荐

这次,我们邀请了......

Timothy Chen,硅谷 Mesos 专家【确认中】

分布式系统专家,专注于容器化和大数据框架。他是 Apache Drill 和 Apache Mesos 项目的 PMC/ 贡献者,对 Spark、Kafka 和 Docker 等开源项目亦有贡献。Tim 还有 Halo 上的大数据服务、CloudFoundry (PaaS) 和搜索引擎方面的经验。

《CNTV 容器技术探索与实践》 【已确认】

张航源,CNTV 技术中心-高级工程师

2009年加入CNTV,主要负责CNTV容器化的探索和平台搭建,存储平台的架构和运维,以及ELK平台的建设等工作。

《Containerizer Modularization Proposal for Mesos》【已确认】

黄浩松,Engineer @ Shopee

负责公司自动化运维平台建设。 业余时间在 Apache Mesos / Apache Hadoop / Apache HBase 打酱油。

《思科微服务管理框架 Mantl》【已确认】

谢军,思科大中华区解决方案和产品团队首席架构师

负责思科大中华区下一代数据中心和云体系架构及市场推广,专注混合云/微服务架构/分布式存储等。

议程,是这样安排的......

13:30 - 14:00 签到 
14:00 - 14:15 开场 
14:15 - 14:55 《CNTV容器技术探索与实践》张航源 
14:55 - 15:35 《Containerizer Modularization Proposal for Mesos》黄浩松 
15:35 - 16:15 Timothy Chen 
16:15 - 16:55 《思科微服务管理框架 Mantl》谢军 
16:55 - 17:10 《老肖有话说》肖德时

时间:7月23日 14:00 - 17:10 地点:P2 联合创业办公社—中关村 e 世界 A 座 B2

活动行报名链接:http://t.cn/R5QjqdF

关于Docker 1.12中的最新功能,你需要了解这些

宁静胡同 发表了文章 • 0 个评论 • 603 次浏览 • 2016-06-28 10:46 • 来自相关话题

DockerCon已然落幕,留下了无数激动人心的声音。随着Docker1.12版本的发布,众多新功能新提升的出现,无疑将对Docker为中心的生态圈产生不小的影响。今天小数与大家看一看新版本对于存储层面都有哪些影响——



新版本的发布对存储层面来说,最值得关注的自然是分卷驱动器支持能力的强化。这些变更不仅能够使我们对分卷进行标记,从而明确其属于本地抑或全局可访问对象,同时也能够提供与可用分卷相关的驱动器具体信息。另外,1.12版本中还出现了众多提升及修复机制。很明显,部分变更将帮助Docker Swarm更好地完成规模化使命,甚至可以说这一规模化发展思路正是本届DockerCon大会的主旨所在。


值得关注的变化


支持分卷范围(本地/全局)#22077


虽然这一变更谈不到什么飞跃,但如今使用docker分卷(例如swarm)的各服务已经能够将可用分卷识别为本地(特定主机)或全局(全部主机)。过去,当我们在swarm管理器中运行“docker volume ls”时,所有可用于全部swarm代理的全局分卷都会在各主机上被分别列出。这使得我们很难据此构建起可扩展的Docker Swarm集群。现在,新的调整让我们得以轻松区分全局分卷与本地分卷。








支持分卷状态 #21006


过去,每个Docker分卷只包含分卷名称、驱动器名称、安装位置以及基本标签(如果使用)等信息。








而在1.12版本中,我们能够获取更多来自驱动器的各分卷细节信息(嵌套于Status下)。








其它变化


支持ZFS分卷大小 #21946


在1.12版本之前,我们无法强制指定ZFS分卷的大小,但现在已经可以通过“-storage-opts”实现。


支持利用BTRFS实现磁盘配额 #19651


如果利用BTRFS取代devicemapper作为默认docker文件系统,我们将能够为各独立docker容器设置最大大小或容量配额。


分卷名称/驱动器过滤 #21015


新版本提供的增强过滤机制适用于“docker volume”命令/api请求。这意味着我们可以获取更为具体的特定分卷名称信息,或者可由特定分卷驱动器访问的全部分卷。


为分卷安装/卸载请求匹配惟一ID #21015


当分卷安装/卸载请求被发送至分卷驱动器时,系统会同时生成一条惟一ID以确保驱动器对各请求加以追踪。如此一来,分卷驱动器就能够更好地识别安装与卸载请求。


SELinux用户迎来小幅修复 #17262


如果大家在自己的docker主机上使用SELinux,则#17262能够修复将本地目录附加至新容器时z/Z权限选项的使用方式。在原有版本中,由于新容器中不存在启动所需要的文件夹,因此直接附加会导致失败。


本文源自:EMC {code},作者 Chris Duchesne 查看全部
DockerCon已然落幕,留下了无数激动人心的声音。随着Docker1.12版本的发布,众多新功能新提升的出现,无疑将对Docker为中心的生态圈产生不小的影响。今天小数与大家看一看新版本对于存储层面都有哪些影响——



新版本的发布对存储层面来说,最值得关注的自然是分卷驱动器支持能力的强化。这些变更不仅能够使我们对分卷进行标记,从而明确其属于本地抑或全局可访问对象,同时也能够提供与可用分卷相关的驱动器具体信息。另外,1.12版本中还出现了众多提升及修复机制。很明显,部分变更将帮助Docker Swarm更好地完成规模化使命,甚至可以说这一规模化发展思路正是本届DockerCon大会的主旨所在。


值得关注的变化


支持分卷范围(本地/全局)#22077


虽然这一变更谈不到什么飞跃,但如今使用docker分卷(例如swarm)的各服务已经能够将可用分卷识别为本地(特定主机)或全局(全部主机)。过去,当我们在swarm管理器中运行“docker volume ls”时,所有可用于全部swarm代理的全局分卷都会在各主机上被分别列出。这使得我们很难据此构建起可扩展的Docker Swarm集群。现在,新的调整让我们得以轻松区分全局分卷与本地分卷。


1.png



支持分卷状态 #21006


过去,每个Docker分卷只包含分卷名称、驱动器名称、安装位置以及基本标签(如果使用)等信息。



2.png


而在1.12版本中,我们能够获取更多来自驱动器的各分卷细节信息(嵌套于Status下)。


3.png



其它变化


支持ZFS分卷大小 #21946


在1.12版本之前,我们无法强制指定ZFS分卷的大小,但现在已经可以通过“-storage-opts”实现。


支持利用BTRFS实现磁盘配额 #19651


如果利用BTRFS取代devicemapper作为默认docker文件系统,我们将能够为各独立docker容器设置最大大小或容量配额。


分卷名称/驱动器过滤 #21015


新版本提供的增强过滤机制适用于“docker volume”命令/api请求。这意味着我们可以获取更为具体的特定分卷名称信息,或者可由特定分卷驱动器访问的全部分卷。


为分卷安装/卸载请求匹配惟一ID #21015


当分卷安装/卸载请求被发送至分卷驱动器时,系统会同时生成一条惟一ID以确保驱动器对各请求加以追踪。如此一来,分卷驱动器就能够更好地识别安装与卸载请求。


SELinux用户迎来小幅修复 #17262


如果大家在自己的docker主机上使用SELinux,则#17262能够修复将本地目录附加至新容器时z/Z权限选项的使用方式。在原有版本中,由于新容器中不存在启动所需要的文件夹,因此直接附加会导致失败。


本文源自:EMC {code},作者 Chris Duchesne

智能运维 | 如何做好持续集成——Jenkins on Mesos 实践

宁静胡同 发表了文章 • 0 个评论 • 1296 次浏览 • 2016-06-24 11:18 • 来自相关话题

今天小数给大家带来的又是十足的干货:当运维遇到云计算,当Docker遇到Mesos和Jenkins,会擦出怎样的火花呢?且看来自数人云运维工程师金烨的演讲实录分享——


持续集成的价值

首先讲一下持续集成的优势。过去公司做测试可能需要十几、二十几个组件,集成一次往往要一两个小时,费力费时,而且复杂容易出错,而一旦配置出错的话耗时会更久。因此,一次集成测试一周才会做一次,测出Bug要到下一周才能更新,再做测试,这个周期会非常漫长。而持续集成的意义就在于减少风险,和重复的过程,最终提高工作效率。

Docker

Docker是现在非常火的一门技术,使用Docker首先解决的是环境的问题。因为开发环境和运维的部署环境千奇百怪,依赖的环境和包各不一样。其次,Docker是可以实现更快速地交付和部署,只要写一个Dockerfile,把服务打成一个镜像,然后再迁移到各种服务器上就行了,部署的过程也非常方便,服务器只要有Docker的环境就可以运行。因为是内核级虚拟化解决方案,Docker利用的额外资源很少,同时,它的更新管理也非常容易,只需要把Dockerfile修改一两行,其他的服务器则不需要做改动,也不需要下载其它的安装依赖包,打好Docker镜像直接就可以部署镜像、直接运行。这些都是它的优势。

Mesos






Apache Mesos是一款开源集群管理软件。Mesos经过了Facebook,Twitter这些大型公司的万台主机验证,在国内,爱奇艺、去哪网,小米网等公司也拥有大规模的Mesos集群应用。Mesos实现了两级调度架构,可以管理多种类型的应用程序。第一级调度是Master的守护进程,管理Mesos集群中所有节点上运行的Slave守护进程。集群由物理服务器或虚拟服务器组成,用于运行应用程序的任务,比如Hadoop和MPI作业。第二级调度由被称作Framework的“组件”组成。Framework包括调度器(Scheduler)和执行器(Executor)进程,其中每个节点上都会运行执行器。Mesos能和不同类型的Framework通信,每种Framework由相应的应用集群管理。图中只展示了Hadoop和MPI两种类型,其它类型的应用程序也有相应的Framework。Mesos支持多种Framework,比如说Hadoop,Spark,Storm等等,各类型的Framework在它上面都可以运行。

Marathon

Marathon是Mesosphere为Mesos生态圈打造的一个轻量级管理服务APP框架,它可以用RESTful API方便地进行操作。

Marathon 协调应用和Frameworks

下图是在Marathon上发布各种的服务,它们都可以通过Marathon发到Mesos的集群资源中。






扩展和故障恢复

例如我们发了三个服务,分别是有一个节点的,三个节点的和五个节点的。

我们想拓展这些服务的话,可以调用Marathon的API进行扩展,秒级扩展到下图。

如果有一台主机宕掉了, Marathon会均匀地把服务迁移到其他的机器上,选择资源有空余的机器进行迁移。这样能就保证服务是动态的调度,保证服务的高可用,并且这些都是它内部自行处理的,不需要手动干预。

Jenkins

介绍

Jenkins是Java开发的一种持续集成的工具,我们在它的基础上做了一些重复的工作,比如版本发布、测试代码,以及调用外部接口。Jenkins支持很多插件,可以很方便地选择使用适合自己团队的插件工具。

问题

Jenkins为我们提供了便利,当然Jenkins本身也有它自己的问题,比如传统的Jenkins是单点的,任务大多是需要排队的,如果每个任务都自己建一套Jenkins的话,资源会非常浪费。为了解决这些问题,我们引入了Jenkins On Mesos。

Jenkins On Mesos

Jenkins 分为Master 节点和Slave 节点,Master 进行调度,Slave节点负责负责执行Job任务。

Jenkins master






首先我们把Jenkins的Master通过Marathon发布,Marathon 去调用 Mesos Master,之后Mesos Master再去Slave节点起Jenkins的Master。这个机制保证了Jenkins Master的高可用,Marathon会监控Jenkins Master的健康状态,当Jenkins Master出现崩溃挂掉,Marathon会自动再启动一个Jenkins Master的任务。Jenkins Master使用Mesos整个大的资源池,Mesos的资源池是一个资源共享的状态,资源利用率也会更高一些。

Jenkins Slave






Jenkins Master做的是调度,Jenkins Slave则是真正执行构建任务的地方。Jenkins Master会在Mesos Master上注册一个它自己的Framework,如果有任务需要构建的话,Jenkins Master 会通知 Jenkins Framework 调用 Mesos Master构建一个任务。之后Mesos Master 再调用 Mesos Slave去起一个Jenkins Slave的节点去构建任务,它是实时的,用户资源可能被分配到各个机器上,在不同的机器上并行存在。此外,Jenkins还具备动态调度功能,也就是说,当任务运行完后一定时间,资源会再返还给Mesos,实现合理地利用整个集群的资源,提高集群的资源利用率。

Mesos 整体流程






这张图是Mesos整体的调度流程。第一步,它的集群有三个Mesos Slave节点资源,资源上报到Mesos Master,Mesos Master收集到这些资源之后把这些资源再提供给Marathon,Marathon如果要发任务,它确认一个Offer1,Offer1足够任务来运行,就拒绝其他的Offer,并把这个任务发送给Mesos Master,之后Mesos Master去找Slave1起Marathon的任务。这是Marathon的任务启动过程。Mesos本身可以和多框架进行通信,Jenkins Master要跑一个任务,Mesos Master同样提供资源给Jenkins,提供的资源包括了Marathon 任务使用剩下的资源,比如Task1 确认的 Offer1没有用完和没有使用的资源,Mesos也会它提供给Jenkins。而Jenkins也会选择,比如Jenkins选择了Offer3,拒绝了其他的Offer,把Jenksin的任务再通过Mesos Master去Mesos Slave中起起来。

Jenkins On Mesos Docker化

Jenkins部署起来非常麻烦,需要安装各种依赖,如果代码是从Git上下载的,那么还需要安装一些Git包。而动态调度需要每台机器上都装这些依赖,为了解决这种问题,我们把服务全部进行了Docker化,主机上只需要有Docker环境就可以运行我们的服务。

遇到的坑

进行Docker化之后就会面临Docker化的问题,因为Docker和 Mesos都是比较新的技术,我们遇到了很多坑,也需要去解决。

我们遇到的第一个问题是Jenkinson Mesos需要调度Mesos的Lib库,如果Docker化之后是隔离的,就调不到Mesos Lib。

第二个问题是Docker化的数据,因为Jenkins是没有数据库的,数据都是存在本地的JENKINS_HOME目录中,如果Jenkins Master挂掉之后,相应的数据就没有了。

第三个问题是Jenkins需要升级,插件也需要升级,而镜像本身没办法自动升级。

解决

为了解决这些问题,首先我们将Mesos打成一个基础镜像,在这个基础镜像上安装Jenkins的服务制作成一个Jenkins的镜像,这样就可以调用Mesos的Lib库文件了。

第二是数据备份,我们在Jenkins上安装了一个插件,就是SCM Sync Configuration Plugin 这个插件,它会同步数据到Github。如果这个Jenkins Master挂掉了,迁移到另外一台主机上,它会从Github上面把数据克隆下来,数据是不会丢失的。此外,如果插件出了故障,或者因为网络问题导致Github访问不了,我们把JENKINS HOME目录挂在主机上进行备份,进行恢复的时候也会很方便。用以上这两点来保证数据的完整性。

第三对于Jenkins升级或其插件的升级,我们现在的做法是把它重新打一个镜像,重新在Mararhton发布Jenkins Master。

Jenkins Slave On Docker 工作流程






首先Jenkins Master如果要构建一个Job,让Mesos Slave起一个Jenkins Slave这样的容器,容器里面是没有Docker环境的,因为容器里面再装一个Docker环境就太重了。我们现在的做法是把Jenkins Slave用到的命令挂载,其中包括 /usr/bin/docker /var/lib/docker /sys/fs/cgroup /var/run/docker.sock ,这样在容器内部就可以操作主机上的Docker环境,Jenkins Slave 可以在容器内部进行一些Docker Build,Docker Run,Docker Push等工作。

Jenkins Job List






这是我们运维平台一些Job List,左下角是Mesos各个Slave的节点,每一个节点上都有任务,这些任务都是并行的。因为我们的服务模块比较多,可能一个模块一天提交十几次,这么多的模块在一天提交几十次或者上百次的情况也出现过。手动更新、构建的话是非常难做到的。现在,做成Jenkins 分布式执行Job的模式,一天构建几百上千次也没有问题,它会把构建的任务均匀的分布在主机资源里。

数人云运维平台持续集成实践






这是数人云运维平台的持续集成实践。首先讲几个组件,比如Github,它是存储代码的,第二个组件是我们自己开发了的一个Configserver的API,第三个组件是Jenkins和Marathon。第四个组件是我们的私有Registry,是Docker的一个存储镜像的镜像仓库。最右下角是CDN,安装包传送到达的地方。

首先Jenkins触发任务,Jenkins调用Configserver提供的API,这个API就去Github上获取最新代码的Tag,并对比现有的已经更新过的Tag。如果不需要更新,这个任务就完成了,结束了。如果需要更新的话,就进行第三步,把从Github拉的代码放到Configserver上,Jenkins Slave的节点会从Configserver去拉取代码到Slave的容器之中。把代码下载之后再去Pull一个我们编译环境的镜像,然后再用这个镜像去编译我们的代码。比如编译出来一个二进制代码,我们把这个二进制重新打一个运行时的镜像。这个Runtime镜像打好之后我们再使用Docker Push把它推到私有的Registry,镜像Push到Registry后,就可以发布到各种的环境,比如说Dev Demo生产环境,调用Marathon API直接发布就可以了。同样在Jenkins Slave,推完镜像之后就可以去调用。这样一个整体构建镜像再部署的任务就构建完成了。

如果有一些安装包,比如我们的Agent包,它不需要发布Marathon,需要上传到CDN,也是在Jenkins Slave 中执行的。

配置管理

问题

因为我们引入了Docker,而且是分布式动态调度的,传统的配置工具如Ansible、Puppet 、SaltStack都已经不适用了,没办法去管理Docker内部的东西。这些配置文件修改起来非常麻烦。

配置中心一期






讲一下如何进行配置的更新。首先我们做了一个配置中心的一期,把镜像嵌入自己的脚本,这个脚本实现的功能就是 根据传入的ENV CONFIG_SERVER和 SERVICE ,访问 Configserver的API,API返回的数据就是这个服务需要下载的配置文件的列表,以及它需要下载到哪个目录底下。Configserver也非常简单,起一个Nginx,去Vim手动修改。容器一重启,就会自动拉这些配置文件,把配置进行更新。

一期的问题

一期完成之后,因为是多种环境,如Dev Demo环境、预生产环境、生产环境等等,虽然把这些配置都在Configserver上集中配置,但还需要手动修改这些配置。手动修改容易出错,例如Dev更新了一个服务,可能过了一周才会更新到生产环境。那个时候再去修改生产就很容易出错,导致无法运行。此外,如果配置发生了Bug需要回滚,手动修改也是不合适的。

配置中心二期






为了解决这些问题,我们做了ConfigCenter的二期。其中有我们自己开发的一个运维平台,以及Github和Gitlab。Github是个存储项目的代码,Gitlab是用了存储配置模板和最终配置文件的。我们用Jenkins把它们整体的串起来,我们的第一个工作是把所有的配置文件抽象化,各种环境的文件抽象出来一个模板,放在Gitlab上。它的数据是放在数据库里面,这样组合起来是一个完整的配置文件。各个环境的值是不一样的。 我们的运维平台触发Jenkins,Jenkins去调度我们的ConfigCenter API,它传入两个参数,一个是需要更新的环境,第二个是更新哪个服务。之后API去做对比,从数据库去读现有的配置文件的模板Tag,再去读新模板的Tag进行对比。如果这个文件需要更新,把它从数据库拉过来,数据做匹配,渲染成我们最终的配置文件,再传到Gitlab上。剩下的通过Jenkins 触发 Configserver去调Gitlab下载最新的配置文件到Configserver服务器,Jenkins再去调用Marathon去重启服务,服务就会成功更新配置文件。

这里有两个需要注意的点,一方面模板需要更新,另一方面值要更新,这是两种模式。模板更新是所有的流程都要走一遍,如果模板没有更新,只是值更新的话,我们只需要在运维平台上做修改。修改的同时它会做一个标记,说明这个服务配置文件是需要更新的,之后就会生成一个最新的配置继续下面的操作。如果这两个都不需要更新的话就返回,不再操作。

今天的分享就到此为止,谢谢大家。

  查看全部


今天小数给大家带来的又是十足的干货:当运维遇到云计算,当Docker遇到Mesos和Jenkins,会擦出怎样的火花呢?且看来自数人云运维工程师金烨的演讲实录分享——



持续集成的价值

首先讲一下持续集成的优势。过去公司做测试可能需要十几、二十几个组件,集成一次往往要一两个小时,费力费时,而且复杂容易出错,而一旦配置出错的话耗时会更久。因此,一次集成测试一周才会做一次,测出Bug要到下一周才能更新,再做测试,这个周期会非常漫长。而持续集成的意义就在于减少风险,和重复的过程,最终提高工作效率。

Docker

Docker是现在非常火的一门技术,使用Docker首先解决的是环境的问题。因为开发环境和运维的部署环境千奇百怪,依赖的环境和包各不一样。其次,Docker是可以实现更快速地交付和部署,只要写一个Dockerfile,把服务打成一个镜像,然后再迁移到各种服务器上就行了,部署的过程也非常方便,服务器只要有Docker的环境就可以运行。因为是内核级虚拟化解决方案,Docker利用的额外资源很少,同时,它的更新管理也非常容易,只需要把Dockerfile修改一两行,其他的服务器则不需要做改动,也不需要下载其它的安装依赖包,打好Docker镜像直接就可以部署镜像、直接运行。这些都是它的优势。

Mesos

mesos1.jpg


Apache Mesos是一款开源集群管理软件。Mesos经过了Facebook,Twitter这些大型公司的万台主机验证,在国内,爱奇艺、去哪网,小米网等公司也拥有大规模的Mesos集群应用。Mesos实现了两级调度架构,可以管理多种类型的应用程序。第一级调度是Master的守护进程,管理Mesos集群中所有节点上运行的Slave守护进程。集群由物理服务器或虚拟服务器组成,用于运行应用程序的任务,比如Hadoop和MPI作业。第二级调度由被称作Framework的“组件”组成。Framework包括调度器(Scheduler)和执行器(Executor)进程,其中每个节点上都会运行执行器。Mesos能和不同类型的Framework通信,每种Framework由相应的应用集群管理。图中只展示了Hadoop和MPI两种类型,其它类型的应用程序也有相应的Framework。Mesos支持多种Framework,比如说Hadoop,Spark,Storm等等,各类型的Framework在它上面都可以运行。

Marathon

Marathon是Mesosphere为Mesos生态圈打造的一个轻量级管理服务APP框架,它可以用RESTful API方便地进行操作。

Marathon 协调应用和Frameworks

下图是在Marathon上发布各种的服务,它们都可以通过Marathon发到Mesos的集群资源中。

marathon1.png


扩展和故障恢复

例如我们发了三个服务,分别是有一个节点的,三个节点的和五个节点的。

我们想拓展这些服务的话,可以调用Marathon的API进行扩展,秒级扩展到下图。

如果有一台主机宕掉了, Marathon会均匀地把服务迁移到其他的机器上,选择资源有空余的机器进行迁移。这样能就保证服务是动态的调度,保证服务的高可用,并且这些都是它内部自行处理的,不需要手动干预。

Jenkins

介绍

Jenkins是Java开发的一种持续集成的工具,我们在它的基础上做了一些重复的工作,比如版本发布、测试代码,以及调用外部接口。Jenkins支持很多插件,可以很方便地选择使用适合自己团队的插件工具。

问题

Jenkins为我们提供了便利,当然Jenkins本身也有它自己的问题,比如传统的Jenkins是单点的,任务大多是需要排队的,如果每个任务都自己建一套Jenkins的话,资源会非常浪费。为了解决这些问题,我们引入了Jenkins On Mesos。

Jenkins On Mesos

Jenkins 分为Master 节点和Slave 节点,Master 进行调度,Slave节点负责负责执行Job任务。

Jenkins master

jenkins_master.png


首先我们把Jenkins的Master通过Marathon发布,Marathon 去调用 Mesos Master,之后Mesos Master再去Slave节点起Jenkins的Master。这个机制保证了Jenkins Master的高可用,Marathon会监控Jenkins Master的健康状态,当Jenkins Master出现崩溃挂掉,Marathon会自动再启动一个Jenkins Master的任务。Jenkins Master使用Mesos整个大的资源池,Mesos的资源池是一个资源共享的状态,资源利用率也会更高一些。

Jenkins Slave

jenkins_slave.png


Jenkins Master做的是调度,Jenkins Slave则是真正执行构建任务的地方。Jenkins Master会在Mesos Master上注册一个它自己的Framework,如果有任务需要构建的话,Jenkins Master 会通知 Jenkins Framework 调用 Mesos Master构建一个任务。之后Mesos Master 再调用 Mesos Slave去起一个Jenkins Slave的节点去构建任务,它是实时的,用户资源可能被分配到各个机器上,在不同的机器上并行存在。此外,Jenkins还具备动态调度功能,也就是说,当任务运行完后一定时间,资源会再返还给Mesos,实现合理地利用整个集群的资源,提高集群的资源利用率。

Mesos 整体流程

jenkins_on_mesos.png


这张图是Mesos整体的调度流程。第一步,它的集群有三个Mesos Slave节点资源,资源上报到Mesos Master,Mesos Master收集到这些资源之后把这些资源再提供给Marathon,Marathon如果要发任务,它确认一个Offer1,Offer1足够任务来运行,就拒绝其他的Offer,并把这个任务发送给Mesos Master,之后Mesos Master去找Slave1起Marathon的任务。这是Marathon的任务启动过程。Mesos本身可以和多框架进行通信,Jenkins Master要跑一个任务,Mesos Master同样提供资源给Jenkins,提供的资源包括了Marathon 任务使用剩下的资源,比如Task1 确认的 Offer1没有用完和没有使用的资源,Mesos也会它提供给Jenkins。而Jenkins也会选择,比如Jenkins选择了Offer3,拒绝了其他的Offer,把Jenksin的任务再通过Mesos Master去Mesos Slave中起起来。

Jenkins On Mesos Docker化

Jenkins部署起来非常麻烦,需要安装各种依赖,如果代码是从Git上下载的,那么还需要安装一些Git包。而动态调度需要每台机器上都装这些依赖,为了解决这种问题,我们把服务全部进行了Docker化,主机上只需要有Docker环境就可以运行我们的服务。

遇到的坑

进行Docker化之后就会面临Docker化的问题,因为Docker和 Mesos都是比较新的技术,我们遇到了很多坑,也需要去解决。

我们遇到的第一个问题是Jenkinson Mesos需要调度Mesos的Lib库,如果Docker化之后是隔离的,就调不到Mesos Lib。

第二个问题是Docker化的数据,因为Jenkins是没有数据库的,数据都是存在本地的JENKINS_HOME目录中,如果Jenkins Master挂掉之后,相应的数据就没有了。

第三个问题是Jenkins需要升级,插件也需要升级,而镜像本身没办法自动升级。

解决

为了解决这些问题,首先我们将Mesos打成一个基础镜像,在这个基础镜像上安装Jenkins的服务制作成一个Jenkins的镜像,这样就可以调用Mesos的Lib库文件了。

第二是数据备份,我们在Jenkins上安装了一个插件,就是SCM Sync Configuration Plugin 这个插件,它会同步数据到Github。如果这个Jenkins Master挂掉了,迁移到另外一台主机上,它会从Github上面把数据克隆下来,数据是不会丢失的。此外,如果插件出了故障,或者因为网络问题导致Github访问不了,我们把JENKINS HOME目录挂在主机上进行备份,进行恢复的时候也会很方便。用以上这两点来保证数据的完整性。

第三对于Jenkins升级或其插件的升级,我们现在的做法是把它重新打一个镜像,重新在Mararhton发布Jenkins Master。

Jenkins Slave On Docker 工作流程

jenkins_slave_docker.png


首先Jenkins Master如果要构建一个Job,让Mesos Slave起一个Jenkins Slave这样的容器,容器里面是没有Docker环境的,因为容器里面再装一个Docker环境就太重了。我们现在的做法是把Jenkins Slave用到的命令挂载,其中包括 /usr/bin/docker /var/lib/docker /sys/fs/cgroup /var/run/docker.sock ,这样在容器内部就可以操作主机上的Docker环境,Jenkins Slave 可以在容器内部进行一些Docker Build,Docker Run,Docker Push等工作。

Jenkins Job List

jenkins_job_list.png


这是我们运维平台一些Job List,左下角是Mesos各个Slave的节点,每一个节点上都有任务,这些任务都是并行的。因为我们的服务模块比较多,可能一个模块一天提交十几次,这么多的模块在一天提交几十次或者上百次的情况也出现过。手动更新、构建的话是非常难做到的。现在,做成Jenkins 分布式执行Job的模式,一天构建几百上千次也没有问题,它会把构建的任务均匀的分布在主机资源里。

数人云运维平台持续集成实践

sryci.png


这是数人云运维平台的持续集成实践。首先讲几个组件,比如Github,它是存储代码的,第二个组件是我们自己开发了的一个Configserver的API,第三个组件是Jenkins和Marathon。第四个组件是我们的私有Registry,是Docker的一个存储镜像的镜像仓库。最右下角是CDN,安装包传送到达的地方。

首先Jenkins触发任务,Jenkins调用Configserver提供的API,这个API就去Github上获取最新代码的Tag,并对比现有的已经更新过的Tag。如果不需要更新,这个任务就完成了,结束了。如果需要更新的话,就进行第三步,把从Github拉的代码放到Configserver上,Jenkins Slave的节点会从Configserver去拉取代码到Slave的容器之中。把代码下载之后再去Pull一个我们编译环境的镜像,然后再用这个镜像去编译我们的代码。比如编译出来一个二进制代码,我们把这个二进制重新打一个运行时的镜像。这个Runtime镜像打好之后我们再使用Docker Push把它推到私有的Registry,镜像Push到Registry后,就可以发布到各种的环境,比如说Dev Demo生产环境,调用Marathon API直接发布就可以了。同样在Jenkins Slave,推完镜像之后就可以去调用。这样一个整体构建镜像再部署的任务就构建完成了。

如果有一些安装包,比如我们的Agent包,它不需要发布Marathon,需要上传到CDN,也是在Jenkins Slave 中执行的。

配置管理

问题

因为我们引入了Docker,而且是分布式动态调度的,传统的配置工具如Ansible、Puppet 、SaltStack都已经不适用了,没办法去管理Docker内部的东西。这些配置文件修改起来非常麻烦。

配置中心一期

cfgcenter1.png


讲一下如何进行配置的更新。首先我们做了一个配置中心的一期,把镜像嵌入自己的脚本,这个脚本实现的功能就是 根据传入的ENV CONFIG_SERVER和 SERVICE ,访问 Configserver的API,API返回的数据就是这个服务需要下载的配置文件的列表,以及它需要下载到哪个目录底下。Configserver也非常简单,起一个Nginx,去Vim手动修改。容器一重启,就会自动拉这些配置文件,把配置进行更新。

一期的问题

一期完成之后,因为是多种环境,如Dev Demo环境、预生产环境、生产环境等等,虽然把这些配置都在Configserver上集中配置,但还需要手动修改这些配置。手动修改容易出错,例如Dev更新了一个服务,可能过了一周才会更新到生产环境。那个时候再去修改生产就很容易出错,导致无法运行。此外,如果配置发生了Bug需要回滚,手动修改也是不合适的。

配置中心二期

cfgcenter2.png


为了解决这些问题,我们做了ConfigCenter的二期。其中有我们自己开发的一个运维平台,以及Github和Gitlab。Github是个存储项目的代码,Gitlab是用了存储配置模板和最终配置文件的。我们用Jenkins把它们整体的串起来,我们的第一个工作是把所有的配置文件抽象化,各种环境的文件抽象出来一个模板,放在Gitlab上。它的数据是放在数据库里面,这样组合起来是一个完整的配置文件。各个环境的值是不一样的。 我们的运维平台触发Jenkins,Jenkins去调度我们的ConfigCenter API,它传入两个参数,一个是需要更新的环境,第二个是更新哪个服务。之后API去做对比,从数据库去读现有的配置文件的模板Tag,再去读新模板的Tag进行对比。如果这个文件需要更新,把它从数据库拉过来,数据做匹配,渲染成我们最终的配置文件,再传到Gitlab上。剩下的通过Jenkins 触发 Configserver去调Gitlab下载最新的配置文件到Configserver服务器,Jenkins再去调用Marathon去重启服务,服务就会成功更新配置文件。

这里有两个需要注意的点,一方面模板需要更新,另一方面值要更新,这是两种模式。模板更新是所有的流程都要走一遍,如果模板没有更新,只是值更新的话,我们只需要在运维平台上做修改。修改的同时它会做一个标记,说明这个服务配置文件是需要更新的,之后就会生成一个最新的配置继续下面的操作。如果这两个都不需要更新的话就返回,不再操作。

今天的分享就到此为止,谢谢大家。

 
Docker等容器技术交流