Ansible मा चरहरूको लागि प्रणाली दृष्टिकोण

उत्तरदायी devops codestyle

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

यो गाइडले परिनियोजनमा चरहरू व्यवस्थित गर्ने तरिका प्रदान गर्दछ। यो गाइड तिनीहरूका लागि डिजाइन गरिएको हो जसले पहिले नै आफ्नो प्लेबुकमा भूमिकाहरू प्रयोग गर्छन् र पढ्छन् उत्तम अभ्यासहरूतर समान समस्याहरूमा दौडिरहेको छ:

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

हामीले हाम्रो कम्पनीमा परियोजनाहरूमा यी समस्याहरूको सामना गर्यौं, जसको परिणाम स्वरूप हामी हाम्रा प्लेबुकहरूमा चरहरू ढाँचाका लागि नियमहरूमा आएका छौं, जसले केही हदसम्म यी समस्याहरू समाधान गर्यो।

भूमिकाहरूमा चरहरू

एक भूमिका एक अलग डिप्लोइमेन्ट सिस्टम वस्तु हो। प्रणालीको कुनै पनि वस्तु जस्तै, यो प्रणालीको बाँकीसँग अन्तरक्रिया गर्नको लागि इन्टरफेस हुनुपर्छ। भूमिका चर यस्तो इन्टरफेस हो।

उदाहरणका लागि, भूमिका लिनुहोस् api, जसले सर्भरमा जाभा अनुप्रयोग स्थापना गर्दछ। यसमा कस्ता चरहरू छन्?

भूमिका चरहरूलाई प्रकारद्वारा २ प्रकारमा विभाजन गर्न सकिन्छ:

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

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

क्वेरी चर चरहरू हुन् जसको मान भूमिकामा बाह्य स्रोतहरू निर्दिष्ट गर्न प्रयोग गरिन्छ।

परिवर्तनशील श्रोताहरू भेरिएबलहरू हुन् जसको मान क्वेरी चरहरू बनाउन प्रयोग गरिन्छ।

अर्कोतर्फ, 1a, 2a, 2b चरहरू हुन् जुन वातावरणमा निर्भर हुँदैन (फलाम, बाह्य स्रोतहरू, आदि) र पूर्वनिर्धारित भूमिकामा पूर्वनिर्धारित मानहरू भर्न सकिन्छ। यद्यपि, 1.b र 2.c जस्ता चरहरूलाई 'उदाहरण' बाहेक अन्य मानहरूले भर्न सकिँदैन, किनकि तिनीहरू वातावरणको आधारमा स्ट्यान्ड देखि स्ट्यान्डमा परिवर्तन हुनेछन्।

कोड शैली

• चरको नाम भूमिकाको नामबाट सुरु हुनुपर्छ। यसले भविष्यमा भ्यारीएबल कुन भूमिकाबाट हो र यसको लागि जिम्मेवार छ भनेर पत्ता लगाउन सजिलो बनाउँदछ।
• भूमिकाहरूमा चरहरू प्रयोग गर्दा, तपाईंले encapsulation को सिद्धान्तको पालना गर्न र भूमिकामा वा हालको निर्भर हुने भूमिकाहरूमा परिभाषित चरहरू प्रयोग गर्न निश्चित हुनुपर्छ।

• चरका लागि शब्दकोशहरू प्रयोग नगर्नुहोस्। 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 सक्षम गर्न सकेनौं। हामीले यो समस्या समाधान गरेपछि, यो मध्यम स्वतन्त्र भयो र प्लेबुक चरहरूमा सारियो।

समूहहरूको लागि सम्पत्ति चर

फरक जाभा एप्लिकेसनको साथ, तर फरक सेटिङहरूसँग सर्भरका २ समूहहरू थपेर चित्र १ मा हाम्रो मोडेल विस्तार गरौं।

यस अवस्थामा प्लेबुक कस्तो देखिन्छ कल्पना गर्नुहोस्:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

हामीसँग प्लेबुकमा तीनवटा समूहहरू छन्, त्यसैले यसलाई group_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. दस्तावेज

लेखक

Kalyuzhny डेनिस Alexandrovich

स्रोत: www.habr.com