Containers, and DevOps
What this domain tests
Containers, and DevOps tests how software is packaged and shipped: Docker images and layers, Kubernetes objects on IBM Cloud Kubernetes Service or OpenShift, CI/CD pipelines, infrastructure as code, and the observability that tells you a release is healthy.
Core rules and concepts
- An image is a stack of immutable layers built from a Dockerfile; a container is a running instance of that image. Registries (Docker Hub, IBM Cloud Container Registry) store and distribute images.
- Containers share the host kernel and start in seconds; virtual machines each run a guest OS and are heavier.
- Kubernetes: a Pod is the smallest deployable unit; a Deployment manages replicas and rolling updates; a Service gives pods a stable DNS name and virtual IP; ConfigMaps and Secrets inject configuration.
kubectl get,describeandlogsare the first three debugging commands.CrashLoopBackOffmeans the container keeps exiting - read its logs.- A pipeline builds, tests, scans, pushes the image, then deploys. Blue-green and canary releases limit blast radius; Helm and Terraform make environments reproducible.
- Container filesystems are ephemeral: anything you must keep goes in a volume or an external service.
Worked example
A Dockerfile does COPY . . then RUN npm install, and every one-line code change rebuilds all dependencies. Reasoning: a layer's cache is invalidated whenever the files it copies change, and COPY . . touches everything. Reorder to COPY package*.json ./, RUN npm install, then COPY . .. Now the dependency layer stays cached until the manifest changes, and a .dockerignore keeps node_modules and build output out of the build context so the copy stays small.
Traps that cost marks
- Writing uploads or logs to the container filesystem and losing them on restart.
- Deploying with the
latesttag, so you cannot tell which build is running. - Reaching pods by pod IP instead of through a Service.
- Using
kubectl createin a pipeline and breaking on the second run instead ofapply.