企业应用快速跨向容器时代的正确姿势

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 本文讲的是企业应用快速跨向容器时代的正确姿势【编者的话】文章以通俗易懂的方式详细解读容器的诞生、容器的管理以及容器如何对应打包等问题。
本文讲的是企业应用快速跨向容器时代的正确姿势【编者的话】文章以通俗易懂的方式详细解读容器的诞生、容器的管理以及容器如何对应打包等问题。

云计算的发展脉络

云计算整个发展过程,用一句话来形容,就是“分久必合,合久必分”。
1.jpg

容器的诞生

云计算解决了基础资源层的弹性伸缩,却没有解决 PaaS层应用随基础资源层弹性伸缩而带来的批量、快速部署问题。于是容器应运而生。

容器是 Container,Container另一个意思是集装箱,其实容器的思想就是要变成软件交付的集装箱。集装箱的特点,一是打包,二是标准。
2.jpg

在没有集装箱的时代,假设将货物从 A运到 B,中间要经过三个码头、换三次船。每次都要将货物卸下船来,摆的七零八落,然后搬上船重新整齐摆好。因此在没有集装箱的时候,每次换船,船员们都要在岸上待几天才能走。
3.jpg

有了集装箱以后,所有的货物都打包在一起了,并且集装箱的尺寸全部一致,所以每次换船的时候,一个箱子整体搬过去就行了,小时级别就能完成,船员再也不用上岸长时间耽搁了。

这是集装箱“打包”、“标准”两大特点在生活中的应用。下面用一个简单的案例来看看容器在开发部署中的实际应用。

假设有一个简单的 Java网站需要上线,代码的运行环境如下:
4.jpg

看,一个简单的 Java网站,就有这么多零零散散的东西!这就像很多零碎的货物,如果不打包,就需要在开发、测试、生产的每个环境上重新查看以保证环境的一致,有时甚至要将这些环境重新搭建一遍,就像每次将货物卸载、重装一样麻烦。中间稍有差池,比如开发环境用了 JDK 1.8,而线上是 JDK 1.7;比如开发环境用了 root用户,线上需要使用 Hadoop用户,都可能导致程序的运行失败。
5.jpg

那么容器如何对应用打包呢?还是要学习集装箱,首先要有个封闭的环境,将货物封装起来,让货物之间互不干扰,互相隔离,这样装货卸货才方便。好在 Ubuntu中的LXC技术早就能做到这一点。
6.jpg

封闭的环境主要使用了两种技术,一种是看起来是隔离的技术,称为 Namespace,也即每个 Namespace中的应用看到的是不同的 IP地址、用户空间、程号等。另一种是用起来是隔离的技术,称为 Cgroups,也即明明整台机器有很多的 CPU、内存,而一个应用只能用其中的一部分。
有了这两项技术,集装箱的铁盒子我们是焊好了,接下来就是决定往里面放什么。
7.jpg

最简单粗暴的方法,就是将上面列表中所有的都放到集装箱里面。但是这样太大了!因为即使你安装一个干干静静的 Ubuntu 操作系统,什么都不装,就很大了。把操作系统装进容器相当于把船也放到了集装箱里面!传统的虚拟机镜像就是这样的,动辄几十G。答案当然是 NO!所以第一项操作系统不能装进容器。

撇下第一项操作系统,剩下的所有的加起来,也就几百 M,就轻便多了。因此一台服务器上的容器是共享操作系统内核的,容器在不同机器之间的迁移不带内核,这也是很多人声称容器是轻量级的虚拟机的原因。轻不白轻,自然隔离性就差了,一个容器让操作系统崩溃了,其他容器也就跟着崩溃了,这相当于一个集装箱把船压漏水了,所有的集装箱一起沉。

另一个需要撇下的就是随着应用的运行而产生并保存在本地的数据。这些数据多以文件的形式存在,例如数据库文件、文本文件。这些文件会随着应用的运行,越来越大,如果这些数据也放在容器里面,会让容器变得很大,影响容器在不同环境的迁移。而且这些数据在开发、测试、线上环境之间的迁移是没有意义的,生产环境不可能用测试环境的文件,所以往往这些数据也是保存在容器外面的存储设备上。这也是为什么人们称容器是无状态的。

至此集装箱焊好了,货物也装进去了,接下来的问题就是如何将这个集装箱标准化,从而在哪艘船上都能运输。这里的标准一个是镜像,一个是容器的运行环境。

