Search
30 results for “devops”
Search results
DevOps Engineer Roadmap
From container networking and infrastructure as code through orchestration, delivery automation, and observability, the core path for a working DevOps engineer, linked into Cloud Tech by Victor topic references.
How does platform engineering differ from traditional DevOps or a shared infrastructure team?
Traditional DevOps distributes infrastructure responsibility to product teams ("you build it, you run it"), while a shared infrastructure team typically operates as a ticket-driven service, product teams request resources and wait. Platform engineering treats the internal platform itself as a product, with its own users (the engineers building on it) and a deliberate design goal: reduce cognitive load by providing paved, self-service paths for common needs, rather than either forcing every team to become infrastructure experts or making them wait on a queue. The platform team builds golden paths; product teams self-serve through them.
Bash Fundamentals
The scripting layer built on top of the shell - variables, conditionals, loops, and functions - and the quoting and exit-status habits that separate a script that looks right from one that fails safely.
CI/CD Pipelines
What continuous integration and continuous delivery actually automate, how a pipeline stage graph is structured, and why fast feedback loops matter more than pipeline complexity.
Cloud Cost Optimization
Why idle and over-provisioned resources, not raw usage, are where most cloud spend actually leaks, and the concrete levers (rightsizing, commitment discounts, autoscaling) that address it.
Docker Fundamentals
How images, containers, volumes, and networks fit together in Docker's runtime model, and the mental shift from "installing software" to "running a packaged image" that trips up newcomers.
Docker Networking
How Docker's bridge, host, and overlay network drivers work, how container DNS resolution happens, and the port-publishing model that trips up most beginners.
Git Fundamentals
How the working directory, staging area, and commit history actually relate to each other, and why understanding that three-stage model makes branching, rebasing, and undoing changes stop feeling arbitrary.
GitOps Principles
Why treating Git as the single source of truth for cluster state, instead of running kubectl/terraform apply by hand, changes how deployments, rollbacks, and audits actually work.
Kubernetes Fundamentals
How Pods, Deployments, and Services fit together, what the control loop actually does, and why Kubernetes networking confuses people coming straight from Docker Compose.
Linux Fundamentals
The core command-line building blocks - navigation, permissions, processes, networking, and services - that every other Linux topic on this site (filesystem hierarchy, storage, users, networking) assumes you already have.
Observability Fundamentals
How logs, metrics, and traces answer different questions, why "we have monitoring" isn't the same as being able to debug an incident, and the cardinality trap that breaks metrics systems.
Platform Engineering Fundamentals
What an internal developer platform actually is, why "golden paths" beat unlimited flexibility, and how platform engineering differs from just having a good DevOps team.
Service Mesh Basics
What a sidecar proxy actually intercepts, why service meshes exist once you already have Kubernetes Services, and the mTLS/observability/traffic-shaping capabilities that justify the added complexity.
Terraform Basics
How Terraform's declarative state model, providers, and plan/apply workflow let infrastructure be versioned and reviewed like code, and the state pitfalls that trip up most teams.
What is the difference between `[ ]` and `[[ ]]` in Bash conditionals?
`[ ]` is the POSIX test command, an actual command whose arguments undergo the shell's normal word-splitting and globbing before it ever sees them, which is why an unquoted variable inside it can break in surprising ways. `[[ ]]` is a Bash keyword with special parsing: it does not word-split or glob its arguments, supports pattern matching (`==`, `=~`) and logical operators (`&&`, `||`) directly inside the brackets, and is generally the safer, more predictable choice in Bash-specific scripts, at the cost of not being portable to a strict POSIX `/bin/sh`.
Why does `set -euo pipefail` matter at the top of a script?
By default, Bash keeps executing after a command fails, treats referencing an unset variable as an empty string instead of an error, and reports a pipeline's exit status as only its last command's; all three hide real failures. `-e` exits on a non-zero status from most simple commands, but only in contexts where errexit actually applies; it does not trigger inside `if`/`while`/`until` conditions, for any but the last command in a pipeline (unless combined with `pipefail`), or for a non-final command in a `&&`/`||` list, whose status is checked by the operator itself rather than causing an exit. The final command in that list is not exempt, though: if it fails and the list isn't itself acting as an `if`/`while`/`until` condition or the left side of another `&&`/`||`, errexit still triggers. `-u` turns an unset-variable reference into an error, and `-o pipefail` makes a pipeline fail if any stage fails, not just the last one. Together they turn a script that silently continues past errors into one that fails loudly in the cases where errexit applies, which is almost always what you want for anything beyond a one-off interactive command, but it is not a blanket guarantee that catches every failure everywhere.
Why should variables almost always be quoted, e.g. `"$name"` instead of `$name`?
An unquoted variable expansion undergoes word-splitting (on whitespace) and globbing (on `*`, `?`, etc.) before the command sees it, so a value containing a space or a shell metacharacter silently becomes multiple arguments or an unintended file-glob expansion instead of one literal string. Quoting (`"$name"`) suppresses both, so the variable's value is always passed through as exactly one argument, which is why nearly every Bash style guide treats an unquoted variable expansion as a latent bug rather than a style preference.
What is the difference between continuous integration, continuous delivery, and continuous deployment?
Continuous integration means every code change is automatically built and tested against the main branch frequently; the goal is catching integration problems within minutes, not weeks. Continuous delivery extends that so every change that passes CI is automatically packaged into a release-ready artifact, though a human still decides when to actually deploy it. Continuous deployment goes one step further and removes that human gate, every change that passes all automated checks is deployed to production automatically. The three form a spectrum of increasing automation, and most teams stop at continuous delivery rather than full continuous deployment for anything customer-facing.
Why is pipeline speed treated as a first-class metric, not just a convenience?
A slow pipeline directly increases the cost of every mistake, if tests take 40 minutes to run, a developer either waits 40 minutes for feedback or, more likely, starts the next task and context-switches back later, making the eventual failure much more expensive to fix. Fast pipelines keep the feedback loop close to the moment the mistake was introduced, which is when it is cheapest to fix. This is why teams invest in parallelizing test suites, caching dependencies, and running only the checks relevant to what changed, rather than accepting pipeline slowness as a fixed cost.
What is a deployment gate, and why put one between CI and production?
A deployment gate is a checkpoint, automated (a canary health check, a manual approval, a change-freeze window), that must pass before a build progresses to the next environment. It exists because passing CI only proves the code works in isolation; it doesn't prove the deployment itself will succeed, or that now is a safe time to deploy (e.g., not during a change freeze, not without on-call coverage). Gates let teams keep deployments frequent and automated while still retaining a control point for the decisions that genuinely need human or environmental judgment.
Why is "rightsizing" usually the highest-leverage cost optimization, and why do teams under-invest in it?
Rightsizing means matching provisioned capacity (instance size, allocated memory) to actual observed usage, and it typically has the biggest impact because most cloud resources are provisioned for a peak or a guess, then never revisited, meaning steady-state waste compounds every hour, every day, indefinitely. Teams under-invest in it because it requires ongoing measurement and periodic action, competing for attention against feature work that has more visible payoff, and because a resource that's "working fine" doesn't generate the same urgency as one that's broken, even if it's costing several times what it needs to.
What is the difference between a reserved/committed-use discount and a spot/preemptible instance, and when does each make sense?
A committed-use discount (reserved instances, savings plans) trades a usage commitment, a fixed amount of spend or capacity over a term, typically one or three years, for a significant price reduction on workloads you know will run continuously. Spot/preemptible instances offer a much steeper discount in exchange for the provider being able to reclaim the capacity with little notice, making them suitable only for interruption-tolerant workloads (batch jobs, stateless workers, CI runners) rather than anything requiring guaranteed uptime. Committed-use addresses predictable steady-state load; spot addresses flexible, interruption-tolerant load, using either for the wrong workload type either wastes the discount or causes outages.
Why doesn't autoscaling alone guarantee cost efficiency?
Autoscaling matches capacity to load, but only within whatever floor and configuration a team sets, a minimum instance count set too high, overly conservative scale-down thresholds, or scaling policies that react slowly to load drops all leave a workload over-provisioned even with autoscaling technically "on." Autoscaling is necessary but not sufficient: it needs to be tuned against real traffic patterns and revisited periodically, the same way static rightsizing does, or it just becomes a more complex way to still be over-provisioned most of the time.
What is the difference between a Docker image and a Docker container?
An image is a read-only, layered filesystem snapshot plus metadata (entrypoint, exposed ports, environment); it never changes once built and can be shared through a registry. A container is a running (or stopped) instance of an image: Docker adds a thin writable layer on top of the image's read-only layers and starts a process inside an isolated namespace. You can start many independent containers from the same image, each with its own writable layer and state, the same way many processes can run from the same binary on a normal OS.
Why does data written inside a container disappear when the container is removed?
Anything a container writes lands in its own writable layer, which is deleted along with the container by `docker rm`. That is deliberate; it is what makes containers disposable and reproducible, a fresh container from the same image always starts from the same known state. Anything that actually needs to survive a container's lifecycle (a database's data files, uploaded assets) has to live outside that writable layer, in a named volume or a bind mount, which Docker mounts into the container at a chosen path but manages independently of the container itself.
Why is publishing a port with `-p 8080:80` different from the container just "having" port 80?
A container's ports exist only on its own private network namespace by default; nothing on the host or outside can reach them until Docker explicitly forwards a host port to it. `-p 8080:80` tells Docker's network layer to forward the host's port 8080 to port 80 inside the container's namespace, host port first, container port second. Leaving a port `EXPOSE`d in a Dockerfile only records metadata/documentation, it has no effect on connectivity at all: another container on the same Docker network can already reach any port the first container is listening on, EXPOSE or not. Publishing to the host is the one thing that always requires an explicit `-p`.
What is the default Docker network driver and how does container-to-container communication work on it?
The default is the bridge driver, Docker creates a private virtual network on the host, and each container gets its own network namespace with a virtual ethernet interface connected to that bridge. Containers on the same user-defined bridge network can reach each other by container name, because Docker runs an embedded DNS server that resolves container names to their internal IPs on that network. Containers on the default (unnamed) bridge network do not get this automatic DNS resolution, only user-defined bridge networks provide it.
Why does publishing a port with -p 8080:80 not automatically make the container reachable from other containers?
-p (or --publish) maps a port on the Docker host to a port inside the container, specifically for reaching the container from outside the Docker network, from the host machine or the internet. Other containers on the same user-defined network do not need that mapping at all; they can reach the container directly on its internal port via the container's name and internal port, because they share the internal bridge network. Publishing a port is about host-to-container access, not container-to-container access.
What is the difference between the bridge and host network drivers?
With the bridge driver (the default), a container gets its own isolated network namespace and IP address, and ports must be explicitly published to be reachable from the host. With the host driver, the container shares the host's network namespace directly, no isolation, no port publishing needed, the container's ports are the host's ports. Host networking is faster (no NAT/bridge overhead) but sacrifices network isolation, so it is used selectively, not as a default.