टेराफॉर्म: बहु-किरायेदारी के लिए राज्य प्रबंधन

Question

चूंकि हम बहु-किरायेदारी सास के लिए हमारी उत्तरदायी प्रावधान प्रक्रिया को बदलने (आंशिक रूप से) करने के लिए टेराफॉर्म का मूल्यांकन करने की प्रगति में हैं, हम टेराफॉर्म की सुविधा, प्रदर्शन और विश्वसनीयता को महसूस करते हैं क्योंकि हम संभाल सकते हैं बुनियादी ढांचे में परिवर्तन (जोड़ना/हटाना) सुचारू रूप से, इन्फ्रा राज्य का ट्रैक रखना (यह बहुत अच्छा है)।

हमारा आवेदन एक बहु-किरायेदारी सास है जिसे हम अपने ग्राहकों के लिए अलग-अलग उदाहरणों का प्रावधान करते हैं - उत्तर में हमारे पास अपनी गतिशील सूची है (ईसी 2 गतिशील सूची के समान ही)। हम टेराफॉर्म किताबों/ट्यूटोरियल और सर्वोत्तम प्रथाओं के माध्यम से जाते हैं जहां कई सुझाव देते हैं कि बहु पर्यावरण राज्यों को दूर से टेराफॉर्म में & प्रबंधित किया जाना चाहिए, लेकिन वे सभी स्थिर env (जैसे देव/स्टेजिंग/प्रोड) की तरह दिखते हैं।

बहु-किरायेदारी ऐप्स के लिए राज्यों की गतिशील सूची प्रबंधित करने का कोई सर्वोत्तम अभ्यास या वास्तविक उदाहरण है? हम उदाहरणों के प्रत्येक ग्राहक सेट की स्थिति को ट्रैक करना चाहते हैं - उन्हें आसानी से परिवर्तनों को पॉप्युलेट करें।

एक दृष्टिकोण हम प्रत्येक ग्राहक के लिए एक निर्देशिका बना सकते हैं और * .tf स्क्रिप्ट्स को अंदर रख सकते हैं, जो हमारे मॉड्यूल को कहीं भी होस्ट किया जाएगा। राज्य फ़ाइलों को एस 3 में रखा जा सकता है, इस तरह हम आवश्यकतानुसार प्रत्येक ग्राहक को परिवर्तनों को पॉप्युलेट कर सकते हैं।

Answer 1

आपका सुझाया गया दृष्टिकोण मेरे लिए सही लगता है, लेकिन कुछ और चीजें हैं जिन पर आप विचार कर सकते हैं।

रखें मूल terraform टेम्पलेट्स (नीचे पेड़ में _template) रूप संस्करणीकृत विरूपण साक्ष्य (Git रेपो, उदाहरण के लिए) और सिर्फ वे मुख्य मान गुण पारित अपने बुनियादी ढांचे को पुन: करने में सक्षम हो। इस तरह आपके पास निर्देशिकाओं में चारों ओर बिछाए गए टेराफॉर्म कॉन्फ़िगरेशन कोड चिपकाने वाली प्रतिलिपि की बहुत छोटी मात्रा होगी।

यह है कि यह कैसे दिखता है:

/tf-infra 
├── _global 
│   └── global 
│    ├── README.md 
│    ├── main.tf 
│    ├── outputs.tf 
│    ├── terraform.tfvars 
│    └── variables.tf 
└── staging 
    └── eu-west-1 
     ├── saas 
     │   ├── _template 
     │   │   └── dynamic.tf.tpl 
     │   ├── customer1 
     │   │   ├── auto-generated.tf 
     │   │   └── terraform.tfvars 
     │   ├── customer2 
     │   │   ├── auto-generated.tf 
     │   │   └── terraform.tfvars 
... 

दो सहायक स्क्रिप्ट की जरूरत है:

1. खाका प्रतिपादन। उपयोग या तो sedmodule's source attribute उत्पन्न या (के रूप में उदाहरण के लिए यह airbnb/streamalert में किया जाता है) और अधिक शक्तिशाली उपकरण का उपयोग

2. आवरण स्क्रिप्ट के। रन terraform -var-file=... आमतौर पर पर्याप्त है। अच्छी तरह से संसाधनों जो वैश्विक होना चाहिए (निर्देशिका _global ऊपर) के रूप

साझा terraform राज्य फ़ाइलें, S3 पर संग्रहीत किया जा सकता है, ताकि अन्य परतों उन तक पहुँच सकते हैं।

पुनश्च: मैं, प्रस्तावित समाधान पर टिप्पणियों के लिए बहुत ज्यादा खुला हूँ क्योंकि इस पर काम करने के लिए एक दिलचस्प काम है :)

Answer 2

