posts - 269,&
comments - 1205,&
trackbacks - 0
将容器日志发送到 STDOUT 和 STDERR 是 Docker 的默认日志行为。实际上，Docker 提供了多种日志机制帮助用户从运行的容器中提取日志信息。这些机制被称作 logging driver。&
Docker 的默认 logging driver 是&json-file。
# docker info |grep 'Logging Driver'Logging Driver: json-file
如果容器在启动时没有特别指明，就会使用这个默认的 logging driver。
json-file&会将容器的日志保存在 json 文件中，Docker 负责格式化其内容并输出到 STDOUT 和 STDERR。
我们可以在 Host 的容器目录中找到这个文件，器路径为&/var/lib/docker/containers/&contariner ID&/&contariner ID&-json.log
比如我们可以查看前面 httpd 容器 json 格式的日志文件。
可以看到 5 条日志记录。
除了&json-file，Docker 还支持多种 logging driver。完整列表可访问官方文档&
none&是 disable 容器日志功能。
syslog&和&journald&是 Linux 上的两种日志管理服务。
awslogs、splunk&和&gcplogs&是第三方日志托管服务。
gelf&和&fluentd&是两种开源的日志管理方案，我们会在后面分别讨论。
容器启动时可以通过&--log-driver&指定使用的 logging driver。如果要设置 Docker 默认的 logging driver，需要修改 Docker daemon 的启动脚本，指定&--log-driver&参数，比如：
ExecStart=/usr/bin/dockerd -H fd:// --log-driver=syslog --log-opt ......
每种 logging driver 都有自己的&--log-opt，使用时请参考官方文档。
下一节我们开始学习 ELK。
书籍：1.《每天5分钟玩转Docker容器技术》2.《每天5分钟玩转OpenStack》
阅读(...) 评论()中国领先的IT技术网站
51CTO旗下网站
容器技术反例：哪些不适合利用Docker实现？
容器适合处理无状态且仅需要短期运行的应用。这意味着我们不应将数据或者日志存储在容器内――否则其会在容器终止时一并消失。相反，利用分卷映射将其持久存储于容器之外。ELK堆栈可用于存储及处理日志。
作者：核子可乐译来源：51CTO| 09:41
【快译】 此篇文章，将为大家详细介绍那些不适合利用Docker实现的技术。
一）容器中的数据或者日志
容器适合处理无状态且仅需要短期运行的应用。这意味着我们不应将数据或者日志存储在容器内&&否则其会在容器终止时一并消失。相反，利用分卷映射将其持久存储于容器之外。ELK堆栈可用于存储及处理日志。如果所管理分卷曾在测试流程中使用，那么请在dockerrm命令中添加-v将其移除。
二）容器IP地址
每套容器都拥有自己的IP地址。多套容器彼此通信以创建同一应用，例如部署在应用服务器上的应用即需要与数据库对话。在运行过程中，会不断有旧容器关闭，新容器开启。依靠容器IP地址意味着我们需要不断更新应用配置方能保持这种通信能力。相反，我们应当为其创建专门的服务，用于容纳动态变化的容器引用逻辑名称，并借此实现基本的负载均衡功能。
三）容器中运行单一进程
每个Dockerfile都会使用一个CMD与ENTRYPOINT。通常来讲，CMD会利用脚本以执行部分镜像配置，而后启动该容器。不要尝试在该脚本中使用多个进程。大家应当在创建Docker镜像时遵循分离原则的方针，否则会令容器在管理、日志收集以及更新方面遭遇更多难题。大家可以考虑将应用拆分成多套容器，并对其进行逐一管理。
四）不要使用docker exec
docker exec命令会在运行中的容器内开始一条新命令。其适用于利用docker exec -it {cid}
bash实现shell附加。然而除此之外，容器本身应该已经运行有该进程。
五）保持镜像精简
创建一个新目录，并将Dockerfile及其它相关文件保存在其中。另外，考虑使用.dockeringore以移除任何日志、源代码等，而后再进行镜像创建。确保移除一切已经被解压的下载软件包。
六）利用运行中的容器创建镜像
应使用docker
commit命令创建新镜像。这种方式适用于容器已经发生改变的情况。不过由此创建的镜像不可重现。相反，我们应在Dockerfile中进行修改，终止现有容器，并利用更新后的镜像启动新容器。
七）Docker镜像中的安全凭证
不要将安全凭证存储在Dockerfile当中。其将以明文形式存在并被检入存储库内，这将引发潜在的安全威胁。使用-e将密码指定为环境变更。而后，可利用--env-file读取文件中的环境变量。另一种方案是利用CMD或者ENTRYPOINT指定一套脚本。该脚本负责将凭证由第三方处提取出来并用于配置应用。
八）latest标签
很多朋友可能习惯利用couchbase启动镜像。如果未指定标签，那么容器会默认使用couchbase:latest镜像。此镜像可能并非最新，而是引用某个陈旧版本。需要强调的是，将应用引入生产流程要求配合一套采用特定镜像版本的完全受控环境。确保始终使用正确的标签以运行容器&&例如使用couchbase:enterprise-4.5.1而非couchbase。
九）镜像不匹配
不要在开发、测试、分段以及生产环境内使用不同的图像或者标签。作为&选定来源&的镜像应仅创建一次，并被推送至存储库内。该镜像应被用于各类不同环境。在某些情况下，大家可以考虑在WAR文件上运行单元测试，而后再创建镜像。不过请注意，任何系统集成测试都应当在生产环境实际使用的镜像中完成。
十）发布端口
不要利用-P以发布全部公开端口，因为如此一来大家将能够运行多套容器并发布其公开端口。这样做亦意味着全部端口都将公开发布。相反，请使用-p以发布特定端口。
原文标题：Docker Container Anti-Patterns,原文作者：Arun Gupta
【51CTO译稿，合作站点转载请注明原文译者和出处为】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
聚焦热点热点热点热点
24H热文一周话题本月最赞
讲师：305186人学习过
讲师：132411人学习过
讲师：782635人学习过
精选博文论坛热帖下载排行
这并不是一本传统的技术专著，因为它并没有包含一行代码，而更像是一部技术评论。作者通过幽默诙谐而又不失辛辣的语言，从程序员、用户等多...
订阅51CTO邮刊博客访问： 966182
博文数量： 280
博客积分： 1574
博客等级： 上尉
技术积分： 2912
注册时间：
生活的美妙在于，不知道一下秒是惊艳还是伤神，时光流转，珍惜现在的拥有的时光
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： 虚拟化
2.1 容器技术
&&& 2.1.1 关于容器技术
&&&&&&& 容器技术是轻量级的操作系统虚拟化.
&&&&&&& 容器技术在linux内核原生集成.
&&&&&&& 容器主要使用2大linux内核特性:
&&&&&&&&&&& Cgroup:资源控制
&&&&&&&&&&& NameSpace:访问隔离
&&&&&&&&&&& Cgroup与Namespace两种技术并不强相关,可以单独使用.同时使用时就创建了一个容器.
&&& 2.1.2 容器技术的历史
&&&&&&& 文件系统隔离:chroot(不安全)=>pivot_root(安全加强,目前在用)
&&&&&&& 容器:virtuozzo=>OpenVZ=>Cgroup,NameSpace(docker让容器技术获得世界的关注)
&&&&&&&&&&& NameSpace:&&& 使用3个系统调用:clone,setns,unshare
&&&&&&&&&&&&&&& Mount
&&&&&&&&&&&&&&& UTS
&&&&&&&&&&&&&&& IPC
&&&&&&&&&&&&&&& PID
&&&&&&&&&&&&&&& Net
&&&&&&&&&&&&&&& User
&&&&&&&&&&& Cgroup:&&& 使用cgroupfs虚拟文件系统,标准挂载点 /sys/fs/cgroup
&&&&&&&&&&&&&&& cpuset
&&&&&&&&&&&&&&& CPU
&&&&&&&&&&&&&&& memory
&&&&&&&&&&&&&&& device
&&&&&&&&&&&&&&& freezer
&&&&&&&&&&&&&&& blkio
&&&&&&&&&&&&&&& net cls
&&&&&&&&&&&&&&& hugetlb ...
2.2 一分钟理解容器
&&& 2.2.1 容器的组成
&&&&&&& 容器=namespace+cgroup+rootfs+容器引擎(用户态工具)
&&&&&&&&&&&&&&& 访问隔离+资源控制+文件系统隔离+生命周期控制
&&& 2.2.2 容器的创建原理
&&&&&&&& clone namespace=>cgroup=>pivot rootfs=>执行命令
2.3NameSpace
&&&&2.3.1namespace对内核全局资源做封闭,每个namespace都有独立资源,不同进程在各自的namespace中调用同一资源互不干扰.
&&&&&&&&&&& NameSpace& 6大组件:
&&&&&&&&&&&&&&&&IPC:&&& 隔离system V IPC和posix消息队列(IPC用到了标识符) &&&&&&
&&&&&&&&&&&&&&&&Mount:&&& 隔离文件系统
&&&&&&&&&&&&&&& UTS:&&& 隔离主机名和域名
&&&&&&&&&&&&&&& PID:&&& 隔离进程ID
&&&&&&&&&&&&&&& Net:&&& 隔离网络资源
&&&&&&&&&&&&&&& User:&&&&隔离用户ID和组ID
&&& 2.3.2 namespace的接口和使用
&&&&&& 操作:
&&&&&&&&&&&&clone(创建新),
&&&&&&&&&&&&unshare(为旧进程创建新namespace),
&&&&&&&&&&&&setns(将旧进程放入新namespace)(docker exec的实现原理就是setns)
&&&&&& pid=clone(flags,...)
&&&&&&&&&&& (flags:CLONE_NEWNS(这个是mount namespace),CLONE_NEWIPC,CLONE_NEWPID,CLONE_NEWUSER,CLONE_NEWUTS,CLONE_NEWNET,) 新进程创建出来的子进程也使用这个namespace
&&&&&&& setns通过procfs(/proc/$$/ns)指定namespace信息
2.4 Cgroup(control group)
&&& 组件:&&& 之前只能使用ulimit对单一进程时行控制
&&&&&&& devices:&&&& 设备权限控制
&&&&&&& cpuset:&&&&& 分配指定CPU和内存节点(避免进程跨节点访问CPU内存导致性能下降)
&&&&&&& CPU:&&&&&&&&& 控制CPU占有率
&&&&&&& cpuacct:&&& 统计CPU使用情况
&&&&&&& memory:&&& 控制内存使用上限
&&&&&&& freezer:&&&&& 冻结或暂停Cgroup中的进程
&&&&&&& net_cls:&&&&&&& 配合tc限制网络流量
&&&&&&& net_prio:&&&&& 设置进程网络流量优先级
&&&&&&& huge_tlb:&&& & 限制hugeTLBr使用.
&&&&&&& perf_event:&&&& && 允许perf基于cgroup做性能监测
systemd默认使用cgroupfs
[root@220 ~]# ls -l /sys/fs/cgroup/
drwxr-xr-x 2 root root& 0 Jan 11 18:00 blkio
lrwxrwxrwx 1 root root 11 Jan 11 18:00 cpu -> cpu,cpuacct
lrwxrwxrwx 1 root root 11 Jan 11 18:00 cpuacct -> cpu,cpuacct
drwxr-xr-x 2 root root& 0 Jan 11 18:00 cpu,cpuacct
drwxr-xr-x 2 root root& 0 Jan 11 18:00 cpuset
drwxr-xr-x 4 root root& 0 Jan 11 18:00 devices
drwxr-xr-x 2 root root& 0 Jan 11 18:00 freezer
drwxr-xr-x 2 root root& 0 Jan 11 18:00 hugetlb
drwxr-xr-x 2 root root& 0 Jan 11 18:00 memory
drwxr-xr-x 2 root root& 0 Jan 11 18:00 net_cls
drwxr-xr-x 2 root root& 0 Jan 11 18:00 perf_event
drwxr-xr-x 4 root root& 0 Jan 11 18:00 systemd
直接操作namespace,cgroup还是有点难的,但docker通过libcontainer很容易搞定这些复杂的操作
2.5容器造就docker
&&& 容器是docker核心技术之一.
&&& 微服务(micro service)设计哲学.
阅读(620) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。Docker容器: 那些你不知道的事
Docker容器: 那些你不知道的事
晗狄技术观
先说说我们知道的事，Docker 是 PaaS 提供商 DotCloud 开源的一个高级容器引擎，源代码托管在 Github 上，基于go语言并遵从Apache2.0协议开源。Docker相当于物理行业的集装箱对物流的影响一样，成为Container上运行镜象的统一打包和交换的标准，Docker介绍请参看文章容器演进和技术基础介绍。我们知道，Docker使用了容器的环境隔离和资源限制技术，把镜像和运行环境打包到Image中。Register支持容器上传和下载功能。我们知道，Docker同时提供了Build，Ship和Run，运维只需要在环境重配置好Docker，剩下的工作就是部署容器，实现Build Once Run Anywhere和Configure Once Run Anything；从而促进了容器技术的爆发。Docker采用Client Server模式和插件式架构设计，Docker的后端采用非常松耦合的架构，模块之间相互独立，具体请参看文章Docker技术架构详细分析。用户通过Docker Client与Docker Daemon建立通信，并发送请求给Docker Daemon。Docker Daemon提供Server功能接受Docker Client的请求；随后通过Engine执行Docker内部的一系列工作，每项工作都是以一个Job的形式的存在。Docker讲底层容器运行时剥离出来，实现更好的平台无关性。LibContainer是对各种容器的抽象，发展为RunC，并贡献给OCP组织作为定义容器环境的标准。我们还知道Docker容器的三大编排工具，Compose、Swarm和Machine。Compose是服务编排工具，是定义和运行Docker主机上多容器应用的工具，通过单独文件，定义多容器应用并运行容器。Machine是机器管理工具，简化容器安装和部署，通过简单命令实现对Docker容器的启动、升级和网络配置。Swarm是Docker容器的机器管理工具，使得Docker机器能够有效的被管理起来，另外，Docker还有个打包工具叫DockerFile。我们也知道，Docker的网络技术和能力一直是容器技术中最难、也是最不看好的技术之一，由于容器技术本身的网络能力具有局限性，参看文章Docker原生网络和实现原理。所以目前Docker的网络技术流派也很多，具体请参看文章Docker网络增强项目或将引爆未来。Libnetwork是Docker公司正在开发的新的网络底层架构，由libcontainer和Docker Engine中的网络相关的代码合并而成。Libnetwork的目标是引入了容器网络模型(CNM)，并为应用程序提供一致的编程API接口以及网络抽象。 Libnetwork的容器网络模型包含了三个重要概念，Network Sandbox，Endpoint和Network。Weave创建了Networking Plugin技术，目前成熟的有Networking Plugin和Volume Plugin。Weave方案包含两大组件，用户态Shell脚本和Weave虚拟路由容器。Weave虚拟路由容器需要在每个宿主机上布置第三方插件，把不同宿主机的Route容器连接起来，使得Docker工具生态无缝集成到Docker。Weave创建一个虚拟网络，链接多个主机的Docker容器，并使他们可以被自动发现，对使用该网络的应用来说，所以容器就像是链接在同一个网络交换机上，无需配置端口映射、链路等参数。或许我们知道，只有满足要求的Docker相关代码，资源才允许发布。这是Docker安全特性的要求，为了提升Docker的安全性，Notary安全过滤器被引入到Docker中，保证互联网用户操作的规范性和安全性。但是，下面的内容您就不一定知道，那么下面我们就重点谈谈我们不知道或知道不多的Docker知识。容器和容器OSCoreOS支持集群管理，是最为受欢迎的容器虚拟化OS，专为Docker设计和内核裁剪。 CoreOS中有两个关键容器集群管理工具，etcd主要实现集群服务发现、信息共享和数据同步；而Fleet实现集群状态维护、容器操作和确保服务一致可用。VMware也推出了容器OS系统Photon，在VMware上创建VM，并且安装Photon系统即可部署运行容器，并且支持目前主流的Docker、Rkt和PGC容器平台。Photon可以容器管理认证工具Lightwave配合，可以实现更好的权限管理。Docker容器和存储Docker容器在数据读写和存储上，是采用分层和COW的存储技术实现，具体请参看文章Docker携手AUFS陪你共度七巧节。Docker本身的COW文件系统不支持数据持久保存，在容器被删除或重启后，之前的文件更改就会丢失（变化的数据被以COW写到一个新的位置）。Volume的引入虽然解决了数据丢失问题，但是当容器迁移后，数据卷无法跟随Docker容器一起迁移，ClusterHQ的Flocker的出现恰恰解决Volume的不足，使得数据跟随Docker迁移。Flocker的容器和存储卷迁移分为全迁移和增量同步两个过程，配置文件描述Docker部署方式和状态，运行配置则生效（迁移Redis）；以迁移本地存储（非共享存储）为例，整个过程为先打快照，全迁移，增量同步。Flocker以Docker Volume Plugin的方式部署在Docker中，与Docker集成。目前共享存储的支持能力比较成熟，支持的产品包括AWS EBS、Scale IO和XtremIO等，并且支持如AWS、Rackspace等云平台；本地存储方式在技术成熟度上并不高。Flocker通过Storage Driver屏蔽存储差异，并通过存储提供的Flocker标准接口实现对底层存储操作，当主机容器在不同主机间迁移时，Flocker只需要对容器的Volume进行主机的重映射。Rex-Ray和Dogged是Docker开源存储项目，旨在抽象容器卷管理，通过Docker storage API和Storage Driver屏蔽存储差异，以容器为粒度管理和发放存储，简化容器管理。在容器持久化容器方面，EMC已经抢占先机，通过与Flock合作，并且直接参与Docker开源项目Rex-Ray和Dogged，已经事实上控制了存储虚拟化接口标准，对存储和Docker容器的发展上已经获得更多话语权。随着Docker技术的飞速发展，容器类似于虚拟机对阵列的接口需求将随之而来，Rex-Ray和Dogged技术例证。Docker与PaaS随之容器的发展，CaaS容器即服务的概念也应时而生，其大意就是基础设施以容器的方式来供给给应用使用。以容器为单位成为PaaS的共识，基于Docker的容器打包和分发有望成为PaaS平台的标准, Docker将大幅拓宽PaaS的应用范围，并促进PaaS的快速发展。基于容器的打包一统新一代PaaS，第三代PaaS，DEIS、Flynn等均基于Docker，挑战老的PaaS平台。PaaS已经出现了数年时间，第一批是Azure和Heroku等公用云服务，之后出现的Cloud Foundry和OpensShift允许用户建立自己的PaaS，包括了内部数据中心以及云环境。现在，第三代PaaS浪潮正在到来。Flynn是一个开源的PaaS平台，可自动构建部署任何应用到Docker容器集群上运行，其功能特性与组件设计大量参考了传统的PaaS平台Heroku。Flynn目前还不是很稳定。但整个系统非常灵活，相互松耦合，便于任意组件的替换。Docker与IaaS平台主流IaaS云平台都支持Docker的运行 (AWS、Google Compute Engine、Rackspace等)。Docker弥合了不同IaaS之间的差异，Docker的轻量和可移动性使得其比较适合用在Hybrid Cloud中。降低了IaaS服务商用户粘性，使得跨云服务商迁移更加自由。从而使得IaaS服务商被管道化。如果Container把安全问题解决了，可能就会有比较大的变化。出现基于Docker的Container as a Service或Orchestration as a Service，如Tutum，可以避免IaaS的锁定，甚至不用关心是运行在物理设施上，还是运行在哪家IaaS平台上。2014年6月Rackspace宣布和CoreOS合作提供Baremetal as a Service方案OnMetal，结合了云计算的灵活性和基于container的高性能虚拟化，提供single tenant baremetal cloud serivce。这种模式将影响当前以虚拟机为核心的IaaS平台，预计后续可能出现同时提供Docker over Baremetal、 Docker over VM和VM三种混合的资源分配和调度云平台。Docker也引发了基于容器的应用集群管理平台，如Kubernetes得到了微软、红帽、IBM、Vmware、Docker、Mesosphere、CoreOS和SaltStack等多家厂商的支持。容器集群管理技术可能导致Openstack边缘化。Docker和KubernetesKubernetes源于Google内部集群管理项目Omega，为了帮助开发者快速部署和管理基于Docker的大规模应用，但Docker容器集群的管理不仅仅只有Kubernetes。Kubernetes实现容器集群管理、资源调度和监控、容器生命周期管理、Service管理、负载均衡管理；可以运行在公有云、私有云和裸机上。支持微软、红帽、IBM、Vmware、Docker、Mesosphere、CoreOS和SaltStack等多家厂商。容器集群管理技术可能导致Openstack 边缘化。Docker与Openstack从目前来看，Docker集成到OpenStack的方案主要有下面三种方案。主流观点认为基于Nova调度和管理Docker容器不能发挥Docker的优势，而把Docker与Heat集成更能发挥其优势。Docker Driver for Nova通过nova-api，docker driver作为hypervisor部署。原理很好理解，nova-computer-api调用virt api 将nova docker driver作为http agent和docker rest api互通，从而控制docker和与容器的通信。另外，glance作为docker register服务的本地节点，提供image服务。这种方式不支持Docker的一些高级特性。Docker Plugin for Heat通过Heat组件来实现。利用heat来管理docker的资源模板，这样可以避免nova仅仅在hypervisor层面对docker管理的限制，比如一些docker本身构建的能力，或是docker容器之间的网络管理等。这种方式能够充分利用Docker的API，但缺乏quota、 host aggregate 调度机制，不能用Glance来管理镜像。Docker与DevOps基于Docker可以更好的实现DevOps。虽然有许多工具适合DevOps部署，使开发人员和操作更贴近，但Docker是一个与DevOps原则密切相关的框架。使用Docker，开发人员可以专注于他们的代码，而不必担心在生产环境中运行它们的负面影响。DevOps团队可以将整个容器作为容器处理，文件系统和依赖关系管理的分层方法使得环境的配置更容易维护。在相同的源代码控制系统（如Git工作流程）中版本化和维护Dockerfiles使得它非常有效地管理多个开发/测试环境。不同环境的多个容器可以在同一VM上运行时被隔离。Docker还可以很好地使用现有的工具，如Jenkins，Chef，Puppet，Ansible，Salt Stack，Nagios和Opsworks。Docker有可能对DevOps生态系统产生重大影响。它可以从根本上改变开发人员和运营专业人员合作的方式。新兴DevOps作为服务公司，如CloudMunch，Factor.io，Drone.io可能必须采用Docker并将其带入他们的CI和CD解决方案。Docker与微服务架构基于Docker容器和其生态系统的微服务架构是下一代PaaS的核心，在Docker出现之前，虽然我们谈论微服务架构，但是其实是很难实现的。微服务要运行，首先需要一套执行的环境。这套环境不能对外部有依赖性。同时，执行环境的粒度又必须足够的小，这样才能称之为”微“，否则必然是对资源的巨大浪费。一个微服务可以跑在一台虚拟机上面，但是虚拟机粒度太大，即使最小的虚拟机，也至少也有1个核。服务一个用户的服务，显然用不了一个核。同时，虚拟机有没有一套方便的管理机制，能够快速的让这些服务之间能够组合和重构。Docker出现以后，我们看到了微服务的一个非常完美的运行环境。一个容器就是一个完整的执行环境，不依赖外部任何的东西，具备独立性。一台物理机器可以同时运行成百上千个容器，粒度细。其计算粒度足够的小。容器可以在秒级进行创建和销毁，非常适合服务的快速构建和重组。数量众多的容器编排管理工具，能够快速的实现 服务的组合和调度。Docker的生态系统早在2014年Linux Foundation 北美峰会上公布的最活跃开源云项目排名，Docker仅次于Openstack排在第二位。目前围绕Docker已形成庞大的生态系统，涵盖编排/调度、容器/OS、应用部署、网络/SDN、Hosting/SP、Big Data、配置管理工具、开发工具等。互联网厂商/云服务商加入Docker生态圈，在容器部署、管理、编排等领域发力，抢占容器集群管理的标准控制权，积极部署Container和仓储服务，打造基于各自云服务的应用生态体系。Docker将催生云计算服务标准化，可以在系统的构建者和使用者之间划出一条清晰的界限，将IT系统的交付标准化。譬如游戏的开发商可以交付标准化的服务给游戏的发行商，发行商在不依赖开发商的情况下能够独立运营系统，或者交由第三方运营系统。Docker Hub为组件/系统提供商建立了一个部署到Docker 上的生态、App Market 环境。个人应用的普及依赖公有仓库，企业级应用普及依赖私有仓库。为私有容器提供安全、高速访问和多云联通。Docker的挑战者RocketCoreOS 使用 Docker 容器构建其服务，并对 Docker 项目做出巨大贡献。但2014年CoreOS宣布正在开发自己的容器引擎Rocket ，因为其不同Docker 的发展方向。CoreOS在 Docker 早期时候认为 Docker 在为开发人员提供一个标准的容器架构，简化了开发人员的日常工作。后来发现 Docker在获得很多资金后的使命已经扩张太多，现在不是在谈论 Docker 容器，而是 Docker平台。Docker的Roadmap表明旨在想要构筑一个完整的Docker平台，包括Machine (系统配置), Swarm (Docker 化应用的原生集群), Compose (多容器应用组装)。Docker的发展方向将对Docker的周边生态产生复杂影响，后续可能面临更多来自生态的挑战。请搜索“ICT_Architect”关注“架构师技术联盟”公众号，获取更多精彩内容。
本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。
晗狄技术观
百家号 最近更新：
简介: 微信公众号“架构师技术联盟”自媒体作者
作者最新文章