അൻസിബിളിലെ വേരിയബിളുകളിലേക്കുള്ള സിസ്റ്റം സമീപനം

ansible devops codestyle

ഹേയ്! എന്റെ പേര് ഡെനിസ് കലുഷ്നി ഞാൻ ഡെവലപ്‌മെന്റ് പ്രോസസ് ഓട്ടോമേഷൻ ഡിപ്പാർട്ട്‌മെന്റിൽ എഞ്ചിനീയറായി ജോലി ചെയ്യുന്നു. എല്ലാ ദിവസവും, നൂറുകണക്കിന് കാമ്പെയ്‌ൻ സെർവറുകളിൽ പുതിയ ആപ്ലിക്കേഷൻ ബിൽഡുകൾ പുറത്തിറക്കുന്നു. ഈ ആവശ്യങ്ങൾക്കായി അൻസിബിൾ ഉപയോഗിച്ചതിന്റെ അനുഭവം ഈ ലേഖനത്തിൽ ഞാൻ പങ്കുവെക്കുന്നു.

ഈ ഗൈഡ് വിന്യാസത്തിൽ വേരിയബിളുകൾ സംഘടിപ്പിക്കുന്നതിനുള്ള ഒരു മാർഗം വാഗ്ദാനം ചെയ്യുന്നു. ഈ ഗൈഡ് അവരുടെ പ്ലേബുക്കുകളിൽ ഇതിനകം റോളുകൾ ഉപയോഗിക്കുന്നവർക്കും വായിച്ചിട്ടുള്ളവർക്കും വേണ്ടിയുള്ളതാണ് മികച്ച രീതികൾ, എന്നാൽ സമാനമായ പ്രശ്നങ്ങൾ അഭിമുഖീകരിക്കുന്നു:

• കോഡിൽ ഒരു വേരിയബിൾ കണ്ടെത്തിയതിനാൽ, അതിന്റെ ഉത്തരവാദിത്തം എന്താണെന്ന് പെട്ടെന്ന് മനസ്സിലാക്കാൻ കഴിയില്ല;
• നിരവധി റോളുകൾ ഉണ്ട്, വേരിയബിളുകൾ ഒരു മൂല്യവുമായി ബന്ധപ്പെടുത്തേണ്ടതുണ്ട്, പക്ഷേ അത് പ്രവർത്തിക്കുന്നില്ല;
• നിങ്ങളുടെ പ്ലേബുക്കുകളിലെ വേരിയബിളുകളുടെ ലോജിക് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് മറ്റുള്ളവരോട് വിശദീകരിക്കാൻ ബുദ്ധിമുട്ടുണ്ട്

ഞങ്ങളുടെ കമ്പനിയിലെ പ്രോജക്റ്റുകളിൽ ഞങ്ങൾ ഈ പ്രശ്നങ്ങൾ നേരിട്ടു, അതിന്റെ ഫലമായി ഞങ്ങളുടെ പ്ലേബുക്കുകളിൽ വേരിയബിളുകൾ രൂപകൽപ്പന ചെയ്യുന്നതിനുള്ള നിയമങ്ങളിൽ ഞങ്ങൾ എത്തി, ഇത് ഒരു പരിധിവരെ ഈ പ്രശ്നങ്ങൾ പരിഹരിച്ചു.

റോളുകളിലെ വേരിയബിളുകൾ

വിന്യാസ സംവിധാനത്തിന്റെ ഒരു പ്രത്യേക വസ്തുവാണ് റോൾ. ഏതൊരു സിസ്റ്റം ഒബ്‌ജക്‌റ്റിനേയും പോലെ, സിസ്റ്റത്തിന്റെ ബാക്കിയുള്ളവയുമായി സംവദിക്കുന്നതിന് ഇതിന് ഒരു ഇന്റർഫേസ് ഉണ്ടായിരിക്കണം. അത്തരമൊരു ഇന്റർഫേസ് റോൾ വേരിയബിളുകളാണ്.

