├── .gitignore ├── requirements.txt ├── img ├── build.png ├── ghost.png └── container.png ├── index.py ├── cherryhttp.py ├── CaaSproblems.md ├── Dockerfile ├── README.md └── Docker和DaoCloud纯小白入门手册.md /.gitignore: -------------------------------------------------------------------------------- 1 | Docker/ 2 | Docker.key/ -------------------------------------------------------------------------------- /requirements.txt: -------------------------------------------------------------------------------- 1 | cherrypy 2 | bottle 3 | requests 4 | six 5 | werobot -------------------------------------------------------------------------------- /img/build.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/adrianzhang/wechat-psn-backend/HEAD/img/build.png -------------------------------------------------------------------------------- /img/ghost.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/adrianzhang/wechat-psn-backend/HEAD/img/ghost.png -------------------------------------------------------------------------------- /img/container.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/adrianzhang/wechat-psn-backend/HEAD/img/container.png -------------------------------------------------------------------------------- /index.py: -------------------------------------------------------------------------------- 1 | # -*- coding:utf-8 -*- 2 | import werobot 3 | 4 | #robot = werobot.WeRoBot(token='robot', enable_session=True, session_storage=saekvstorage.SaeKVDBStorage()) 5 | #robot = werobot.WeRoBot(token='testrobot', enable_session=True, session_storage=filestorage.FileStorage()) 6 | robot = werobot.WeRoBot(token='testrobot', enable_session=True) 7 | 8 | @robot.subscribe 9 | def subscribe(message): 10 | return '欢迎关注本公众号！' 11 | 12 | @robot.handler 13 | def echo(message): 14 | return '我是WeRoBot机器人' 15 | 16 | robot.run(server='cherrypy',host='0.0.0.0',port=80) -------------------------------------------------------------------------------- /cherryhttp.py: -------------------------------------------------------------------------------- 1 | # cherrypy as http server 2 | # -*- coding:utf-8 -*- 3 | import cherrypy 4 | import werobot 5 | 6 | class Werobot_Run(): 7 | __init__(self,name) 8 | 9 | robot = werobot.WeRoBot(token='testrobot', enable_session=True) 10 | 11 | @robot.subscribe 12 | def subscribe(message): 13 | return '欢迎关注本公众号！' 14 | 15 | @robot.handler 16 | def echo(message): 17 | return '我是WeRoBot机器人' 18 | 19 | #robot.run(server='cherrypy',host='0.0.0.0',port=80) 20 | 21 | def raw_wsgi_app(): 22 | 23 | start = Werobot_Run() 24 | 25 | cherrypy.tree.graft(raw_wsgi_app, '/weixin') -------------------------------------------------------------------------------- /CaaSproblems.md: -------------------------------------------------------------------------------- 1 | 本文作为对：[《CaaS国内服务商测评》][1]一文的补充。 2 | 3 | 如果开发一个web应用，若脚本语言，则有dev——testenv——stgenv——prodenv的上线过程；若非脚本语言，则有dev——devtest——ci——testenv——stgenv——prodenv的上线过程。这里仅就前一种情况进行阐述。 4 | 5 | CaaS具有快速部署一个环境的优点，然而选择CaaS服务商提供的平台上线，有如下痛点： 6 | 7 | # UI的简洁 8 | 9 | 根据[《Docker和DaoCloud纯小白入门手册》][2]一文，理解了Docker的机制，那么就希望快速找到相关的功能并进行操作。在这点上，DaoCloud布局是个非常好的范例。 10 | 11 | # 代码仓库支持度 12 | 支持的自由程度决定了企业可以将代码仓库放到哪里。可供选择范围越大，企业自由度越大。 13 | 14 | # 构建过程 15 | 由于有了Docker，开发过程完全可以直接使用CaaS平台进行直观测试，也就是devenv。这要求：与仓库代码集成顺畅无故障，构建所需时间短，构建服务稳定可靠，每个commit都可以执行自动构建。 16 | 对于testevn测试环境、对构建无要求，只需要用镜像就可以。 17 | stgenv、prodenv，需要打tag再构建（stgenv使用dev branch，prodenv使用master branch）。 18 | 企业私有服务，一定不希望镜像在CaaS上是公开的。这需要CaaS提供选择设置镜像公开或私有。 19 | 20 | # 容器 21 | 对于容器地理位置，能提供的范围越大越好，毕竟企业服务的客户有可能遍布国内国外。节点质量（比如硬盘使用SSD或普通）越好，当然服务也就越好。但让企业付费时候可以选择节点质量，也是一个很好的商业方式，但对于不想选择的企业，就可能构成麻烦。如果能够对接企业自己建立的节点，对于企业来说就少了一些迁移和部署的麻烦，也就是可以轻松实现混合云。 22 | 23 | # 部署 24 | 有了镜像后，testenv, stgenv和prodenv都需要能够选择不同版本的镜像以便调入容器运行。对于大规模web应用，架构层级往往比较多，这需要CaaS支持自动编排（yaml配置文件）或手工安排（可视化编排）。而不同的环境(test、stg、prod)以及不同的架构层级，对于端口的映射需求也不同。那么CaaS需要提供不同的端口映射方法。新镜像有了以后，对于dev、test和stg，都需要自动直接部署，部署失败可以干预，而prod就不需要自动部署，必须手工。四个环境都需要可以选择不同的镜像版本来部署，所以CaaS必须提供这个功能。 25 | 26 | # 服务 27 | 部署为服务的话，一个服务的可用、可靠、可扩展性需要予以考虑。 28 | 29 | - 对于可用，需要提供shell允许进到容器去观察和处理一些事务。 30 | - 对于可靠，无需多言，容器当机等现象不允许出现。 31 | - 对于可扩展，有些服务，例如web server, app server，架构能支持横向扩展，CaaS予以容器可自动或手工扩展的实现支持，当然自动最好。自动和手工的选择往往处于商业角度，若自动则付费不可控，若手工则付费可控，所以CaaS应提供选项支持。 32 | 33 | 相关CaaS服务商测评表格见[《CaaS国内服务商测评》][1]最下方。 34 | 35 | [1]: http://adrian-devblog.daoapp.io/2015/09/06/caasguo-nei-fu-wu-shang-ce-ping/ 36 | [2]: http://open.daocloud.io/an-explicate-of-docker-and-daocloud/ -------------------------------------------------------------------------------- /Dockerfile: -------------------------------------------------------------------------------- 1 | FROM buildpack-deps:wheezy 2 | 3 | # remove several traces of debian python 4 | RUN apt-get purge -y python.* 5 | 6 | # http://bugs.python.org/issue19846 7 | # > At the moment, setting "LANG=C" on a Linux system *fundamentally breaks Python 3*, and that's not OK. 8 | ENV LANG C.UTF-8 9 | 10 | # gpg: key 18ADD4FF: public key "Benjamin Peterson " imported 11 | RUN gpg --keyserver ha.pool.sks-keyservers.net --recv-keys C01E1CAD5EA2C4F0B8E3571504C367C218ADD4FF 12 | 13 | ENV PYTHON_VERSION 2.7.10 14 | 15 | # if this is called "PIP_VERSION", pip explodes with "ValueError: invalid truth value ''" 16 | ENV PYTHON_PIP_VERSION 7.1.0 17 | 18 | RUN set -x \ 19 | && mkdir -p /usr/src/python \ 20 | && curl -SL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz" -o python.tar.xz \ 21 | && curl -SL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz.asc" -o python.tar.xz.asc \ 22 | && gpg --verify python.tar.xz.asc \ 23 | && tar -xJC /usr/src/python --strip-components=1 -f python.tar.xz \ 24 | && rm python.tar.xz* \ 25 | && cd /usr/src/python \ 26 | && ./configure --enable-shared --enable-unicode=ucs4 \ 27 | && make -j$(nproc) \ 28 | && make install \ 29 | && ldconfig \ 30 | && curl -SL 'https://bootstrap.pypa.io/get-pip.py' | python2 \ 31 | && pip install --no-cache-dir --upgrade pip==$PYTHON_PIP_VERSION \ 32 | && find /usr/local \ 33 | \( -type d -a -name test -o -name tests \) \ 34 | -o \( -type f -a -name '*.pyc' -o -name '*.pyo' \) \ 35 | -exec rm -rf '{}' + \ 36 | && rm -rf /usr/src/python 37 | 38 | # install "virtualenv", since the vast majority of users of this image will want it 39 | RUN pip install --no-cache-dir virtualenv 40 | 41 | # revised for DaoCloud.io 42 | 43 | # these maybe install 44 | RUN pip install --no-cache-dir pycrypto 45 | RUN pip install --no-cache-dir lxml 46 | 47 | # copy code 48 | COPY ./ /tmp/ 49 | WORKDIR /tmp 50 | 51 | # install CherryPy & WeRoBot & WeRoBot dependencies: from WeRoBotsource/requirements.txt 52 | RUN pip install --no-cache-dir -r requirements.txt && rm -rf requirements.txt 53 | 54 | # listen 80 port 55 | EXPOSE 80 56 | 57 | # CMD ["python2"] 58 | ENTRYPOINT ["python"] 59 | CMD ["index.py"] 60 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # wechat-psn-backend 2 | 一个微信公众号（服务号，Public Service Number）后台环境（Linux+python+werobot+cherrypy），使用[DaoCloud网站][1]或[灵雀云][4]来管理运行，使用者几分钟即可拥有自己的类似SAE/GAE/BAE云的应用开发平台，只要部署了自己的代码，即可在几秒钟内提供微信订阅号/服务号后台服务。这个平台使用纯Python、CherryPy和WeRoBot构建。在这个平台上开发请[阅读WeRoBot的文档][5]。或者您也可以把Dockerfile改改，安装成您自己喜欢的应用框架和web服务器。 3 | 4 | ## 起源 5 | 这个项目的起源是被逼无奈。起初，在SAE上申请个账号，申请了应用空间。结果遇到了巨大的麻烦： 6 | - SAE主要推荐SVN管理代码，而开发Python最方便的Mac OS上并没有什么好的免费GUI工具. 7 | - SAE也支持Git管理代码，但是使用方法没有详细介绍以至于摸索了一阵子。 8 | - 帐户未作实名认证只能申请最多两个应用。一个应用已经可以运行了，另一个应用需要部署一个框架，这个框架必须用SVN部署到SAE应用空间去，而SAE并不支持同时SVN+Git的管理方法，只能选择其中之一，无奈只好删除应用，打算重新启用SVN管理代码，谁知道SAE上删除应用居然要两天！于是有两天时间必须寻找其他平台解决方法。 9 | 10 | ## [DaoCloud][1] 11 | 通过[七牛网][2]的友情链接发现了[DaoCloud][1]，在[DaoCloud][1]的技术人员热情地帮助下，发现了Docker是一个非常先进的工具，可以用来快速构建自己的应用环境，而[DaoCloud][1]则可以帮助我们实现快速将Docker方式实现的应用环境部署到云中。如此一来，还需要xAE们吗？自己就可以实现一个**myAE**了。 12 | 13 | 更好玩的是：在[DaoCloud][1]的管理下，我们可以将环境的不同组件部署到不同的地方去——应用主机可以放在AWS的VPS上，数据库可以放在RackSpace或阿里云、腾讯云、微软Arzur云平台上，存储放到七牛云。实现了应用环境的分布式。甚至高兴的话，把应用主机部署在自己家里的树莓派上，哪怕没有公网IP也可以！ 14 | 15 | ## [灵雀云][4] 16 | 这是另一个类似DaoCloud的网站，用来作为网络Docker系统实现，可以网络式构建docker image，然后直接部署在灵雀云的容器中，上线！ 17 | 18 | ## [时速云][7] 19 | 这个网站是比较早的一个Docker云服务商。在这个网站上面使用该repo和在上面两个网站的使用方法是一致的。 20 | 21 | ## Docker 22 | 23 | 若第一次看到Docker这个词，请参考[《Docker和DaoCloud纯小白入门手册》][3]来了解它。若有了一定了解，那么这个Repository里的dockerfile就是用来构建docker image的。目标是形成一个开箱即用的用于开发微信公众号后台的App Engine，当然了，这个App Engine与其他SAE/GAE等不同的地方在于它完全是属于开发者自己的。可以随便更改环境配置，比如增加个框架什么的。 24 | 25 | ## 使用方法 26 | 27 | 那么对于开发者，这个Repository到底有什么好处呢？这个Repository里有构建环境必要的Dockfile和配置文件yaml，只需要fork这个Repository，然后您本人的GitHub目录下就有了同名repository，把自己的Python代码push到这个同名repository里，使用[DaoCloud][1]，点两下鼠标就能在几分钟之内发布自己的微信服务号后台，在微信公众号配置页面开发者模式中关联这个后台，微信公众号立刻可用。相比较原先需要几个小时乃至几天的安装、配置环境、部署代码、运行，大大节省了时间。作为演示，此Repo中已经放置了index.py，在任何一个Docker云服务商那里运用这个Repo生成镜像并部署成应用，那么马上就可以把微信公众号后台开发者模式绑定这个应用，Token使用testrobot。关注自己的公众号，发个消息，看看会发生什么吧。 28 | 29 | ## 测试方法 30 | 在DaoCloud或灵雀云上运行起来之后，使用微信提供的[测试页面][6]，URL填写为在DaoCloud或灵雀云获得的应用URL，Token填写为testrobot，加密调试选“兼容模式”，其他的按照微信文档说明填写。即可向这个后台应用发消息并获得回复。 31 | 32 | [1]: 33 | [2]: 34 | [3]: <./Docker和DaoCloud纯小白入门手册.md> 35 | [4]: 36 | [5]: 37 | [6]: 38 | [7]: -------------------------------------------------------------------------------- /Docker和DaoCloud纯小白入门手册.md: -------------------------------------------------------------------------------- 1 | # [Docker][1]和[DaoCloud][2]纯小白入门手册 2 | 3 | > 一天，乔布斯走进了拉里.凯尼恩(Larry Kenyan)的办公隔间，他是负责麦金塔电脑操作系统的工程师，乔布斯抱怨说开机启动时间太长了。凯尼恩开始解释，但乔布斯打断了他。他问道：“如果能救人一命的话，你愿意想办法让启动时间缩短10秒钟吗？”凯尼恩说也许可以。乔布斯于是走到一块白板前开始演示，如果有500万人使用Mac，而每天开机都要多用10秒钟，那加起来每年就要浪费大约3亿分钟，而3亿分钟相当于至少100个人的终身寿命。“这番话让拉里十分震惊，几周过后，乔布斯再来看的时候，启动时间缩短了28秒，”阿特金森回忆说，“史蒂夫能看到宏观层面，从而激励别人工作。” 4 | 5 | > 引述自：《史蒂夫·乔布斯传》p.111 6 | 7 | 乔布斯对时间的理解，促使我也有了写这篇文章的动力。因为：[Docker][1]和[DaoCloud][2]是划时代的伟大工具。web程序开发者、测试员、系统管理员们利用它们能够节约巨量的时间，加快产品上线进而也能节省用户（你、我、每个人）的时间。然而，居然没有一篇为纯粹只懂得个人电脑的小白所写的入门手册以至于这么优秀的工具无法迅速普及从而拯救N个人的生命，这简直太令人发指！ 8 | 9 | 工具的产生是为了解决问题，那么先来看看世界上存在着什么样的问题需要Docker和DaoCloud来解决。 10 | 11 | ## 原始时代 12 | 13 | ![Ghost](img/ghost.png) 14 | 15 | 回忆一下Windows 98年代使用广泛的Norton Ghost软件（现在属于Symantec公司）。Ghost软件的作用是对可运行的系统环境做clone（克隆），形成一个镜像（image），以便Windows 98崩溃以后能够从镜像中迅速恢复一个可用的系统环境。这解决了频繁重装Windows 98的麻烦，而且从镜像恢复比安装更节约时间。它有几种常见用法： 16 | 17 | - 操作系统（例如Windows 98）安装好以后，对C盘（系统盘）做一个clone； 18 | - 装完操作系统后再装些软件（例如输入法），然后对系统盘做clone（假设输入法也装在系统盘里）； 19 | - 或者装完操作系统，再装完软件（比如photoshop），然后对photoshop做一些自己习惯的配置，最后再clone。 20 | 21 | 显然，将更多的手工工作clone到image里，更能够节约多次安装的时间和人工劳动。 22 | 23 | Docker对这个模式进行了Linux和网络世界的完美实现，但是以一种更网络化的方式实现，更加节省时间和更加灵活。接着来看没有Docker以前在Linux和网络世界会遇到什么情况： 24 | 25 | 我们都知道网络上运行着很多服务器，有web服务器，有DNS服务器等等。如果我们需要自己建一个服务器，要经过许多步骤，就拿最常见的web服务器来做个说明： 26 | 27 | 1. 先要有服务器。服务器外形与我们家用的电脑（台式机和笔记本）不一样，但是里面的硬件是一样的——CPU、内存、主板、硬盘。只不过作为服务千万人的服务器，这些硬件性能比家用电脑好很多。或者，也可以用虚拟机，甚至是从云服务商那里买VPS（Virutual Private Server，云服务商提供的存在于网上的虚拟机）。 28 | 2. 安装操作系统（Linux或Windows Server版）； 29 | 3. 安装web服务器软件（Apache、Nginx等）； 30 | 4. 安装动态Web所需要的语言环境（PHP，Ruby，Python等）和数据库（MySQL等）； 31 | 5. 有时为了快速开发还需要安装一些框架（比如Python的django等）； 32 | 6. 部署代码到web服务器软件指定目录下，有时我们需要代码的版本控制系统（Subversion、Git等），这个系统可以直接安装在服务器上（通常情况，对外提供服务的正式服务器——谓之“生产环境”是不能够装版本控制系统的，但是用来做开发用途的服务器——谓之“开发环境”可以这么干）； 33 | 7. 安装配置后，还需要配置公网IP地址，买好域名并将www.域名.com指向这个IP。 34 | 35 | 累吗？很累！但是还没完！ 36 | 37 | 系统管理员都知道，相同软件环境的服务器有时候要部署很多台，比如为了负载均衡，要部署一堆同样的web服务器，用户点网页的时候可以由不同服务器提供服务，以便响应海量用户。 38 | 39 | 开发者都知道，他们需要有很多台不同配置的服务器，原因在于，如果只有一个开发环境，一个项目使用python 2.7，另一个使用python 3.0，那需要进行一番设置。最头疼的是，这些软件环境升级还好说，如果需要降级就很麻烦，各种依赖库版本各种打架。因此，通常开发者都要求为不同的项目配备符合本项目软件环境要求的开发服务器，这就带来了大量不同软件环境服务器安装的需求。 40 | 41 | 有的时候，性能也出来捣乱，比如自己写的程序在配备了酷睿1代CPU的开发环境上运行的很吃力，想换到配备了酷睿5代CPU的机器，但是酷睿5代机器却没有同样的操作系统和软件环境，怎么办？只能在它上面按照旧机器的软件环境要求一模一样地安装一遍。这些问题弄的人头大以至于无法专心写代码，就连系统管理人员和测试人员也被折磨得疲惫不堪。 42 | 43 | 所以，三大痛点： 44 | 45 | 1. **相同软件环境的多个服务器的安装** 46 | 2. **不同软件环境服务器的安装** 47 | 3. **不同硬件环境的相同软件环境的安装** 48 | 49 | Ghost方式解决的是第1和3类型的问题，而第3类型并没解决好（硬件驱动不同）。况且Linux体系的特性与Windows不同，因此没有类似Norton Ghost这样的软件，对于这三大痛点解决方案是：由于Linux系统有着可以网络安装的特性，操作系统和软件都放在服务器上，在安装不同软件环境的时候，使用相应的脚本来进行网络化自动安装，减少一些手工操作。以上这些，还没有涉及代码部署和把服务器连到网络上（上线）的自动化问题，这些步骤很多仍需要人工操作。 50 | 51 | 虚拟技术出现以后，使用虚拟机能够更方便一点解决第3个痛点。在硬件服务器操作系统中安装虚拟化软件（例如VMware）生成虚拟机母平台，在虚拟机母平台上产生多个虚拟机（没装操作系统的），再在这些虚拟机中安装操作系统和软件环境。如果遇到上述那个经典问题——机器性能不够，需要把开发环境迁移到性能更好的机器上去，那么只需要将虚拟机迁移到更好硬件平台的虚拟机母平台上去并给虚拟机分配更多的资源。 52 | 53 | 这个时代被我定义为“原始时代”，因为里面有大量的步骤是手工操作，类似于流水线生产还没有出现的原始手工时代。 54 | 55 | ## 解决原始时代的问题 56 | 57 | 终于，一群聪明人实在受不了天天把时间耗费在无穷无尽的安装配置中。他们发明了**Docker**来解决这些问题。[Docker][1]用**docker image**（中文叫做**Docker镜像**）来代替原始时代的镜像（或光盘），用**docker file**来取代自动安装脚本，用**docker node**来代替虚拟机母平台，用**container（容器）**来代替虚拟机。综合了原始时代那些工具的所有的优点使得Linux和网络实现了完全自动化。 58 | 59 | - 镜像（或光盘）==> Docker image 60 | - 安装脚本 ==> Docker file 61 | - 安装了虚拟机软件的服务器 ==> Docker node 62 | - 虚拟机（未安装操作系统的）==> Docker container 63 | 64 | ### Docker image与Docker file 65 | 66 | **docker image**存储在[Docker][1]专门配置的网络仓库[Docker Hub][6]或[DaoCloud][2]这样的Docker云服务商的网络仓库中(任何人都可以建立这样的网络仓库，通过web服务发布这些镜像)。 67 | 68 | **docker file**可以引用已经存在于网络仓库里的docker镜像，在其基础上继续定制的新docker镜像。所谓引用就是在docker file的开头写一句基于哪个镜像（语法是：`FROM 镜像库/镜像名`）。想让多少工序自动化，就将多少工序的相应命令写在docker file里。若将安装配置操作系统、软件的全部过程甚至代码部署都写在docker file中，那么，只需要更新代码，就实现了web应用的自动上线，从而节省大量的时间以及人工重复性工作。 69 | 70 | 执行docker file生成新docker image的操作，叫做**“构建”**。整个构建过程可以想象成模拟clone：将源docker image运行起来，按照docker file里的命令安装一些软件或者做一些配置，这一切做完以后，将整个环境制作成一个新docker image。 71 | 72 | 实际上源image并不运行，只是在docker file里写一些对其的操作，这些操作语句将被包含在新docker镜像里**（新docker镜像=源docker镜像+docker file）**，新docker镜像*运行*的时候才会执行docker file中的命令。 73 | 74 | 若一个更新的docker file引用了这个"新docker镜像"，构建的实质是将更新的docker file里的操作命令与"新docker镜像"中包含的docker file命令合并，并添加到那个更新的docker镜像里。所以，构建的本质是脚本安装，却表现为clone。 75 | 76 | Docker术语体系中，每执行一条docker file里的命令，叫做增加一个**“层”**，无论这个“层”干的活是安装还是删除。由于镜像具有不可直接修改的性质，如果想从源docker镜像里删除某些软件后形成新的docker镜像，那么就在docker file里写入删除那些软件的语句，新构建生成的docker 镜像*运行起来*就没有那些软件了。由前述构建的实质可知：新docker 镜像本身不比源docker镜像小。 77 | 78 | 引用带来的好处是减少制作新docker镜像所需要写在docker file里的命令。举个例子：源镜像是Linux操作系统，那么可以引用它并制作出一个含有Linux+Apache+PHP的docker镜像，现在就有了两个可以充当源镜像的docker镜像。如果要制作标准的LAMP（Linux+Apache+MySQL+PHP）web服务器的docker镜像，只需要引用Linux+Apache+PHP这个源镜像，再在docker file里添加一句：下载并安装MySQL（语法请参考docker file相关文档，这里不多介绍），就成了。 79 | 80 | ![构建](img/build.png) 81 | 82 | ### Docker node与Docker container 83 | 84 | docker image运行在**container（容器）**中。将docker image调入容器运行的动作叫做**“部署”**。将指定的docker image部署到指定的容器，并完成启动，就产生了一个**“服务”**。 85 | 86 | 容器由**Docker node**提供。Docker体系中，**docker软件**（也就是很多文章里提到的下载、安装、配置的docker server）是虚拟化软件（回想一下VMware软件），docker node就是一个安装了docker软件的硬件机器（或者不用硬件机器，而是用虚拟机或VPS），从而成为了Docker虚拟机母平台，docker虚拟机就是容器（回想一下没有安装操作系统的VMware虚拟机）。通过操作docker软件，可以在docker node上创建多个容器。 87 | 88 | ![容器](img/container.png) 89 | 90 | Docker能够模拟“clone”的关键原因在于：容器与原始时代虚拟机实质上不同，它并不被母平台硬件不同所干扰，在docker镜像看来每个容器硬件环境都一样，也就不需要运行docker镜像后再手工去安装不同的驱动。表现与VMware虚拟机类似，但采用的是“沙盒”技术。 91 | 92 | ### DaoCloud的舞台 93 | 94 | 而[Docker Hub][6]和[DaoCloud][2]这样的云Docker服务商，为这条流水线完成了最后一环——使所有的步骤都在网络上进行，将上线也自动化并节省了从安装操作系统到服务器上线各个环节的时间，从而大大缩短了整体上线时间。 95 | 96 | - 它们存储了足够多种类的源docker镜像，使定制image需要的安装步骤尽可能少，甚至一些源镜像可以直接上线； 97 | - 用足够强大的服务器来构建docker image； 98 | - 提供docker node和容器，IP地址，域名以及相关的防火墙等网络基础上线平台； 99 | - 还有从[GitHub][3]和其他代码仓库下载我们编写的docker file以及代码的能力。 100 | 101 | 这相当于：docker镜像仓库、构建docker镜像的服务器，docker node以及其上的容器，均可以布置在一个云服务商内部的局域网中。从而节省了下载源docker镜像的时间、使用我们自己不够快的电脑制作docker镜像的时间、配置IP和域名的时间、还节省了安装配置相关防火墙以及负载均衡等网络设施的时间（开发者更无须了解这些配置的细节）。只要将符合我们需求的docker file以及程序源代码上传到已关联的GitHub repository，在DaoCloud网站中构建新镜像并指定该Docker file，然后部署、生成服务，即可实现服务器上线。 102 | 103 | [DaoCloud][2]不仅提供了以上所说的那些功能，还可以管理不属于DaoCloud的docker node，无论这个docker node在哪里（可以在家里的树莓派上、台式电脑或笔记本里，也可以在AWS上）。从而为分布式部署我们的web应用服务器提供了方便。 104 | 105 | ## 与DaoCloud共舞 106 | 107 | 至此，Docker和DaoCloud是什么以及能做什么，都已经介绍完毕。那么我们怎么利用这套系统呢？先去[DaoCloud][2]注册一个帐户，个人设置中关联自己的GitHub帐号。在[GitHub][3]里新建一个repository，存入Docker file文件。也可以在[GitHub][3]上找找别人的docker file，fork到自己[GitHub][3]帐户下的Repository里。跟着[DaoCloud][2]的[入门手册][4]和[视频][5]，在DaoCloud控制面板里点击“构建”（选择自己GitHub里有dockerfile的那个repository）、“部署”、点完这几个按钮后，便能获取一个运行着的服务器。 108 | 109 | 可能有些人还想在开发环境运行起来以后登录进去，以便再做一些手工工作或者上传代码，那么找找编写docker file的参考资料，里面会有介绍。其实呢，完全可以把自己的代码也放在GitHub用来存储docker file的同一个repository里，然后docker file里写一句`COPY ./ /tmp`，在docker镜像部署到容器运行以后，这些代码在/tmp目录里。要是想把一个index.html放在/www/html/中呢？Docker file里写成：`COPY ./ /www/html`就可以了。 110 | 111 | ## 注意事项 112 | 113 | - Docker技术目前还不能运用于Windows体系，只运用于Linux/Unix体系。 114 | - 在DaoCloud部署的服务器必须是Web服务器。 115 | 116 | ## 尾声 117 | 118 | 本文写到这里，就算完成入门的任务了，小白们如果还有不明白的地方，欢迎来邮件询问，这篇文章将根据需要进行更新，力图最最白的那位小白也能看懂，从此开始学习docker技术相关知识，妥善利用[DaoCloud][2]网站，节省开发部署所用的时间。因为：时间就是生命。 119 | 120 | 121 | [1]: 122 | [2]: 123 | [3]: 124 | [4]: 125 | [5]: 126 | [6]: 127 | 128 | 作者：Adrian Zhang，adrian@favap.com 129 | 2015-08-24 V2.0 --------------------------------------------------------------------------------