Docker缩短新开发者熟悉项目时间的五个方面

【编者的话】本文介绍了如何使用Docker容器来减小新员工入职加入团队的准备启动时间的五个方法，包括Docker容器是惟一的依赖、容易知道如何构建环境、跨机器的便携性、一致性的开发环境以及轻量级的环境。

不管公司规模大小，加入新的开发者而且想要让其尽快达到可以干活的程度，仍然是一个显著的挑战。新开发者被雇佣和生产（做者所谓的生产能够看“注1”）的时间越长，须要耗费的时间就越长，尤为是一些经验丰富的开发者。

鉴于此，有效的入职工做流程有两个须要考虑关键的问题：

• 如何将重新人坐下到熟悉项目的时间缩短到尽量小？
• 新员工如何尽快进入状态？

实际上，一个更好的问题是：不管开发人员是刚刚到公司仍是刚刚接触一个项目，咱们该如何让他们尽快熟悉项目并进行开发？

*注【1】：本文中，所谓生产能够理解为添加新功能，修复现有bug，或者可以调研安装开发过程须要用到的代码库。

有不少技术能够用来解决上述问题，包括shell脚本、WAMP、MAMP和LAMP 堆栈技术以及虚拟机，可是我发现最引人注目的是Docker。Docker是DevOps世界中众所周知的新生儿，它最新的一系列技术，旨在使项目可以从开发环境平滑地过滤到生产环境。

固然，Docker可以让你比较容易接触新技术，而且让你以为它无所不能。 然而，Docker真的特别擅长减小新开发人员的新人时间（从入职到能干活）。今天，我将介绍Docker能够显着减小新员工熟悉项目时间的五个方面。

 

Docker是惟一的依赖

 

若是你已经作开发至少五年，你应该熟悉一系列用于构建开发环境的方法。

最初，有（L，W，M）AMP堆栈，可让开发人员的机器包含各类开发库和依赖包。虽然对于一些项目是颇有用的，可是这种方法每每会致使机器迅速变得凌乱。特别是在不一样的项目须要不一样版本的相同开发库（例如加密，字符串处理，数字处理或SSL）的时候。

开发机器也可能会被迅速填满大量安装包，以及一系列配置。 所以，几乎不可能在生产环境中或在任何其余地方从新构建相同的环境。相反，这又将致使不良的“为我所用”的效应。

有了Docker，这不就再是一个问题。 在Docker Hub上拥有一系列预配置的Docker容器，能够知足各类开发需求。好比说，若是你正在建立一个Ruby app，能够从Docker Hub上拉取一个Ruby容器。若是您要建立Go或Python app，能够拉取Go或Python容器。更进一步，若是你正在建立一个基于框架的应用程序，例如Zend Expressive for PHP，你能够从Docker Hub上拉取相应的容器配置。

若是应用程序的需求更多，你能够先肯定相关的需求，而后构建一个自定义的容器配置，组装必要的容器来知足这些需求。若是你构建了自定义容器，而Docker Hub上尚未这种容器，你能够考虑把容器上传，以便其余人也可使用它。

不管你的需求是什么，使用Docker后，开发机器再也不须要安装各类不一样类型的开发库，软件包或配置。这样，开发机将变得更加轻量、更加干净，而不是由于一堆的依赖变得臃肿。开发人员也不会再逃避责任，总觉得机器“为我所用”。

 

Docker很容易让你知道如何构建环境

 

让咱们看看Docker如何简化配置需求。长期以来，虚拟机是配置开发环境的最佳工具。经过使用基于VirtualBox、Parallels和VMWare等工具建立的虚拟机，开发环境能够构建成与测试，暂存，生产或任何其余环境彻底相同。在这些环境中，你能够模拟代码被托管的方式。

然而，虚拟机与在裸机硬件上运行的机器没有什么不一样。全部的软件，库，扩展和依赖仍然须要安装和配置。所以，构建它们的时间仍然不是小任务，而且为不一样的项目复制它们也不简单。所以，你须要使用Vagrant、Puppet、Chef、Salt和Ansible等工具来解决这个问题。这些工具能够建立可复制和可版本化的配置脚本，经过这些脚本能够在任何环境上构建相同的虚拟机。

可是，无论选择哪一种配置工具，都须要花费不少时间来学习。有些工具甚至须要花费更长的时间来学习，即便是最简单的一款工具（Ansible），想要建立配置，用以构建一个具有缓存、日志、邮件和数据库等功能的PHP应用程序仍是要花费很多的时间。最近我就建立了一个这样的项目，配置开发，测试和生产环境包括了15个目录和34个文件。

而后就是资源利用率的问题。假设你须要在生产环境的不一样机器上部署Web、数据库、队列和缓存服务器，你至少在开发环境中准备四个虚拟机进行开发，而后将他们组装在一块儿造成完整的服务，而每一台每一个虚拟机都须要分配内存、CPU和驱动器空间。

