1 of 11

Using Docker For Frontend Development

2 of 11

What Is Docker?

Tool for building and running containerized environments
What is a container? How is it different than a VM?

An OS running on top of your existing host OS
Containers consume fewer resources than a VM
Use an isolated file system

3 of 11

Why use Docker In Development?

Ease of onboarding new team members
Consistency between members, and between dev and prod
Isolate dependencies from host environment
Declarative environment
More easily claim an error is not in your part of the stack
Collated logs from multiple processes

Why anyone should use docker in development?

To start with

*click*

Ease of onboarding new team members

Because Docker runs containers from shareable images and scripts, a new team member can get a dev environment running in minutes.
While working on a recent client they didn’t have useable mocked services and their backend. It was a distributed systems that required a minimum of 6 running processes to operate. They required outdated versions of Python & Node, so to run this in my host environment I’d have needed to downgrade, use a python virtual env and run all the processes manually, just work on the front end. It took the better part of a day for a new dev to get their environment configured. After switching to docker it took less than 20 minutes.
By the same token an existing dev member can delete and rebuild their dev environment, undoing any experimental changes they’ve done in minutes

While fast onboarding is great, maybe even more important is

*click*

Consistency:

reduce the number of times you hear (or end up saying) “works on my machine”
use an environment closer to what production runs, compared to mock services
On that client I’d just mentioned, another dev had told me their code worked on their machine

which was using their host environment for development.I’d asked them to try reproducing it in the dockerized environment.
A few minutes later the issue could be reproduced and the dev realized they had made some changes to their database which were likely masking the problem.

On another client, the difference in file name case sensitivity between MacOS & Linux was the root of an issue.

If we had been doing our testing in an environment more consistent with production we would’ve noticed immediately.

*click*

Isolate Dependencies:

Most useful in languages that often install dependencies globally, like Python or C.
Not as important for node since libraries are already isolated to a single project
but it makes it really easy to clean up your host when leaving a project.

*click*

Declarative environment:

Easily see and edit all the dependencies of your application in a consistent format

OS packages
Libraries
environment variables

Can see all the relevant environment at a glance

*click*

Refute that an error is in the frontend

I’m sure as front end devs we’re familiar with being the first to get blamed for what are ultimately issues in the backend.
Running a backend in development gets you convenient access to logs and code so you point out exactly what the issue is rather than play the blame game with another team.

*click*

Collated logs

If you’re working on a system with interprocess communication it can be a pain to have to collate logs from multiple files to trace the execution of a task
Dockers built in log collection can easily collate the logs from multiple containers, removing that problem in development

Some of these points, that last point in particular, was rather backend focused, so you might still be thinking:

*click*

4 of 11

Is Docker Really For Frontend Devs?

Very frequently don’t have access to good test environments

Security reasons
Inaccurate or missing mock services
User contention

Problems can arise in frontend work due to environments

Differing versions of Node
OS effects

“Is Docker really for frontend devs?”

You might say:

“I don’t need a local dev backend because we have mock services”

Or

“My client already has a shared testing backend”

*click*

But in my own experience I’ve never worked for a client who’s had mock services that good or a shared testing backend whose state was consistent

*click*

sometimes the client has security reasons for not letting devs access a fully detailed environment

*click*

or they have mock services but parts are missing or inaccurate

*click*

or you have a testing environment, but it’s shared with QA and frequently changing, altering the results of hands-on testing.

It’s often easier to convince a client to make their containerize their backend, than it is to convince them they need more comprehensive mock services

And even when you do have a decent backend, it can still be nice to do your development and testing through a container

*click*

At one point or another we’ve all ran into bugs from

*click*

a version of node on our host machine different than what the app needed

*click*

Like I mentioned on the last slide I’ve had an experience with OS effects causing bugs.

one inappropriate camelcase on a module import had our whole team confused why our tests were failing on the build server

*click*

Hopefully I’ve convinced a little bit that using docker may help your workflow, and now you’re asking:

*click*

5 of 11

What do I need to know to get started?

6 of 11

How To Use Docker In Development?�Dockerfiles

Dockerfiles define an image for containers to be built from
Dockerfiles specify:

Base image including an OS and possibly an application
Actions applied to the base image, customizing the environment
Default behaviour of the container when ran

Dockerfiles.

*click*

Dockerfiles specify an image that containers are created from. Images are the template for the actual functioning environments, which are the containers.

*click*

Dockerfiles specify:

*click*

The base image: images can inherit from other images

*click*

The actions that customize that base image, things like:

setting environment variables
running console commands (e.g installing packages)
copying files from the host into the image

In Dockerfiles you can also configure is:

*click*

The default behavior of the container when ran, things like;

default application to run when starting the container
mount points for volumes
ports to expose to other containers or the host

Even though you can define these runtime parameters as part of a dockerfile, I personally prefer to keep images all about the environment state.

Instead I define my runtime params using the next tool we’ll talk about.

But first lets take a quick look at a dockerfile:

*click*

7 of 11

How To Use Docker In Development?�Dockerfile

Example Dockerfile:

FROM ubuntu:latest

LABEL author="nils@bitovi.com"

RUN apt-get update

RUN apt-get install -y python python-pip wget

RUN pip install Flask

ADD hello.py /home/hello.py

WORKDIR /home

8 of 11

How To Use Docker In Development?

docker-compose

docker-compose is a CLI that runs containers via runtime configurations
Configurations are specified in a docker-compose.yml file
Offers full declarative control over runtime:

which services are dependencies of a given service
what host folders to mount into the service (e.g source code)
amount of logs to keep for a given service
working directory and default command when run

9 of 11

How To Use Docker In Development?

docker-compose.yml

Example docker-compose.yml:

version: '3'

services:

db:

image: postgres

web:

build: .

command: python manage.py runserver 0.0.0.0:8000

depends_on:

- db

volumes:

- .:/code

ports:

- "8000:8000"

10 of 11

Additional Resources

11 of 11

Questions?