s://cloud.tencent.com/developer/?fromSource=waitui , 获取更多腾讯海量技术实践干货哦~
本文由宝哥 @devops 运维 https://cloud.tencent.com/developer/user/1680532 发表于云 + 社区专栏 https://cloud.tencent.com/developer/column/3110
一, 什么是容器?
容器这个词, 当你第一眼看它或许脑子里是这东西: 瓶瓶罐罐, 装水, 装其他东西的玩意.
不管是什么, 总的来说, 容器给人第一印象就是 --"装".
那今天我们要说的容器技术是怎么一个概念呢? 其实, IT 里的容器技术是英文单词 Linux Container 的直译. container 这个单词有集装箱, 容器的含义(主要偏集装箱意思). 不过, 在中文环境下, 咱们要交流要传授, 如果翻译成 "集装箱技术" 就有点拗口, 所以结合中国人的吐字习惯和文化背景, 更喜欢用容器这个词. 不过, 如果要形象的理解 Linux Container 技术的话, 还是得念成集装箱会比较好. 我们知道, 海边码头里的集装箱是运载货物用的, 它是一种按规格标准化的钢制箱子. 集装箱的特色, 在于其格式划一, 并可以层层重叠, 所以可以大量放置在特别设计的远洋轮船中(早期航运是没有集装箱概念的, 那时候货物杂乱无章的放, 很影响出货和运输效率). 有了集装箱, 那么这就更加快捷方便的为生产商提供廉价的运输服务.
因此, IT 世界里借鉴了这一理念. 早期, 大家都认为硬件抽象层基于 hypervisor 的虚拟化方式可以最大程度上提供虚拟化管理的灵活性. 各种不同操作系统的虚拟机都能通过 hypervisor(KVM,XEN 等)来衍生, 运行, 销毁. 然而, 随着时间推移, 用户发现 hypervisor 这种方式麻烦越来越多. 为什么? 因为对于 hypervisor 环境来说, 每个虚拟机都需要运行一个完整的操作系统以及其中安装好的大量应用程序. 但实际生产开发环境里, 我们更关注的是自己部署的应用程序, 如果每次部署发布我都得搞一个完整操作系统和附带的依赖环境, 那么这让任务和性能变得很重和很低下.
基于上述情况, 人们就在想, 有没有其他什么方式能让人更加的关注应用程序本身, 底层多余的操作系统和环境我可以共享和复用? 换句话来说, 那就是我部署一个服务运行好后, 我再想移植到另外一个地方, 我可以不用再安装一套操作系统和依赖环境. 这就像集装箱运载一样, 我把货物一辆兰博基尼跑车 (好比开发好的应用 APP), 打包放到一容器集装箱里, 它通过货轮可以轻而易举的从上海码头(CentOS7.2 环境) 运送到纽约码头 (Ubuntu14.04 环境). 而且运输期间, 我的兰博基尼(APP) 没有受到任何的损坏(文件没有丢失), 在另外一个码头卸货后, 依然可以完美风骚的赛跑(启动正常).
Linux Container 容器技术的诞生 (2008 年) 就解决了 IT 世界里 "集装箱运输" 的问题. Linux Container(简称 LXC)它是一种内核轻量级的操作系统层虚拟化技术. Linux Container 主要由 Namespace 和 Cgroup 两大机制来保证实现. 那么 Namespace 和 Cgroup 是什么呢? 刚才我们上面提到了集装箱, 集装箱的作用当然是可以对货物进行打包隔离了, 不让 A 公司的货跟 B 公司的货混在一起, 不然卸货就分不清楚了. 那么 Namespace 也是一样的作用, 做隔离. 光有隔离还没用, 我们还需要对货物进行资源的管理. 同样的, 航运码头也有这样的管理机制: 货物用什么样规格大小的集装箱, 货物用多少个集装箱, 货物哪些优先运走, 遇到极端天气怎么暂停运输服务怎么改航道等等... 通用的, 与此对应的 Cgroup 就负责资源管理控制作用, 比如进程组使用 CPU/MEM 的限制, 进程组的优先级控制, 进程组的挂起和恢复等等.
二, 容器技术的特点
容器的特点其实我们拿跟它跟硬件抽象层虚拟化 hypervisor 技术对比就清楚了, 我们之前也提到过, 传统的虚拟化 (虚拟机) 技术, 创建环境和部署应用都很麻烦, 而且应用的移植性也很繁琐, 比如你要把 vmware 里的虚拟机迁移到 KVM 里就很繁琐(需要做镜像格式的转换). 那么有了容器技术就简单了, 总结下容器技术主要有三个特点:
\1. 极其轻量: 只打包了必要的 Bin/Lib;
\2. 秒级部署: 根据镜像的不同, 容器的部署大概在毫秒与秒之间(比虚拟机强很多);
\3. 易于移植: 一次构建, 随处部署;
\4. 弹性伸缩: Kubernetes,Swam,Mesos 这类开源, 方便, 好使的容器管理平台有着非常强大的弹性管理能力.
三, 容器的标准化
当前, docker 几乎是容器的代名词, 很多人以为 docker 就是容器. 其实, 这是错误的认识, 除了 docker 还有 coreos. 所以, 容器世界里并不是只有 docker 一家. 既然不是一家就很容易出现分歧. 任何技术出现都需要一个标准来规范它, 不然各搞各的很容易导致技术实现的碎片化, 出现大量的冲突和冗余. 因此, 在 2015 年, 由 Google,Docker,CoreOS,IBM, 微软, 红帽等厂商联合发起的 OCI(Open Container Initiative)组织成立了, 并于 2016 年 4 月推出了第一个开放容器标准. 标准主要包括 runtime 运行时标准和 image 镜像标准. 标准的推出, 有助于替成长中市场带来稳定性, 让企业能放心采用容器技术, 用户在打包, 部署应用程序后, 可以自由选择不同的容器 Runtime; 同时, 镜像打包, 建立, 认证, 部署, 命名也都能按照统一的规范来做.
两种标准主要包含以下内容:
容器运行时标准 (runtime spec)
a). creating: 使用 create 命令创建容器, 这个过程称为创建中 b). created: 容器创建出来, 但是还没有运行, 表示镜像和配置没有错误, 容器能够运行在当前平台 c). running: 容器的运行状态, 里面的进程处于 up 状态, 正在执行用户设定的任务 d). stopped: 容器运行完成, 或者运行出错, 或者 stop 命令之后, 容器处于暂停状态. 这个状态, 容器还有很多信息保存在平台中, 并没有完全被删除
容器镜像标准(image spec)
a). 文件系统: 以 layer 保存的文件系统, 每个 layer 保存了和上层之间变化的部分, layer 应该保存哪些文件, 怎么表示增加, 修改和删除的文件等; b). config 文件: 保存了文件系统的层级信息(每个层级的 hash 值, 以及历史信息), 以及容器运行时需要的一些信息(比如环境变量, 工作目录, 命令参数, mount 列表), 指定了镜像在某个特定平台和系统的配置. 比较接近我们使用 docker inspect
四, 容器的主要应用场景
容器技术的诞生其实主要解决了 PAAS 的层的技术实现. 像 OpenStack,Cloudstack 这样的技术是解决 IAAS 层的问题. IAAS 层和 PAAS 层大家估计也听得很多了, 关于他们的区别和特性我这里不在描述. 那么容器技术主要应用在哪些场景呢? 目前主流的有以下几种:
\1. 容器化传统应用 容器不仅能提高现有应用的安全性和可移植性, 还能节约成本.
每个企业的环境中都有一套较旧的应用来服务于客户或自动执行业务流程. 即使是大规模的单体应用, 通过容器隔离的增强安全性, 以及可移植性特点, 也能从 Docker 中获益, 从而降低成本. 一旦容器化之后, 这些应用可以扩展额外的服务或者转变到微服务架构之上.
\2. 持续集成和持续部署 (CI/CD) 通过 Docker 加速应用管道自动化和应用部署, 交付速度提高至少 13 倍.
现代化开发流程快速, 持续且具备自动执行能力, 最终目标是开发出更加可靠的软件. 通过持续集成 (CI) 和持续部署 (CD), 每次开发人员签入代码并顺利测试之后, IT 团队都能够集成新代码. 作为开发运维方法的基础, CI/CD 创造了一种实时反馈回路机制, 持续地传输小型迭代更改, 从而加速更改, 提高质量. CI 环境通常是完全自动化的, 通过 git 推送命令触发测试, 测试成功时自动构建新镜像, 然后推送到 Docker 镜像库. 通过后续的自动化和脚本, 可以将新镜像的容器部署到预演环境, 从而进行进一步测试.
\3. 微服务 加速应用架构现代化进程.
应用架构正在从采用瀑布模型开发法的单体代码库转变为独立开发和部署的松耦合服务. 成千上万个这样的服务相互连接就形成了应用. Docker 允许开发人员选择最适合于每种服务的工具或技术栈, 隔离服务以消除任何潜在的冲突, 从而避免 "地狱式的矩阵依赖". 这些容器可以独立于应用的其他服务组件, 轻松地共享, 部署, 更新和瞬间扩展. Docker 的端到端安全功能让团队能够构建和运行最低权限的微服务模型, 服务所需的资源 (其他应用, 涉密信息, 计算资源等) 会适时被创建并被访问.
\4. IT 基础设施优化 充分利用基础设施, 节省资金.
Docker 和容器有助于优化 IT 基础设施的利用率和成本. 优化不仅仅是指削减成本, 还能确保在适当的时间有效地使用适当的资源. 容器是一种轻量级的打包和隔离应用工作负载的方法, 所以 Docker 允许在同一物理或虚拟服务器上毫不冲突地运行多项工作负载. 企业可以整合数据中心, 将并购而来的 IT 资源进行整合, 从而获得向云端的可迁移性, 同时减少操作系统和服务器的维护工作.
来源: https://www.cnblogs.com/qcloud1001/p/9273549.html