Docker Containers for Local Development

This repo contains docker containers I use mostly for JavaScript development but they can be used for just about anything. Below is a breakdown of how I make use of most of them. This should give you an idea of how I try to implement DevOps even on my local machine.

Firstly, here's a list of things you'll need (I may be biased towards Linux as I use Manjaro as my daily driver):

1. Docker: docker and docker-compose are necessary (I mean, docker containers, right? 🤷‍♂️)
2. A local DNS server such as dnsmasq (Optional)
3. An SSL certificate generator such as mkcert (Optional)

Features

• Configuration
  • Environment Variables
  • Docker Compose File
  • Networks External to Docker Compose Project
• dnsmasq
• mkcert
  • Usage in Mobile Development
  • Usage with Node.js
• Traefik
  • Setting Up Traefik
  • Using Traefik to Proxy to Services
• Managing Services

Configuration

Environment Variables

Take time to go through the .env.example file to see the default values and make your own copy according to your environment (dev or prod).

cp .env.example .env

Docker Compose File

Copy the docker-compose.example.yml to docker-compose.yml file so that you have a good starting point for your containers. This file works hand in hand with the .env file so you might want to run through both and get an idea of how they both work.

cp docker-compose.example.yml docker-compose.yml

Networks External to Docker Compose Project

This docker-compose.yml configuration makes use of two networks external to the docker-compose project, namely, dockernet and backdocker. You'll have to create two docker networks. You can use any IP range you choose but keep in mind that you'll have to update IP addresses in the docker-compose.yml configuration. An example:

docker network create --subnet 192.168.90.0/24 --gateway 192.168.90.1 backdocker

docker network create --subnet 192.168.0.0/24 --gateway 192.168.0.1 dockernet

dnsmasq

dnsmasq makes it easier to have services and projects running under an optional domain name on your local machines. It's pretty much like having an automated /etc/hosts file. Once you have a domain set up, you don't need to worry about adding subdomains. You can read about how to set it up here.

The domain I use for my local development is usually local.test as can be seen in my dnsmasq.conf config file.

After completing the configurations, run the following commands:

  dnsmasq --test # to confirm the syntax of the config file

  sudo systemctl enable dnsmasq # to enable the dnsmasq service

  sudo systemctl start dnsmasq # to start the dnsmasq service (or restart if it was running before)

You may also need to make changes to your resolvconf.conf so that you are able to browse external websites. You can check out this gist for an example, but for brevity, the lines to change are shown below:

# Use the local name server
name_servers="127.0.0.1 1.1.1.1 8.8.8.8"

# Write out dnsmasq extended configuration and resolv files
dnsmasq_conf=/etc/dnsmasq-conf.conf
dnsmasq_resolv=/etc/dnsmasq-resolv.conf

After making said changes run the following command and restart the dnsmasq service:

sudo resolvconf -u # updates resolv subdirectories

And that's it, as long as you have a service running at port 80, the domain local.test will resolve to it without needing to touch your hosts file. For services running at other ports, keep reading! 😉

mkcert

mkcert is an awesome tool I use for local SSL development. According to the developers of the tool:

mkcert is a simple tool for making locally-trusted development certificates. It requires no configuration.

Installation, and instructions on setting up can be found at this GitHub repository.

I created a bash script to help with using mkcert once you have it installed for the sole purpose of creating SSL certificates. It's available in this repository here. The script itself is heavily commented and can be used to install and create a domain certificate all at once.

I'd encourage you to get familiar with the script and ultimately read through the mkcert repository documentation to have a thorough understanding of how to utilize this tool. I will, however, show you how I use it below.

mkcert -install # to create a new local CA

To create certificates that I'll use with my Traefik container, I run the following command from the root of this repository.

./traefik/certs/generate.sh "*.local.test"

The reason I use a wildcard domain is because of how I use service names as subdomains. Using a wildcard certificate will allow the creation of one certificate for a number of subdomains.

Usage in Mobile Development

When creating websites that should be mobile-first, I like to have the experience of entering qualified domain names. But for me to implement SSL, and to have the certificates trusted on my mobile device(s), I have to have the root CA installed on my device(s) as well. It is the rootCA.pem file in the folder printer by the command mkcert -CAROOT. The developers of mkcert explained it rather well in their documentation. In a nutshell:

On iOS, you can either use AirDrop, email the CA to yourself, or serve it from an HTTP server. After installing it, you must enable full trust in it. For Android, you will have to install the CA and then enable user roots in the development build of your app.

Usage with Node.js

As explained by mkcert developers, you will have to set the NODE_EXTRA_CA_CERTS environment variable. I have the following command appended to my ~/.bash_aliases file so that it runs in every terminal:

export NODE_EXTRA_CA_CERTS="$(mkcert -CAROOT)/rootCA.pem"

Now, onto the best part, the proxy server! 🤩

Traefik

I use Traefik in development and production, as well. I find it easier to transition projects that way since the only difference between environments is just a configuration file. Additionally, I only ever have to expose port 80 or port 443 to the internet for any of the services I have, whether in production, or development.

Setting Up Traefik

1. Within the traefik directory, there is a .env.example file that will need to be copied to a .env file similar to the overall configuration step. The only difference is that this .env is private to the Traefik container that will be created.
2. Depending on the environment, either the traefik.development.yaml or the traefik.production.yaml file will need to be copied to a traefik.yaml file. Of course, since we are looking at local development, we will go with the former. This is the configuration file for the Traefik container that will be created.

cp .env.example .env

cp traefik.development.yaml traefik.yaml

These are just starter defaults that can be customized to your whim. To get a better understanding of Traefik, you will do well to check their documentation on their website.

Using Traefik to Proxy to Services

Now that Traefik is set up, you can point it to the many services, containerized or not, running on your local machine. The SSL certificates you created earlier are already in the right directory for the Traefik service to use them. Their is a more detailed explanation in the traefik directory

Managing Services

To run a service, run the following command

docker-compose up -d serviceName

where the serviceName is the name of a service in the docker-compose.yml file under the services object.

To stop a container service:

docker-compose stop serviceName

To destroy container services:

docker-compose down