Intermediate concepts in DevOps & Cloud, page 2
Docker Networking: How Containers Talk to Each Other
Docker gives each container its own isolated network, preventing port conflicts. Containers connect via networks, like bridge for local communication. For containers to find each other by name, you must use a user-defined bridge network; the default one…
Pull Requests: A Structured Conversation About Code
A Pull Request (PR) is a structured conversation about a proposed code change. It's used in team projects to review new features and fixes, ensuring quality and sharing knowledge. The footgun is treating PRs as a rubber-stamp approval instead of a real review.
Docker Build Cache: Don't Rebuild What Hasn't Changed
Docker's build cache is like a saved game for your image layers. It skips rebuilding if instructions and files haven't changed. A common footgun is an early COPY . . command, which can invalidate the cache for all subsequent steps on every code change.
Git Merge: Combining Development Histories
Git merge combines separate lines of development into one branch. It creates a special merge commit that ties the two histories together, preserving the context of each. Use it to integrate a feature branch into your main line.
The .dockerignore File: Keep Your Build Context Lean
.dockerignore is like .gitignore for your Docker build. It tells the daemon which files to exclude from the build context, preventing large or sensitive files from slowing your build and bloating your image. The footgun is forgetting it and sending everything.
Cloud Load Balancer: Your App's Traffic Cop
A cloud load balancer is a traffic cop for your servers, distributing requests across a pool of machines to prevent overload. It's essential for scaling apps and ensuring high availability.
Auto Scaling Groups: Elasticity and Self-Healing
An Auto Scaling Group (ASG) is like a thermostat for your servers, automatically adding or removing instances to match demand and replacing any that fail. Use it for web apps with variable traffic or services that need to self-heal from instance failures.
Git Rebase: Rewriting History for a Cleaner Timeline
Git rebase rewrites history by transplanting your commits onto a new base, creating a clean, linear project history instead of a merge bubble. It's used to catch a feature branch up with main. Never rebase a branch others are using; it rewrites history.
Git Tags: Immutable Milestones for Release History
A Git tag is a permanent bookmark on a commit, usually marking releases like v2.0. Annotated tags store author, date, and GPG signatures to anchor deploy pipelines.
AWS Reserved Instances: Commit to Compute, Save Big
Reserved Instances are like leasing a car instead of renting daily: commit to 1-3 years of compute for a steep discount. They're ideal for predictable, steady-state workloads. The footgun is buying inflexible Standard RIs when your needs might change.
User Data Scripts: Day-One Instance Configuration
User data scripts are your instance's "Day One" instructions, automatically running commands like package installs on first boot. Use it to set up a web server or install agents without manual SSH.
GitHub Flow: A Simple, Branch-Based Workflow
GitHub Flow is a simple workflow where main is always stable and new work happens on a feature branch. It's used for continuous delivery, from code to documentation.
SLO Burn Rate: Alerting on Budget Consumption
SLO burn rate measures how fast you're using your error budget. A burn rate of 2 means you're consuming budget twice as fast as allowed. It's used to trigger alerts for both fast outages and slow-burning problems to prevent SLO breaches.
Error Budget Burndown: Your Service's Reliability Fuel Gauge
An error budget burndown chart is a fuel gauge for your service's reliability. It shows how much 'allowable downtime' you've used, helping you decide when to ship features versus fix bugs. The footgun is ignoring a steep burn rate until it's too late.
Docker Compose Networking: How Services Talk to Each Other
Docker Compose puts your services on a private network, letting them communicate using service names as hostnames. This is how a 'web' container finds your 'db' container. The footgun is using localhost; always use the service name for inter-container calls.
Environment Variables in Docker Compose
Environment variables are the runtime knobs for your Docker Compose services, letting you pass configuration like API keys or database URLs without rebuilding your image. Use them to connect services or set feature flags.
Docker Compose: Control Startup with `depends_on`
depends_on controls service startup order in Docker Compose, ensuring a database starts before your app. The footgun: it only waits for the container to start, not for the application inside to be ready. Use healthcheck for true readiness.
Building Images with Docker Compose
Docker Compose builds images from a compose.yml file, turning a Dockerfile into a runnable service within a multi-container app. It's for local dev where you need a database and backend to start together. The footgun: up won't rebuild without --build.
Data Durability vs. Availability: Lost vs. Unreachable
Availability is "can I reach my data right now?" while durability is "will my data still exist tomorrow?". Cloud storage systems are designed for both, but they solve different problems: network outages vs. data corruption.
Static Analysis: Read Code, Don't Run It
Static analysis is like a spell checker for your code, catching errors before you run the program. It powers linters and security scanners in CI pipelines to find bugs and vulnerabilities. The footgun: it can't understand intent, leading to false positives.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles