100个容器周边项目,点亮你的容器集群技能树

摘要: 大规模的容器技术运用从来不是一项独立工程,而是一个汇集虚拟化技术、容器编排、任务调度、操作系统、容器仓库、跨节点网络、分布式存储、动态扩缩、负载均衡、日志监控、故障自恢复等系统性难题的复杂有机体。随着Docker的诞生和Google等互联网公司的推波助澜,这个领域出现了一大批优秀的开源项目,它们在简化容器技术使用成本的同时,也经常使得刚刚接触容器时间不太长的开发者和企业用户感到不知所措。

大规模的容器技术运用从来不是一项独立工程,而是一个汇集虚拟化技术、容器编排、任务调度、操作系统、容器仓库、跨节点网络、分布式存储、动态扩缩、负载均衡、日志监控、故障自恢复等系统性难题的复杂有机体。随着Docker的诞生和Google等互联网公司的推波助澜,这个领域出现了一大批优秀的开源项目,它们在简化容器技术使用成本的同时,也经常使得刚刚接触容器时间不太长的开发者和企业用户感到不知所措。

将知识分类是梳理零散信息的一种有效方式。对于容器技术的生态圈来说,其中涉及领域众多,有的项目横跨多个细分领域,有的项目则是针对特定场景需求定制的,难以对其功能类型做精确定义。不过,若仅考虑通用领域里的相关产品和工具,大致来说可以划分成14种主要类别。

以下将围绕容器生态,分别举例介绍这些类别中的典型开源项目,以及部分虽未开源但比较常用的100个周边产品。

1. 容器引擎

容器引擎是容器集群生态圈的核心部分,它是与内核Namespace和CGroup等功能直接交互,并提供相应API使得外部能够与之集成的工具或服务。Docker无疑是目前为止最成功、广泛最使用的容器引擎之一。实际上从1.12版本以后,Docker的容器化功能已经由独立的项目RunC来实现,但Docker仍作为一个开源产品为用户提供完整的容器化解决方案。此外,社区中还有许多容器引擎项目,例如:

  • 001. Docker:https://www.docker.com
  • 002. Rkt:https://coreos.com/rkt
  • 003. Systemd-nspawn:https://www.freedesktop.org/wiki/Software/systemd
  • 004. Hyper:https://hyper.sh
  • 005. Garden:https://github.com/cloudfoundry/garden
  • 006. LXC:https://linuxcontainers.org
  • 007. Photon:https://github.com/vmware/photon
  • 008. Vagga:https://github.com/tailhook/vagga
  • 009. gVisor:https://github.com/google/gvisor
  • 010. Pouch:https://github.com/alibaba/pouch

