Ansible मधील व्हेरिएबल्सकडे प्रणालीचा दृष्टीकोन

उत्तरदायी devops codestyle

अहो! माझं नावं आहे डेनिस कल्युझनी मी विकास प्रक्रिया ऑटोमेशन विभागात अभियंता म्हणून काम करतो. दररोज, शेकडो मोहिम सर्व्हरवर नवीन अनुप्रयोग तयार केले जातात. आणि या लेखात मी या हेतूंसाठी उत्तरदायी वापरण्याचा माझा अनुभव सामायिक करतो.

हे मार्गदर्शक उपयोजनामध्ये व्हेरिएबल्स आयोजित करण्याचा एक मार्ग देते. हे मार्गदर्शक त्यांच्यासाठी आहे जे आधीच त्यांच्या प्लेबुकमध्ये भूमिका वापरतात आणि वाचले आहेत चांगला सराव, परंतु समान समस्यांना तोंड द्यावे लागते:

• कोडमध्ये व्हेरिएबल आढळल्यानंतर, ते कशासाठी जबाबदार आहे हे त्वरित समजणे अशक्य आहे;
• तेथे अनेक भूमिका आहेत आणि व्हेरिएबल्स एका मूल्याशी संबंधित असणे आवश्यक आहे, परंतु ते कार्य करत नाही;
• तुमच्या प्लेबुकमधील व्हेरिएबल्सचे तर्क कसे कार्य करतात हे इतरांना समजावून सांगण्यात अडचण येत आहे

आमच्या कंपनीतील प्रकल्पांवर आम्हाला या समस्या आल्या, परिणामी आम्ही आमच्या प्लेबुकमध्ये व्हेरिएबल्स डिझाइन करण्याच्या नियमांवर आलो, ज्यामुळे काही प्रमाणात या समस्यांचे निराकरण झाले.

भूमिकांमध्ये चल

भूमिका उपयोजन प्रणालीचा एक वेगळा ऑब्जेक्ट आहे. कोणत्याही सिस्टीम ऑब्जेक्ट प्रमाणे, त्यास उर्वरित सिस्टमसह परस्परसंवादासाठी इंटरफेस असणे आवश्यक आहे. असा इंटरफेस म्हणजे रोल व्हेरिएबल्स.

उदाहरणार्थ, भूमिका घेऊ api, जे सर्व्हरवर Java अनुप्रयोग स्थापित करते. त्यात कोणते चल असू शकतात?

प्रकारानुसार परिवर्तनीय भूमिका 2 प्रकारांमध्ये विभागल्या जाऊ शकतात:

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

परिवर्तनीय गुणधर्म हे चल आहेत जे भूमिकेचे वर्तन निर्धारित करतात.

क्वेरी व्हेरिएबल्स - हे व्हेरिएबल्स आहेत ज्यांचे मूल्य भूमिकेसाठी बाह्य संसाधने नियुक्त करण्यासाठी वापरले जाते.

परिवर्तनशील श्रोते - हे व्हेरिएबल्स आहेत ज्यांचे मूल्य विनंती व्हेरिएबल्स तयार करण्यासाठी वापरले जाते.

दुसरीकडे, 1a, 2a, 2b हे चल आहेत जे पर्यावरणावर अवलंबून नाहीत (हार्डवेअर, बाह्य संसाधने इ.) आणि डीफॉल्ट भूमिकेत डीफॉल्ट मूल्यांनी भरले जाऊ शकतात. तथापि, प्रकार 1.b आणि 2.c च्या व्हेरिएबल्सना ‘उदाहरण’ व्यतिरिक्त इतर मूल्यांसह भरणे अशक्य आहे, कारण ते वातावरणानुसार स्टँड टू स्टँड बदलतील.

कोड शैली

• व्हेरिएबलचे नाव भूमिकेच्या नावाने सुरू होणे आवश्यक आहे. हे व्हेरिएबल कोणत्या भूमिकेतून आहे आणि ते कशासाठी जबाबदार आहे हे भविष्यात शोधणे सोपे करेल.
• रोल्समध्ये व्हेरिएबल्स वापरताना, तुम्ही एन्कॅप्स्युलेशनच्या तत्त्वाचे पालन केल्याचे सुनिश्चित केले पाहिजे आणि एकतर भूमिकेमध्ये किंवा ज्या भूमिकांवर वर्तमान अवलंबून आहे त्यामध्ये परिभाषित व्हेरिएबल्स वापरणे आवश्यक आहे.

