- 625 Terraform workspaces और 38 AWS accounts में 165,000 से अधिक cloud resources का प्रबंधन
- 170 engineers में से 40 infra specialists हैं
- हर दिन 225 infrastructure releases (
terraform apply) और 723 plans (terraform plan) चलाए जाते हैं
- इसके लिए Terraform Cloud को अपनाकर infrastructure release process को automate किया गया, जिससे developers का manual work और errors कम हुए
Terraform Cloud अपनाने से पहले की समस्याएँ
- उच्च AWS access permissions की आवश्यकता : infra team के पास उच्च स्तर की AWS access permissions होनी पड़ती थीं
- समय लेने वाले काम : हर directory में
terraform apply चलाकर review और approval दोहराना पड़ता था, और एक बदलाव का असर 120 से अधिक workspaces पर पड़ सकता था
- infrastructure drift होना : अनपेक्षित बदलाव जमा होते जाते थे, इसलिए apply के समय अतिरिक्त review और कार्रवाई की ज़रूरत पड़ती थी
Terraform Cloud अपनाना और उसके प्रभाव
- drift समाप्त → infrastructure drift हटाकर risk और developers पर पड़ने वाला बोझ कम किया गया
- developers का समय बचा → सालाना लगभग 8,000 घंटे developers के समय की बचत (जो 4 developers के workload के बराबर है)
- changes track किए जा सकते हैं → audit logs के ज़रिए changes को track करना और debugging आसान हुआ
- speculative plans का समर्थन → changes को अपने-आप test किया जा सकता है और results सीधे GitHub CI में देखे जा सकते हैं
वर्तमान Terraform Cloud संचालन तरीका
- self-hosted : Terraform Cloud for Business को self-host किया गया है, और AWS account के भीतर ECS cluster में TFC agents चलाए जा रहे हैं
- agent pool configuration : 120 agents को development environment (40) और production environment (80) में बाँटकर चलाया जाता है ताकि उच्च concurrency बनी रहे
जिन बातों की खास निगरानी की जाती है
- agent exhaustion और concurrency limits → agent कम पड़ने पर on-call engineer को alert
- plan time → development environment में plan time 4 मिनट से ऊपर जाने पर team को alert
- infrastructure drift → अभी इसे मापा नहीं जाता (क्योंकि drift लगभग नहीं होता)
गुणवत्ता सुधार के लिए optimization
- TFC CLI development : कई workspaces में changes का CLI के जरिए automated review और approval संभव बनाया गया
- notification system बनाना : Slack notifications के जरिए Terraform apply छूट न जाए, इसके लिए automation किया गया
- workspace auto-management : Terraform का उपयोग करके 625 workspaces को manage किया जाता है, और tags लगाकर owner teams को अलग किया जाता है
- Terraform Cloud usage analysis : TFC API का उपयोग करके state version data इकट्ठा किया जाता है, ताकि resource usage और growth trends समझे जा सकें
- Terraform State backup : state files को अपने-आप S3 bucket में backup किया जाता है, ताकि failure होने पर recovery संभव हो
- workspace dependency management : module dependency tree बनाकर उन directories को workspaces के लिए अपने-आप सेट किया जाता है जिन्हें monitor करना चाहिए
- provider upgrade automation : Dependabot का उपयोग करके providers को हर महीने upgrade किया जाता है, और automation से management burden कम किया जाता है
आगे के सुधार
- phased rollout :
main branch आधारित releases से multi-stage deployment (development → staging → production) मॉडल में बदलाव
- बड़े workspaces का विभाजन : मौजूदा 625 workspaces को 1500 से अधिक में बाँटकर plan और apply time कम करने और change impact scope घटाने की योजना
- notification features में सुधार : Slack notifications में reassignment feature जोड़ना और
tfc review command auto-generation feature लाना
- agent auto scaling : EKS आधारित auto scaling system अपनाकर variable workloads को अधिक कुशलता से संभालने की योजना
- self-developed tools को open source करना : अंदरूनी तौर पर बनाए गए विभिन्न tools को open source के रूप में जारी करने की योजना, ताकि दूसरी teams भी उनका उपयोग कर सकें
अभी कोई टिप्पणी नहीं है.