这些项目只是众多支持不同平台和具有不同特性的容器引擎的冰山一角。例如Google曾经主导的lmctfy(http://lmctfy.io/)项目也是个十分优秀的容器引擎,然而该项目自2015年以后就不再被维护了。而最近Google刚刚开源的gVisor则是该领域中的新秀。另外值得一说的是,Hyper采用虚拟机的方式对环境进行隔离,并不是一种基于容器的隔离方案,但它能很好地与Docker或Kubernetes等容器集群技术相结合,取代其环境隔离的功能,因此也归属此列。

2. 监控和数据收集

由于容器基于内核的特殊隔离方式,对容器性能和状态的监控与虚拟机存在一些差别。传统的虚拟机监控工具,例如Nagios和Zabbix等,对容器监控的原生支持并不十分易用。而一些新起的开源项目对这种场景具有更友好的体验,例如:

  • 011. cAdvisor:https://github.com/google/cadvisor
  • 012. Sysdig:http://sysdig.org
  • 013. Prometheus:https://prometheus.io
  • 014. TICK-Stack:https://influxdata.com
  • 015. Docker-Alertd:https://github.com/deltaskelta/docker-alertd
  • 016. Grafana:https://grafana.com

其中的TICK-Stack指的是Influxdata推出的Telegraf、InfluxDB、Chronograf、Kapacitor四款开源工具,不过从1.0以后,这些工具在开源版基础上提供了企业版本,后者提供了例如高可用、云端存储等企业级功能。

3. 容器管理和界面工具

可视化是用户友好性十分重要的一部分,Shipyard和Decking是Docker早期时十分受欢迎的可视化工具,之后Docker也收购了Kitematic作为官方的容器管理UI。但随着容器应用集群化,早期的UI工具不再流行,一些针对特定集群平台定制的新型管理UI开始出现。例如Kubernetes官方推出了Dashboard项目用于可视化的管理集群,Cockpit则是红帽公司推出的Kubernetes集群管理界面。以下是其中一些开源的容器管理UI项目:

  • 017. Kitematic:https://kitematic.com
  • 018. DockerUI:https://github.com/crosbymichael/dockerui
  • 019. Panamax:http://panamax.io
  • 020. Rapid Dashboard:https://github.com/ozlerhakan/rapid
  • 021. Cockpit:http://cockpit-project.org
  • 022. Portainer:https://www.portainer.io
  • 023. Shipyard:http://shipyard-project.com
  • 024. Seagull:https://github.com/tobegit3hub/seagull
  • 025. Dockeron:https://github.com/dockeron/dockeron
  • 026. DockStation:https://dockstation.io

4. 基础设施集成

容器集群的实施是需要以硬件基础设施作为依托的,有些辅助工具能够简化这个过程。这些项目往往与具体的底层平台相关,例如:

  • 027. Nova-docker:https://github.com/stackforge/nova-docker
  • 028. Magnum:https://github.com/openstack/magnum
  • 029. Machine:https://docs.docker.com/machine
  • 030. Boot2Docker:https://github.com/boot2docker/boot2docker
  • 031. Clocker:https://github.com/brooklyncentral/clocker
  • 032. MaestroNG:https://github.com/signalfuse/maestro-ng

Nova-docker和Magnum都是在OpenStack集成容器集群的项目,不过目前OpenStack官方正在尝试通过让Kubernetes直接创建虚拟机的方式来统一它在IaaS层和CaaS层的差异,其中的Nova-docker已经被废弃了。Machine是Docker公司推出的基础设施管理工具,Boot2Docker曾经是在Windows和Mac上使用Docker的官方方案,但随着Docker 1.12版本发布了多种操作系统的发行版后,已经不再被推荐使用了。

5. 编排和调度

编排和调度是容器集群的基本功能,因此选择编排和调度工具实际上就是在选择容器集群的方案。以下是一些开源的容器任务编排调度工具:

  • 033. SwarmKit:https://github.com/docker/swarmkit
  • 034. Kubernetes:http://kubernetes.io
  • 035. Marathon:https://github.com/mesosphere/marathon
  • 036. Rancher:http://www.rancher.io
  • 037. Nomad:https://github.com/hashicorp/nomad
  • 038. OpenShift:https://www.openshift.com
  • 039. Crane:https://github.com/michaelsauter/crane
  • 040. Nebula:https://github.com/nebula-orchestrator
  • 041. GearD:http://openshift.github.io/geard

其中的OpenShift主要是指其3.0之后的发行版,它是红帽公司基于Kubernetes二次开发的集持续集成和交付于一体的容器集群方案,具有开源和商业两个版本。

6. 容器镜像仓库

镜像仓库是基于容器的在软件发布流程中必要的组成部分,Docker开源了其镜像仓库的最小实现,但对于企业级应用来说,它缺少了高可用、权限控制、管理界面等必要功能。Docker Hub和国内的许多容器云平台都提供了公有云的企业级仓库服务,社区中也有一些容器仓库的开源或免费的实现,例如:

  • 042. Repository:https://github.com/docker/distribution
  • 043. Nexus:http://www.sonatype.org/nexus
  • 044. Habor:http://vmware.github.io/harbor
  • 045. Portus:https://github.com/SUSE/Portus
  • 046. Docker Registry UI:https://github.com/atcol/docker-registry-ui
  • 047. Dragonfly:https://github.com/alibaba/Dragonfly

其中的Nexus是一种通用的软件包仓库解决方案,支持包括Maven、NPM、PIP、RPM等许多主流打包格式的分发和管理,它是在3.0以后的版本中开始支持作为Docker镜像仓库的。VMWare推出的Habor是目前相对常用的企业级开源Docker仓库解决方案。Portus和Docker Registry UI是基于官方Repository镜像仓库的界面化管理工具。Dragonfly是一款P2P协议的镜像分发工具,并非直接提供镜像存储功能,但也属于仓库辅助类的工具。

7. 服务发现和容器域名服务

服务发现和域名服务实际上是微服务架构和容器集群的调度工具所需的组件,它们在容器集群中十分常见,也是这个生态圈中举足轻重的一部分,以下是其中一些在实际工程中被提及较多的工具:

  • 048. Etcd:https://github.com/coreos/etcd
  • 049. Consul:http://www.consul.io
  • 050. ZooKeeper:https://zookeeper.apache.org
  • 051. Eureka:https://github.com/Netflix/eureka
  • 052. Traefik:https://traefik.io
  • 053. Muguet:https://github.com/mattallty/muguet
  • 054. Registrator:https://github.com/gliderlabs/registrator
  • 055. SkyDNS:https://github.com/skynetservices/skydns

8. 容器日志收集处理

和容器集群的监控一样,收集容器中的服务运行日志与虚拟机中的方式同样存在许多差异。目前Docker直接通过插件能够支持的日志收集工具包括Rsyslog、Splunk和Fluentd,虽然FileBeat不在此列,但由于其小巧便捷的部署机制,也得到了许多用户青睐。一些过去用于虚拟机的日志收集器,比如LogStash或Flume,同样能够使用与容器中的服务,但它们都不再是首选的方案。

  • 056. Splunk:https://www.splunk.com
  • 057. Fluentd:https://www.fluentd.org
  • 058. ElasticStack:https://www.elastic.co
  • 059. Flume:https://flume.apache.org
  • 060. Rsyslog:https://www.rsyslog.com/

ElasticStack是Beats、Logstash、ElasticSearch和Kibana四款开源项目的统称,这是一套十分流行的日志汇聚、处理、存储和展示的工具组合。其中的ElasticSearch和Kibana也可以与Fluentd配合,形成端到端日志处理方案。另外值得指出的是,Splunk并不是开源或免费的,但它在企业级日志处理方案中的应用十分广泛。

9. 容器相关的系统发行版

有些Linux发行版是为容器运行而优化的,Atomic和ClearLinux系统都属于此类。另一些Linux发行版在设计之初就充分地将容器机制融入了系统的架构理念,例如CoreOS。有的系统甚至将Docker作为系统的核心服务来管理其他用户进程,例如RancherOS和Hyper容器引擎所使用的操作系统。类似的项目还有许多,它们都是架设容器集群时十分称手的基础设施,例如:

  • 061. Container Linux:http://coreos.com
  • 062. Project Atomic:http://www.projectatomic.io
  • 063. RancherOS:http://rancher.com/rancher-os
  • 064. ClearLinux:https://clearlinux.org
  • 065. Photon OS:https://vmware.github.io/photon
  • 066. CargoOS:https://cargos.io
  • 067. SmartOS:https://www.joyent.com/smartos

10. 容器平台

容器平台是大规模容器运用的产物,它通常会与持续集成、持续交付的工具结合,成为连接上层应用服务和底层基础设施、帮助使用者快速实现从代码提交到产品上线全过程的端到端交付过程。以下是其中一些相关的开源项目:

  • 068. Deis:https://deis.com
  • 069. Flynn:http://flynn.io
  • 070. Dokku:https://github.com/progrium/dokku
  • 071. Fabric8:http://fabric8.io
  • 072. Kel:http://www.kelproject.com
  • 073. Nanobox:https://nanobox.io
  • 074. Tsuru:https://tsuru.io

除了这些开源的容器平台服务实现之外,互联网上还有许多在线按量付费的容器即服务平台,它们也是整个容器集群生态的一部分。

11. 容器网络

容器技术在解决环境隔离和配额问题的同时,也引入了网络层面的复杂性。由于使用了Network Namespace,每个容器都可以获得独立的IP地址,这对于单个主机的情况并无大碍,但对于容器集群的情况,IP地址的分配和互联就成为了新的问题。因此在设计容器集群时,通常需要专门为网络的连接方式加以考虑。常用的开源方案例如:

  • 075. Libnetwork:https://github.com/docker/libnetwork
  • 076. Flannel:https://github.com/coreos/flannel
  • 077. Calico:http://www.projectcalico.org
  • 078. Weave:https://github.com/zettio/weave
  • 079. Romana:http://romana.io
  • 080. Canal:https://github.com/projectcalico/canal
  • 081. Open vSwitch:http://openvswitch.org
  • 082. Pipework:https://github.com/jpetazzo/pipework

这些网络方案大多采用了七层网络的Overlay Network方式,也就是在容器之间通信的网络包上封装了用于路由寻址的额外包头,这种方式会导致网络通信效率的下降,具体影响程度与所封装的额外数据大小有关。而Calico采用修改每个主机节点上的IPtables和路由表规则实现容器间数据路由和访问控制,属于三层网络的方式,这种方案在节点规模不太大(最多几百个节点)时的效率优势十分明显,是一种比较受推荐的容器网络工具。除了这些较常用的方案外,一些条件允许的企业也会结合MacVLAN等二层网络方案实现容器的互联,以获得更好的网络性能。

12. 容器安全

容器安全性问题的根源在于容器和宿主机共用内核,因此受攻击的面特别大。另外,如果容器里的应用导致Linux内核崩溃,整个宿主机系统都会崩溃,这一点与虚拟机是不同的。此外,镜像的安全性也是容器安全的一部分,如何保障用户下载的镜像是可信的、未被篡改过的,以及如何保证镜像中不会意外包含具有大量漏洞的老旧软件都是需要考虑的问题。目前这些安全课题主要在一些企业级应用中引起较多重视,下面是一些相关的开源工具和项目:

  • 083. Notary:https://github.com/docker/notary
  • 084. Clair:https://github.com/coreos/clair
  • 085. AppArmor:http://wiki.apparmor.net/index.php/Main_Page
  • 086. SELinux:https://selinuxproject.org
  • 087. Twistlock:https://www.twistlock.com
  • 088. OpenSCAP:https://github.com/OpenSCAP/container-compliance

13. 容器数据持久化

容器是一种不可变的基础设施,容器的数据应该通过Volume的方式保存到外部的介质上,容器持久化存储本质上就是要解决如何简便地将外部存储挂载到容器中使用的问题。Docker在1.9版本后提供了存储的插件,这也为许多存储方案提供了便利,以下列举几个例子:

  • 089. Flocker :https://github.com/clusterhq/flocker
  • 090. Convoy:https://github.com/rancher/convoy
  • 091. REX-Ray:https://github.com/codedellemc/rexray
  • 092. Netshare:https://github.com/ContainX/docker-volume-netshare
  • 093. OpenStorage:https://github.com/libopenstorage/openstorage

其中Ceph是通用的网络存储工具,同时提供块存储和对象存储能力,对容器化场景下的应用数据持久化具有良好的支持。

14. 容器相关开发流程工具

容器的镜像可以被看作一种新型的应用打包方式,因此容器常常与软件的开发和持续集成、持续交付流程相结合,提供不同环境一致性部署能力。以下是一些利用容器改善软件开发和交付的工具或平台:

  • 094. Drone.io:https://drone.io
  • 095. Shippable:http://shippable.com
  • 096. Cyclone:https://github.com/caicloud/cyclone
  • 097. Screwdriver:http://screwdriver.cd
  • 098. WatchTower:https://github.com/v2tec/watchtower
  • 099. Wercker:http://wercker.com
  • 100. Totem:http://totem.github.io

以上内容节选自近期刚刚面市的新书《容器即服务:从零构建企业级容器集群》,这是一本迄今为止最完整阐述容器集群技术及其周边生态体系的著作。其作者是来自阿里巴巴的一线技术专家,也一名从Lxc-Docker(最早的Docker 0.x版本)时期就开始在项目中运用容器的一线技术咨询师,目睹了容器技术从兴起到成熟的整个过程,在一次次的技术选型和实践里,亲身经历各类相关开源项目的大坑小洼,并多次在技术大会上进行过演讲分享(比较大型的会议包括2015年的CNut全球容器技术大会、2016年的CSDN架构技术实战峰会、2017年的CNut全球运维技术大会等)。全书分为8个章节,不仅囊括当前排名最靠前的4大主流开源容器集群方案,同时介绍了许多容器相关项目的技术选型和原理细节,具体目录列举如下:

  • 第1章 容器集群综述
  • 第2章 SwarmKit 集群解决方案
  • 第3章 Kubernetes 集群解决方案
  • 第4章 Mesos 集群解决方案
  • 第5章 Rancher 集群解决方案
  • 第6章 容器集群的网络和存储
  • 第7章 容器服务的基础设施
  • 第8章 容器技术新风向

学会一项技术很快,但学懂一门技术则需要时间的积累,做到知其然并知其所以然是一段辛苦而快乐的过程。愿《容器即服务:从零构建企业级容器集群》能够为你的容器学习之路铺上一块稳固的基石。

原文链接

原文地址:http://blog.51cto.com/13679539/2119197

时间: 2024-10-08 10:17:14

100个容器周边项目,点亮你的容器集群技能树的相关文章

Java企业级电商项目架构演进之路 Tomcat集群与Redis分布式百度云实战分享

muke慕课实战课程分享QQ313675301 新增课程: Java企业级电商项目架构演进之路 Tomcat集群与Redis分布式百度云实战分享 后端开发: 1.高级java软件架构师实战培训视频教程2.大型SpringMVC,Mybatis,Redis,Solr,Nginx,SSM分布式电商项目视频教程3.Spark Streaming实时流处理项目实战4.Java校招面试 Google面试官亲授5.Java开发企业级权限管理系统6.Java大牛 带你从0到上线开发企业级电商项目7.Java

Java企业级电商项目架构演进之路Tomcat集群与Redis分布式

Java企业级电商项目架构演进之路Tomcat集群与Redis分布式网盘地址:https://pan.baidu.com/s/1taAooW3AhdGcdGSvOLqjkg 密码:nwip备用地址(腾讯微云):https://share.weiyun.com/5JdkNHX 密码:s9pm74 第1章 课程介绍[赠送一期源码+一期内容回顾]第2章 Lombok框架集成及原理解析第3章 Maven环境隔离应用场景及验证实战第4章 Tomcat集群演进详解及环境搭建第5章 Redis基础强化第6章

Java企业级电商项目架构演进之路 Tomcat集群与Redis分布式

Java企业级电商项目架构演进之路  Tomcat集群与Redis分布式 Redisson介绍Redisson是架设在Redis基础上的一个java驻内存数据网格.Redisson在基于NIO的Netty框架上,充分的利用了Redis键值数据库提供的一系列优势.在java使用工具包中常用接口的基础上,为使用者提供了一系列具有分布式特性的常用工具类.使得原本作为协调单机多线程并发程序的工具包获得了协调分布式多机多线程并发系统的能力,大大降低了设计和研发大规模分布式系统的难度.同时结合各富特色的分布

云计算之路-阿里云上-容器难容:容器服务故障以及自建 docker swarm 集群故障

3月21日,由于使用阿里云服务器自建 docker swarm 集群的不稳定,我们将自建 docker swarm 集群上的所有应用切换阿里云容器服务 swarm 版(非swarm mode). 3月22日,我们进行移除与重启节点的操作时引发了故障,详见 云计算之路-阿里云上-容器服务:移除节点引发博问站点短暂故障 . 3月24日,我们参考阿里云容器服务帮助文档-指定多节点调度通过给节点添加用户标签的方式成功移除了部分节点.我们是这么操作的,当时所有节点没有添加用户标签,给待移除节点之外的所有节

云计算之路-阿里云上-容器难容:自建docker swarm集群遭遇无法解决的问题

我们从今年6月开始在生产环境进行 docker 容器化部署,将已经迁移至 ASP.NET Core 的站点部署到 docker swarm 集群上.开始我们选用的阿里云容器服务,但是在使用过程中我们遭遇了恐怖的路由服务(acsrouting)路由错乱问题 —— 请求被随机路由到集群中的任一容器,虽然后来阿里云修复了这个问题,但我们对容器服务失去了信心,走上了用阿里云服务器自建 docker swarm 集群的道路. 用上自建 docker swarm 集群之后,本以为可以在云上容器中过上安稳的日

java架构师大型分布式综合项目实战,高并发,集群,高可用,程序设计,性能优化,架构设计,负载均衡,大数据量

* { font-family: "Microsoft YaHei" !important } h1 { color: #FF0 } 15套java架构师.集群.高可用.高可扩 展.高性能.高并发.性能优化.Spring boot.Redis.ActiveMQ.Nginx.Mycat.Netty.Jvm大型分布 式项目实战视频教程 视频课程包含: 高级Java架构师包含:Spring boot.Spring  cloud.Dubbo.Redis.ActiveMQ.Nginx.Mycat

项目里面加入redis单机版 和集群版的配置

第一步: 如果你是maven项目,你直接配置就可以了,如果不是需要下载这个包 jedis包 <!-- Redis  客户端 -->          <dependency>                <groupId>redis.clients</groupId>                <artifactId>jedis</artifactId>  </dependency> 2.  单机版测试 @Test 

kafka_2.10-0.8.1.1.tgz的1或3节点集群的下载、安装和配置(图文详细教程)绝对干货

运行kafka ,需要依赖 zookeeper,你可以使用已有的 zookeeper 集群或者利用 kafka自带的zookeeper. 单机模式,用的是kafka自带的zookeeper, 分布式模式,用的是外部安装的zookeeper,即公共的zookeeper. 见博客 4 kafka集群部署及生产者java客户端编程 + kafka消费者java客户端编程

JAVA架构师大型分布式高并发电商项目实战,性能优化,集群,亿级高并发,web安全,缓存架构实战

现任58到家技术委员会主席,高级技术总监,负责企业,支付,营销.客户关系等多个后端业务部门.本质,技术人一枚.互联网架构技术专家,"架构师之路"公众号作者.曾任百度高级工程师,58同城高级架构师,58同城技术委员会主席,58同城C2C技术部负责人. 内容介绍 1.大数据量时,数据库架构设计原则 2.数据库水平切分架构设计方向 3.用户中心,帖子中心,好友中心,订单中心水平切分架构实践 下面是58沈剑老师的演讲实录 大家好,我是58沈剑,架构师之路的小编,后端程序员一枚,平时比较喜欢写写