The basic idea behind Docker is to build small independent deployable units of software (Containers) that run in the same predictable way, no matter where or how many times you deploy them. You don’t have to install and configure all software components yourself on a bunch of different servers, hoping no mistake has been made when setting everything up. Docker Containers have the ability to scale exceptionally well. Because setting up the whole infrastructure with commands, this approach is often referred to ‘infrastructure as code‘.

Advantages for Web Developers

Containers will (usually) help you to get your development environment set up much quicker, because they are pre-configured entities that can be created and moved faster than VMs.

They also help you to avoid App Conflicts because Containers can run separately and isolated from each other, having different versions of frameworks or tools.

With Containers you can get consistent environments. For example you can expect that your Development environment runs pretty much the same way as your staging or production environment.

All of that allows you to generally ship software faster in a more reliant, consistent and predictable way.

Basic terminology

Images and containers

Docker Container Images (or simply Images) are the read-only blueprints/templates composed of layered filesystems that are used to share common files. Images contain your application code along with the runtime, library dependencies, static assets and configuration. Out of an image you build isolated Containers that you deploy and run on servers that have Docker Engine installed. Again, images are not deployed and executed, it is Containers built from Images that are deployed and run.

Containers can be started, stopped, moved and deleted. A Docker Container is simply another process on your machine that has been isolated from all other processes on the host machine and uses its own isolated file system which is provided by the image. They usually only exist during runtime but can also be persisted back to an image. They start and stop much faster than Virtual machines. Docker Images are portable between systems and allow snapshots and versioning.

Docker Hub

There are hundreds of thousands public Images on Docker Hub for all kinds of pre-configured software, for example nginx, NodeJs and many more. Even trimmed down, security-optimized Images of a certain software product. Updating to a new nginx version means using an updated image version.

buildpacks and Dockerfile

You want to eventually create an image yourself (most probably based on another image) that contains your application files and its dependencies. There are two approaches to build an image, straight from the source code via a tool called buildpacks or via a script called Dockerfile that contains statements about which base Image to use, which files to copy over and which commands to run once a Container starts.

Image repository and registry

A Docker repository is where you can store one or more versions of a specific Docker image, just like GitHub is a repository for your code.

A registry stores a collection of repositories. You could say a registry has many repositories and a repository has many different versions of the same image which are individually versioned with tags.

Cluster, Node, Stack, Swarm and service

A Swarm is a group of machines that are running Docker and that are joined into a cluster. The machines in a swarm can be physical or virtual. After joining a swarm, a machine is referred to as a node. A Stack is a group of interrelated services that share dependencies, and can be orchestrated and scaled together.

A docker Service is one or more containers with the same configuration running under Docker’s swarm mode. It’s similar to docker run in that you spin up a container. The difference is that you now have orchestration.

Docker Containers vs. Virtual Machines

Virtual machines take more space and add much more redundant things than containers. For example Virtual machines require their own Guest OS.