【图文】Docker容器云平台介绍_百度文库
您的浏览器Javascript被禁用，需开启后体验完整功能，
享专业文档下载特权
&赠共享文档下载特权
&100W篇文档免费专享
&每天抽奖多种福利
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
您可以上传图片描述问题
联系电话：
请填写真实有效的信息，以便工作人员联系您，我们为您严格保密。
Docker容器云平台介绍
IT技术顾问|
总评分4.4|
用知识赚钱
&&Docker,Container,容器,容器开发,企业容器平台,互联网转型,Devops,微服务
试读已结束，如果需要继续阅读或下载，敬请购买
定制HR最喜欢的简历
你可能喜欢你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
58私有云平台是58同城架构线基于容器技术为内部服务开发的一套业务实例管理平台，支持业务实例按需扩展，秒级伸缩，平台提供友好的用户交互过程，规范化的测试、上线流程，旨在将开发、测试人员从基础环境的配置与管理中解放出来，使其更聚焦于自己的业务。本文和大家分享在私有云平台实施过程中的相关容器技术实践。
本文主要从以下三个部分来进行讨论：
背景：当前存在哪些问题，为什么使用容器技术 整体架构：整个容器技术的架构方案核心模块的设计方案：一些核心模块的选型决策与解决方案
为什么使用容器技术在没有用容器化技术之前，我们存在这些问题：
资源利用率问题不同业务场景对资源的需求是不一样的，有CPU密集型、内存密集型、网络密集型，这就可能会导致资源利用率不合理的问题，比如一个机器上部署的服务都是网络密集型，那么CPU资源和内存资源就都浪费了。有些业务可能只聚焦于服务本身而忽略机器资源利用率的问题。
混合部署交叉影响对于线上服务，一台机器要混合部署多个服务，那么服务之间可能存在相互影响的情况，比如：一个服务由于某些原因突然网络流量暴涨，可能把整个机器的带宽都打满，那么其他服务就会受到影响。
扩/缩容效率低当业务节点需要进行扩/缩时，从机器下线到应用部署、测试，周期较长。当业务遇到突发流量高峰时，机器到手部署后，可能流量高峰已经过去了。
多环境代码不一致由于过去内部开发流程的不规范，存在一些问题，业务提测的代码在测试环境测试完毕后，在沙箱可能会进行修改、调整，然后再打包上线。这就会导致测试的代码和线上运行的代码是不一致的，增加了服务上线的风险，也增加了线上服务故障排查的难度。
缺少稳定的线下测试环境在测试过程中，会遇到一个问题，服务依赖的其他下游服务都没有提供稳定的测试环境，这导致无法在测试环境模拟整个线上流程进行测试，所以很多测试同学会用线上服务进行测试，这里有很高的潜在风险。
为了解决上述问题，架构线云团队进行了技术选型与反复论证，最终决定使用Docker容器技术。
整体架构58私有云的整体架构如下：
基础设施整个私有云平台接管了所有的基础设施，包括服务器、存储和网络等资源；
容器层基础设施之上提供了整个容器初始化层，容器初始化层包含Kubernetes、Agent、IPAM；Kubernetes是Docker的调度和管理组件；Agent部署在宿主机上，用于系统资源和底层基础设施的管理，包含监控采集、日志采集、容器限速等。IPAM是Docker的网络管理模块，用于管理整个网络系统的IP资源；
资源管理容器层之上是资源管理层，包含容器管理、缩扩容、回滚降级、上线发布、配额管理、资源池管理等模块；
应用层运行用户提交的业务实例，可以是任意编程语言；
基础组件私有云平台为容器运行环境提供必备的基础组件，包含服务发现、镜像中心、日志中心、监控中心。
服务发现接入云平台的服务提供统一的服务发现机制，便捷业务接入云平台；
镜像中心存储业务镜像，分布式存储，可弹性扩展；
日志中心中心化收集业务实例日志，提供统一的可视化入口，方便用户分析与查询；
监控中心汇总全部的宿主和容器监控信息，监控视图化，报警定制化，为智能化调度提供基础；
统一门户可视化的UI门户页面，规范化整个业务流程，简洁的用户流程，可动态管理整个云环境的所有资源。
全新的架构带来全新的业务流转方式：
平台定义了四套基础环境：测试环境、沙箱环境、稳定环境、线上环境。业务基于SVN提交的代码构建镜像，镜像的整个生命周期就是在4个环境中流转。因为是基于同一个镜像创建实例，所以可以保证测试通过的程序与线上运行的程序是完全一致的。
测试环境：测试人员进行功能测试，对接到线下环境；
沙箱环境：程序预发布环境，对接到线上环境；
线上环境：提供服务的线上环境；
稳定环境：运行在线下环境的实例，为其他上游服务提供稳定的测试环境实例；
核心模块的设计方案开发58私有云平台需要考虑很多细节，这里主要和大家分享下其中的五个核心模块：容器管理、日志收集、网络模型、监控告警、镜像仓库。有了这几个核心模块，平台就有了基础框架，可以运转起来。
容器管理我们调研的基于Docker的管理平台主要有三个：Swarm、Mesos、Kubernetes，通过对比，我们最终选择了Kubernetes。Swarm功能过于简陋，所以最早就pass了，Mesos + Marathon是一个成熟的解决方案，但是社区不够活跃，而且使用起来要熟悉两套框架；Kubernetes是专门针对容器技术提供的调度管理平台，更专一，社区非常活跃，配套的组件与解决方案较多，使用其的公司也越来越多，通过和一些公司沟通，他们也在逐步的将Docker应用从Mesos迁移到Kubernetes上。下面表格为我们团队关注点的一些对比情况：
网络模型网络模型是任何云环境都必须面对的问题，因为网络规模一旦扩大之后，会带来各种问题。网络选型这块，针对Docker和Kubernetes的特性，对六种组网方式进行了对比，如下所示：
针对每种网络模型，云团队都做了相应的性能测试，Calico除外，因为公司所用的机房不支持开启BGP协议，所以没有进行测试。
iPerf测试网络带宽结果如下：
Qperf测试TCP延迟结果如下：
Qperf测试UDP延迟结果如下：
通过测试结果可以看出：Host模式和Bridge模式性能与宿主机是最接近的，其他组网模式还是有一些差距的，这和Overlay的原理有关。
私有云平台最终选择了Bridge + VLAN的组网方式，原因如下：
性能较好，组网简单，可以与现有网络无缝对接；可以很好的实现容器与容器、容器与宿主互通故障易于调试，传统的SA即可解决；适应任意物理设备，可大规模扩展公司内部服务之间都是基于RPC协议，有自己的服务发现机制，可以很好的兼容；现有内部框架改动小
由于VLAN最多有4096个，所以VLAN是有个数限制的，这也是为什么会有VLAN的原因。在云平台当前的网络规划中，VLAN是够用的，未来随着使用规模的扩大，技术的发展，我们也会深入研究更合适的组网方式。
网上也有同学反馈Calico的IPIP模式网络性能也很高；但是考虑到Calico当前的坑比较多，需要有专门的网络组来支撑，而这块是云团队所欠缺的，所以没有深入调研。
这里还有一个问题，默认的使用Bridge模式是每个宿主机配置不同网段的地址，这样就可以保证不同宿主机上为容器分配的IP不冲突，但是这样也会导致会出现大量的IP浪费；机房的内网环境IP资源有限，没有办法这样配置网络，所以只能开发IPAM模块进行全局的IP管理。IPAM模块的实现参考了开源项目的实现，将可分配的网段写入etcd中，Docker实例启动时，会通过IPAM模块从etcd中获取一个可用IP，在实例关闭时，会对IP进行归还，整体架构如下所示：
另外，由于Kubernetes不支持使用CNM，所以我们针对Kubernetes源码进行了修改。
网络方面还有一个点需要考虑：就是网络限速。由于篇幅原因这里不赘述，以后专门探讨。
镜像仓库Docker的镜像仓库使用官方提供的镜像仓库，但是后端提供的存储系统我们进行选型，默认的存在本地磁盘的方式是无法应用到线上系统的。具体的选型如下：
通过对比，可以看出Ceph是最合适的，但是最终云团队选择使用HDFS作为镜像仓库的后端存储，原因如下：Swift是官方默认提供支持的存储类型，但是搭建一套Swift并保证其稳定运行需要专人深入研究，由于人员有限所有暂没使用，Ceph也是基于同理没有进行选择。HDFS系统公司有专门的数据平台部门在管理和维护，他们更专业，云团队可以放心的将Docker镜像托管到HDFS上。但是HDFS本身也存在一些问题，比如压力大时，NameNode无法及时响应，未来我们会考虑将后端存储迁移到架构线部门内部自研的对象存储中，以提供稳定高效的服务。
日志系统传统服务迁移到容器环境，日志是一个大问题。因为容器即用即销，容器关闭后，容器的存储也会被删除。虽然可以把容器中的日志导出到宿主机上的指定位置，但是容器会经常漂移，在排查故障时，我们还需要知道历史上的某一时刻，某个容器在哪台宿主机上运行，并且由于使用方没有宿主机的登陆权限，所以使用方也没法很好的获取日志。在容器环境下，需要新的故障排查方式。这里，一个通用的解决方案就是采用中心化的日志解决方案，将零散的日志统一进行收集存储，并提供灵活的查询方式。私有云平台的采用的方案如下：
使用方在管理门户上配置要采集的日志，私有云平台通过环境变量的方式映射到容器中，宿主机上部署的Agent根据环境变量获取要采集的日志，启动Flume进行采集。Flume将日志统一上传到Kafka中，上传到Kafka中的日志保证严格的先后顺序。Kafka有两个订阅者，一个将日志上传到搜索服务中，供管理门户查询使用；一个将日志上传到HDFS中，用于历史日志的查询和下载，使用方也可以自己编写Hadoop程序对指定日志进行分析。
监控告警资源的监控和报警也是一个云平台必不可少的部分。针对容器的监控有很多成熟的开源软件可供选择，58内部也有专门的监控组件，如何更好的监控，云团队也进行了相应的选型。
最终，云团队选择使用WMonitor来作为容器的监控组件，因为WMonitor本身集成了物理机和报警逻辑，我们不需要在做相对应的开发，只需要开发容器监控部分的组件，并且针对内部的监控需求，我们可以很好的进行定制。Heapster + InfluxDB + Grafana是Kubernetes官方提供的监控组件，规模小时用它也没有问题，但是规模大时使用它可能会存在问题，因为它是轮询获取所有节点监控信息的。
后记以上是58同城架构线针对容器技术如何落地进行了相关探索，很多技术选型无关优劣，只选择适合58相关应用场景的。整个云平台要解决的技术点有很多，这里选取其中几个关键的点和大家进行分享，后续我们云团队还会针对每个技术点的实施细节以及遇到的问题和大家进行深入分享。
原文链接：
姚远：58同城资深开发工程师，近些年一直致力于消息总线等中间件系统与Docker、KVM等云计算底层基础设施建设；关注服务的高并发与高可用；邮箱：。
要回复文章请先或
DockOne.io发起人准备工作：
CentOS 7安装docker：
#yum -y install docker
1、获取节点所需镜像
--主机执行
#docker pull django
#docker pull haproxy
#docker pull redis
# docker images
REPOSITORY&&&&&&&&&&&&& TAG&&&&&&&&&&&&&&&& IMAGE ID&&&&&&&&&&& CREATED&&&&&&&&&&&& SIZE
docker.io/haproxy&&&&&& latest&&&&&&&&&&&&& d2deb2e11e09&&&&&&& 6 days ago&&&&&&&&& 135.5 MB
docker.io/redis&&&&&&&& latest&&&&&&&&&&&&& 4e482b286430&&&&&&& 13 days ago&&&&&&&& 98.95 MB
docker.io/django&&&&&&& latest&&&&&&&&&&&&& eb40dcf64078&&&&&&& 6 months ago&&&&&&& 436 MB
2、启动各个容器
--主机执行
# 启动redis容器
sudo docker run -it --name redis-master redis /bin/bash
sudo docker run -it --name redis-slave1 --link redis-master:master redis /bin/bash
sudo docker run -it --name redis-slave2 --link redis-master:master redis /bin/bash
# 启动django容器
sudo docker run -it --name APP1 --link redis-master:db -v ~/Projects/Django/App1:/usr/src/app django /bin/bash
sudo docker run -it --name APP2 --link redis-master:db -v ~/Projects/Django/App2:/usr/src/app django /bin/bash
# 启动haproxy容器
sudo docker run -it --name HAProxy --link APP1:APP1 --link APP2:APP2 -p
-v ~/Projects/HAProxy:/tmp haproxy /bin/bash
# docker ps
CONTAINER ID&&&&&&& IMAGE&&&&&&&&&&&&&& COMMAND&&&&&&&&&&&&&&&&& CREATED&&&&&&&&&&&& STATUS&&&&&&&&&&&&& PORTS&&&&&&&&&&&&&&&&&&& NAMES
61ceae4c7c85&&&&&&& haproxy&&&&&&&&&&&& "/docker-entrypoint.s"&& 8 hours ago&&&&&&&& Up 8 hours&&&&&&&&& 0.0.0.0:/tcp&& HAProxy
7b11baf7b2fd&&&&&&& django&&&&&&&&&&&&& "/bin/bash"&&&&&&&&&&&&& 8 hours ago&&&&&&&& Up 8 hours&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& app2
bdb9ddacefdb&&&&&&& django&&&&&&&&&&&&& "/bin/bash"&&&&&&&&&&&&& 8 hours ago&&&&&&&& Up 8 hours&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& app1
d&&&&&&& redis&&&&&&&&&&&&&& "docker-entrypoint.sh"&& 8 hours ago&&&&&&&& Up 8 hours&&&&&&&&& 6379/tcp&&&&&&&&&&&&&&&& redis-slave2
a39b414d570c&&&&&&& redis&&&&&&&&&&&&&& "docker-entrypoint.sh"&& 8 hours ago&&&&&&&& Up 8 hours&&&&&&&&& 6379/tcp&&&&&&&&&&&&&&&& redis-slave1
c7c22a1a4123&&&&&&& redis&&&&&&&&&&&&&& "docker-entrypoint.sh"&& 8 hours ago&&&&&&&& Up 8 hours&&&&&&&&& 6379/tcp&&&&&&&&&&&&&&&& redis-master
3、redis节点配置
主机操作，切换到容器挂载目录下，进行master节点配置：
# docker inspect --format "{{ .Config.Volumes }}" c7c22a1a4123
map[/data:{}]
# docker inspect c7c22a1a4123 | grep Source
&&&&&&&&&&&&&&& "Source": "/var/lib/docker/volumes/4e823da40e10ce54d11b34ff55cbd05/_data",
#cd /var/lib/docker/volumes/4e823da40e10ce54d11b34ff55cbd05/_data
#cp &your-own-redis-dir&/redis.conf redis.conf
#vim redis.conf
修改以下内容：
bind 0.0.0.0
daemonize yes
pidfile /var/run/redis.pid
容器内操作，启动redis master节点服务：
#cp redis.conf /usr/local/bin
#cd /usr/local/bin
#redis-server redis.conf
4、配置redis slave节点
主机操作配置redis配置文件：
# docker inspect --format "{{ .Config.Volumes }}" a39b414d570c
map[/data:{}]
# docker inspect a39 | grep Source
&&&&&&&&&&&&&&& "Source": "/var/lib/docker/volumes/3c4ae73e1457456daf67ee0c03c33a41f855edc9c1c5de3804561b/_data",
#cd /var/lib/docker/volumes/3c4ae73e1457456daf67ee0c03c33a41f855edc9c1c5de3804561b/_data
#cp &your-own-redis-dir&/redis.conf redis.conf
#vim redis.conf
修改以下内容：
bind 0.0.0.0
daemonize yes
pidfile /var/run/redis.pid
slaveof master 6379
切换到redis slave1节点容器下执行：
#cp redis.conf /usr/local/bin
#cd /usr/local/bin
#redis-server redis.conf
同理启动redis另一个从节点。
至此redis配置完成，进行redis功能测试：
以redis-cli方式登录redis master节点：
# redis-cli
127.0.0.1:6379& set master c7c2
127.0.0.1:6379& get master
127.0.0.1:6379& quit
以redis-cli方式登录redis slave节点：
# redis-cli
127.0.0.1:6379& get master
127.0.0.1:6379& quit
Slave节点能正常接收主节点设置，说明redis配置成功。
5、app容器节点配置
App容器内安装python语言redis支持包：
#pip install redis
Python 3.4.5 (default, Dec 14 :20)
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
&&& import redis
&&& print(redis.__file__)
/usr/local/lib/python3.4/site-packages/redis/__init__.py
&&& quit()
6、创建app：
#cd /usr/src/app
#mkdir dockerapp&&& ##注意，这里需要关闭主机的selinux功能，关闭方式：setenforce 0
#cd dockerapp
# django-admin.py startproject redisweb
# cd redisweb/
manage.py& redisweb
# python manage.py startapp helloworld
helloworld& manage.py& redisweb
# cd ~/Projects/Django/App1/
# cd dockerweb/redisweb/helloworld/
admin.py& apps.py& __init__.py& migrations& models.py& __pycache__& tests.py& views.py
# vim views.py
内容如下：
from django.shortcuts import render
from django.http import HttpResponse
# Create your views here.
import redis
def hello(request):
str=redis.__file__
str+="&br&"
r = redis.Redis(host='db',port=6379,db=0)
info=r.info()
str+=("Set Hi &br&")
r.set('Hi','Helloworld-app1')
str+=("Get Hi:%s &br&" % r.get('Hi'))
str+=("Redis Info: &br&")
str+=("Key : Info Value")
for key in info:
& str+=("%s:%s &br&" % (key,info[key]))
return HttpResponse(str)
编辑settings.py文件：
__init__.py& __pycache__& settings.py& urls.py& wsgi.py
# vim settings.py
修改内容如下：
ALLOWED_HOSTS = ['*']&&&&&&&&&&&&&&&& --此处需要修改
# Application definition
INSTALLED_APPS = [
&&& 'django.contrib.admin',
&&& 'django.contrib.auth',
&&& 'django.contrib.contenttypes',
&&& 'django.contrib.sessions',
&&& 'django.contrib.messages',
&&& 'django.contrib.staticfiles',
&&& 'helloworld',&&&&&&&&&&&&&&&&&&&&&& --添加此处
最后再修改urls.py文件：
# vim urls.py
修改后内容如下：
from django.conf.urls import include,url
from django.contrib import admin
from helloworld.views import hello
urlpatterns = [
&&& url(r'^admin/', include(admin.site.urls)),
&&& url(r'^helloworld$',hello),
进入app容器，完成项目的生成：
# python manage.py makemigrations
No changes detected
# python manage.py migrate
Operations to perform:
& Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
& Applying contenttypes.0001_initial... OK
& Applying auth.0001_initial... OK
& Applying admin.0001_initial... OK
& Applying admin.0002_logentry_remove_auto_add... OK
& Applying contenttypes.0002_remove_content_type_name... OK
& Applying auth.0002_alter_permission_name_max_length... OK
& Applying auth.0003_alter_user_email_max_length... OK
& Applying auth.0004_alter_user_username_opts... OK
& Applying auth.0005_alter_user_last_login_null... OK
& Applying auth.0006_require_contenttypes_0002... OK
& Applying auth.0007_alter_validators_add_error_messages... OK
& Applying auth.0008_alter_user_username_max_length... OK
& Applying sessions.0001_initial... OK
# python manage.py createsuperuser
Username (leave blank to use 'root'):
Email address:
Password (again):
This password is too short. It must contain at least 8 characters.
Password (again):
Superuser created successfully.
至此，app节点配置完成，按照相同步骤配置app节点2.
容器内启动两个app节点：
# python manage.py runserver 0.0.0.0:8001
# python manage.py runserver 0.0.0.0:8002
7、haproxy节点配置
主机操作：
# cd ~/Projects/HAProxy/
#vim haproxy.cfg
内容如下：
log 127.0.0.1 local0
maxconn 4096
chroot /usr/local/sbin
pidfile /usr/local/sbin/haproxy.pid
log 127.0.0.1 local3
option dontlognull
option redispatch
maxconn 2000
balance roundrobin
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
listen redis_proxy
bind 0.0.0.0:6301
stats enable
stats uri /haproxy-stats
server app1 app1:8001 check inter 2000 rise 2 fall 5
server app2 app2:8002 check inter 2000 rise 2 fall 5
进入容器，启动haproxy负载均衡服务：
#cd /usr/local/sbin
# cp /tmp/haproxy.cfg haproxy.cfg
# haproxy -f haproxy.cfg
至此，代理服务配置完成。
应用测试：
客户机登录：http://192.168.100.235:6301/helloworld
客户机也可以登录后台管理界面：
阅读(...) 评论()Access denied | www.pansoso.com used Cloudflare to restrict access
Please enable cookies.
What happened?
The owner of this website (www.pansoso.com) has banned your access based on your browser's signature (447c4ca-ua98).}