Ansible में वेरिएबल्स के लिए सिस्टम दृष्टिकोण

ansible डेवॉप्स कोडस्टाइल

अरे! मेरा नाम है डेनिस कल्युज़्नी मैं विकास प्रक्रिया स्वचालन विभाग में एक इंजीनियर के रूप में काम करता हूँ। हर दिन, नए एप्लिकेशन बिल्ड को सैकड़ों अभियान सर्वरों पर रोल आउट किया जाता है। और इस लेख में, मैं इन उद्देश्यों के लिए Ansible का उपयोग करने का अपना अनुभव साझा करता हूं।

यह मार्गदर्शिका परिनियोजन में चरों को व्यवस्थित करने का एक तरीका प्रदान करती है। यह मार्गदर्शिका उन लोगों के लिए डिज़ाइन की गई है जो पहले से ही अपनी प्लेबुक में भूमिकाओं का उपयोग करते हैं और पढ़ते हैं सर्वोत्तम प्रथाएंलेकिन समान समस्याओं में चल रहा है:

• कोड में एक वेरिएबल मिलने के बाद, यह तुरंत समझना असंभव है कि यह किसके लिए जिम्मेदार है;
• कई भूमिकाएँ हैं, और चर को एक मान के साथ संबद्ध करने की आवश्यकता है, लेकिन यह काम नहीं करता है;
• दूसरों को यह समझाने में कठिनाई हो रही है कि आपकी प्लेबुक में चर का तर्क कैसे काम करता है

हमें अपनी कंपनी में परियोजनाओं पर इन समस्याओं का सामना करना पड़ा, जिसके परिणामस्वरूप हम अपनी प्लेबुक में वेरिएबल्स को फ़ॉर्मेट करने के नियमों तक पहुंचे, जिससे कुछ हद तक इन समस्याओं का समाधान हो गया।

भूमिकाओं में परिवर्तनशील

भूमिका एक अलग परिनियोजन सिस्टम ऑब्जेक्ट है। सिस्टम के किसी भी ऑब्जेक्ट की तरह, इसमें सिस्टम के बाकी हिस्सों के साथ इंटरैक्ट करने के लिए एक इंटरफ़ेस होना चाहिए। भूमिका चर एक ऐसा इंटरफ़ेस है।

उदाहरण के लिए, भूमिका को ही लीजिए api, जो सर्वर पर जावा एप्लिकेशन इंस्टॉल करता है। इसमें कौन से चर हैं?

भूमिका चर को प्रकार के अनुसार 2 प्रकारों में विभाजित किया जा सकता है:

1. Свойства
    a) независимые от среды
    б) зависимые от среды
2. Связи
    a) слушатели 
    б) запросы внутри системы
    в) запросы в среду

परिवर्तनशील गुण वे चर हैं जो किसी भूमिका के व्यवहार को परिभाषित करते हैं।

क्वेरी वेरिएबल्स वे चर हैं जिनके मान का उपयोग भूमिका से बाहर के संसाधनों को निर्दिष्ट करने के लिए किया जाता है।

परिवर्तनशील श्रोता वे वेरिएबल हैं जिनके मान का उपयोग क्वेरी वेरिएबल बनाने के लिए किया जाता है।

दूसरी ओर, 1ए, 2ए, 2बी वेरिएबल हैं जो पर्यावरण (लोहा, बाहरी संसाधन, आदि) पर निर्भर नहीं होते हैं और डिफ़ॉल्ट भूमिका में डिफ़ॉल्ट मानों से भरे जा सकते हैं। हालाँकि, 1.b और 2.c जैसे वेरिएबल्स को 'उदाहरण' के अलावा अन्य मानों से नहीं भरा जा सकता है, क्योंकि वे पर्यावरण के आधार पर स्टैंड से स्टैंड में बदल जाएंगे।

कोड शैली

• वेरिएबल का नाम भूमिका के नाम से शुरू होना चाहिए। इससे भविष्य में यह पता लगाना आसान हो जाएगा कि वेरिएबल की क्या भूमिका है और वह किसके लिए जिम्मेदार है।
• भूमिकाओं में वेरिएबल्स का उपयोग करते समय, आपको एनकैप्सुलेशन के सिद्धांत का पालन करना सुनिश्चित करना चाहिए और या तो भूमिका में या उन भूमिकाओं में परिभाषित वेरिएबल्स का उपयोग करना चाहिए जिन पर वर्तमान भूमिका निर्भर करती है।

