I have worked as a member of numerous teams, as a team leader, and project manager. In my 10 years as a developer, the one thing that has brought me to the brink of insanity more than any other is dealing with development environments. What version of which language are we going to use? Which version manager? Which version of the version manager? How are we managing dependencies? Where are they going? What database are we using? How are we running the server? The tests? Why isn’t this working? “I don’t know, it works for me…” Docker Docker is an excellent way to create consistent environments. If you aren’t already familiar with it, provides a perfect explanation of what it does: Docker’s own website Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run: code, runtime, system tools, system libraries — anything that can be installed on a server. This guarantees that the software will always run the same, regardless of its environment. Containers include the application and all of its dependencies — but share the kernel with other containers, running as isolated processes in user space on the host operating system. Docker containers are not tied to any specific infrastructure: they run on any computer, on any infrastructure, and in any cloud. This containerization makes it so easy to create application environments that don’t step on each others toes. Each environment has exactly what it needs to run that application in isolation. The only potential downside with Docker, is that to feel comfortable using it, you need to not only learn how Docker works, but you need to have some level of familiarity with Linux and DevOps concepts like containers, networking, etc. This isn’t a bad thing, but it’s not something everyone is going to be able to accomplish. With how much Docker has to offer, the idea of making it more accessible to developers of all skill levels is becoming quite popular. is new to the growing list of tools attempting to bring Docker to everyone. It’s designed with the app developer in mind, providing a simple way to leverage Docker to create consistent, reusable, environments, allowing app developers to focus on building applications rather than infrastructure. Nanobox Set up a simple dev environment Place , called a boxfile.yml, at the root of any project: a simple config file # boxfile.ymlrun.config:engine: nodejs # php, python, ruby, golang, elixir, etc. Now run ; This will use Docker to create an instant, isolated, dev environment for your project, and drop you into a console where your project code is mounted. nanobox run Set up a production environment The reality is that no environment is going to be that simple. If you’re planning on running anything significant, you’re going to need a lot more. The following example will provision an entire production level ruby on rails development environment (which can even be tested in a production setting with ). nanobox deploy dry-run Rinse and Repeat No matter how many machines you run your application on, the result will always be the same: a consistent development environment that . just works
