使用 Docker 面对的一个挑战是，尽管我们只是对我们的代码做了一个小小的变更，我们都必须要走一遍构建一个新容器的过程，把它拉取（pull）到我们的服务器，并替代正在运行的版本。 在 Ionic，我们是 Docker 的铁杆粉丝。我们的代码以及代码的依赖全部运行在 Docker 中，Docker 让我们的产品更充分地利用计算资源，比如 Ionic Creator，以及即将到来的 www.introzo.com 服务。 使用 Docker 面对的一个挑战是，尽管我们只是对我们的代码做了一个小小的变更，我们都必须要走一遍构建一个新容器的过程，把它拉取（pull）到我们的服务器，并替代正在运行的版本。 我们所有的代码都存储在 GitHub，使用 Docker Registry（这里推荐下国内的 www.introzo.com，速度比官方的快很多，不用担心“你懂的”问题） 来自动构建和存储我们的代码，并使用 Ansible 来管理和部署我们的容器到我们的服务器上。即使是一个完全自动化的过程，部署一个小变更都可能需要花费我们 20 分钟或者更多的时间。经过头脑风暴，我们意识到我们有一个更好的方法来利用 Docker。 在最初的容器构建之后，99% 的变更都是纯代码。我们不需要添加任何依赖，或者是改变任何代码运行所必需的东西。Docker 实际上只是一种封装基础架构的方式，要求我们的代码运行在一个自包含的包中。因为我们 99% 的变更都是代码，不是基础架构，我们意识我们不需要在每次变更的时候都努力重新构建我们的基础架构。 让我们解决这个问题的是 Docker 的杀手级特性 volumes。在我们 Docker files 的***次迭代中，我们从 GitHub 拉取代码，并直接构建进容器中。现在，我们故意把代码放在容器外面，并在容器启动的时候，通过加载一个主机卷（host volume) 来代替。当我们想做一个新发布，Ansible 从 GitHub 上拉取 master 分支到我们服务器的 app 目录。这时，它通过检查来确保相关联的容器正在运行，如果没有在运行，它将启动这个容器并把 app 代码映射进容器。 使得我们的工作更便捷的另外一个组件是 uWSGI，因为我们的大部分 app 是 Python 的（Django），所以我们在 Docker 容器中使用 uWSGI 提供服务。uWSGI 有一个 touch reload 特性，可以监控指定的文件，当该文件被 touch 的时候，会重载 uWSGI 服务。在 Ansible 从 GitHub 拉取我们的变更之后，我们使用 Ansible 来 touch uwsgi.ini 文件，这会触发正在运行的容器中的 uWSGI 重载。我们就是这样来运行我们代码的更新版本的！ 这是什么意思呢？简单地说，花费我们 20+ 分钟的部署过程是这样的： 提交（Commit）和 推送（push）变更到 GitHub。 Docker Registry 拉取（pulls）变更和构建一个新容器。 Ansible 连接到我们的服务器并拉取（pulls）这个新容器 。 Ansible 发现任何旧容器正在运行的实例并停止它们。 Ansible 启动该容器的新实例。 类似的 10 秒的过程是这样的： 提交（Commit）和 推送（push）变更到 GitHub。 Ansible 连接到我们的服务器，从 GitHub 拉取***的 master。 Ansible touches 该 app 的 uwsgi.ini 文件来触发 UWSGI 的重载。 步骤分解 Supervisor / uWSGI 我们在 Docker 容器中使用 Supervisor 来启动容器中的进程运行。我们的 supervisord.conf 文件看起来像下面这样： [supervisord] nodaemon=true [program:uwsgi] command = /usr/local/bin/uwsgi --touch-reload=/path/to/code/in/container/uwsgi.ini --ini /path/to/code/in/container/uwsgi.ini  我们通过 --touch-reload 选项来把 uwsgi.ini 文件作为触发文件。 Docker 当我们启动我们的容器，我们添加一个包含我们 app 代码的主机卷（host volume），该主机卷被映射到容器中的一个 app 路径，uWSGI 将从这个路径加载 app。 docker run -d -P -v /path/to/code/on/host:/path/to/code/in/container --name=container_name driftyco/testapp  Ansible Ansible 负责从 GitHub 克隆（clone）我们应用程序的代码到我们主机的 app 目录，确保 Docker 容器正在运行以及 touch 配置的 uWSGI touch-reload 文件。我们已经创建了 playbooks 来直接部署我们的每个服务，因此部署仅仅是一个运行正确的问题。 对于一个快速代码部署，我们运行一个包含这些任务的 playbook，并只需要几秒来运行： - set_fact: host_volume="/path/to/code/on/host" - name: Git pull the latest code git: repo=support@www.introzo.com:{{ org }}/{{ container }}.git 对于一个全量部署，我们按顺序运行这两个 playbooks；这是非常简单的。 总结因为 Docker 主要的一个方式是封装基础架构到一个自包含的，可部署的包。这不需要重新构建整个容器仅仅只是为了几个代码变更。通过在 Docker 中利用卷（volumes），我们从容器中移除了代码，使得代码能独立于容器更新。***，我们可以使用 UWSGI 的 touch reload 特性在容器中重启 UWSGI，并从卷（volume）中加载更新的代码。 注：本文作者是 Joel Weirauch，本文原文是 Fast code deployments with Docker dest={{ host_volume }} accept_hostkey=yes force=yes - name: Gracefully reload uwsgi file: path={{ touch_file }} state=touch  如果我们需要重启整个容器或者是更新我们的系统包，我们可以做一个容器部署，这将花费几分钟，使用这些任务： - name: Add app dir if it doesn't yet exist file: path={{ host_volume }} owner=nobody group=docker recurse=yes state=directory sudo: yes - name: Pull Docker image command: "{{ item }}" ignore_errors: yes with_items: - docker pull {{ org }}/{{ container }} - docker stop {{ container }} - docker rm {{ container }} - name: Run Docker image with app volumes command: docker run -d -P -v {{ host_volume }}:{{ container_volume }} --name={{ container }} {{ extra_params }} {{ org }}/{{ container }}  对于一个全量部署，我们按顺序运行这两个 playbooks；这是非常简单的。 总结 因为 Docker 主要的一个方式是封装基础架构到一个自包含的，可部署的包。这不需要重新构建整个容器仅仅只是为了几个代码变更。通过在 Docker 中利用卷（volumes），我们从容器中移除了代码，使得代码能独立于容器更新。***，我们可以使用 UWSGI 的 touch reload 特性在容器中重启 UWSGI，并从卷（volume）中加载更新的代码。 注：本文作者是 Joel Weirauch，原文地址：http://www.introzo.com/blog/docker-hot-code-deploys/ 本文出自：http://www.introzo.com/article/86