所谓的镜像,就是将你焊好集装箱的那一刻,将集装箱的状态保存下来,就像孙悟空说:“定”,集装箱里面就定在了那一刻,然后将这一刻的状态保存成一系列文件。这些文件的格式是标准的,谁看到这些文件都能还原当时定住的那个时刻。将镜像还原成运行时的过程(就是读取镜像文件,还原那个时刻的过程)就是容器运行的过程。除了大名鼎鼎的 Docker,还有其他的容器,例如 AppC、Mesos Container,都能运行容器镜像。所以说容器不等于 Docker。

总而言之,容器是轻量级的、隔离差的、适用于无状态的,可以基于镜像标准实现跨主机、跨环境的随意迁移。
8.jpg

有了容器,使得 PaaS层对于用户自身应用的自动部署变得快速而优雅。容器快就快在两方面:第一,虚拟机启动的时候要先启动操作系统,容器不用启动操作系统,因为是共享内核的;第二,虚拟机启动后使用脚本安装应用,容器不用安装应用,因为已经打包在镜像里面了。所以最终虚拟机的启动是分钟级别,而容器的启动是秒级。容器咋这么神奇?其实一点都不神奇,第一是偷懒少干活了,第二是提前把活干好了。

因为容器启动快,人们往往不会创建一个个小的虚拟机来部署应用,因为这样太浪费时间了,而是创建一个大的虚拟机,然后在大的虚拟机里面再划分容器,而不同的用户不共享大的虚拟机,可以实现操作系统内核的隔离。这又是一次合久必分的过程。由 IaaS层的虚拟机池,划分为更细粒度的容器池。

容器管理平台

有了容器的管理平台,又是一次分久必合的过程。

容器的粒度更加细,管理起来更难管,甚至是手动操作难以应对的。假设你有 100台物理机,其实规模不是太大,用 Excel人工管理是没问题的,但是一台上面开 10台虚拟机,虚拟机的个数就是 1000台,人工管理已经很困难了,但是一台虚拟机里面开 10个容器,就是 10000个容器,你是不是已经彻底放弃人工运维的想法了。

所以容器层面的管理平台是一个新的挑战,关键字就是自动化:
9.jpg

自发现:容器与容器之间的相互配置还能像虚拟机一样,记住 IP地址然后互相配置吗?这么多容器,一旦一台虚拟机挂了重启,IP改变,你怎么记得住应该改哪些配置,列表长度至少万行级别的啊。所以容器之间的配置通过名称来的,无论容器跑到哪台机器上,名称不变,就能访问到。

自修复:容器挂了,或是进程宕机了,能像虚拟机那样登陆上去查看一下进程状态,如果不正常可以重启一下么?那你要登陆万台 Docker了。所以容器的进程挂了,容器就自动挂掉了,然后自动重启。

弹性自伸缩 Auto Scaling:当容器的性能不足的时候,需要手动伸缩、手动部署么?当然也要自动来。

当前火热的容器管理平台有三大流派:
10.jpg

  • 一个是 Kubernetes,我们称为段誉型。
    段誉(Kubernetes)的父亲(Borg)武功高强,出身皇族(Google),管理过偌大的一个大理国(Borg是 Google数据中心的容器管理平台)。作为大理段式后裔,段誉的武功基因良好(Kubernetes的理念设计比较完善),周围的高手云集,习武环境也好(Kubernetes生态活跃,热度高),虽然刚刚出道的段誉武功不及其父亲,但是只要跟着周围的高手不断切磋,武功即可飞速提升。
  • 一个是 Mesos,我们称为乔峰型。
    乔峰(Mesos)的主要功夫降龙十八掌(Mesos的调度功能)独步武林,为其他帮派所无。而且乔峰也管理过人数众多的丐帮(Mesos管理过 Tweeter的容器集群)。后来乔峰从丐帮出来,在江湖中特例独行(Mesos的创始人成立了公司 Mesosphere)。乔峰的优势在于,乔峰的降龙十八掌(Mesos)就是在丐帮中使用的降龙十八掌,相比于段誉初学其父的武功来说,要成熟很多。但是缺点是,降龙十八掌只掌握在少数的几个丐帮帮主手中(Mesos社区还是以 Mesosphere为主导),其他丐帮兄弟只能远远崇拜乔峰,而无法相互切磋(社区热度不足)。
  • 一个是 Swarm,我们称为慕容型。
    慕容家族(Swarm是 Docker家族的集群管理软件)的个人功夫是非常棒的(Docker可以说称为容器的事实标准),但是看到段誉和乔峰能够管理的组织规模越来越大,有一统江湖的趋势,着实眼红了,于是开始想创建自己的慕容鲜卑帝国(推出 Swarm容器集群管理软件)。但是个人功夫好,并不代表着组织能力强(Swarm的集群管理能力),好在慕容家族可以借鉴段誉和乔峰的组织管理经验,学习各家公司,以彼之道,还施彼身,使得慕容公子的组织能力(Swarm借鉴了很多前面的集群管理思想)也在逐渐的成熟中。