terraform एक फ़ोल्डर स्तर पर काम करता है, सभी .tf फाइलों में खींच (और द्वारा डिफ़ॉल्ट terraform.tfvars फ़ाइल)।

तो हम Anton के answer के समान कुछ करते हैं लेकिन sed के साथ templating चीजों के आसपास कुछ जटिलता से दूर करते हैं।तो एक बुनियादी उदाहरण के रूप में अपने संरचना इस प्रकार दिखाई देंगे:

$ tree -a --dirsfirst 
. 
├── components 
│   ├── application.tf 
│   ├── common.tf 
│   ├── global_component1.tf 
│   └── global_component2.tf 
├── modules 
│   ├── module1 
│   ├── module2 
│   └── module3 
├── production 
│   ├── customer1 
│   │   ├── application.tf -> ../../components/application.tf 
│   │   ├── common.tf -> ../../components/common.tf 
│   │   └── terraform.tfvars 
│   ├── customer2 
│   │   ├── application.tf -> ../../components/application.tf 
│   │   ├── common.tf -> ../../components/common.tf 
│   │   └── terraform.tfvars 
│   └── global 
│    ├── common.tf -> ../../components/common.tf 
│    ├── global_component1.tf -> ../../components/global_component1.tf 
│    ├── global_component2.tf -> ../../components/global_component2.tf 
│    └── terraform.tfvars 
├── staging 
│   ├── customer1 
│   │   ├── application.tf -> ../../components/application.tf 
│   │   ├── common.tf -> ../../components/common.tf 
│   │   └── terraform.tfvars 
│   ├── customer2 
│   │   ├── application.tf -> ../../components/application.tf 
│   │   ├── common.tf -> ../../components/common.tf 
│   │   └── terraform.tfvars 
│   └── global 
│    ├── common.tf -> ../../components/common.tf 
│    ├── global_component1.tf -> ../../components/global_component1.tf 
│    └── terraform.tfvars 
├── apply.sh 
├── destroy.sh 
├── plan.sh 
└── remote.sh 

यहाँ आप चलाने के लिए अपनी योजना/लागू/रूट स्तर से नष्ट जहां आवरण शेल स्क्रिप्ट निर्देशिका में cd'ing और terraform get -update=true चल जैसी चीजों को संभाल लेकिन फ़ोल्डर के लिए terraform init भी चला रहा है ताकि आपको S3 के लिए एक अद्वितीय स्थिति फ़ाइल कुंजी मिल सके, जिससे आप स्वतंत्र रूप से प्रत्येक फ़ोल्डर के लिए राज्य को ट्रैक कर सकें।

उपर्युक्त समाधान में सामान्य मॉड्यूल हैं जो चीजों को आम इंटरफ़ेस प्रदान करने के लिए संसाधनों को लपेटते हैं (उदाहरण के लिए हमारे ईसी 2 उदाहरण कुछ इनपुट चर के आधार पर एक विशिष्ट तरीके से टैग किए जाते हैं और एक निजी रूट 53 रिकॉर्ड भी दिया जाता है) और फिर "लागू घटक "।

इन घटकों में मॉड्यूल/संसाधनों का एक समूह होता है जो टेराफॉर्म द्वारा उसी फ़ोल्डर में लागू किया जाएगा। तो हम application.tf के तहत एक ईएलबी, कुछ एप्लिकेशन सर्वर और डेटाबेस डाल सकते हैं और फिर उस स्थान पर सिम्लिंक कर सकते हैं जो हमें टेराफॉर्म के साथ नियंत्रित करने के लिए एक ही स्थान देता है। जहां हमें किसी स्थान के संसाधनों में कुछ अंतर हो सकते हैं, तो उन्हें अलग कर दिया जाएगा। उपर्युक्त उदाहरण में आप देख सकते हैं कि staging/global में global_component2.tf है जो उत्पादन में मौजूद नहीं है। यह ऐसा कुछ हो सकता है जो केवल गैर-उत्पादन वातावरण में लागू होता है जैसे पर्यावरण नेटवर्क तक इंटरनेट पहुंच को रोकने के लिए कुछ नेटवर्क नियंत्रण।

वास्तविक लाभ यह है कि डेवलपर्स के लिए स्रोत नियंत्रण में सबकुछ आसानी से देखा जा सकता है, जो टेराफॉर्म कोड जो आपके इच्छित टेराफॉर्म कोड उत्पन्न करता है।

यह डीआरवाई का पालन करने में भी मदद करता है जहां वातावरण के बीच केवल वास्तविक अंतर terraform.tfvars स्थानों में फाइलों में हैं और उन्हें लाइव रखने से पहले परिवर्तनों का परीक्षण करना आसान बनाता है क्योंकि प्रत्येक फ़ोल्डर दूसरे के समान ही होता है।