Docker易伸缩，Container越来越大，各种版本的冲突不断，安装包管理器是怎么处理的，如果还在为这些头疼，还在有这些疑问，可以了解一个小工具——Nix Docker是作为一个可以容易伸缩应用的工具而开始的，一般会被用作SaaS平台的建设（Docker是dotCloud的一部分，一个提供PaaS服务的平台）。 今天Docker经常被用于分配应用程序，而不是仅仅易于扩展，如果你只是在开发环境下用Docker，只是用它来复制你的开发环境，那你很有可能没有用到Docker的易扩展性。
糟糕的软件分配 Docker经常被用在分配应用程序上，因为现在分配应用程序是一件很糟糕的事情。先让我们看看日常我们能接触到的包管理器：yum、apt-get、npm、composer、gem、cabal等等。每一种语言的生态里都有自己的包管理器。基本上这些包管理器都做着同样的事情：解决依赖性确保应用程序可用。一般意味着要下载二进制文件，将其放在PATH，亦或者下载JavaScript源码使之可用于正在运行的环境中。 许多包管理器把安装包存在一个全局可变的目录下。例如 /usr/local/bin。现在如果说我们有应用A，依赖于Ruby 1.8.1安装在了/usr/local/bin同时在PATH下可用。假如我们现在要安装不同的应用B，其需要依赖于Ruby 2.2.1 ，因此我们得去升级Ruby。那么现在应用A因为其不能兼容新的Ruby版本就要被破坏了。即因为安装B我们不得不破坏A。换句话说就是安装包是有副作用的。这是由于全局可变的目录。
由于这些副作用你不能仅仅考虑你安装的东西了。你不得不去担忧会破坏你现有的设置。当然这其实也就是容器的可贵之处：你可随意实验同时重启容器，就像你可以只运送蛋糕，而不是配方，来避免那些副作用。这也意味着这些东西我们只要运行就能立即工作。并没有那些因为依赖产生的错误。 不好的一面就是容器体积会越来越大。意味着部署会越来越慢变成一个更慢的工具。容器通常包含着整个系统。想想看：你运行的操作系统仅仅是运行着自己的操作系统。虽然看起来不是很好，但是有副作用也不是什么好的做法。 欢迎来到未来：Nix Nix是一个打破全局可变目录的包管理器，引用Nix网站的一段话：
让我们回顾一下刚才应用A和B的例子。Nix可以说“A只需要Ruby 1.8.1”同时“B只需要Ruby 2.2.1”。Nix可以让应用程序运行在特定的应用环境里。就像是A在他的PATH中有Ruby 1.8.1，B在他的PATH中有Ruby 2.2.1 。 在Nix的管理下安装包将不再有所谓的副作用。两个不同的Ruby可以同时运行，是因为这里有一个典型的包管理意义上的全局目录（使用nix-env，https://nixos.org/nix/manual/#sec-nix-env。但是这是用户，而不是应用程序。）。这个特有的功能将不断的往全局目录里边塞东西。但是Nix并没有添加其到PATH中。要使用的话得明确的告诉Nix，不然包还是不可用的。 因为Nix是免费的没有副作用，你不需要容器来获得可重复的构建。Nix去除包管理的缺点，从而取代了现在Docker的作用。当你可以用Nix更换整个容器时，你不需要第二次来更换操作系统与您的容器。
有一些情况，其中容器是有意义的。前面已经说了用Docker扩展软件很容易。但大多数Docker使用者不拥有这些类型的问题。他们赋予Docker一种“它只是工作”的感觉。 Docker和Nix并不互相违背。您可以使用Nix来构建你的Docker镜像。现在，你的开发人员可以运行软件，而无需使用Docker，因为他们可以得到相同的设置作为其本地机器上运行，而生产安装使用Docker，方便的缩放的容器。 小贴士 Docker是用于伸缩的，但被滥用来分发可重复的构建。其原因是：包管理器因为这会导致副作用可变全局状态不可预测的。使用像Nix一个很好的包管理器可重复建立你的软件，你最有可能不需要Docker了。一个好的包管理器可以让你任意玩却不破坏环境，就像容器做的那样。 了解更多关于Nix在https://nixos.org/nix/about.html，你不会后悔的。 出处：dockone |
