TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
You're spending 40 hours a week writing code that AI could do in 10.
While you're grinding through pull requests, 200k+ engineers at OpenAI, Google & Meta are using AI to ship faster. How?
The Code newsletter teaches them exactly which AI tools to use and how to use them. Here's what you get:
AI coding techniques used by top engineers at top companies in just 5 mins a day
Tools and workflows that cut your coding time in half
Tech insights that keep you 6 months ahead
IN TODAY'S EDITION
🧠 Use Case
How Ansible Inventory Works in Modern DevOps
👀 Remote Jobs
Social Discovery Group is hiring a DevOps Engineer
Remote Location: Worldwide
Panoptyc is hiring a Cloud Operations Manager
Remote Location: Worldwide
Powered by: Jobsurface.com
📚 Resources
If you’re not a subscriber, here’s what you missed last week.
To receive all the full articles and support TechOps Examples, consider subscribing:
🛠 TOOL OF THE DAY
Ultimate DevSecOps library - This library contains list of tools and methodologies accompanied with resources. The main goal is to provide to the engineers a guide through opensource DevSecOps tooling.
🧠 USE CASE
How Ansible Inventory Works in Modern DevOps
A team maintaining a static inventory file for forty servers usually hits the same wall eventually. Someone spins up three new servers for a traffic spike, deploys to them directly to save time, and forgets to add their IPs to the inventory file. The next scheduled playbook run configures the original forty and quietly skips the three that actually needed it. Nothing errors out, the run just finishes having done less than expected.
Ansible inventory is simply the list of hosts a playbook is allowed to touch. How that list gets built, by a person typing it out or by a script asking a cloud provider what currently exists, is the real difference between static and dynamic inventory.
Static Inventory
A static inventory is a plain text or YAML file listing hosts, usually grouped under labels like web or db. When a playbook targets the web group, Ansible looks up whichever addresses are currently written under that label in the file.
The Management Node is the machine ansible-playbook actually runs from. It reads the file, resolves web to those three addresses, and connects to each over SSH. For a small, stable set of servers, a physical rack that rarely changes, for example, this is often the simplest and most reliable option, since there is no API call involved and nothing that can fail beyond a typo in the file. The weakness only shows up once servers start being added or removed faster than someone remembers to update the list by hand.
Dynamic Inventory
A dynamic inventory replaces that file with a script or plugin that asks an external source, typically a cloud provider, what servers currently exist, and builds the host list fresh every time a playbook runs.
dynamic_inventory.py here represents that query script. Ansible ships a ready-made plugin for AWS, amazon.aws.aws_ec2, that does this against the EC2 API without anyone writing custom code, other cloud providers have their own equivalents. The important part is that every playbook run pulls a live snapshot of what actually exists right now, rather than trusting a file that might be days or weeks out of date.
Why Filtering Matters
Querying a cloud account directly returns every instance in it, test servers, forgotten one-off boxes, database hosts, everything. A playbook meant only for web servers cannot safely run against that unfiltered list.
This is what the "Filtered by: Tag / env" step in the diagram is doing. The inventory plugin is configured to only include instances carrying a specific tag, for example Environment: production, before handing the list to the playbook. Skip this step, and a forgotten test server tagged web from months ago could quietly receive production configuration alongside everything else.
A Shared Limitation
Neither approach changes how SSH access actually works. Whether the host list came from a static file or a live API query, the Management Node still needs valid SSH trust to every server before any task can run. Ansible does not manage that trust itself, it only decides which addresses to attempt a connection to. This means a slightly too broad filter on the dynamic side does not fail with an error, it simply expands the list of servers a playbook tries to reach, and if SSH access happens to already work on those extra servers too, the playbook can end up running somewhere nobody intended.
Choosing Between Them
A handful of long lived servers that rarely change gains little from the added complexity of a dynamic inventory, the API call, the plugin setup, the filtering rules. A static file does the job with less to maintain. Environments where servers are created and destroyed regularly, autoscaling groups or short lived test environments, are where a static file becomes a liability instead, since it cannot keep up with infrastructure that changes on its own.
Practical Points Worth Applying
Use static inventory only for infrastructure that changes rarely, anything created or destroyed automatically needs dynamic inventory instead.
Always filter dynamic inventory queries by tag or environment, an unfiltered query against a shared account will eventually include something unintended.
Cache dynamic inventory results rather than querying the cloud API fresh on every single run, especially in CI pipelines that run playbooks frequently.
Review SSH access separately from inventory source, since neither static nor dynamic inventory controls who can actually be reached, only which addresses get attempted.
THE CODE - Learn how to code faster with AI in 5 mins a day. Loved by 300k+ devs, engineers at Meta, Google, OpenAI, and more.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Looking to promote your company, product, service, or event to 49,000+ DevOps and Cloud Professionals? Let's work together.
