Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
यह दस्तावेज़ टेराफ़ॉर्म का उपयोग करके सर्वोत्तम प्रथाओं का व्यवस्थित रूप से वर्णन करने का एक प्रयास है और टेराफ़ॉर्म उपयोगकर्ताओं द्वारा अनुभव की जाने वाली सबसे लगातार समस्याओं के लिए सिफारिशें प्रदान
Terraform शक्तिशाली है (यदि अभी सबसे शक्तिशाली नहीं है) और सबसे अधिक उपयोग किए जाने वाले उपकरणों में से एक है जो बुनियादी ढांचे के प्रबंधन को कोड के रूप में अनुमति देता है। यह डेवलपर्स को बहुत सी चीजें करने की अनुमति देता है और उन्हें उन चीजों को करने से प्रतिबंधित नहीं करता है जिनका समर्थन करना या एकीकृत करना मुश्किल होगा।
इस पुस्तक में वर्णित कुछ जानकारी सर्वोत्तम प्रथाओं की तरह नहीं लग सकती है। मुझे यह पता है, और पाठकों को स्थापित सर्वोत्तम प्रथाओं को अलग करने में मदद करने के लिए और चीजों को करने का एक और राय वाला तरीका क्या है, मैं कभी-कभी सर्वोत्तम प्रथाओं से संबंधित प्रत्येक उपखंड पर परिपक्वता के स्तर को निर्दिष्ट करने के लिए कुछ संदर्भ और आइकन प्रदान करने के लिए संकेतों का उपयोग करता हूं।
पुस्तक 2018 में सनी मैड्रिड में शुरू की गई थी, यहां मुफ्त में उपलब्ध है
https://www.terraform-best-practices.com/.
कुछ वर्षों बाद इसे टेराफॉर्म 1.0 के साथ उपलब्ध अधिक वास्तविक सर्वोत्तम प्रथाओं के साथ अद्यतन किया गया है। आखिरकार, इस पुस्तक में टेराफॉर्म उपयोगकर्ताओं के लिए निर्विवाद सर्वोत्तम अभ्यास और अनुशंसाएं शामिल होनी चाहिए।
Please contact me if you want to become a sponsor.
यदि आप इस पुस्तक का अन्य भाषाओं में अनुवाद करने में सहायता करना चाहते हैं तो मुझसे संपर्क करें।
मैं हमेशा फीडबैक प्राप्त करना चाहता हूं और इस पुस्तक को अपडेट करना चाहता हूं क्योंकि समुदाय परिपक्व होता है और समय के साथ नए विचारों को लागू और सत्यापित किया जाता है।
यदि आप विशिष्ट विषयों में रुचि रखते हैं, तो कृपया , या उस मुद्दे को स्वीकार करें जिसे आप कवर करना चाहते हैं। यदि आपको लगता है कि आपके पास सामग्री है और आप योगदान देना चाहते हैं, तो एक मसौदा लिखें और एक पुल अनुरोध सबमिट करें (इस समय अच्छा पाठ लिखने की चिंता न करें!)
इस पुस्तक का रखरखाव द्वारा विभिन्न योगदानकर्ताओं और अनुवादकों की सहायता से किया जाता है।
यह काम Apache 2 लाइसेंस के तहत लाइसेंस प्राप्त है। पूरी जानकारी के लिए लाइसेंस देखें।
इस सामग्री के लेखक और योगदानकर्ता यहां मिली जानकारी की वैधता की गारंटी नहीं दे सकते। कृपया सुनिश्चित करें कि आप समझते हैं कि यहां प्रदान की गई जानकारी स्वतंत्र रूप से प्रदान की जा रही है, और यह कि आपके और इस सामग्री या परियोजना से जुड़े किसी भी व्यक्ति के बीच किसी प्रकार का समझौता या अनुबंध नहीं किया गया है। लेखक और योगदानकर्ता किसी भी पक्ष के लिए किसी भी नुकसान, क्षति, या इस सामग्री से जुड़ी या जुड़ी जानकारी में त्रुटियों या चूक के कारण होने वाले व्यवधान के लिए किसी भी दायित्व को स्वीकार नहीं करते हैं और इससे इनकार करते हैं, चाहे ऐसी त्रुटियां या चूक से परिणाम लापरवाही, दुर्घटना, या कोई अन्य कारण।
Copyright © 2018-2023 Anton Babenko.
— Terraform Compliance Simplified. Make your Terraform modules compliance-ready.
—
pre-commit बहु-भाषा प्री-कमिट हुक के प्रबंधन और रखरखाव के लिए एक ढांचा है। यह Python में लिखा गया है और एक गिट रिपॉजिटरी के लिए कोड प्रतिबद्ध होने से पहले एक डेवलपर की मशीन पर स्वचालित रूप से कुछ करने के लिए एक शक्तिशाली उपकरण है। आम तौर पर, इसका उपयोग लिंटर चलाने और कोड को प्रारूपित करने के लिए किया जाता है (see supported hooks).
टेराफॉर्म कॉन्फ़िगरेशन के साथ pre-commit का उपयोग कोड को प्रारूपित करने और मान्य करने के साथ-साथ प्रलेखन को अपडेट करने के लिए किया जा सकता है.
इसके साथ खुद को परिचित करने के लिए pre-commit-terraform repository भंडार देखें, और मौजूदा भंडार (उदाहरण के लिए, terraform-aws-vpc)) जहां यह पहले से ही उपयोग किया जाता है।
terraform-docs एक ऐसा उपकरण है जो विभिन्न आउटपुट स्वरूपों में टेराफॉर्म मॉड्यूल से प्रलेखन तैयार करता है। आप इसे मैन्युअल रूप से चला सकते हैं (प्री-कमिट हुक के बिना), or use pre-commit-terraform hooks दस्तावेज़ को स्वचालित रूप से अपडेट करने के लिए.
@todo: Document module versions, release, GH actions
Blog post by :
यह सुनिश्चित करने के लिए Terraform pre-commit hooks का उपयोग करें कि कोड मान्य है, ठीक से स्वरूपित है, और स्वचालित रूप से इसे git में धकेलने और मनुष्यों द्वारा समीक्षा करने से पहले प्रलेखित किया गया है।
Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform
इस उदाहरण में कोड को एक बड़े आकार के बुनियादी ढांचे के लिए टेराफॉर्म कॉन्फ़िगरेशन की संरचना के उदाहरण के रूप में शामिल किया गया है जो उपयोग करता है:
2 AWS खाते
2 क्षेत्र
2 अलग-अलग वातावरण (ठेस और मंच जो कुछ भी साझा नहीं करते हैं)। प्रत्येक वातावरण एक अलग AWS खाते में रहता है और 2 क्षेत्रों के बीच संसाधन फैलाता है प्रत्येक वातावरण टेराफॉर्म रजिस्ट्री से प्राप्त ऑफ-द-शेल्फ इंफ्रास्ट्रक्चर मॉड्यूल (एलबी) के एक अलग संस्करण का उपयोग करता है प्रत्येक वातावरण एक आंतरिक मॉड्यूल मॉड्यूल/नेटवर्क के समान संस्करण का उपयोग करता है क्योंकि इसे स्थानीय निर्देशिका से प्राप्त किया जाता है।
देखेंउन परियोजनाओं के लिए बिल्कुल सही जहां बुनियादी ढांचा तार्किक रूप से अलग है (अलग AWSखाते)
अच्छा है जब AWS खातों के बीच साझा संसाधनों को संशोधित करने की आवश्यकता नहीं है (एक वातावरण = एक AWS खाता = एक राज्य फ़ाइल)
अच्छा है जब वातावरण के बीच परिवर्तन के आयोजन की कोई आवश्यकता नहीं है
अच्छा है जब बुनियादी ढाँचे के संसाधन प्रति पर्यावरण उद्देश्य से भिन्न होते हैं और उन्हें सामान्यीकृत नहीं किया जा सकता है (उदाहरण के लिए, कुछ संसाधन एक वातावरण में या कुछ क्षेत्रों में अनुपस्थित हैं)
जैसे-जैसे परियोजना बढ़ती है, इन परिवेशों को एक-दूसरे के साथ अप-टू-डेट रखना कठिन होगा। दोहराने योग्य कार्यों के लिए इंफ्रास्ट्रक्चर मॉड्यूल (ऑफ-द-शेल्फ या आंतरिक) का उपयोग करने पर विचार करें।
आधिकारिक टेराफॉर्म दस्तावेज़ीकरण विवरण में कॉन्फ़िगरेशन के सभी पहलुओं का वर्णन करता है। इस सेक्शन के बाकी हिस्सों को समझने के लिए इसे ध्यान से पढ़ें।
यह खंड उन प्रमुख अवधारणाओं का वर्णन करता है जिनका उपयोग पुस्तक के अंदर किया जाता है।
संसाधन aws_vpc, aws_db_instance, आदि है, एक संसाधन एक प्रदाता से संबंधित है, तर्कों को स्वीकार करता है, विशेषताओं को आउटपुट करता है, और उसका जीवन चक्र होता है। संसाधन बनाया जा सकता है, पुनर्प्राप्त किया जा सकता है, अपडेट किया जा सकता है और हटाया जा सकता है।
संसाधन मॉड्यूल कनेक्टेड संसाधनों का एक संग्रह है जो एक साथ सामान्य क्रिया करता है (for e.g., AWS VPC Terraform module creates VPC, subnets, NAT gateway, etc).यह प्रदाता कॉन्फ़िगरेशन पर निर्भर करता है, जिसे इसमें परिभाषित किया जा सकता है, या उच्च-स्तरीय संरचनाओं (e.g., in infrastructure module).
एक इंफ्रास्ट्रक्चर मॉड्यूल संसाधन मॉड्यूल का एक संग्रह है, जिसे तार्किक रूप से कनेक्ट नहीं किया जा सकता है, लेकिन वर्तमान स्थिति/प्रोजेक्ट/सेटअप में एक ही उद्देश्य पूरा होता है। यह प्रदाताओं के लिए कॉन्फ़िगरेशन को परिभाषित करता है, जो डाउनस्ट्रीम संसाधन मॉड्यूल और संसाधनों को पास किया जाता है। यह आमतौर पर एक इकाई प्रति लॉजिकल सेपरेटर (जैसे, AWS क्षेत्र, Google प्रोजेक्ट) में काम करने तक सीमित होता है।
For example, terraform-aws-atlantis मॉड्यूल जैसे संसाधन मॉड्यूल का उपयोग करता है terraform-aws-vpc and चलाने के लिए आवश्यक बुनियादी ढांचे का प्रबंधन करने के लिए on .
एक और उदाहरण मॉड्यूल जहां द्वारा कई मॉड्यूल बुनियादी ढांचे के प्रबंधन के साथ-साथ डॉकर छवियों को बनाने, धक्का देने और तैनात करने के लिए डॉकर संसाधनों का उपयोग करने के लिए एक साथ उपयोग किया जा रहा है। ऑल इन वन सेट।
संरचना बुनियादी ढांचे के मॉड्यूल का एक संग्रह है, जो कई तार्किक रूप से अलग क्षेत्रों (जैसे, AWS क्षेत्र, कई AWS खातों) में फैला हो सकता है। संरचना का उपयोग पूरे संगठन या परियोजना के लिए आवश्यक संपूर्ण बुनियादी ढांचे का वर्णन करने के लिए किया जाता है।
एक रचना में बुनियादी ढांचे के मॉड्यूल शामिल होते हैं, जिसमें संसाधन मॉड्यूल शामिल होते हैं, जो व्यक्तिगत संसाधनों को लागू करते हैं।
डेटा स्रोत केवल पढ़ने के लिए ऑपरेशन करता है और प्रदाता कॉन्फ़िगरेशन पर निर्भर होता है, इसका उपयोग संसाधन मॉड्यूल और इन्फ्रास्ट्रक्चर मॉड्यूल में किया जाता है।
डेटा स्रोत terraform_remote_state उच्च-स्तरीय मॉड्यूल और रचनाओं के लिए एक गोंद के रूप में कार्य करता है।
The डेटा स्रोत एक बाहरी प्रोग्राम को डेटा स्रोत के रूप में कार्य करने की अनुमति देता है, जो टेराफ़ॉर्म कॉन्फ़िगरेशन में कहीं और उपयोग के लिए मनमाने ढंग से डेटा को उजागर करता है.यहां से एक उदाहरण दिया गया है जहां बाहरी पायथन स्क्रिप्ट को कॉल करके फ़ाइल नाम की गणना की जाती है।
The डेटा स्रोत दिए गए URL पर एक HTTP GET अनुरोध करता है और प्रतिक्रिया के बारे में जानकारी निर्यात करता है जो अक्सर उन एंडपॉइंट्स से जानकारी प्राप्त करने के लिए उपयोगी होता है जहां एक देशी टेराफ़ॉर्म प्रदाता मौजूद नहीं है।
इन्फ्रास्ट्रक्चर मॉड्यूल और रचनाओं को अपना बना रहना चाहिए एक दूरस्थ स्थान पर जहां इसे दूसरों द्वारा नियंत्रित तरीके से पुनर्प्राप्त किया जा सकता है (e.g., specify ACL, versioning, logging).
आधिकारिक दस्तावेज़ीकरण में प्रदाता, प्रोविजनर और कुछ अन्य शर्तें बहुत अच्छी तरह से वर्णित हैं और यहां इसे दोहराने का कोई मतलब नहीं है। मेरी राय में, अच्छे टेराफॉर्म मॉड्यूल लिखने से उनका कोई लेना-देना नहीं है।
जबकि व्यक्तिगत संसाधन बुनियादी ढांचे में परमाणुओं की तरह होते हैं, संसाधन मॉड्यूल अणु (परमाणुओं से युक्त) होते हैं। एक मॉड्यूल सबसे छोटी संस्करण वाली और साझा करने योग्य इकाई है। इसमें तर्कों की एक सटीक सूची है, ऐसी इकाई के लिए आवश्यक फ़ंक्शन करने के लिए मूल तर्क लागू करें। e.g., module creates aws_security_group and aws_security_group_rule resources based on input. इन्फ्रास्ट्रक्चर मॉड्यूल बनाने के लिए अपने आप में इस संसाधन मॉड्यूल का उपयोग अन्य मॉड्यूल के साथ किया जा सकता है।
मॉड्यूल के आउटपुट और डेटा स्रोतों का उपयोग करके अणुओं (संसाधन मॉड्यूल और अवसंरचना मॉड्यूल) में डेटा तक पहुंच की जाती है।
रचनाओं के बीच पहुंच अक्सर रिमोट स्टेट डेटा स्रोतों का उपयोग करके की जाती है। There are .
छद्म संबंधों में ऊपर वर्णित अवधारणाओं को डालते समय यह इस तरह दिख सकता है:
टेराफॉर्म को संकेत देने का मददगार तरीका कि टेराफॉर्म कॉन्फ़िगरेशन में कोई प्रत्यक्ष निर्भरता न होने पर भी कुछ संसाधनों को पहले हटा दिया जाना चाहिए।
आवश्यक तर्क index_document सेट किया जाना चाहिए, यदि var.website एक खाली नक्शा नहीं है।
वैकल्पिक तर्क error_document छोड़ा जा सकता है।
website = {
index_document = "index.html"
}variable "website" {
type = map(string)
default = {}
}
resource "aws_s3_bucket" "this" {
# omitted...
dynamic "website" {
for_each = length(keys(var.website)) == 0 ? [] : [var.website]
content {
index_document = website.value.index_document
error_document = lookup(website.value, "error_document", null)
}
}
}composition-1 {
infrastructure-module-1 {
data-source-1 => d1
resource-module-1 {
data-source-2 => d2
resource-1 (d1, d2)
resource-2 (d2)
}
resource-module-2 {
data-source-3 => d3
resource-3 (d1, d3)
resource-4 (d3)
}
}
}
FTP (Frequent Terraform Problems)
Terragrunt - Orchestration tool (ऑर्केस्ट्रेशन टूल)
tflint - Code linter (कोड लिंटर)
tfenv - Version manager (संस्करण प्रबंधक)
- Pull Request automation (पुल अनुरोध स्वचालन)
- उपयोग किए जाने वाले टेराफॉर्म के लिए गिट हुक का संग्रह
- टेराफॉर्म इन पुल अनुरोधों के लिए क्लाउड लागत अनुमान। Terragrunt, Atlantis और pre-commit-terraform के साथ भी काम करता है.
संसाधन और आधारभूत संरचना मॉड्यूल के संस्करण निर्दिष्ट किए जाने चाहिए। प्रदाताओं को मॉड्यूल के बाहर कॉन्फ़िगर किया जाना चाहिए, लेकिन केवल संरचना में। प्रदाताओं के संस्करण और टेराफॉर्म को भी लॉक किया जा सकता है।
कोई मास्टर निर्भरता प्रबंधन उपकरण नहीं है, लेकिन निर्भरता विनिर्देशों को कम समस्याग्रस्त बनाने के लिए कुछ सुझाव हैं। उदाहरण के लिए, निर्भरता अद्यतनों को स्वचालित करने के लिए उपयोग किया जा सकता है। Dependabot आपकी निर्भरताओं को सुरक्षित और अद्यतित रखने के लिए पुल अनुरोध बनाता है। डिपेंडाबॉट टेराफॉर्म कॉन्फ़िगरेशन का समर्थन करता है।
उन लोगों के लिए एक कार्यशाला भी है जो इस गाइड में वर्णित कुछ चीजों का अभ्यास करना चाहते हैं।
The content is here -
Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
इस उदाहरण में एक मध्यम आकार के बुनियादी ढांचे के लिए टेराफॉर्म कॉन्फ़िगरेशन को संरचित करने के उदाहरण के रूप में कोड शामिल है जो उपयोग करता है:
2 AWS खाते
2 अलग-अलग वातावरण (ठेस और मंच जो कुछ भी साझा नहीं करते हैं)। प्रत्येक परिवेश एक अलग AWS खाते में रहता है
प्रत्येक परिवेश ऑफ़-द-शेल्फ अवसंरचना मॉड्यूल (alb) के भिन्न संस्करण का उपयोग करता है, जो से प्राप्त होता है
प्रत्येक वातावरण एक आंतरिक मॉड्यूल मॉड्यूल/नेटवर्क के समान संस्करण का उपयोग करता है क्योंकि इसे स्थानीय निर्देशिका से प्राप्त किया जाता है।
उन परियोजनाओं के लिए बिल्कुल सही जहां बुनियादी ढांचा तार्किक रूप से अलग है (अलग AWS खाते)
अच्छा है जब AWS खातों के बीच साझा संसाधनों को संशोधित करने की आवश्यकता नहीं है (एक वातावरण = एक AWS खाता = एक राज्य फ़ाइल)
अच्छा है जब वातावरण के बीच परिवर्तन के आयोजन की कोई आवश्यकता नहीं है
अच्छा है जब बुनियादी ढाँचे के संसाधन प्रति पर्यावरण उद्देश्य से भिन्न होते हैं और उन्हें सामान्यीकृत नहीं किया जा सकता है (उदाहरण के लिए, कुछ संसाधन एक वातावरण में या कुछ क्षेत्रों में अनुपस्थित हैं)
जैसे-जैसे परियोजना बढ़ती है, इन परिवेशों को एक-दूसरे के साथ अप-टू-डेट रखना कठिन होगा। दोहराने योग्य कार्यों के लिए इंफ्रास्ट्रक्चर मॉड्यूल (ऑफ-द-शेल्फ या आंतरिक) का उपयोग करने पर विचार करें।
No
very-large
कई प्रदाता (AWS, GCP, Azure)। मल्टी-क्लाउड परिनियोजन। टेराग्रंट का उपयोग करना।
No
Yes
टेराफॉर्म का उपयोग करते हुए कई AWS खाते और वातावरण, ऑफ-द-शेल्फ इंफ्रास्ट्रक्चर मॉड्यूल।
Yes
कई AWS खाते, कई क्षेत्र, कॉपी-पेस्ट, कस्टम इंफ्रास्ट्रक्चर मॉड्यूल, रचनाओं के भारी उपयोग को कम करने की तत्काल आवश्यकता है। टेराफॉर्म का उपयोग करना।
WIP
very-large
कई प्रदाता (AWS, GCP, Azure)। मल्टी-क्लाउड परिनियोजन। टेराफॉर्म का उपयोग करना।
No
medium
कई AWS खाते और वातावरण, ऑफ-द-शेल्फ इंफ्रास्ट्रक्चर मॉड्यूल, टेराग्रंट का उपयोग कर संरचना पैटर्न।
No
large
कई AWS खाते, कई क्षेत्र, कॉपी-पेस्ट, कस्टम इंफ्रास्ट्रक्चर मॉड्यूल, रचनाओं के भारी उपयोग को कम करने की तत्काल आवश्यकता है। टेराग्रंट का उपयोग करना।
टेराफॉर्म कोड संरचना से संबंधित प्रश्न समुदाय में अब तक सबसे अधिक बार आते हैं। सभी ने किसी समय परियोजना के लिए सर्वोत्तम कोड संरचना के बारे में भी सोचा।
यह उन प्रश्नों में से एक है जहां बहुत सारे समाधान मौजूद हैं और सार्वभौमिक सलाह देना बहुत कठिन है, तो आइए यह समझने के साथ शुरू करें कि हम किसके साथ काम कर रहे हैं।
आपकी परियोजना की जटिलता क्या है?
संबंधित संसाधनों की संख्या
टेराफॉर्म प्रदाताओं की संख्या ("तार्किक प्रदाताओं" के बारे में नीचे नोट देखें)
आपका इंफ्रास्ट्रक्चर कितनी बार बदलता है?
महीने/सप्ताह/दिन में एक बार से
लगातार (हर बार जब कोई नई प्रतिबद्धता होती है)
कोड परिवर्तन आरंभकर्ता? क्या आप एक नया आर्टिफैक्ट बनने पर सीआई सर्वर को रिपोजिटरी अपडेट करने देते हैं?
केवल डेवलपर्स ही इन्फ्रास्ट्रक्चर रिपॉजिटरी को आगे बढ़ा सकते हैं
हर कोई पीआर खोलकर किसी भी चीज़ में बदलाव का प्रस्ताव दे सकता है (सीआई सर्वर पर चलने वाले स्वचालित कार्यों सहित
आप किस परिनियोजन प्लेटफ़ॉर्म या परिनियोजन सेवा का उपयोग करते हैं?
AWS CodeDeploy, Kubernetes, या OpenShift को थोड़े अलग दृष्टिकोण की आवश्यकता होती है
पर्यावरण, क्षेत्र, परियोजना के अनुसार
जब आप शुरू कर रहे हों या एक उदाहरण कोड लिख रहे हों तो सभी कोड को main.tf में रखना एक अच्छा विचार है। अन्य सभी मामलों में आप बेहतर होंगे कि कई फाइलें इस तरह तार्किक रूप से विभाजित हों:
main.tf - सभी संसाधन बनाने के लिए कॉल मॉड्यूल, स्थानीय और डेटा स्रोत
variables.tf - main.tf में उपयोग किए जाने वाले चरों की घोषणाएं शामिल हैं
outputs.tf
terraform.tfvars को छोड़कर कहीं भी उपयोग नहीं किया जाना चाहिए।
कम संसाधनों के साथ काम करना आसान और तेज़ है
terraform plan औरterraform apply दोनों संसाधनों की स्थिति को सत्यापित करने के लिए क्लाउड एपीआई कॉल करते हैं
यदि आपके पास एक ही संरचना में अपना संपूर्ण बुनियादी ढांचा है तो इसमें कुछ समय लग सकता है
इस पुस्तक में, उदाहरण परियोजनाओं को जटिलता के आधार पर समूहीकृत किया गया है - छोटे से लेकर बहुत बड़े बुनियादी ढांचे तक। यह अलगाव सख्त नहीं है, इसलिए अन्य संरचनाओं की भी जांच करें।
एक छोटा बुनियादी ढांचा होने का मतलब है कि बहुत कम संख्या में निर्भरता और कुछ संसाधन हैं। जैसे-जैसे परियोजना बढ़ती है, टेराफॉर्म कॉन्फ़िगरेशन के निष्पादन की श्रृंखला की आवश्यकता होती है, विभिन्न बुनियादी ढांचे मॉड्यूल को जोड़ने, और एक संरचना के भीतर मूल्यों को पारित करना स्पष्ट हो जाता है।
डेवलपर्स द्वारा उपयोग किए जाने वाले ऑर्केस्ट्रेशन समाधानों के कम से कम 5 अलग-अलग समूह हैं:
केवल टेराफॉर्म। बहुत सीधा, डेवलपर्स को काम पूरा करने के लिए केवल टेराफॉर्म को जानना होगा।
Terragrunt. शुद्ध ऑर्केस्ट्रेशन टूल जिसका उपयोग संपूर्ण आधारभूत संरचना को व्यवस्थित करने के साथ-साथ निर्भरताओं को संभालने के लिए भी किया जा सकता है।. Tमूल रूप से बुनियादी ढांचे के मॉड्यूल और रचनाओं के साथ काम करता है, इसलिए यह कोड के दोहराव को कम करता है।
आन्तरिक स्क्रिप्ट। अक्सर यह ऑर्केस्ट्रेशन की ओर एक प्रारंभिक बिंदु के रूप में और Terragrunt की खोज से पहले होता है।
इसे ध्यान में रखते हुए, यह पुस्तक इन परियोजना संरचनाओं में से पहले दो की समीक्षा करती है, Terraform only और Terragrunt.
अगले अध्याय में या के लिए कोड संरचनाओं के उदाहरण देखें।
main.tf versions.tf - टेराफॉर्म और प्रदाताओं के लिए संस्करण आवश्यकताएं शामिल हैं
एक विस्फोट त्रिज्या (सुरक्षा उल्लंघन के मामले में) कम संसाधनों के साथ छोटा होता है
असंबंधित संसाधनों को अलग-अलग रचनाओं में रखकर एक-दूसरे से इन्सुलेट करने से कुछ गलत होने पर जोखिम कम हो जाता है
दूरस्थ स्थिति का उपयोग करके अपना प्रोजेक्ट प्रारंभ करें क्योंकि:
आपका लैपटॉप आपके बुनियादी ढांचे के सत्य के स्रोत के लिए कोई जगह नहीं है
git में tfstate फ़ाइल को प्रबंधित करना एक दुःस्वप्न है
बाद में जब बुनियादी ढांचे की परतें कई दिशाओं में बढ़ने लगती हैं (निर्भरता या संसाधनों की संख्या) तो चीजों को नियंत्रण में रखना आसान हो जाएगा
एक सुसंगत संरचना और नामकरण परंपरा का अभ्यास करें:
प्रक्रियात्मक कोड की तरह, लोगों को पहले पढ़ने के लिए टेराफॉर्म कोड लिखा जाना चाहिए, अब से छह महीने बाद परिवर्तन होने पर स्थिरता में मदद मिलेगी
टेराफॉर्म राज्य फ़ाइल में संसाधनों को स्थानांतरित करना संभव है, लेकिन यदि आपके पास असंगत संरचना और नामकरण है तो ऐसा करना कठिन हो सकता है
संसाधन मॉड्यूल को यथासंभव सादा रखें
उन मानों को हार्डकोड न करें जिन्हें चर के रूप में पारित किया जा सकता है या डेटा स्रोतों का उपयोग करके खोजा जा सकता है
डेटा स्रोतों और terraform_remote_state का उपयोग विशेष रूप से संरचना के भीतर अवसंरचना मॉड्यूल के बीच गोंद के रूप में करें
और अन्य Kubernetes-inspired समाधान। कभी-कभी कुबेरनेट्स पारिस्थितिकी तंत्र का उपयोग करना और आपके टेराफॉर्म कॉन्फ़िगरेशन की वांछित स्थिति प्राप्त करने के लिए एक सुलह लूप सुविधा को नियोजित करना समझ में आता है। अधिक जानकारी के लिए वीडियो देखें।
परिवेशों को कैसे समूहीकृत किया जाता है?Source:
इस उदाहरण में छोटे आकार के बुनियादी ढांचे के लिए टेराफॉर्म कॉन्फ़िगरेशन की संरचना के उदाहरण के रूप में कोड शामिल है, जहां कोई बाहरी निर्भरता का उपयोग नहीं किया जाता है।
आरंभ करने के लिए बिल्कुल सही और जैसे ही आप जाते हैं रिफैक्टर करें
छोटे संसाधन मॉड्यूल के लिए बिल्कुल सही
छोटे और रैखिक आधारभूत संरचना मॉड्यूल के लिए अच्छा है (eg, )
संसाधनों की एक छोटी संख्या के लिए अच्छा है (20-30 से कम)
यदि संसाधनों की संख्या बढ़ रही है तो सभी संसाधनों के लिए सिंगल स्टेट फाइल टेराफॉर्म के साथ काम करने की प्रक्रिया को धीमा कर सकती है (संसाधनों की संख्या को सीमित करने के लिए एक argument -target का उपयोग करने पर विचार करें)
हर जगह - (डैश) के बजाय _ (अंडरस्कोर) का उपयोग करें (संसाधन नाम, डेटा स्रोत नाम, चर नाम, आउटपुट आदि में)
लोअरकेस अक्षरों और संख्याओं का उपयोग करना पसंद करें (भले ही UTF-8 समर्थित हो)।
संसाधन नाम में संसाधन प्रकार को न दोहराएं (आंशिक रूप से नहीं, न ही पूरी तरह से):
यदि कोई और वर्णनात्मक और सामान्य नाम उपलब्ध नहीं है, या यदि संसाधन मॉड्यूल इस प्रकार का एकल संसाधन बनाता है, तो संसाधन नाम को इसका नाम दिया जाना चाहिए (eg, in प्रकार का एक ही संसाधन है aws_nat_gateway और प्रकार के कई संसाधन typeaws_route_table, इसलिए aws_nat_gatewayनाम दिया जाना चाहिए this तथाaws_route_table अधिक वर्णनात्मक नाम होने चाहिए - जैसे private, public, database).
नामों के लिए हमेशा एकवचन संज्ञा का प्रयोग करें।
उपयोग - तर्कों के अंदर मूल्यों और उन जगहों पर जहां मूल्य मानव के सामने आ जाएगा (eg, inside DNS name of RDS instance).
संसाधन या डेटा स्रोत ब्लॉक के अंदर तर्क count / for_each को शीर्ष पर पहले तर्क के रूप में शामिल करें और इसके बाद न्यूलाइन द्वारा अलग करें।
तर्क tags शामिल करें, यदि संसाधन द्वारा समर्थित है, तो अंतिम वास्तविक तर्क के रूप में, यदि आवश्यक हो तो depends_on and lifecycle के बाद। इन सभी को एक खाली लाइन से अलग किया जाना चाहिए।
एक तर्क में शर्तों का उपयोग करते समय count / for_each उपयोग करने के बजाय बूलियन मान पसंद करें length या अन्य भाव.
संसाधन मॉड्यूल में पहिया का पुन: आविष्कार न करें: जिस संसाधन के साथ आप काम कर रहे हैं, उसके लिए "तर्क संदर्भ" अनुभाग में परिभाषित चर के लिए नाम, विवरण और डिफ़ॉल्ट मान का उपयोग करें।
चरों में सत्यापन के लिए समर्थन सीमित है (उदाहरण के लिए अन्य चरों तक नहीं पहुंच सकते हैं या लुकअप नहीं कर सकते हैं)। तदनुसार योजना बनाएं क्योंकि कई मामलों में यह सुविधा बेकार है।
एक चर नाम में बहुवचन रूप का प्रयोग करें जब प्रकार list(...) or map(...) हो।
उत्पादन को उसके दायरे के बाहर संगत और समझने योग्य बनाएं (जब कोई उपयोगकर्ता मॉड्यूल का उपयोग कर रहा हो तो यह स्पष्ट होना चाहिए कि यह किस प्रकार और मूल्य का गुण लौटाता है)।
आउटपुट का नाम उस संपत्ति का वर्णन करना चाहिए जिसमें यह शामिल है और सामान्य रूप से जितना आप चाहते हैं उससे कम फ्री-फॉर्म होना चाहिए
आउटपुट के नाम के लिए अच्छी संरचना दिखती है {name}_{type}_{attribute} , जहां:
{name} प्रदाता उपसर्ग के बिना संसाधन या डेटा स्रोत का नाम है। {name}
सुरक्षा समूह की अधिकतम एक आईडी पर लौटें:
एक ही प्रकार के कई संसाधन होने पर, इसे आउटपुट के नाम से हटा दिया जाना चाहिए:
हमेशा सभी चरों पर विवरण शामिल करें, भले ही आपको लगता है कि यह स्पष्ट है (आपको भविष्य में इसकी आवश्यकता होगी)।
जब तक आपको प्रत्येक कुंजी पर सख्त बाधाओं की आवश्यकता न हो, तब तक साधारण प्रकार(number, string, list(...), map(...), any) कोई भी) विशिष्ट प्रकार जैसे object() का उपयोग करना पसंद करें।
यदि मानचित्र के सभी तत्वों का एक ही प्रकार (जैसे string) है या इसमें परिवर्तित किया जा सकता है (जैसे संख्या प्रकार को स्ट्रिंग में परिवर्तित किया जा सकता है) तो मानचित्र like map(map(string)) जैसे विशिष्ट प्रकारों का उपयोग करें।
एक निश्चित गहराई से शुरू होने वाले प्रकार सत्यापन को अक्षम करने के लिए या जब कई प्रकारों का समर्थन किया जाना चाहिए, तो टाइप करें का उपयोग करें।
मान {} कभी-कभी एक नक्शा होता है लेकिन कभी-कभी एक वस्तु। नक्शा बनाने के लिए tomap(...) का उपयोग करें क्योंकि कोई वस्तु बनाने का कोई तरीका नहीं है।
aws_subnetsubnetaws_vpcvpc{type} संसाधन स्रोतों का एक प्रकार है
{attribute} आउटपुट द्वारा लौटाई गई एक विशेषता है
.
यदि आउटपुट प्रक्षेप कार्यों और कई संसाधनों के साथ एक मान लौटा रहा है, {name} and {type} जितना संभव हो उतना सामान्य होना चाहिए (this as prefix should be omitted). .
यदि लौटाया गया मान एक सूची है तो उसका बहुवचन नाम होना चाहिए। .
हमेशा सभी आउटपुट के लिए विवरण description शामिल करें भले ही आपको लगता है कि यह स्पष्ट है.
जब तक आप सभी मॉड्यूल में सभी जगहों पर इस आउटपुट के उपयोग को पूरी तरह से नियंत्रित नहीं करते तब तक संवेदनशील sensitive तर्क सेट करने से बचें।
Prefer try() (available since Terraform 0.13) over element(concat(...)) (legacy approach for the version before 0.13)
`resource "aws_route_table" "public" {}``resource "aws_route_table" "public_route_table" {}``resource "aws_route_table" "public_aws_route_table" {}`resource "aws_route_table" "public" {
count = 2
vpc_id = "vpc-12345678"
# ... remaining arguments omitted
}
resource "aws_route_table" "private" {
for_each = toset(["one", "two"])
vpc_id = "vpc-12345678"
# ... remaining arguments omitted
}resource "aws_route_table" "public" {
vpc_id = "vpc-12345678"
count = 2
# ... remaining arguments omitted
}resource "aws_nat_gateway" "this" {
count = 2
allocation_id = "..."
subnet_id = "..."
tags = {
Name = "..."
}
depends_on = [aws_internet_gateway.this]
lifecycle {
create_before_destroy = true
}
} resource "aws_nat_gateway" "this" {
count = 2
tags = "..."
depends_on = [aws_internet_gateway.this]
lifecycle {
create_before_destroy = true
}
allocation_id = "..."
subnet_id = "..."
}resource "aws_nat_gateway" "that" { # Best
count = var.create_public_subnets ? 1 : 0
}
resource "aws_nat_gateway" "this" { # Good
count = length(var.public_subnets) > 0 ? 1 : 0
}output "security_group_id" {
description = "The ID of the security group"
value = try(aws_security_group.this[0].id, aws_security_group.name_prefix[0].id, "")
}output "this_security_group_id" {
description = "The ID of the security group"
value = element(concat(coalescelist(aws_security_group.this.*.id, aws_security_group.web.*.id), [""]), 0)
}output "rds_cluster_instance_endpoints" {
description = "A list of all cluster instance endpoints"
value = aws_rds_cluster_instance.this.*.endpoint
}- उन लोगों की सूची जो टेराफॉर्म के साथ बहुत सक्रिय रूप से काम करते हैं और आपको बहुत कुछ बता सकते हैं (यदि आप उनसे पूछें)।
- हशीकॉर्प के टेराफॉर्म पर संसाधनों की क्यूरेटेड सूची।
- "Your Weekly Dose of Terraform" YouTube channel by Anton Babenko. समीक्षा, साक्षात्कार, प्रश्नोत्तर, लाइव कोडिंग और टेराफॉर्म के साथ कुछ हैकिंग के साथ लाइव स्ट्रीम।
- टेराफॉर्म साप्ताहिक समाचार पत्र। टेराफॉर्म दुनिया में विभिन्न समाचार (परियोजनाएं, घोषणाएं, चर्चाएं) by Anton Babenko.