经过Docker，这些事情会变得容易，你不须要花太多时间设置全部环境。使用Docker Compose，根据你应用程序的需求，配置可能以下：

这里咱们为PHP应用程序构建了一个环境，有两个容器，一个运行NGINX，一个经过FPM运行PHP。这与Ansible或Puppet配置造成鲜明对比。使用Ansible或Puppet，你必须指定全部必需的依赖包。而使用Docker，你只须要一个容器之间能共享的基础镜像，而后添加你须要的东西。

因为咱们只须要两个组件来运行应用程序，咱们就只须要关心这两个组件。 所以，使用Docker有如下几个好处：

• 咱们没必要关心全部相关的二进制文件。
• 配置很是简单明了。
• 学习时间大大减小。

若是有人历来没有接触过Docker，不要紧，我建议他们能够花20到30分钟学习下Docker，充分了解Docker的原理以及配置方式，例如文件在容器中所处的位置等等。不须要进行冗长的培训课程，他们也没必要成为DevOps大师，若是须要的话，他们本身就能够进行配置更改。

经过将一组现有容器链接在一块儿并提供所需的额外配置，能够很是快速地建立容器配置。所以，DevOps能够很是快地建立开发环境配置，而不是花费过多的时间在其余技术上。

 

跨机器可移植性

 

在许多方面，Docker能够根本上解决可移植性问题，即便在Windows和Mac上也是如此。

Docker如今使用的只有Linux技术，它基于Linux容器（LXC）、cgroups和内核命名空间，默认状况下，Mac和Windows没法运行Docker。2014年，微软宣布初步支持改进Windows Server，以即可以支持Docker。然而，我不知道在写这篇文章的时候，这种改进是否已经完成或者苹果是否有相似的这种支持。

尽管如此，Docker仍然能够在两个平台上运行，分别经过Docker for Windows和Docker for Mac。这些包提供了一个Linux基础库，能够在其上运行Docker。基于这些改变和软件包，不管开发人员使用哪一种平台，他们均可以利用Docker配置文件和相关工具快速搭建工做所需的全部环境。

考虑到配置文件是一个或一系列的文本文件，经过文本编辑器就能够进行维护，而文本编辑器在全部主流操做系统中都存在，这使得配置文件易于在版本控制下进行存储。

我知道，可能有些IT企业的政策是限制使用某些操做系统。然而，这一般是一个很差的选择。因为Docker适用于全部主要平台，所以没有理由限制开发人员选择想用的操做系统。

 

跨开发环境一致性

 

这是我真正喜欢的一个好处，也是我在使用虚拟机时未曾体会到的。当你使用Docker容器时，能够跨机器移动它。只要目的端机器能够运行Docker，就没什么问题。你能够将应用程序及其依赖项整合在一个容器中，并将其从一个机器移动到另外一个机器。

不管Docker运行在什么主机上，它能够确保不出现任何兼容性问题。这是我前段时间在构建装有Docker的虚拟机时，想要作到可是没有成功作到的事情。

 

轻量级环境

 

这是一个有趣的，但或许又稍有争议的问题。Docker每一个容器只运行一个进程，所以，容器的资源需求一般不大。由于资源需求至关小，使用Docker的其余应用均可以变得比较轻量和灵活。

举个例子，使用Mac OS X做为主机操做系统进行开发，并使用Docker for Mac来提供Mac和Docker之间的过渡层。当Docker for Mac启动时，就已经完成了最长的启动时间。

当你引导容器配置时，一般发生在几秒钟，而不是像虚拟机须要几分钟（或更长）。不管是建立一个仍是多个容器，或者启动现有的容器，均可以在秒级完成。这和使用VirtualBox和Ansible建立或启动一个虚拟机所耗费的配置时间或启动时间进行比较，Docker启动和运行的要更快。

让咱们拿BusyBox作对比，BusyBox是一个微小的Linux发行版，只有5mb大，能够用它来构建虚拟机。通常使用BusyBox都是由于它比较轻量和灵活，但考虑到虚拟机和Docker的工做方式，Docker仍然会更快地开始运行。

我确实作了一些普遍的归纳，但我并非要说VirtualBox、Vagrant、Ansible或任何其余虚拟机工具很差。我已经使用这些工具好久了，而且我会继续使用。

 

总结

 

虽然Docker仍然是一个新事物，但它不是一项新技术，它很早就被使用来构建，管理和部署应用程序。此外，它具备许多优势，使其成为构建开发环境的首选工具，能够大幅缩短新加入公司、部门或项目等开发人员熟悉项目的时间。

若是你尚未使用过Docker，我强烈推荐你去试一试。若是你想进行尝试，你能够从Codeship网站的"request a 14-day trial"着手，它将教会你如何减小开发成本以及快速构建应用程序。快去试一试Docker，看看它如何可以帮助你作得更好。

 

来源：http://www.youruncloud.com/docker/1_66.html