• व्हेरिएबल्ससाठी शब्दकोश वापरणे टाळा. Ansible तुम्हाला शब्दकोशातील वैयक्तिक मूल्ये सोयीस्करपणे ओव्हरराइड करण्याची परवानगी देत ​​नाही.

  खराब व्हेरिएबलचे उदाहरण:

  myrole_user:
      login: admin
      password: admin

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

  myrole_user_login: admin
  myrole_user_password: admin

उपयोजन प्लेबुकमधील चल

डिप्लॉयमेंट प्लेबुक (यापुढे प्लेबुक म्हणून संदर्भित) संकलित करताना, आम्ही नियमाचे पालन करतो की ते वेगळ्या भांडारात ठेवले पाहिजे. भूमिकांप्रमाणेच: प्रत्येक त्याच्या स्वतःच्या git भांडारात. हे तुम्हाला हे समजून घेण्यास अनुमती देते की भूमिका आणि प्लेबुक हे डिप्लॉयमेंट सिस्टमच्या वेगवेगळ्या स्वतंत्र वस्तू आहेत आणि एका ऑब्जेक्टमधील बदलांचा दुसऱ्याच्या ऑपरेशनवर परिणाम होऊ नये. व्हेरिएबल्सची डीफॉल्ट मूल्ये बदलून हे साध्य केले जाते.

प्लेबुक संकलित करताना, थोडक्यात, रोल व्हेरिएबल्सची डीफॉल्ट मूल्ये दोन ठिकाणी ओव्हरराइड करणे शक्य आहे: प्लेबुक व्हेरिएबल्समध्ये आणि इन्व्हेंटरी व्हेरिएबल्समध्ये.

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

*- व्हेरिएबल्स आणि व्हॉल्ट्स

फरक असा आहे की प्लेबुक व्हेरिएबल्स नेहमी त्याच स्तरावर असलेल्या प्लेबुकला कॉल करताना वापरले जातात. याचा अर्थ पर्यावरण-स्वतंत्र व्हेरिएबल्सची डीफॉल्ट मूल्ये बदलण्यासाठी हे व्हेरिएबल्स उत्तम आहेत. याउलट, इन्व्हेंटरी व्हेरिएबल्सचा वापर केवळ विशिष्ट वातावरणासाठी केला जाईल, जो पर्यावरण-विशिष्ट व्हेरिएबल्ससाठी आदर्श आहे.

हे लक्षात घेणे महत्त्वाचे आहे की व्हेरिएबल प्रायॉरिटी तुम्हाला प्लेबुक व्हेरिएबल्समध्ये प्रथम व्हेरिएबल्स ओव्हरराइड करू देणार नाही आणि नंतर एका इन्व्हेंटरीमध्ये स्वतंत्रपणे.

याचा अर्थ असा आहे की या टप्प्यावर आधीपासूनच व्हेरिएबल पर्यावरणावर अवलंबून आहे की नाही हे ठरवणे आणि ते योग्य ठिकाणी ठेवणे आवश्यक आहे.

उदाहरणार्थ, एका प्रकल्पात, SSL सक्षम करण्यासाठी जबाबदार व्हेरिएबल बर्याच काळापासून पर्यावरणावर अवलंबून होते, कारण आम्ही एका स्टँडवर आमच्या नियंत्रणाबाहेरील कारणांमुळे SSL सक्षम करू शकलो नाही. आम्ही या समस्येचे निराकरण केल्यानंतर, ते पर्यावरण स्वतंत्र झाले आणि प्लेबुक व्हेरिएबल्समध्ये हलविले.

गटांसाठी मालमत्ता चल

भिन्न Java ऍप्लिकेशनसह, परंतु भिन्न सेटिंग्जसह सर्व्हरचे 1 गट जोडून आकृती 2 मधील आमचे मॉडेल विस्तृत करू.

या प्रकरणात प्लेबुक कसे दिसेल याची कल्पना करूया:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

