Docker &amp; Kubernetes

How Compose services reach each other by name

Services share a default network and the web app uses the database's service name as the hostname; Docker's embedded DNS resolves it to the container IP.

Docker Compose default networking

Compose creates one default user-defined bridge network for the project; all services join it and reach each other by service name via embedded DNS, isolated from other projects.

Manage startup order and readiness in Compose

Depends_on only orders start, not readiness; add a healthcheck to the DB and use depends_on with condition: service_healthy so the web app waits until the DB passes its health check.

Compose image directive versus build directive

Image pulls a prebuilt image from a registry; build builds from a local Dockerfile and context; use build for your own custom application code.

Bind mounts versus named volumes

A bind mount maps a host path into the container (great for live source in dev); a named volume is Docker-managed storage decoupled from the host layout (ideal for database data).

Structuring Compose files across environments

A base compose.yaml plus override files, the default override auto-merge, and explicit -f flags or extends per environment.

Optimizing Dockerfile layer caching

Order instructions least-to-most volatile, copy dependency manifests and install before copying source, and understand any changed layer busts all later layers.

Docker Compose profiles for optional services

Profiles tag services so they stay off by default, activate via --profile or COMPOSE_PROFILES, and unprofiled services always run.

Tag and push an image to a private registry

Authenticate with docker login, retag the image to include the registry host and repo path, then docker push that full reference.

Why :latest is a production anti-pattern

Latest is mutable so pods run different code, rollbacks and pull policy break, and you should use immutable version tags or digests.

Debugging ImagePullBackOff on a private registry

ImagePullSecrets reference a dockerconfigjson Secret on the pod or service account, kubelet uses it to authenticate, and you inspect events to isolate auth versus name versus network errors.

Three techniques to shrink a Docker image

Multi-stage builds to drop build tooling, smaller base images like slim or distroless, and fewer or cleaner layers plus dockerignore.

Manifest lists and multi-arch images

A manifest list maps platform descriptors to per-arch image manifests, the client picks by os and architecture, and pulls only that variant.

Vulnerability scanning as a deploy gate

Scan with Trivy or Clair, fail the build on high or critical severity above threshold, and enforce again at admission with signing and registry policies.

Reducing cross-region image pull costs

A per-region pull-through cache or geo-replicated registry serves pulls locally, cutting latency and egress, traded against consistency lag, storage cost, and cache management.

Node, Pod, and Container relationship

A Node is a machine, a Pod is the smallest deployable unit wrapping one or more containers that share network and storage, and the Pod abstraction enables co-location and lifecycle management.

Core control plane components

Api-server as the front door, etcd as state store, scheduler placing pods, and controller-manager running reconciliation loops, plus cloud-controller-manager.

Minimal objects to expose a stateless app

A Deployment to run and self-heal replicas plus a Service to give a stable endpoint, exposed externally via type LoadBalancer or NodePort, or an Ingress.

What happens after kubectl apply

Apiserver validates and persists to etcd, scheduler binds the Pod to a Node, kubelet pulls the image and starts the container via the runtime, status flows back.