Tutorials covering the tools that developers use every day — version control, editors, build systems, package managers, containers, and the command-line utilities that make work faster. Each chapter is standalone, built around real examples and verified commands.
A quick-reference for npm commands, configuration, and dependency resolution. Organized for lookup, not for reading. Core Commands Command Purpose npm init Create package.json interactively npm init -y Create with defaults npm install Install all dependencies npm install <pkg> Install and save to dependencies npm install <pkg>@<ver> Install specific version npm install -D <pkg> Install as…
A volume driver is the mechanism that determines where a volume’s data actually lives. The default driver stores it on the local host filesystem. Other drivers store it on an NFS server, a cloud block device, or a distributed storage cluster. The driver is specified when the volume is created, and it determines the volume’s…
A container’s root filesystem is writable by default. The application can write to any directory that its user has permission to write to, including the directories where the application’s own binaries and configuration files live. This is convenient for development and for applications that assume they can write anywhere. It is also a security liability….
The storage driver is the layer between a container’s filesystem and the host’s disk. It determines how image layers are stacked, how writes are handled, and how much space and inode overhead the container incurs. Docker supports several drivers, but overlay2 is the default on most Linux distributions and the one most LFCS and Docker…
A container’s network is not one thing. It is a namespace, a set of interfaces, a routing table, and a driver that constructs all three. The driver determines whether the container is isolated, shares the host’s network, or appears as a physical device on the LAN. The choice of driver is the choice of how…
Two containers on the same host cannot talk to each other by name unless they are on a user-defined network. The default bridge network, the one Docker creates automatically at installation, does not provide DNS resolution between containers. This is not a bug; it is a deliberate limitation, kept for backward compatibility with the legacy…
The host network driver removes the network namespace from the container. The container shares the host’s network stack directly, with the host’s IP address, the host’s interfaces, and the host’s ports. There is no NAT, no virtual bridge, and no port mapping. The container’s application binds to the host’s port directly, and the performance is…
A bridge network puts the container behind a NAT. The container has its own IP, but it is on a virtual subnet, and the outside world reaches it only through published ports. Some applications do not accept this. A legacy application that uses broadcast discovery, a monitoring tool that needs to see all traffic, a…
A published port is a promise. The container’s application listens on a port inside its own network namespace, and the host promises that a connection to a specific host port will reach it. The mechanism behind that promise is a set of iptables rules in the host’s NAT table, a connection-tracking system, and—for the traffic…
A running container is not necessarily a working container. The main process can be alive while the application inside it is wedged — a web server stuck in an infinite loop, a database accepting connections but unable to serve queries, a worker that has lost its connection to the queue. Docker’s HEALTHCHECK instruction exists to…