Basics
Containerized app vs traditional VM
Docker Objects
- Image (Container Image): Similar to an ISO or DMG, it’s an executable package of software. Includes code, runtime, system tools, system libraries, settings, and instructions for creating a Docker container. Built from a Dockerfile.
- Container: Runnable instance of an Image. It’s the entire application, containerized and portable—isolated from other processes on the host machine (and from other containers unless specified). A container packages up all code and dependencies. Deployable locally, on VM, or on cloud.
File Formats
- Compose file: A YAML file defining services, networks, and volumes for a Docker application. Defines a multi-container application.
- Dockerfile: Text document that contains all commands needed to create an Image. Defines the steps needed to create the image and run it.
- When you change the Dockerfile and rebuild the image, only those layers which have changed are rebuilt. This is part of what makes images so lightweight, small, and fast, when compared to other virtualization technologies
Data, Storage, & Mount Types
Volume
- Managed within Docker (via Docker CLI commands and Docker API). Self-contained storage.
- Isolated from the Host; more secure because of this
- Can be shared among other containers
- Higher performance than bind mount
Bind
- Files and/or directories located externally on the host, but mounted into a container.
- Referenced by absolute path on the host
- Can’t use Docker CLI commands to directly manage bind mounts
Networking & Types/Drivers
The mechanism for connecting Docker containers with one another, or with non-docker workloads.
Bridge
- The default network driver. If you don’t specify a driver, this is the type of network you are creating. Bridge networks are usually used when your applications run in standalone containers that need to communicate. See bridge networks
- Best when you need multiple containers to communicate on the same Docker host.
Host
- For standalone containers, remove network isolation between the container and the Docker host, and use the host’s networking directly. See use the host network.
- Best when the network stack should not be isolated from the Docker host, but you want other aspects of the container to be isolated.
Overlay
- Overlay networks connect multiple Docker daemons together and enable swarm services to communicate with each other. You can also use overlay networks to facilitate communication between a swarm service and a standalone container, or between two standalone containers on different Docker daemons. This strategy removes the need to do OS-level routing between these containers. See overlay networks.
- Best when you need containers running on different Docker hosts to communicate, or when multiple applications work together using swarm services.
IPVLAN
- IPvlan networks give users total control over both IPv4 and IPv6 addressing. The VLAN driver builds on top of that in giving operators complete control of layer 2 VLAN tagging and even IPvlan L3 routing for users interested in underlay network integration. See IPvlan networks
MACVLAN
- Macvlan networks allow you to assign a MAC address to a container, making it appear as a physical device on your network. The Docker daemon routes traffic to containers by their MAC addresses. Using the
macvlandriver is sometimes the best choice when dealing with legacy applications that expect to be directly connected to the physical network, rather than routed through the Docker host’s network stack. See Macvlan networks - Best when you are migrating from a VM setup or need your containers to look like physical hosts on your network, each with a unique MAC address.
None
- For this container, disable all networking. Usually used in conjunction with a custom network driver.
noneis not available for swarm services. See disable container networking
Other Information & Charts
- Docker Hub: Repository of images. Basically the GitHub of Docker.
