But First, Why Containers?

Developing and maintaining software for the cloud has traditionally been a major challenge. We’ve gone from shared hosting, where everything is just installed onto a server at the top level, to Virtual Machines (VMs), where we take a beefy server and chop it up (via software) into smaller, virtualized computers that have a significant amount of isolation built into them, allowing for sharing a server without ever knowing anyone else is running on the same physical machine. Containers are the next step in this evolution.

A container, at its core, is really just a process with some restrictions on it. It runs on the host, but uses features of the Linux kernel to isolate it so that it appears to be the only process running on the machine (among some other isolations, such as network). This is advantageous for a few reasons. First, we get all the benefits of using the host machine — not much overhead, and the container is able to run on the real hardware instead of jumping through virtualized hoops. Second, we get many, if not all of the benefits of virtualization — isolated processes, resource caps, and a sterile, reproducible environment for our applications.

Another premier feature of using containers is the ability to run them anywhere regardless of the underlying OS, packages, versions, or anything else for that matter, whether it’s on your local machine or in the cloud with a platform like Cycle. So this article will not make any assumptions other than:

The system has Docker installed. You’re able to pull a repo from Github.

With Docker, you could buy a computer, install git, a code editor and immediately have a dev environment capable of working with any language.

That's pretty great, so let’s dive right in.

Getting the files

Pull this repo into a new directory (doesn’t matter what it’s named).

This repo is the same collection of files you receive when running the following command, plus a few QOL add-ins:

npx create-react-app appname

There is a file named devscript included in the repo. To execute this file enter the following into your command line from the applications root directory, ./devscript.sh . This script builds an image named firstreactapp using Dockerfile.dev . It also runs the image with a bind mount on the applications src directory, allowing for hot reloading*. Take a look inside the script if you want to see the commands I’m running to automate these steps.

* Hot reloading means your application reloads after you make changes to the source without needing to rebuild the image and restart the container.

Hot reload is set up on the src folder, as that's what I make changes to the most during dev. If you make changes to other files, outside of src — just stop the container that’s running with ctrl + c and run the devscript again to rebuild the image and restart the container.