三大容器门派,到底鹿死谁手,谁又能一统江湖,尚未可知。

网易之所以选型 Kubernetes作为自己的容器管理平台,是因为基于 Borg 成熟的经验打造的 Kubernetes为容器编排管理提供了完整的开源方案,并且社区活跃,生态完善,积累了大量分布式、服务化系统架构的最佳实践。

容器初体验

我们先了解一下 Docker的生命周期。如图所示。
11.jpg

图中中间的就是最核心的两个部分,一个是镜像 Images,一个是容器 Containers。镜像运行起来就是容器。容器运行的过程中,基于原始镜像做了改变,比如安装了程序,添加了文件,也可以提交回去(commit)成为镜像。

如果大家安装过系统,镜像有点像 GHOST镜像,从 GHOST镜像安装一个系统,运行起来,就相当于容器;容器里面自带应用,就像 GHOST镜像安装的系统里面不是裸的操作系统,里面可能安装了微信,QQ,视频播放软件等。安装好的系统使用过程中又安装了其他软件,或者下载了文件,还可以将这个系统重新 GHOST成一个镜像,当其他人通过这个镜像再安装系统的时候,则其他的软件也就自带了。

普通的 GHOST镜像就是一个文件,但是管理不方便。比如如果有十个 GHOST镜像的话,你可能已经记不清楚哪个镜像里面安装了哪个版本的软件了。所以容器镜像有 tag的概念,就是一个标签,比如 dev-1.0,dev-1.1,production-1.1等,凡是能够帮助你区分不同镜像的都可以。
为了镜像的统一管理,有一个镜像库的东西,可以通过 push将本地的镜像放到统一的镜像库中保存,可以通过 pull将镜像库中的镜像拉到本地来。

从镜像运行一个容器可使用下面的命令,如果初步使用 Docker,记下下面这一个命令就可以了。
12.png

这行命令会启动一个里面安装了 MySQL的容器。其中 docker run就是运行一个容器;--name就是给这个容器起个名字;-v 就是挂数据盘,将外面的一个目录 /my/own/datadir挂载到容器里面的一个目录 /var/lib/mysql作为数据盘,外面的目录是在容器所运行的主机上的,也可以是远程的一个云盘;-e 是设置容器运行环境的环境变量,环境变量是最常使用的设置参数的方式,例如这里设置 MySQL的密码。mysql:tag就是镜像的名字和标签。

docker stop可以停止这个容器,start可以再启动这个容器,restart可以重启这个容器。在容器内部做了改变,例如安装了新的软件,产生了新的文件,则调用 docker commit变成新的镜像。

镜像生产过程,除了可以通过启动一个 Docker,手动修改,然后调用 docker commit形成新镜像之外,还可以通过书写 Dockerfile,通过 docker build来编译这个 Dockerfile形成新的镜像。为什么要这样做呢?前面的方式太不自动化了,需要手工干预,而且还经常会忘了手工都做了什么。用 Dockerfile可以很好地解决这个问题。

Dockerfile 的一个简单的例子如下:
13.png

这其实是一个镜像的生产说明书,Docker build 的过程就是根据这个生产说明书来生产镜像:
  • FROM基础镜像,先下载这个基础镜像,然后从这个镜像启动一个容器,并且登陆到容器里面;
  • RUN 运行一个命令,在容器里面运行这个命令;
  • COPY/ADD 将一些文件添加到容器里面;
  • 最终给容器设置启动命令 ENTRYPOINT,这个命令不在镜像生成过程中执行,而是在容器运行的时候作为主程序执行;
  • 将所有的修改commit成镜像。

