52.35 Docker

#DevOps #MLOps

VM vs Container

VMs have their own OS. Therefore each VM can be in GBs.
Therefore, VMs will take more time to boot up.
On the other hand containers share the OS and only have their own binaries/libraries with a shared container runtime.
Which causes the images lightweight and the boot time faster.
Each VM is a node and there are one or more containers are inside a node. These are managed by orchastrators like k8s. Nomad from Hashicorp and Docker Swarm are two other orchastrators.

Note: There is much more nuance to "performance" than this chart can capture. A VM or container doesn't inherently sacrifice much performance relative to the bare metal it runs on, but being able to have more control over things like connected storage, physical proximity of the system relative to others it communicates with, specific hardware accelerators, etc... do enable performance tuning.

Three fundamental technologies of container

Namespaces
Control groups (Cgroups)
Union Filesystem

Docker Desktop Architecture

|800

Building Container Images

General principles to build Docker image

Optimization	Security	Build Speed	Clarity
Pin specific versions	✅	✅	✅
Base images (either major +minor OR SHA256 hash)		✅	✅
System Dependencies	✅		✅
Application Dependencies	✅		✅
Use small + secure base images	✅	✅
Protect the layer cache		✅	✅
Order commands by frequency of change		✅
COPY dependency requirements file → install deps → copy remaining source code		✅
Use cache mounts		✅
Use COPY --link		✅
Combine steps that are always linked (use heredocs to improve tidiness)		✅	✅
Be explicit	✅		✅
Set working directory with WORKDIR			✅
Indicate standard port with EXPOSE			✅
Set default environment variables with ENV	✅		✅
Avoid unnecessary files	✅	✅	✅
Use .dockerignore	✅	✅	✅
COPY specific files	✅	✅	✅
Use non-root USER	✅
Install only production dependencies	✅	✅	✅
Avoid leaking sensitive information	✅
Leverage multi-stage builds	✅	✅

A sample best Docker image

# syntax=docker/dockerfile:1.5

FROM node:19.4-bullseye AS build

# Specify working directory other than /
WORKDIR /usr/src/app

# Copy only files required to install
# dependencies (better layer caching)
COPY package*.json ./

# Use cache mount to speed up install of existing dependencies
RUN --mount=type=cache,target=/usr/src/app/.npm \
  npm set cache /usr/src/app/.npm && \
  npm install

COPY . .

RUN npm run build

# Use separate stage for deployable image
FROM nginxinc/nginx-unprivileged:1.23-alpine-perl

# Use COPY --link to avoid breaking cache if we change the second stage base image
COPY --link nginx.conf /etc/nginx/conf.d/default.conf

COPY --link --from=build usr/src/app/dist/ /usr/share/nginx/html

EXPOSE 8080

Additional Features

# syntax=docker/dockerfile:1.5
# escape=\
# ^ OPTIONAL "directives" (must be at top if used)

# THIS IS A COMMENT

# ARG is the only instruction that can come before FROM 
ARG BASE_IMAGE_TAG=19.4
# ARGs can be overriden at build time 
# > docker build --build-arg BASE_VERSION=19.3 .

FROM node:${BASE_IMAGE_TAG}

LABEL org.opencontainers.image.authors="[email protected]"

RUN echo "Hey Team 👋 (shell form)"
RUN ["echo", "Hey Team 👋 (exec form)"]

# Heredocs allow for specifying multiple commands to 
# be run within a single step, across multiple lines
# without lots of && and \
RUN <<EOF
apt update
apt install iputils-ping -y
EOF

# --mount allows for mounting additional files
# into the build context
# RUN --mount=type=bind ...
# RUN --mount=type=cache ...
# RUN --mount=type=ssh ...
RUN --mount=type=secret,id=secret.txt,dst=/container-secret.txt \
  echo "Run the command that requires access to the secret here"

# Available only at build time
# (Still in image metadata though...)
ARG BUILD_ARG=foo

# Available at build and run time
ENV ENV_VAR=bar

# Set the default working directory 
# Use the convention of your language/framework 
WORKDIR path/to/the/working/directory

ENTRYPOINT [ "echo", "Hey Team 👋 (entrypoint)" ]
CMD [ "+ (cmd)" ]

Container Registry

Running Containers

with Docker compose.

https://www.chainguard.dev/ provides secure docker images.

sneak and trivy to scan docker images.

Image Security
«What vulnerabilities exist in your image
that an attacker could exploit?"
• Keep attack surface area as small as possible:
• Use minimal base images (multi-stage builds are a key
enabler)
• Don't install things you don't need (don't install dev deps)
• Scan images!
• Use users with minimal permissions
• Keep sensitive info out of images
• Sign and verify images
• Use fixed image tags
• Either pin major.minor (allows patch fixes to be integrated)
• Pin specific image hash

Runtime Security
If an attacker successfully compromises a
container, what can they do? How difficult
will it be to move laterally?
• Docker daemon (dockerd)
• Start with --userns-remap option
(https://docs.docker.com/engine/security/userns-remap/
• Individual containers:
• Use read only filesystem if writes are not needed
• --cap-drop=all, then --cap-add anything you need
• Limit cpu and memory --cpus="0.5" --memory 1024m
• Use — security-opt
• seccomp profiles (https://docs.docker.com/engine/
security/seccomp/
• apparmor profiles (https://docs.docker.com/engine/
security/ apparmor/)

Developer Experience

• Easy/simple set up
• Iterate without needing to rebuild container image
• Bind mount code into container
• Use hot reloading utilities
• Include profiling and debugging tooling
• Debug specific compose overlay file
• Execute tests within container
• Test specific compose overlay file
• Continuous Integration
• Ephemeral environments

Resources

Sample App: https://github.com/sidpalas/devops-directive-docker-course/tree/main/05-example-web-application
Dockerfiles: https://github.com/sidpalas/devops-directive-docker-course/tree/main/06-building-container-images
Docker-Compose: https://github.com/sidpalas/devops-directive-docker-course/tree/main/11-development-workflow
Docker CI/CD Automation: https://github.com/BretFisher/docker-ci-automation

Resume from 2:24:43
Complete Docker Course - From BEGINNER to PRO! (Learn Containers) - YouTube