• चरों के लिए शब्दकोशों का उपयोग करने से बचें। Ansible आपको किसी शब्दकोश में व्यक्तिगत मानों को आसानी से ओवरराइड करने की अनुमति नहीं देता है।

  ख़राब वैरिएबल का एक उदाहरण:

  myrole_user:
      login: admin
      password: admin

  यहां, लॉगिन माध्यिका चर है, और पासवर्ड आश्रित चर है। लेकिन
  चूँकि इन्हें एक शब्दकोश में संयोजित किया गया है, इसलिए आपको इसे पूर्ण रूप से निर्दिष्ट करना होगा
  हमेशा। जो बहुत असुविधाजनक है. इस तरह बेहतर है:

  myrole_user_login: admin
  myrole_user_password: admin

परिनियोजन प्लेबुक में चर

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

किसी प्लेबुक को संकलित करते समय, संक्षेप में कहें तो, दो स्थानों पर भूमिका चर के डिफ़ॉल्ट मानों को ओवरराइड करना संभव है: प्लेबुक चर में और इन्वेंट्री चर में।

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   └── myapi.yml               # Файл переменных свойств группы myapi
└── inventories                 #
    └── prod                    # Каталог окружения prod
        ├── prod.ini            # Инвентори файл
        └── group_vars          # Каталог для переменных инвентори
            └── myapi           #
                ├── vars.yml    # Средозависимые переменные группы myapi
                └── vault.yml   # Секреты (всегда средозависимы) *

*— वेरिएबल्स और वॉल्ट्स

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

यह ध्यान रखना महत्वपूर्ण है कि परिवर्तनीय प्राथमिकता आपको पहले प्लेबुक वेरिएबल्स में और फिर एक ही इन्वेंट्री में अलग-अलग वेरिएबल्स को फिर से परिभाषित करने की अनुमति नहीं देगी।

इसका मतलब यह है कि पहले से ही इस स्तर पर आपको यह तय करने की आवश्यकता है कि चर पर्यावरण-निर्भर है या नहीं और इसे सही जगह पर रखें।

उदाहरण के लिए, एक प्रोजेक्ट में, एसएसएल को सक्षम करने के लिए जिम्मेदार वेरिएबल लंबे समय तक पर्यावरण पर निर्भर था, क्योंकि हम किसी एक स्टैंड पर अपने नियंत्रण से परे कारणों से एसएसएल को सक्षम नहीं कर सके। इस समस्या को ठीक करने के बाद, यह माध्यम स्वतंत्र हो गया और प्लेबुक वेरिएबल्स में चला गया।

समूहों के लिए संपत्ति चर

आइए अलग-अलग जावा एप्लिकेशन के साथ, लेकिन अलग-अलग सेटिंग्स के साथ सर्वर के 1 समूहों को जोड़कर चित्र 2 में अपने मॉडल का विस्तार करें।

कल्पना करें कि इस मामले में प्लेबुक कैसी दिखेगी:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

हमारे पास प्लेबुक में तीन समूह हैं, इसलिए एक बार में ग्रुप_वार्स इन्वेंट्री वेरिएबल्स और प्लेबुक वेरिएबल्स में अधिक से अधिक समूह फ़ाइलें बनाने की अनुशंसा की जाती है। इस मामले में एक समूह फ़ाइल प्लेबुक में आपके एप्लिकेशन के एक घटक का विवरण है। जब आप प्लेबुक वेरिएबल्स में समूह फ़ाइल खोलते हैं, तो आपको तुरंत समूह को सौंपी गई भूमिकाओं के डिफ़ॉल्ट व्यवहार से सभी अंतर दिखाई देते हैं। इन्वेंट्री चर में: बूथ से बूथ तक समूह व्यवहार में अंतर।

कोड शैली

• कोशिश करें कि होस्ट_वर्स वेरिएबल्स का बिल्कुल भी उपयोग न करें, क्योंकि वे सिस्टम का वर्णन नहीं करते हैं, बल्कि केवल एक विशेष मामले का वर्णन करते हैं, जो लंबे समय में सवालों को जन्म देगा: "यह होस्ट बाकियों से अलग क्यों है?", जिसका उत्तर है ढूंढना हमेशा आसान नहीं होता.