这里需要说明一下的就是主程序是 Docker里面的一个重要的概念,虽然镜像里面可以安装很多的程序,但是必须有一个主程序,主程序和容器的生命周期完全一致,主程序在则容器在,主程序亡则容器亡。

容器是一个资源限制的框,但是这个框没有底,全靠主进程撑着,主进程挂了,衣服架子倒了,衣服也就垮了。

了解了如何运行一个独立的容器,接下来介绍如何使用容器管理平台。

容器管理平台初体验

容器管理平台会对容器做更高的抽象,容器不再是单打独斗,而且组成集团军共同战斗。

多个容器组成一个 Pod,这几个容器亲如兄弟,干的也是相关性很强的活,能够通过 localhost访问彼此,真是兄弟齐心,力可断金。有的任务一帮兄弟还扛不住,就需要多个 Pod合力完成,这个由 ReplicationController进行控制,可以将一个 Pod复制 N个副本,同时承载任务,众人拾柴火焰高。

N个 Pod如果对外散兵作战,一是无法合力,二是给人很乱的感觉,因而需要有一个老大作为代言人,将大家团结起来,一致对外,这就是 Service。老大对外提供统一的虚拟 IP和端口,并将这个 IP和服务名关联起来,访问服务名则自动映射为虚拟 IP。老大的意思就是如果外面要访问我这个团队,喊一声名字就可以,例如”雷锋班,帮敬老院打扫卫生!”,你不用管雷锋班的哪个人去打扫卫生,每个人打扫哪一部分,班长会统一分配。

最上层通过 Namespace分隔完全隔离的环境,例如生产环境,测试环境,开发环境等。就像军队分华北野战军,东北野战军一样。野战军立正,出发,部署一个 Tomcat的 Java应用。

作者介绍

刘超,网易云首席解决方案架构师,代码级略懂OpenStack、Hadoop、Docker、Lucene、Mesos等开源软件,10多年的云计算架构与开发经历,积累了丰富的企业级应用的微服务化,容器化实战经验,曾出版《Lucene应用开发揭秘》,个人博客可搜索popsuper1982。

原文发布时间为:2017-01-24

本文作者:刘超

本文来自云栖社区合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。

原文标题:企业应用快速跨向容器时代的正确姿势

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
16天前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker和Kubernetes入门
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术成为企业提升敏捷性和效率的关键。本篇文章将引导读者了解如何利用Docker进行容器化打包及部署,以及Kubernetes集群管理的基础操作,帮助初学者快速入门云原生的世界。通过实际案例分析,我们将深入探讨这些技术在现代IT架构中的应用与影响。
56 2
|
1天前
|
Kubernetes 负载均衡 调度
详细对比了Docker Swarm和Kubernetes两大容器编排技术,从集群管理能力、扩展性、资源利用率、服务发现与负载均衡、多租户支持及易用性等方面进行了深入分析
本文详细对比了Docker Swarm和Kubernetes两大容器编排技术,从集群管理能力、扩展性、资源利用率、服务发现与负载均衡、多租户支持及易用性等方面进行了深入分析,并针对不同应用场景提供了选型建议,帮助读者根据自身需求和技术背景做出合适的选择。
8 2
|
6天前
|
Kubernetes Linux 开发者
深入探索容器化技术——Docker 的实战应用
深入探索容器化技术——Docker 的实战应用
29 5
|
9天前
|
运维 Cloud Native 云计算
云原生之旅:Docker容器化实战
本文将带你走进云原生的世界,深入理解Docker技术如何改变应用部署与运维。我们将通过实际案例,展示如何利用Docker简化开发流程,提升应用的可移植性和伸缩性。文章不仅介绍基础概念,还提供操作指南和最佳实践,帮助你快速上手Docker,开启云原生的第一步。
|
13天前
|
机器学习/深度学习 数据采集 Docker
Docker容器化实战:构建并部署一个简单的Web应用
Docker容器化实战:构建并部署一个简单的Web应用
|
11天前
|
运维 持续交付 虚拟化
深入解析Docker容器化技术的核心原理
深入解析Docker容器化技术的核心原理
31 1
|
13天前
|
JavaScript 开发者 Docker
Docker容器化实战:构建并部署一个简单的Web应用
Docker容器化实战:构建并部署一个简单的Web应用