Docker Development Environment (DDE Part 1)

Introduction

The goal of this series of posts is to give an overview of different development environments and how to setup a development environment using Docker.

This environment will consist of the following:

By the end of this series, you should also have a better understanding of how to setup your own Docker-based development environment and how to modify an existing one to meet your needs.

Development Environments

Local Machine

Getting up and running with a PHP, Apache and MySQL development environment is easy with applications like WAMP, XAMPP, or MAMP. You just download one of those applications, install it and you’re up and running. This setup is great when learning web development with PHP and want to get started quickly.

But, what if you want to want to develop using Ruby or Java? And, you want to experiment with different databases like MariaDB, PostgreSQL, or MongoDB? Then, of course, you want to use Composer, NPM, Gulp and Git. Pretty soon your local computer is a mess. The development environment quickly becomes hard to clean up, difficult to maintain, and, if something goes wrong or you need to work on an old project again, difficult to restore.

The Good

  • Setup is easy.
  • Easy to understand for novices.

The Bad

  • Difficult to maintain.
  • Difficult to restore.
  • Not good for teams:  Since each development environment is unique to each developer’s computer, you quickly start to hear, “Well, it works on my machine.”

Virtualbox and Vagrant

With Virtualbox (or VMware) and Vagrant, it is possible to run entire operating systems in a virtualized environment that is independent of the host system. By using a virtualized environment, a development environment can be setup to be identical to production server’s environment.

Each environment has its own virtual machine and is configured using a Vagrantfile. The Vagrantfile tells Vagrant how to set up the virtual machine and what scripts need to be run in order to provision the environment.

The Good

  • Relatively easy to understand and get up and running.
  • Each virtualized server can have its own configuration.
  • Can run on various host machines that are running different operating systems.
  • Scripts can be stored in a repository and shared so developers can have the same development environments.
  • Good online resources.

The Bad

  • Each virtual machine includes your application, all of its dependencies, all of its libraries, and the entire guest operating system.
  • Can be resource intensive in terms of CPU, RAM and disk space.
  • Bringing up new virtualized servers can be slow.

Docker

Docker uses “containers” which include your application and all of its dependencies, but share the operating system with other containers. These containers run as isolated processes on the host operating system but are not tied to any specific infrastructure. This means they can run on any computer.

Docker containers are modular and scalable. Therefore, you can break your application’s functionality out into separate containers. For example, you can have your NGINX web server running in one container and your MySQL database running in another container. Then, if you wanted to change the database to MariaDB, you could easily create and run a MariaDB container and connect to it.

Because there are many, many articles about Docker, we are not going to talk about the fundamental concepts of Docker. For a good Docker introduction, please read A Beginner-Friendly Introduction to Containers, VMs and Docker.

The Good

  • Uses less CPU, RAM, and, potentially, less disk space.
  • New servers can be created quickly:  Once a container is built, bringing up a new one can usually be run in seconds.
  • Modular and Scalable.
  • Can run on various host machines that are running different operating systems.
  • Scripts can be stored in a repository and shared so developers can have the same development environments.
  • Good online resources (i.e. Docker Hub).

The Bad

  • More difficult to understand at first.

Next Steps

To prepare for the next post in the series:

One thought on “Docker Development Environment (DDE Part 1)

Leave a Reply

Your email address will not be published. Required fields are marked *