共计 3624 个字符，预计需要花费 10 分钟才能阅读完成。
晓得一个事物和实现这个事物是齐全不同的事件。从 Docker 诞生那天开始，咱们就幻想着诸如“15 秒部署一个我的项目”，“版本可控开发环境”，以及时尚的运维用语，如“滚动开发”，“软件定义架构”。处于浪尖的行业人士都在以前所未有的激情参加到将很多名词和工具，例如“编排”，“服务发现”等，定义，从新定义以及商品化大潮中。
我认为这股大潮的催化剂来自于 Docker 在利用和基础架构之间带来的美好接口和形象。开发者能够在不用晓得底层架构状况下议论基础架构，操作人员也不用花大量工夫钻研如何装置和管理软件。必定有什么力量暗藏在看似简略的表面下使得大家生存简化，更加高效。
事实世界时残暴的，不要想当然认为采纳一项新技术只会带来享受。过来几年通过一些我的项目的磨难，经验过奇怪的环境，我认为 Docker 也不例外。然而某一个教训个别能够间接利用到我的项目的下一阶段。要想从 Docker 取得功力，必须浸淫到理论我的项目中去磨难。
过来一年中，我全身心投入去传授我的对于 Dokcer 根底的书，Docker in Action。
我留神到简直所有人开始学习 Docker 技术时都会纠结于如何创立开发环境，而后能力理解生态系统之内大家的关系。每个人开始都会认为应用 Docker 会使环境搭建变的简略，也不是齐全不对，有很多“容器化”教程都涵盖了创立一个 image 和如何将某个工具打包到容器（Container）内，然而如何将开发环境 Docker 化是一个齐全不同的事件。
作为一个踏坑先驱者，我能够分享一下我的教训。
我已经是一个资深 Java 使用者，但这个分享的教训不是对于 Java 的，而是围绕着我应用 Go 和 Node 开发利用产生的。我有肯定的 Go 开发教训，被动进步在这一畛域的能力。进入一个不相熟畛域迅速上手碰到的次要问题就是如何取得正确的工作流，而且我还比拟讨厌在笔记本上一直装置软件，这些都驱使我尝试用 Docker 做这些工作，或者有时候采纳 Vagrant。
我所参加的我的项目是用 Go 写一个规范的 REST 服务，基于 gin，依赖 Redis 和 NSQ 的某些库和服务。也就是说须要 import 一些本地运行着的 Redis 和 NSQ 实例的库，更乏味的是我还应用了一些服务于 NGINX 的动态资源。
对门外汉来说，Go 是一种编程语言，实际上还有一种命令行工具也叫“go”。从依赖型治理、编译、测试用例到其它各种工作都应用它。对 Go 我的项目来说，除了 Git 和一个好用的编辑器，剩下就是跟它打交道了。然而还是有一个问题，我不想在笔记本上装置 Go，笔记本上我只想装置 Git 和 Docker。这些问题限度了其余环境下的兼容性，并且对老手来说升高了门槛。
这个我的项目有运行时依赖，意味着此工具集须要为简略环境定义和编排而包含 Docker Compose。很多人会为此感到不适应，那么咱们怎么办？开始创立一个 Dockerfile 或者 docker-compose.yml？好吧，先让我通知大家我是怎么办的，而后解释为什么这么做。
例如在此案中 www.sangpi.com 中我心愿我的本地包是齐全主动的。我不喜爱手动逐条执行步骤，而且我的 vim 配置文件也很简略。我只想从“是否运行”档次管制运行环境。本地化开发环境指标被疾速复制，不仅用于进步生产效率，而且用于共享 Docker images。我最终实现了 Dockerfile，用来产生蕴含 Go，Node，和我最常常应用的打包工具 Gulp 的 images。此 Dockerfile 没有嵌入代码，image 也没有嵌入 Gulpfile。相同的，在一个建设了的 GOPATH（Go workspace 的根门路）上定义了一个卷。
最终，我为此 images 设置了给 gulp 提供服务的 entrypoint，设置默认命令来监控。输入 images 必定不是我称为 build artifact 的货色，从这个意义上来讲，此环境惟一做的就是提供了一个运行实例，帮忙咱们判断是否代码运行。对我的场景来说，运行的十分棒。而我将“artifacts”用于称说另外一个 build。
下一步我用 Compose 定义本地开发环境。首先定义了在 images 中用到的所有 Docker Hub 中定义的依赖服务，将他们连贯到某一个“指标”服务。此服务援用了新 Dockerfile 从哪里生成，将本地源目录绑定到新 image 冀望输入的挂载点，裸露一些能够测试的端口。而后，增加了一个服务，能够一直地向指标服务循环发动一系列集成测试。最终，我增加了 NGINX 服务，挂载了有很多配置文件和动态 assets 的卷。应用卷的益处在于重复使用配置文件和 assets 而不必重建 image。
image.pngimage.pngimage.png
所有代码最终会在电脑上生成本地开发环境，当应用：
docker-compose up –d
时，会启动 git clone，而后循环运行；不须要重建 image 或者重启容器。每当.go 文件发生变化，Gulp 就会重建，并且在运行的容器中重启我的服务。就这么简略。
创立此环境很简略吗？不尽然，然而的确实现了。难道不必容器，而在本地间接装置 Go，Node，Gulp 不是更简略吗？兴许在这个场景是，但也只限于用 Docker 运行此依赖服务。我不喜爱这样。
我已经要治理这些工具的不同版本，而产生了简单的环境变量，到处生成 artifacts。我不得不揭示共事们留神这些容易发生冲突的环境变量，他们太不足集中版本控制了。
兴许你并不喜爱下面形容的环境，或者对我的项目有不同的需要。很好，的确是这样，本文并不是让所有工具都运行在 Docker 中，如果这样就阐明并没思考过要解决什么问题。
当我设计这个环境时，思考过上面几个问题，顾虑，以及某些潜在答案。当开始 Docker 工作环境时，就会发现理论状况可能比本人的答复更蹩脚。
当你思考打包和环境时，最先思考的因素是什么？
这个的确是最重要的问题。在此场景中，有几个选项。我能够应用 go 间接在容器内编程，看起来如下：
image.png
其实这个示例中大部分 bolierplate 能够通过 shell 别名或者函数暗藏，感觉 Go 是装置在本人的设施中似的，还能够跟 Go 工作流分割，创立 artifacts。这些个性对非服务项目有好处，然而对库和软件我的项目就不肯定了。
假如你曾经在应用 Gulp、make、ant 或者其余脚本，那么能够持续，并且应用 Dokcer 作为这些工具的指标。
另外一种办法，我能够通过应用 Dockerbuild 来定义和管制我的 build，取得更多面向 Docker 的教训。代码如下：
image.png
应用 Dokcer 来管制 build 有若干益处。能够应用以前编译好的 image，Dockerfilebuilds 应用缓存办法，使得编译工作只反复最小的步骤（假如有一个很棒的 Dockerfile）。最初，这些 builds 生成的 images 也能够跟其余开发者共享。
这个案例中，我应用 golang 资源库中的 onbuildimage 作为根底。其中包含一些很棒的下载依赖包逻辑。这个办法会生成能够不便用于其余非生产环境的 Dockerimage。这个办法对于生产级别的 image 的问题在于，必须有步骤防止大 image 并且包含某些初始化脚本，用于启动和监控服务前验证状态。
有意思的是，Docker 应用一系列脚本，Makefiles 和 Dockerfiles。build 零碎绝对很强壮了，负责各种游戏测试，linting 等，以及各种操作系统和架构的 artifacts。本场景中，容器是用来产生二进制的工具，然而是从一个本地 build image 中实现的。
裁减 Docker build 的选项，能够应用 Compose 来定义一整套开发环境。
image.png
Compose 负责环境治理。如果感觉零碎十分洁净并不奇怪，Compose 把所有事件都分割起来，优化卷治理，当 images 缺失时主动 build，汇总日志输入。我之所以选这些开关是为了简化服务依赖，也因为它能生成我须要的 artifacts。
这个示例是一个运行时容器，Compose 或者 Docker 都有适合的工具做到这点。此场景中，也可能更须要一个分布式 image，或者可能心愿 build 能够为本机产生一个二进制文件。
如果冀望取得想要的 image，必须确保源码或者预编译库在 build 时候嵌入 image 中。build 时候没有挂载卷，也即须要每次反复时都要重建 image。
如果心愿在容器外部产生某些 artifacts，则须要引入挂载卷。应用 Docker 命令行或者 Compose 环境能够很容易实现。然而要留神，除非容器在运行，否则 build 并不工作，也就意味着不能只用 dockerbuild。
汇总
目前没有 Docker 形式创立开发环境。Docker 是一个可编排工具，不只是圣书。与其应用他人已有的 dockerbuild 零碎，不如花肯定工夫学习此工具，明确本人的需要，而后创立适宜本人的 Docker 环境。
