Week 14: Container Orchestration and Infrastructure as Code Flashcards
(28 cards)
How does a Dockerfile define the steps to build an image? What role do commands like run, copy, and entrypoint play?
A Dockerfile is an imperative script that lists each build instruction in order, creating a new layer per instruction.
RUN executes shell commands (e.g., install packages) in its own layer.
COPY brings files or directories from the build context into a specified path inside the image.
ENTRYPOINT configures the default executable (and arguments) for containers launched from the image.
What is the purpose of multi-stage Docker builds? How do they reduce final image size and complexity?
Multi-stage builds use multiple FROM blocks to separate build-time dependencies from runtime artifacts.
You compile or assemble in earlier “builder” stages, then COPY –from only the necessary outputs into a minimal base image.
This eliminates intermediate tools and libraries from the final image, dramatically shrinking its size (e.g., ~4 MB vs. ~200 MB).
How do image registries and full namespace formatting enable container distribution and deployment?
Public/private registries (e.g., Docker Hub, ECR, ACR, Artifactory) store and distribute images.
A fully qualified image name uses the format <registry>/<org-or-user>/<image-name>:<tag>, ensuring unambiguous pulls and pushes across environments.</tag></image-name></org-or-user></registry>
How does Docker Swarm enable declarative service deployment and container orchestration across distributed nodes?
Swarm services use a declarative model: you specify the desired state (image, replica count, exposed ports), and the Swarm manager maintains that state across all nodes.
Behind the scenes, the manager schedules tasks to match your declared configuration, automatically handling failures and rescheduling as needed.
What is the difference between replicated and global service tasks in Swarm?
Replicated mode runs a specified number of task instances spread over the cluster.
Global mode runs exactly one task on every eligible node, ensuring uniform service presence.
What are the lifecycle stages of Swarm tasks? How does the manager node coordinate with worker nodes for scheduling?
Task states progress through NEW → PENDING → (assigned to node) → RUNNING → COMPLETE (or FAILED).
When you run docker service create, the request hits a manager node, which evaluates cluster capacity and assigns tasks to specific workers according to scheduling policies.
What types of Docker network drivers exist, and how do they support various networking use cases?
bridge: Default single‑host network for container‑to‑container communication.
host: Shares the host’s network namespace (no isolation).
overlay: Multi‑host virtual network spanning swarm nodes.
macvlan: Assigns containers their own MAC addresses on the local LAN.
none: Disables networking for the container.
How does the overlay network driver enable communication across multiple Docker hosts, and what is its role in Swarm mode?
Overlay sits atop host networks, encapsulating and routing packets between daemons so containers on different hosts appear on the same L2 network.
In Swarm, the ingress overlay handles service publish/routing mesh traffic, while user‑defined overlays carry application data among service tasks.
What features are enabled by user-defined overlay networks?
Automatic service‑to‑service DNS resolution within the network.
Built‑in encryption of control traffic; optional AES‑GCM encryption for application data via –opt encrypted.
Custom subnet and gateway settings for network isolation and IP management.
How does Docker’s built-in DNS facilitate service discovery across user-defined bridge and overlay networks?
Each user‑defined bridge or overlay network runs an embedded DNS server that resolves service names to their virtual IPs. You simply connect to the service name (e.g. web) to reach a load‑balanced endpoint; for task‑level endpoints you can lookup tasks.<service‑name>.
Explain how Docker assigns a virtual IP and what its purpose is.
When you create a Swarm service, Docker immediately allocates a virtual IP (VIP) on the service’s network. DNS queries for the service return this VIP, which acts as a single, stable entry point. All traffic sent to the VIP is then distributed across the healthy task containers.
What does the internal service-to-service communication do?
Internal service‑to‑service communication uses the built‑in DNS and VIP to transparently route and load‑balance requests from one service to another. This is automatically enabled for any Swarm service, ensuring calls go only to healthy containers.
What is the role of the Docker Swarm routing mesh? How does it enable published ports to be accessed from any node in the swarm?
The routing mesh provides a built‑in load balancer for Swarm services publishing ports. When you publish a port on a service, the mesh makes that port available on every node in the cluster—connections to the port on any node are transparently forwarded to a node running the service task.
How do different endpoint modes (virtual IP vs DNS round-robin) affect external load balancing strategies?
VIP (default): Docker assigns a single Virtual IP for the service and uses the routing mesh to distribute traffic automatically. External LBs only need to target any node on the published port.
DNSRR: Docker returns a list of task IPs instead of a VIP. There’s no mesh; clients or external load balancers must resolve the service name to all task IPs and balance across them themselves.
What are Docker volumes, and how do they persist container data beyond the container lifecycle?
Docker volumes are a persistent storage abstraction managed by Docker rather than the container’s own UnionFS layers.
Data written to a volume is stored on the Docker host (by default under /var/lib/docker/volumes/) and remains intact even after the container is removed.
Volumes can be created (docker volume create), listed, inspected, and mounted into containers using –mount or -v, enabling data sharing across containers and access from the host.
How can volume drivers and options be configured for advanced storage solutions?
When creating a volume, you can specify a driver (–driver) and any number of options (–opt) to tailor storage behavior.
The local driver supports bind mounts and NFS (via type=nfs, device, o= opts), while third‑party drivers like REX-Ray, CloudStor, or vieux/sshfs enable remote, cloud‑backed, or encrypted volumes.
Driver options can include remote host addresses, export paths, encryption flags, and filesystem parameters to integrate Docker volumes with external storage systems.
What is the difference between Docker configs and secrets?
Secrets are encrypted at rest and stored in the Swarm’s Raft store; they’re only available to Swarm services and are mounted at runtime into an in‑memory filesystem (e.g. /run/secrets/<name>). Configs are likewise only for Swarm services but are not encrypted at rest—they’re mounted directly into the container’s filesystem and persist as files rather than in RAM.</name>
What CLI commands are used to create, inspect, list, and remove?
Secrets: docker secret create, docker secret inspect, docker secret ls, docker secret rm
Configs: docker config create, docker config inspect, docker config ls, docker config rm
What is the difference between imperative and declarative approaches?
Imperative: you script each exact command to reach a goal (e.g., docker network create …, docker container create …).
Declarative: you describe the desired end state and let the tool compute the necessary steps (e.g., a YAML Compose file listing services, networks, volumes).
What is the purpose of Docker Compose? What are the differences in the version types?
Docker Compose is Docker’s primary declarative tool for defining and running multi‑container applications via a YAML file (docker‑compose.yml).
Version1: single‑host only; no support for volumes, networks, or build args.
Version2: adds volumes, networks, build, and startup-order (depends_on).
Version3: aligns single‑host Compose with Swarm stacks; adds secrets support.
How does the Compose specification formalize elements like services, networks, and secrets?
The Compose spec defines a uniform application model specifying:
services (containers and their settings)
networks (user‑defined connection topologies)
volumes (persistent data stores)
configs and secrets (Swarm‑only file and secret management)
This formal spec ensures consistency across single‑host Compose and Swarm stack deployments.
What is the 3-tier web architecture, and how is it implemented in Docker Swarm?
The 3‑tier architecture splits an application into presentation (frontend), logic (application), and data (backend) layers. In Swarm it’s realized as a single stack defining each tier as a separate service—attached to overlay networks named front‑tier, application‑tier, and back‑tier—so that each layer runs in its own logical network segment.
What are the different services provided, and how are they configured?
frontend: web‑app image, 3 replicas, publishes port 443→8043, on front‑tier & application‑tier.
application: application‑logic image, 4 replicas, built with args, on application‑tier & back‑tier.
cache: memcached:1.6, 3 replicas, CPU/memory limits & reservations, on back‑tier.
backend: mysql:8.0 image, restart on failure, uses mysql-password secret for creds, mounts db-data volume, on back‑tier.
How are HAProxy, replica services, secrets, configs, and overlay networks used?
HAProxy: delivered as a Docker config (httpd‑config) and injected into the frontend for request routing.
Replica services: ensure HA by running multiple instances (frontend 3, app 4, cache 3).
Secrets: TLS cert (server‑certificate) and DB password (mysql‑password) mounted at runtime under /run/secrets.
Configs: external config objects manage proxy/web server settings.
Overlay networks: user‑defined multi‑host networks (front‑tier, application‑tier, back‑tier) isolate tiers and enable cross‑node container communication.
