The –memory-reservation flag sets a soft limit for memory reservation. It doesn’t prevent the container from using more memory if it’s available, but it ensures the container is guaranteed at least that amount. This is different from –memory, which sets a hard limit, and –memory-swap, which controls swap usage.

Docker’s build process only has access to files within the specified build context (typically the directory containing the Dockerfile). If a file referenced in a COPY instruction exists on the developer’s machine but is outside this context directory (e.g., in a parent directory or a completely different location), the build will fail because the Docker daemon cannot access it.

A user-defined bridge network provides automatic DNS resolution between containers by container name. By placing both containers on the same user-defined bridge, the frontend can connect to the database using the hostname ‘db’. This network is isolated by default, so the containers are not exposed to the public internet unless specific ports are published to the host.

The `docker stats` command provides a live, updating stream of a container’s resource usage statistics, including CPU, memory, and network I/O. It’s the most direct and real-time way to see if a container is hitting or exceeding its memory limits. `docker inspect` provides a static snapshot of configuration, `docker top` shows processes, and `docker logs` shows output, but none give the immediate resource utilization view of `docker stats`.

This order leverages Docker’s layer caching effectively. It first copies the dependency file (`requirements.txt`) and runs the install command. This layer will only be re-executed if `requirements.txt` changes. Finally, it copies the application code. A change only to `app.py` will not trigger a re-run of the expensive `pip install` step, making builds faster. Copying everything at once (COPY . .) would invalidate the cache for the RUN instruction on any file change.

The core security principle is to run containers with the least privileges necessary. A process running as root inside a container, if it escapes the container’s namespace isolation due to a kernel or runtime vulnerability, would have root privileges on the host operating system. Using a non-root user inside the container significantly reduces the potential impact of such a breakout.

`docker run –rm` creates a new container from the specified image (`nginx:alpine`), executes the given command (`nginx -v`), and then automatically removes the container (`–rm`) after it exits. This is ideal for running one-off diagnostic or informational commands. `docker exec` requires a running container, and the other options are not valid for this use case.

The `–cpus` flag is the simplest way to specify the maximum amount of CPU resources a container can use. Setting `–cpus=”0.5″` means the container will be limited to using at most 50% of a single CPU core’s processing time. `–cpu-shares` sets a relative weight, not a hard limit. `–cpuset-cpus` pins a container to specific CPU cores, and `–cpu-period` is a lower-level flag typically used with `–cpu-quota`.

The `:ro` (read-only) option in a bind mount or volume definition applies to the mount point *inside the container*. It means the container’s processes can read from `/data` but cannot write to or modify it. This is a valuable security and data integrity measure for mounts that contain configuration, libraries, or other static data.

The –memory-reservation flag sets a soft limit for memory reservation. It doesn’t prevent the container from using more memory if it’s available, but it ensures the container is guaranteed at least that amount. This is different from –memory, which sets a hard limit, and –memory-swap, which controls swap usage.0