आमच्याकडे प्लेबुकमध्ये तीन गट आहेत, म्हणून लगेचच ग्रुप_vars इन्व्हेंटरी व्हेरिएबल्स आणि प्लेबुक व्हेरिएबल्समध्ये समान संख्येच्या गट फाइल्स तयार करण्याची शिफारस केली जाते. या प्रकरणात एक गट फाइल प्लेबुकमधील वरील अनुप्रयोगाच्या एका घटकाचे वर्णन आहे. जेव्हा तुम्ही प्लेबुक व्हेरिएबल्समध्ये ग्रुप फाइल उघडता, तेव्हा तुम्हाला ग्रुपवर इंस्टॉल केलेल्या भूमिकांच्या डीफॉल्ट वर्तनातील सर्व फरक लगेच दिसतात. इन्व्हेंटरी व्हेरिएबल्समध्ये: स्टँड ते स्टँड गटाच्या वर्तनातील फरक.

कोड शैली

• host_vars व्हेरिएबल्स अजिबात न वापरण्याचा प्रयत्न करा, कारण ते सिस्टमचे वर्णन करत नाहीत, परंतु केवळ एक विशेष प्रकरण, ज्यामुळे भविष्यात प्रश्न निर्माण होतील: "हे होस्ट इतरांपेक्षा वेगळे का आहे?", ज्याचे उत्तर नाही. शोधणे नेहमीच सोपे.

कम्युनिकेशन व्हेरिएबल्स

तथापि, प्रॉपर्टी व्हेरिएबल्स म्हणजे काय, पण कम्युनिकेशन व्हेरिएबल्सचे काय?
त्यांचा फरक असा आहे की वेगवेगळ्या गटांमध्ये त्यांचा समान अर्थ असावा.

सुरुवातीला ते होते कल्पना एक राक्षसी बांधकाम वापरा जसे:
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 }}"

आता, कनेक्टरचे मूल्य बदलून, आम्हाला खात्री होईल की विनंती त्याच ठिकाणी जाईल जिथे पोर्ट आहे.

कोड शैली

• भूमिका आणि गट भिन्न सिस्टम ऑब्जेक्ट्स असल्याने, त्यांना भिन्न नावे असणे आवश्यक आहे, नंतर लिंक व्हेरिएबल्स अचूकपणे सूचित करतील की ते सर्व्हरच्या विशिष्ट गटाशी संबंधित आहेत, आणि सिस्टममधील भूमिकेशी नाही.

पर्यावरणावर अवलंबून असलेल्या फाइल्स

भूमिका पर्यावरणानुसार भिन्न असलेल्या फाइल्स वापरू शकतात.

अशा फाइल्सचे उदाहरण म्हणजे SSL प्रमाणपत्रे. त्यांना मजकूर स्वरूपात साठवा
व्हेरिएबलमध्ये फार सोयीस्कर नाही. परंतु त्यांच्याकडे जाण्याचा मार्ग व्हेरिएबलमध्ये संग्रहित करणे सोयीचे आहे.

उदाहरणार्थ, आपण व्हेरिएबल वापरतो api_ssl_key_file: "/path/to/file".

हे स्पष्ट आहे की की प्रमाणपत्र पर्यावरणापासून पर्यावरणात बदलेल, हे एक पर्यावरण-अवलंबित व्हेरिएबल आहे, याचा अर्थ ते फाइलमध्ये स्थित असले पाहिजे.
group_vars/myapi/vars व्हेरिएबल्सची यादी आणि त्यात 'उदाहरणार्थ' मूल्य असते.

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

एका वातावरणात अनेक स्टँड

बर्‍याचदा समान वातावरणात कमीतकमी फरकांसह अनेक जवळजवळ एकसारखे स्टँड तैनात करण्याची आवश्यकता असते. या प्रकरणात, आम्ही पर्यावरण-आश्रित व्हेरिएबल्सचे विभाजन करतो जे या वातावरणात बदलत नाहीत आणि जे बदलतात. आणि आम्ही नंतरचे थेट इन्व्हेंटरी फाइल्समध्ये हस्तांतरित करतो. या हाताळणीनंतर, थेट पर्यावरण निर्देशिकेत दुसरी यादी तयार करणे शक्य होते.

ते group_vars इन्व्हेंटरीचा पुन्हा वापर करेल आणि काही व्हेरिएबल्स थेट स्वतःसाठी पुन्हा परिभाषित करण्यास सक्षम असेल.

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

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