चर लिंक करें

हालाँकि, यह संपत्ति चर के बारे में है, लेकिन लिंक चर के बारे में क्या?
उनका अंतर यह है कि विभिन्न समूहों में उनका मूल्य समान होना चाहिए।

शुरुआत में वहाँ था विचार प्रपत्र के एक राक्षसी निर्माण का उपयोग करें:
hostvars[groups['bbauth'][0]]['auth_bind_port'], लेकिन इसे तुरंत छोड़ दिया गया
क्योंकि इसमें खामियां हैं. सबसे पहले, भारीपन. दूसरे, समूह में एक विशिष्ट मेजबान पर निर्भरता। तीसरा, यदि हम अपरिभाषित परिवर्तनीय त्रुटि प्राप्त नहीं करना चाहते हैं, तो तैनाती शुरू करने से पहले सभी मेजबानों से तथ्य एकत्र करना आवश्यक है।

परिणामस्वरूप, लिंक वेरिएबल्स का उपयोग करने का निर्णय लिया गया।

चर लिंक करें वे वेरिएबल हैं जो प्लेबुक से संबंधित हैं और सिस्टम ऑब्जेक्ट को लिंक करने के लिए आवश्यक हैं।

लिंक वेरिएबल सामान्य सिस्टम वेरिएबल में भरे जाते हैं group_vars/all/vars और प्रत्येक समूह से सभी श्रोता चर को हटाकर, और उस समूह का नाम जोड़कर बनाया जाता है जहां से श्रोता को चर की शुरुआत में हटाया गया था।

इस प्रकार, नामों की एकरूपता और गैर-प्रतिच्छेदन सुनिश्चित किया जाता है।

आइए उपरोक्त उदाहरण से वेरिएबल्स को बाइंड करने का प्रयास करें:

कल्पना करें कि हमारे पास वेरिएबल हैं जो एक-दूसरे पर निर्भर हैं:

# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"

# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"

आइए इसे सामान्य चरों में रखें group_vars/all/vars सभी श्रोता, और नाम के साथ समूह का नाम जोड़ें:

# group_vars/all/vars
bbauth_auth_bind_port: "20000"
ghauth_auth_bind_port: "30000"

# group_vars/bbauth/vars
auth_bind_port: "{{ bbauth_auth_bind_port }}"

# group_vars/ghauth/vars
auth_bind_port: "{{ ghauth_auth_bind_port }}"

# group_vars/myapi/vars
api_auth1_address: "http://{{ bbauth_auth_service_name }}:{{ bbauth_auth_bind_port }}"
api_auth2_address: "http://{{ ghauth_auth_service_name }}:{{ ghauth_auth_bind_port }}"

अब, कनेक्टर का मान बदलकर, हम यह सुनिश्चित करेंगे कि अनुरोध उसी पोर्ट पर जाएगा।

कोड शैली

• चूँकि भूमिकाएँ और समूह अलग-अलग सिस्टम ऑब्जेक्ट हैं, इसलिए उनके अलग-अलग नाम होने चाहिए ताकि लिंक वेरिएबल सटीक रूप से दिखा सकें कि वे एक विशिष्ट सर्वर समूह से संबंधित हैं, न कि सिस्टम में किसी भूमिका के लिए।

पर्यावरण फ़ाइलें

भूमिकाएँ उन फ़ाइलों का उपयोग कर सकती हैं जो अलग-अलग परिवेश में भिन्न होती हैं।

एसएसएल प्रमाणपत्र ऐसी फ़ाइलों का एक उदाहरण हैं। उन्हें टेक्स्ट के रूप में संग्रहीत करें
एक वेरिएबल में बहुत सुविधाजनक नहीं है. लेकिन उनके लिए पथ को एक वेरिएबल के अंदर संग्रहीत करना सुविधाजनक है।

उदाहरण के लिए, हम वेरिएबल का उपयोग करते हैं api_ssl_key_file: "/path/to/file".

चूंकि यह स्पष्ट है कि कुंजी प्रमाणपत्र पर्यावरण से पर्यावरण में बदल जाएगा, यह एक पर्यावरण-निर्भर चर है, जिसका अर्थ है कि इसे फ़ाइल में स्थित होना चाहिए
group_vars/myapi/vars चरों की सूची, और 'उदाहरण के लिए' मान शामिल है।