ഉദാഹരണത്തിന്, റോൾ എടുക്കാം api, സെർവറിൽ ഒരു ജാവ ആപ്ലിക്കേഷൻ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ഇതിന് എന്ത് വേരിയബിളുകൾ ഉണ്ടായിരിക്കാം?

തരം അനുസരിച്ച് വേരിയബിൾ റോളുകളെ 2 തരങ്ങളായി തിരിക്കാം:

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

വേരിയബിൾ പ്രോപ്പർട്ടികൾ ഒരു റോളിന്റെ സ്വഭാവം നിർണ്ണയിക്കുന്ന വേരിയബിളുകളാണ്.

അന്വേഷണ വേരിയബിളുകൾ - റോളിന് പുറത്തുള്ള വിഭവങ്ങളെ നിയോഗിക്കാൻ മൂല്യം ഉപയോഗിക്കുന്ന വേരിയബിളുകളാണിവ.

വേരിയബിൾ ശ്രോതാക്കൾ - അഭ്യർത്ഥന വേരിയബിളുകൾ രൂപപ്പെടുത്തുന്നതിന് മൂല്യം ഉപയോഗിക്കുന്ന വേരിയബിളുകളാണ് ഇവ.

മറുവശത്ത്, 1a, 2a, 2b എന്നത് പരിസ്ഥിതിയെ (ഹാർഡ്‌വെയർ, ബാഹ്യ ഉറവിടങ്ങൾ മുതലായവ) ആശ്രയിക്കാത്ത വേരിയബിളുകളാണ്, കൂടാതെ ഡിഫോൾട്ട് റോളിൽ സ്ഥിരസ്ഥിതി മൂല്യങ്ങൾ ഉപയോഗിച്ച് പൂരിപ്പിക്കാനും കഴിയും. എന്നിരുന്നാലും, തരം 1.b, 2.c എന്നിവയുടെ വേരിയബിളുകൾ 'ഉദാഹരണം' ഒഴികെയുള്ള മൂല്യങ്ങൾ ഉപയോഗിച്ച് പൂരിപ്പിക്കുന്നത് അസാധ്യമാണ്, കാരണം അവ പരിസ്ഥിതിയെ ആശ്രയിച്ച് സ്റ്റാൻഡിൽ നിന്ന് സ്റ്റാൻഡിലേക്ക് മാറും.

കോഡ് ശൈലി

• വേരിയബിൾ നാമം റോൾ നാമത്തിൽ ആരംഭിക്കണം. ഭാവിയിൽ വേരിയബിളിന്റെ പങ്ക് എന്താണെന്നും അതിന്റെ ഉത്തരവാദിത്തം എന്താണെന്നും മനസിലാക്കാൻ ഇത് എളുപ്പമാക്കും.
• റോളുകളിൽ വേരിയബിളുകൾ ഉപയോഗിക്കുമ്പോൾ, എൻക്യാപ്‌സുലേഷന്റെ തത്വം നിങ്ങൾ പിന്തുടരുകയും റോളിൽ തന്നെ അല്ലെങ്കിൽ നിലവിലുള്ളത് ആശ്രയിക്കുന്ന റോളുകളിൽ നിർവചിച്ചിരിക്കുന്ന വേരിയബിളുകൾ ഉപയോഗിക്കുകയും വേണം.

• വേരിയബിളുകൾക്കായി നിഘണ്ടുക്കൾ ഉപയോഗിക്കുന്നത് ഒഴിവാക്കുക. ഒരു നിഘണ്ടുവിൽ വ്യക്തിഗത മൂല്യങ്ങൾ സൗകര്യപ്രദമായി മറികടക്കാൻ അൻസിബിൾ നിങ്ങളെ അനുവദിക്കുന്നില്ല.

  ഒരു മോശം വേരിയബിളിന്റെ ഉദാഹരണം:

  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   # Секреты (всегда средозависимы) *

