[{"data":1,"prerenderedAt":321},["ShallowReactive",2],{"authors":3,"\u002Fblog\u002Fmanaging-infrastructure-drift":26,"\u002Fblog\u002Fmanaging-infrastructure-drift-surround":308},[4,16],{"id":5,"avatar":6,"bio":7,"extension":8,"github":9,"meta":10,"name":11,"role":12,"stem":13,"website":14,"__hash__":15},"authors\u002Fauthors\u002Fsagar-kapoor.yml","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F69609200?v=4",null,"yml","sagar-kap",{},"Sagar Kapoor","Chief Executive Officer (CEO)","authors\u002Fsagar-kapoor","https:\u002F\u002Fsagarkapoor.eu","NsLNClfs_S-SNHFEnyR6Vq_7zEc1Xxl7QLoKrk_DB6s",{"id":17,"avatar":18,"bio":7,"extension":8,"github":19,"meta":20,"name":21,"role":22,"stem":23,"website":24,"__hash__":25},"authors\u002Fauthors\u002Fsomraj-saha.yml","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F31373860?v=4","jarmos-san",{},"Somraj Saha","Chief Technology Officer (CTO)","authors\u002Fsomraj-saha","https:\u002F\u002Fjarmos.dev","mDAq8GgPZv9H8en0XHAraq3aYi_v8t2ULWGqp4cp3zY",{"id":27,"title":28,"author":29,"body":30,"category":297,"cover":298,"date":299,"description":300,"extension":301,"meta":302,"navigation":303,"path":304,"seo":305,"stem":306,"__hash__":307},"blog\u002Fblog\u002Fmanaging-infrastructure-drift.md","Managing Infrastructure Drift: How Packer, Terraform, and Ansible Keep Enterprise Environments Compliant","somraj-saha",{"type":31,"value":32,"toc":288},"minimark",[33,41,44,55,68,73,76,96,99,102,106,113,158,162,177,209,213,222,252,256,259,276,285],[34,35,36,37],"p",{},"Every enterprise engineering team knows the dread of ",[38,39,40],"strong",{},"\"Configuration Drift.\"",[34,42,43],{},"It usually starts small: an Infrastructure Engineer temporarily toggles a\nsecurity group rule in the cloud console to troubleshoot an outage at 2:00 AM\nthrough manual intervention. A Software Development Engineer (SDE) applies a\npatch update directly to a production server via SSH. A database parameter is\naltered \"temporarily\" and forgotten. Months later, the production runtime\nenvironment diverge wildly from the requirements specified in the code\nrepository. This turns the server in to nothing more than black box since it is\nundocumented and practically impossible to maintain when an audit hits or a\ndisaster strikes.",[34,45,46,47,54],{},"Combating drift requires more than a single tool. In modern enterprise\nenvironments, maintaining compliance across the entire infrastructure deployment\nlifecycle demands a coordinated pipeline. At ",[48,49,53],"a",{"href":50,"rel":51},"https:\u002F\u002Fweburz.com",[52],"nofollow","Weburz"," we use\nthe following technologies:",[56,57,58,62,65],"ol",{},[59,60,61],"li",{},"Packer for building immutable images.",[59,63,64],{},"Terraform for infrastructure resources provisioning.",[59,66,67],{},"Ansible for runtime configuration of the infrastructure resources.",[69,70,72],"h2",{"id":71},"the-anatomy-of-infrastructure-drift","The Anatomy of Infrastructure Drift",[34,74,75],{},"Our engineering team has identified three distinct layers of the architecture\nwhere drift occurs and should be managed carefully:",[56,77,78,84,90],{},[59,79,80,83],{},[38,81,82],{},"The Image Layer:"," Base AMIs or VMs age out, missing critical security\npatches or OS updates. For example, servers running Debian Stable may or may\nnot be updated for years to come which—surprisingly is quite a common\npractice in legacy environments. Left unamanaged, these aging images become\nprime targets for vulnerabilities because underlying package repositories and\nkernel versions fall too far behind modern security baselines.",[59,85,86,89],{},[38,87,88],{},"The Infrastructure Layer:"," Cloud resources (such as VPCs, subnets, IAM\npolicies, firewalls) are temporarily modified outside of version control\nduring high-pressure troubleshooting and then never reverted back to their\noriginal state afterward. What starts as a \"quick hotfix\" in the cloud\nprovider's web console leaves behind undocumented network rules and overly\npermissive security groups that break our audit readiness.",[59,91,92,95],{},[38,93,94],{},"The Configuration Layer:"," Packages, application dependencies, and local\nfile structures on running nodes mutate over time. As developers SSH into\nservers to test packages or modify configuration files directly, individual\nnodes slowly drift away from their intended blueprint, leading to the classic\n\"it works on my staging server\" syndrome.",[34,97,98],{},"Relying on a single tool to fix all three layers usually leads to brittle\nscripts and automation failure. Instead, we use Packer, Terraform and Ansible to\ndivide and conquer tasks at which each respective tool is particularly good at.",[34,100,101],{},"The next section shows how we do it.",[69,103,105],{"id":104},"layer-1-packer-eliminating-drift-at-the-image-level","Layer 1: Packer - Eliminating Drift at the Image Level",[34,107,108,109,112],{},"Trying to patch running servers individually is a losing battle. Enterprise\ncompliance mandates ",[38,110,111],{},"immutable infrastructure"," wherein, if a server needs a\ncore OS update or security hardening, we do not patch it live but replace it\ncompletely. This approach eliminates the ambiguity of long-lived servers which\naccumulate hidden technical debt over months or years of operation.",[114,115,116,155],"ul",{},[59,117,118,119,124,125,130,131,136,137,142,143,148,149,154],{},"How it works is; ",[48,120,123],{"href":121,"rel":122},"https:\u002F\u002Fpacker.io",[52],"Packer"," bakes our security baselines\n(such as hardended SSH and firewall configurations), compliance agents\n(",[48,126,129],{"href":127,"rel":128},"https:\u002F\u002Ftailscale.com",[52],"Tailscale","), and core software stack\n(",[48,132,135],{"href":133,"rel":134},"https:\u002F\u002Fwww.docker.com",[52],"Docker",", ",[48,138,141],{"href":139,"rel":140},"https:\u002F\u002Frestic.net",[52],"Restic",", etc) into a\nversion-controlled \"golden image\" (aka, a \"snapshot\" on\n",[48,144,147],{"href":145,"rel":146},"https:\u002F\u002Fwww.vultr.com",[52],"Vultr"," and a \"VM image\" on\n",[48,150,153],{"href":151,"rel":152},"https:\u002F\u002Fazure.microsoft.com",[52],"Microsoft Azure","). By pre-packaging these\ndependencies and security policies ahead of time, we drastically reduce\nboot-up configuration times and ensure complete consistency across every\ninstance in our client environments.",[59,156,157],{},"By tying Packer builds to a CI\u002FCD trigger (like GitHub Actions), every\nsecurity update or CVE patch automatically forces a fresh image build. Old,\nvulnerable templates are deprecated and cleaned up from our artifact\nregistries, ensuring that all future deployments always start from a strictly\nverified known-good baseline.",[69,159,161],{"id":160},"layer-2-terraform-enforcing-desired-state-for-resources","Layer 2: Terraform - Enforcing Desired State for Resources",[34,163,164,165,170,171,176],{},"With the golden image ready, we provision the networking, compute, and storage\nsurrounding it. This is where ",[48,166,169],{"href":167,"rel":168},"https:\u002F\u002Fterraform.io",[52],"Terraform"," takes over using\na declarative model backed by a state file (which is securely stored in a blob\nstorage service such as\n",[48,172,175],{"href":173,"rel":174},"https:\u002F\u002Fazure.microsoft.com\u002Fen-us\u002Fproducts\u002Fstorage\u002Fblobs",[52],"Azure Blob Storage",").",[114,178,179,187],{},[59,180,181,182,186],{},"Since Terraform maintains a state mapping our code to reality, running\n",[183,184,185],"code",{},"terraform plan"," actively scans our cloud provider's API to highlight\ndiscrepancies in the infrastructure. If someone manually adds an unauthorized\ningress port in the cloud console to debug a late-night issue, Terraform flags\nit immediately as drift and forces remediation back to the code definition.",[59,188,189,190,192,193,196,197,202,203,208],{},"Most enterprise teams use automated scheduled pipelines to run\n",[183,191,185],{}," daily without applying changes. If drift is detected, an\nalert fires notifying the platform team of out-of-band modifications over an\nemail (",[38,194,195],{},"which by the way is working out fine for us","),\n",[48,198,201],{"href":199,"rel":200},"https:\u002F\u002Fslack.com",[52],"Slack"," or ",[48,204,207],{"href":205,"rel":206},"https:\u002F\u002Fwww.pagerduty.com",[52],"PagerDuty",". This\nloop guarantees that our version-controlled repository remains the ultimate\nsingle source of truth for all cloud resource topology.",[69,210,212],{"id":211},"layer-3-ansible-continuous-runtime-compliance","Layer 3: Ansible - Continuous Runtime Compliance",[34,214,215,216,221],{},"Even with immutable images and locked-down infrastructure, runtime environments\ncan eventually experience drift any way since applications update\nconfigurations, local system files change, and compliance daemons require\nperiodic enforcement. To deal with such a scenario, we rely on\n",[48,217,220],{"href":218,"rel":219},"https:\u002F\u002Fdocs.ansible.com\u002Fprojects\u002Fansible\u002Flatest\u002Findex.html",[52],"Ansible",".",[114,223,224,231,249],{},[59,225,226,227,230],{},"Ansible leverages ",[38,228,229],{},"idempotency"," since playbooks can run repeatedly against\nrunning infrastructure without altering the system unless an actual drift from\nthe desired state is discovered. This mkes it an ideal safety net of enforcing\nruntime invariants without risking uintended service disruptions.",[59,232,233,234,239,240,242,243,245,246,248],{},"While tools like ",[48,235,238],{"href":236,"rel":237},"https:\u002F\u002Fcloud-init.io",[52],"cloud-init"," are often used during the\ninitial boot sequences to bootstrap instances, we don't rely on ",[183,241,238],{},"\nfor ongoing compliance. ",[183,244,238],{}," is fundamentally designed for day-zero\nset up and is notoriously difficult to trigger safely or idempotently on\nrunning systems after the instance has booted. Attempting to force\n",[183,247,238],{}," to manage day-two drift often leads to fragile scripts,\nunpredictable re-runs and silent failures.",[59,250,251],{},"Instead, Ansible can be scheduled via Automation Controller (AWX\u002FAAP) (for\nenterprise requirements) or GitHub Actions (which is what we rely on) to run\nregular compliance check-ups. If a configuration file permission changes or a\nrequired monitoring agent is stopped, Ansible remediates it back to the\ncompliant state automatically.",[69,253,255],{"id":254},"bringing-it-together-the-compliance-pipeline","Bringing It Together: The Compliance Pipeline",[34,257,258],{},"To build a truly resilient enterprise architecture, these three tools shouldn't\noperate in silos. They form a natural assembly line:",[56,260,261,266,271],{},[59,262,263,265],{},[38,264,123],{}," builds the compliance-verified OS image.",[59,267,268,270],{},[38,269,169],{}," provisions the cloud topology utilizing that specific image ID.",[59,272,273,275],{},[38,274,220],{}," consumes the inventory generated by Terraform to apply final\napplication-layer configurations and runtime baselines.",[34,277,278,279,284],{},"By treating our infrastructure pipeline as a strict, code-driven product, we\nshifted from a reactive posture (finding out about drift during an audit or\noutage) to a proactive one where compliance is continuously engineered by\ndefault. To ensure our end-to-end IaC workflows adhere to rigorous security\nstandards, we also recommend reviewing the\n",[48,280,283],{"href":281,"rel":282},"https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FInfrastructure_as_Code_Security_Cheat_Sheet.html",[52],"OWASP Infrastructure as Code Cheat Sheet","\nfor best practices on secrets management, template hardening and state file\nprotection.",[34,286,287],{},"While this write-up provides a brief outlook in to the Infrastructure-as-Code\n(IaC) tools we use to manage our infrastructure at Weburz, it is not detailed\nenough on its own. So, in a series of future articles, we will provide detailed\nguidelines on how we use each of the aforementioned tools for our infrastructure\ndeployment workflow.",{"title":289,"searchDepth":290,"depth":290,"links":291},"",2,[292,293,294,295,296],{"id":71,"depth":290,"text":72},{"id":104,"depth":290,"text":105},{"id":160,"depth":290,"text":161},{"id":211,"depth":290,"text":212},{"id":254,"depth":290,"text":255},"Infrastructure","\u002Fblog\u002Fmanaging-infrastructure-drift.webp","2026-09-03","Stop infrastructure drift before it breaks your enterprise. Discover how combining Packer, Terraform, and Ansible creates a bulletproof, automated pipeline to maintain compliance, lock down security baselines, and enforce desired state across your cloud environments.","md",{},true,"\u002Fblog\u002Fmanaging-infrastructure-drift",{"title":28,"description":300},"blog\u002Fmanaging-infrastructure-drift","4Fb0MydF4hRuqcUrZav61OROD7DNXyKYmi2Nygu3D_E",[309,315],{"title":310,"path":311,"stem":312,"description":313,"date":314,"children":-1},"Hello, world","\u002Fblog\u002Fhello-world","blog\u002Fhello-world","Kicking off the Weburz engineering blog — what to expect, and why we're publishing in the open.","2026-05-22",{"title":316,"path":317,"stem":318,"description":319,"date":320,"children":-1},"Securely Self-Hosting PostgreSQL: Configuration, Backups, and Best Practices","\u002Fblog\u002Fsecurely-self-hosting-postgresql","blog\u002Fsecurely-self-hosting-postgresql","Take full control of your data by setting up your own self-hosted PostgreSQL database. Discover how to configure, secure, and manage production-ready instances efficiently.","2026-08-10",1788432264473]