इस मामले में सबसे सुविधाजनक तरीका कुंजी फ़ाइल को पथ के साथ प्लेबुक रिपॉजिटरी में रखना है
files/prod/certs/myapi.key, तो चर का मान होगा:
api_ssl_key_file: "prod/certs/myapi.key". सुविधा इस तथ्य में निहित है कि किसी विशेष स्टैंड पर सिस्टम को तैनात करने के लिए जिम्मेदार लोगों के पास अपनी फ़ाइलों को संग्रहीत करने के लिए रिपॉजिटरी में अपना स्वयं का समर्पित स्थान भी होता है। साथ ही, यदि प्रमाणपत्र किसी अन्य सिस्टम द्वारा आपूर्ति किए जाते हैं तो सर्वर पर प्रमाणपत्र के लिए पूर्ण पथ निर्दिष्ट करना संभव रहता है।

एक वातावरण में एकाधिक स्टैंड

अक्सर न्यूनतम अंतर के साथ एक ही वातावरण में कई लगभग समान स्टैंडों को तैनात करने की आवश्यकता होती है। इस मामले में, हम पर्यावरण-निर्भर चर को उन लोगों में विभाजित करते हैं जो इस वातावरण में नहीं बदलते हैं और जो बदलते हैं। और हम बाद वाले को सीधे इन्वेंट्री फ़ाइलों में ही निकाल लेते हैं। इस हेरफेर के बाद, पर्यावरण निर्देशिका में सीधे एक और इन्वेंट्री बनाना संभव हो जाता है।

यह ग्रुप_वर्स इन्वेंट्री का पुन: उपयोग करेगा और सीधे अपने लिए कुछ वेरिएबल्स को फिर से परिभाषित करने में भी सक्षम होगा।

परिनियोजन परियोजना के लिए अंतिम निर्देशिका संरचना:

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── files                       # Каталог для файлов деплоя
│   ├── prod                    # Католог для средозависимых файлов стенда prod
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Каталог для средозависимых файлов стенда test1
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   ├── myapi.yml               # Файл переменных свойств группы myapi
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Каталог окружения prod
    │   ├── group_vars          # Каталог для переменных инвентори
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Средозависимые переменные группы myapi
    │   │   │   └── vault.yml   # Секреты (всегда средозависимы)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Инвентори стенда prod
    └── test                    # Каталог окружения test
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Инвентори стенда test1 в среде test
        └── test2.ini           # Инвентори стенда test2 в среде test

उपसंहार

लेख के अनुसार वेरिएबल्स को व्यवस्थित करने के बाद: वेरिएबल्स वाली प्रत्येक फ़ाइल एक विशिष्ट कार्य के लिए ज़िम्मेदार है। और चूँकि फ़ाइल में कुछ कार्य हैं, इसलिए प्रत्येक फ़ाइल की शुद्धता के लिए एक व्यक्ति को जिम्मेदार नियुक्त करना संभव हो गया। उदाहरण के लिए, सिस्टम परिनियोजन का डेवलपर प्लेबुक वेरिएबल्स को सही ढंग से भरने के लिए जिम्मेदार हो जाता है, जबकि प्रशासक, जिसका स्टैंड इन्वेंट्री में वर्णित है, वेरिएबल्स की इन्वेंट्री भरने के लिए सीधे जिम्मेदार है।

भूमिकाएँ अपने स्वयं के इंटरफ़ेस के साथ एक स्व-निहित विकास इकाई बन गईं, जिससे भूमिका डेवलपर को सिस्टम में फिट होने के लिए भूमिका को तैयार करने के बजाय सुविधाएँ विकसित करने की अनुमति मिली। यह समस्या किसी अभियान में सभी प्रणालियों की सामान्य भूमिकाओं के लिए विशेष रूप से सच थी।

सिस्टम प्रशासकों को अब परिनियोजन कोड को समझने की आवश्यकता नहीं है। एक सफल परिनियोजन के लिए उन्हें केवल पर्यावरण चर की फाइलों को भरना आवश्यक है।

साहित्य

1. अभिलेख

लेखक

कलयुज़नी डेनिस अलेक्जेंड्रोविच

स्रोत: www.habr.com