晓得一个事物和实现这个事物是齐全不同的事件。从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环境。