* - വേരിയബിളുകളും നിലവറകളും

ഒരേ തലത്തിൽ സ്ഥിതി ചെയ്യുന്ന പ്ലേബുക്കുകളെ വിളിക്കുമ്പോൾ പ്ലേബുക്ക് വേരിയബിളുകൾ എപ്പോഴും ഉപയോഗിക്കുമെന്നതാണ് വ്യത്യാസം. പരിസ്ഥിതി-സ്വതന്ത്ര വേരിയബിളുകളുടെ സ്ഥിരസ്ഥിതി മൂല്യങ്ങൾ മാറ്റുന്നതിന് ഈ വേരിയബിളുകൾ മികച്ചതാണെന്ന് ഇതിനർത്ഥം. നേരെമറിച്ച്, ഇൻവെന്ററി വേരിയബിളുകൾ ഒരു പ്രത്യേക പരിതസ്ഥിതിക്ക് മാത്രമേ ഉപയോഗിക്കൂ, അത് പരിസ്ഥിതി-നിർദ്ദിഷ്ട വേരിയബിളുകൾക്ക് അനുയോജ്യമാണ്.

ആദ്യം പ്ലേബുക്ക് വേരിയബിളുകളിലും പിന്നീട് ഒരു ഇൻവെന്ററിയിലും വേരിയബിളുകൾ അസാധുവാക്കാൻ വേരിയബിൾ മുൻഗണന നിങ്ങളെ അനുവദിക്കില്ല എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്.

ഇതിനർത്ഥം, ഈ ഘട്ടത്തിൽ, വേരിയബിൾ പരിസ്ഥിതിയെ ആശ്രയിക്കുന്നുണ്ടോ ഇല്ലയോ എന്ന് തീരുമാനിക്കുകയും ഉചിതമായ സ്ഥലത്ത് സ്ഥാപിക്കുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്.

ഉദാഹരണത്തിന്, ഒരു പ്രോജക്റ്റിൽ, SSL പ്രവർത്തനക്ഷമമാക്കുന്നതിന് ഉത്തരവാദിയായ വേരിയബിൾ വളരെക്കാലം പരിസ്ഥിതിയെ ആശ്രയിച്ചിരിക്കുന്നു, കാരണം ഒരു സ്റ്റാൻഡിൽ ഞങ്ങളുടെ നിയന്ത്രണത്തിന് അതീതമായ കാരണങ്ങളാൽ ഞങ്ങൾക്ക് SSL പ്രവർത്തനക്ഷമമാക്കാൻ കഴിഞ്ഞില്ല. ഞങ്ങൾ ഈ പ്രശ്നം പരിഹരിച്ച ശേഷം, അത് പരിസ്ഥിതി സ്വതന്ത്രമാവുകയും പ്ലേബുക്ക് വേരിയബിളുകളിലേക്ക് മാറുകയും ചെയ്തു.

ഗ്രൂപ്പുകൾക്കുള്ള പ്രോപ്പർട്ടി വേരിയബിളുകൾ

വ്യത്യസ്തമായ ജാവ ആപ്ലിക്കേഷനുള്ള 1 ഗ്രൂപ്പുകളുടെ സെർവറുകൾ ചേർത്ത് ചിത്രം 2-ൽ നമ്മുടെ മോഡൽ വികസിപ്പിക്കാം, എന്നാൽ വ്യത്യസ്ത ക്രമീകരണങ്ങൾ.

ഈ സാഹചര്യത്തിൽ പ്ലേബുക്ക് എങ്ങനെയായിരിക്കുമെന്ന് നമുക്ക് സങ്കൽപ്പിക്കാം:

- 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. ഡോക്യുമെന്റേഷൻ

രചയിതാവ്

കല്യുഷ്നി ഡെനിസ് അലക്സാണ്ട്രോവിച്ച്

അവലംബം: www.habr.com