സമീപനം IaC (കോഡ് ആയി ഇൻഫ്രാസ്ട്രക്ചർ) ശേഖരത്തിൽ സംഭരിച്ചിരിക്കുന്ന കോഡ് മാത്രമല്ല, ഈ കോഡിനെ ചുറ്റിപ്പറ്റിയുള്ള ആളുകളും പ്രക്രിയകളും ഉൾക്കൊള്ളുന്നു. സോഫ്റ്റ്‌വെയർ വികസനം മുതൽ ഇൻഫ്രാസ്ട്രക്ചർ മാനേജ്‌മെന്റും വിവരണവും വരെയുള്ള സമീപനങ്ങൾ പുനരുപയോഗിക്കാൻ കഴിയുമോ? ലേഖനം വായിക്കുമ്പോൾ ഈ ആശയം മനസ്സിൽ സൂക്ഷിക്കുന്നത് നന്നായിരിക്കും.

ഇംഗ്ലീഷ് പതിപ്പ്

ഇത് എന്റെ ഒരു ട്രാൻസ്ക്രിപ്റ്റ് ആണ് പ്രകടനങ്ങൾ ഓൺ DevopsConf 2019-05-28.

സ്ലൈഡുകളും വീഡിയോകളും

• ഇംഗ്ലീഷ് പതിപ്പ്
• റഷ്യൻ പതിപ്പ്
• ഡ്രൈ റൺ 2019-04-24 SpbLUG
• DevopsConf 2019-05-28-ൽ നിന്നുള്ള വീഡിയോ(RU).
• വീഡിയോ(RU) DINS DevOps ഈവനിംഗ് 2019-06-20
• സ്ലൈഡ്

ബാഷ് ചരിത്രമായി അടിസ്ഥാന സൗകര്യങ്ങൾ

നിങ്ങൾ ഒരു പുതിയ പ്രോജക്റ്റിലേക്ക് വരുന്നുവെന്ന് കരുതുക, അവർ നിങ്ങളോട് പറയുന്നു: “ഞങ്ങൾക്ക് ഉണ്ട് അടിസ്ഥാന സൗകര്യങ്ങൾ ഒരു കോഡായി". വാസ്തവത്തിൽ അത് മാറുന്നു ബാഷ് ചരിത്രമായി അടിസ്ഥാന സൗകര്യങ്ങൾ അല്ലെങ്കിൽ ഉദാഹരണത്തിന് ബാഷ് ചരിത്രമായി ഡോക്യുമെന്റേഷൻ. ഇത് വളരെ യഥാർത്ഥ സാഹചര്യമാണ്, ഉദാഹരണത്തിന്, സമാനമായ ഒരു കേസ് ഡെനിസ് ലൈസെൻകോ ഒരു പ്രസംഗത്തിൽ വിവരിച്ചു മുഴുവൻ ഇൻഫ്രാസ്ട്രക്ചറും മാറ്റി എങ്ങനെ സുഖമായി ഉറങ്ങാൻ തുടങ്ങും, ബാഷ് ചരിത്രത്തിൽ നിന്ന് പ്രോജക്റ്റിനായി അവർക്ക് ഒരു യോജിച്ച ഇൻഫ്രാസ്ട്രക്ചർ എങ്ങനെ ലഭിച്ചുവെന്ന് അദ്ദേഹം പറഞ്ഞു.

കുറച്ച് ആഗ്രഹം കൊണ്ട് നമുക്ക് അത് പറയാം ബാഷ് ചരിത്രമായി അടിസ്ഥാന സൗകര്യങ്ങൾ ഇത് കോഡ് പോലെയാണ്:

1. പുനരുൽപാദനക്ഷമത: നിങ്ങൾക്ക് ബാഷ് ഹിസ്റ്ററി എടുക്കാനും അവിടെ നിന്ന് കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കാനും കഴിയും, കൂടാതെ നിങ്ങൾക്ക് ഒരു ഔട്ട്പുട്ടായി ഒരു വർക്കിംഗ് കോൺഫിഗറേഷൻ ലഭിച്ചേക്കാം.
2. പതിപ്പിംഗ്: ആരാണ് വന്നതെന്നും അവർ എന്താണ് ചെയ്തതെന്നും നിങ്ങൾക്കറിയാം, ഇത് എക്സിറ്റിലെ പ്രവർത്തന കോൺഫിഗറേഷനിലേക്ക് നിങ്ങളെ നയിക്കുമെന്നത് ഒരു വസ്തുതയല്ല.
3. ചരിത്രം: ആര് എന്ത് ചെയ്തു എന്നതിന്റെ കഥ. സെർവർ നഷ്‌ടപ്പെടുകയാണെങ്കിൽ മാത്രമേ നിങ്ങൾക്ക് അത് ഉപയോഗിക്കാൻ കഴിയൂ.

ഞാൻ എന്തു ചെയ്യണം?

അടിസ്ഥാന സൗകര്യങ്ങൾ ഒരു കോഡായി

അത്തരമൊരു വിചിത്രമായ കേസ് പോലും ബാഷ് ചരിത്രമായി അടിസ്ഥാന സൗകര്യങ്ങൾ നിങ്ങൾക്ക് അത് ചെവിയിൽ വലിക്കാം അടിസ്ഥാന സൗകര്യങ്ങൾ ഒരു കോഡായി, എന്നാൽ നല്ല പഴയ LAMP സെർവറിനേക്കാൾ സങ്കീർണ്ണമായ എന്തെങ്കിലും ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിക്കുമ്പോൾ, ഈ കോഡ് എങ്ങനെയെങ്കിലും പരിഷ്കരിക്കണം, മാറ്റണം, മെച്ചപ്പെടുത്തണം എന്ന നിഗമനത്തിൽ ഞങ്ങൾ എത്തിച്ചേരും. അടുത്തതായി, തമ്മിലുള്ള സമാനതകൾ പരിഗണിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു അടിസ്ഥാന സൗകര്യങ്ങൾ ഒരു കോഡായി സോഫ്റ്റ്‌വെയർ വികസനവും.

ഡ്രൈ

ഒരു സ്റ്റോറേജ് സിസ്റ്റം ഡെവലപ്‌മെന്റ് പ്രോജക്റ്റിൽ, ഒരു ഉപടാസ്‌ക് ഉണ്ടായിരുന്നു ഇടയ്ക്കിടെ SDS കോൺഫിഗർ ചെയ്യുക: ഞങ്ങൾ ഒരു പുതിയ പതിപ്പ് പുറത്തിറക്കുന്നു - കൂടുതൽ പരിശോധനയ്ക്കായി ഇത് പുറത്തിറക്കേണ്ടതുണ്ട്. ചുമതല വളരെ ലളിതമാണ്:

• ssh വഴി ഇവിടെ പ്രവേശിച്ച് കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യുക.
• ഫയൽ അവിടെ പകർത്തുക.
• ഇവിടെ കോൺഫിഗറേഷൻ ശരിയാക്കുക.
• അവിടെ സേവനം ആരംഭിക്കുക
• പങ്ക് € |
• ലാഭം!

വിവരിച്ച യുക്തിക്ക്, ബാഷ് ആവശ്യത്തിലധികം, പ്രത്യേകിച്ച് പ്രോജക്റ്റിന്റെ പ്രാരംഭ ഘട്ടത്തിൽ, അത് ആരംഭിക്കുമ്പോൾ. ഈ നിങ്ങൾ ബാഷ് ഉപയോഗിക്കുന്നത് മോശമല്ല, എന്നാൽ കാലക്രമേണ സമാനമായ എന്തെങ്കിലും വിന്യസിക്കാനുള്ള അഭ്യർത്ഥനകൾ ഉണ്ട്, എന്നാൽ അല്പം വ്യത്യസ്തമാണ്. ആദ്യം മനസ്സിൽ വരുന്നത് കോപ്പി പേസ്റ്റ് ആണ്. ഇപ്പോൾ ഏതാണ്ട് ഒരേ കാര്യം ചെയ്യുന്ന സമാനമായ രണ്ട് സ്ക്രിപ്റ്റുകൾ നമുക്ക് ഇതിനകം ഉണ്ട്. കാലക്രമേണ, സ്ക്രിപ്റ്റുകളുടെ എണ്ണം വർദ്ധിച്ചു, വ്യത്യസ്ത സ്ക്രിപ്റ്റുകൾക്കിടയിൽ സമന്വയിപ്പിക്കേണ്ട ഒരു ഇൻസ്റ്റാളേഷൻ വിന്യസിക്കുന്നതിന് ഒരു പ്രത്യേക ബിസിനസ്സ് ലോജിക് ഉണ്ടെന്ന വസ്തുത ഞങ്ങൾ അഭിമുഖീകരിച്ചു, ഇത് വളരെ സങ്കീർണ്ണമാണ്.

ഡ്രൈ (നിങ്ങളെത്തന്നെ ആവർത്തിക്കരുത്) പോലുള്ള ഒരു സമ്പ്രദായമുണ്ടെന്ന് ഇത് മാറുന്നു. നിലവിലുള്ള കോഡ് വീണ്ടും ഉപയോഗിക്കുക എന്നതാണ് ആശയം. ഇത് ലളിതമാണെന്ന് തോന്നുന്നു, പക്ഷേ ഞങ്ങൾ ഉടൻ തന്നെ ഇതിലേക്ക് വന്നില്ല. ഞങ്ങളുടെ കാര്യത്തിൽ, ഇത് ഒരു നിസ്സാരമായ ആശയമായിരുന്നു: സ്ക്രിപ്റ്റുകളിൽ നിന്ന് കോൺഫിഗറേഷനുകൾ വേർതിരിക്കുക. ആ. ഇൻസ്റ്റാളേഷൻ എങ്ങനെ പ്രത്യേകം വിന്യസിക്കുന്നു എന്നതിന്റെ ബിസിനസ്സ് ലോജിക്, കോൺഫിഗറുകൾ പ്രത്യേകം.

CFM-ന് SOLID

കാലക്രമേണ പദ്ധതി വളർന്നു സ്വാഭാവിക തുടർച്ച അൻസിബിളിന്റെ ഉദയമായിരുന്നു. ടീമിൽ വൈദഗ്ദ്ധ്യം ഉണ്ടെന്നതും സങ്കീർണ്ണമായ യുക്തിക്ക് വേണ്ടി രൂപകൽപ്പന ചെയ്തിട്ടില്ലാത്തതുമാണ് അതിന്റെ രൂപത്തിന്റെ പ്രധാന കാരണം. അൻസിബിൾ സങ്കീർണ്ണമായ യുക്തിയും ഉൾക്കൊള്ളാൻ തുടങ്ങി. സങ്കീർണ്ണമായ ലോജിക് അരാജകത്വത്തിലേക്ക് മാറുന്നത് തടയാൻ, സോഫ്റ്റ്വെയർ വികസനത്തിൽ കോഡ് സംഘടിപ്പിക്കുന്നതിനുള്ള തത്വങ്ങളുണ്ട് സോളിഡ് കൂടാതെ, ഉദാഹരണത്തിന്, ഗ്രിഗറി പെട്രോവ് “ഐടി സ്പെഷ്യലിസ്റ്റിന് എന്തുകൊണ്ട് ഒരു വ്യക്തിഗത ബ്രാൻഡ് ആവശ്യമാണ്” എന്ന റിപ്പോർട്ടിൽ ഒരു വ്യക്തിയെ ചില സാമൂഹിക സ്ഥാപനങ്ങളുമായി പ്രവർത്തിക്കുന്നത് എളുപ്പമാക്കുന്ന തരത്തിലാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നതെന്ന ചോദ്യം ഉന്നയിച്ചു. വസ്തുക്കളാണ്. ഈ രണ്ട് ആശയങ്ങളും സംയോജിപ്പിച്ച് അവ വികസിപ്പിക്കുന്നത് തുടരുകയാണെങ്കിൽ, നമുക്കും ഉപയോഗിക്കാൻ കഴിയുമെന്ന് ഞങ്ങൾ ശ്രദ്ധിക്കും സോളിഡ് ഭാവിയിൽ ഈ യുക്തി പരിപാലിക്കുന്നതും പരിഷ്ക്കരിക്കുന്നതും എളുപ്പമാക്കുന്നതിന്.

ഏക ഉത്തരവാദിത്ത തത്വം

ഓരോ ക്ലാസും ഒരു ജോലി മാത്രമാണ് ചെയ്യുന്നത്.

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

തുറന്ന അടഞ്ഞ തത്വം

തുറന്ന/അടഞ്ഞ തത്വം.

• വിപുലീകരണത്തിനായി തുറക്കുക: പുതിയ എന്റിറ്റി തരങ്ങൾ സൃഷ്‌ടിക്കുന്നതിലൂടെ ഒരു എന്റിറ്റിയുടെ സ്വഭാവം വിപുലീകരിക്കാൻ കഴിയുമെന്നാണ് അർത്ഥമാക്കുന്നത്.
• മാറ്റാൻ അടച്ചിരിക്കുന്നു: ഒരു എന്റിറ്റിയുടെ സ്വഭാവം വിപുലീകരിക്കുന്നതിന്റെ ഫലമായി, ആ എന്റിറ്റികൾ ഉപയോഗിക്കുന്ന കോഡിൽ മാറ്റങ്ങളൊന്നും വരുത്തരുത്.

തുടക്കത്തിൽ, ഞങ്ങൾ വെർച്വൽ മെഷീനുകളിൽ ടെസ്റ്റ് ഇൻഫ്രാസ്ട്രക്ചർ വിന്യസിച്ചു, എന്നാൽ വിന്യാസത്തിന്റെ ബിസിനസ്സ് ലോജിക് നടപ്പിലാക്കുന്നതിൽ നിന്ന് വ്യത്യസ്തമായതിനാൽ, പ്രശ്‌നങ്ങളൊന്നുമില്ലാതെ ഞങ്ങൾ ബെയർമെറ്റലിലേക്ക് റോളിംഗ് ചേർത്തു.

ലിസ്കോവ് സബ്സ്റ്റിറ്റ്യൂഷൻ തത്വം

ബാർബറ ലിസ്കോവിന്റെ സബ്സ്റ്റിറ്റ്യൂഷൻ തത്വം. ഒരു പ്രോഗ്രാമിലെ ഒബ്ജക്റ്റുകൾ പ്രോഗ്രാമിന്റെ ശരിയായ നിർവ്വഹണം മാറ്റാതെ തന്നെ അവയുടെ ഉപവിഭാഗങ്ങളുടെ ഉദാഹരണങ്ങൾ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കേണ്ടതാണ്.

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

ഞങ്ങളുടെ കാര്യത്തിൽ, ഞങ്ങൾ ഇംബ്ജാവ അല്ലെങ്കിൽ ഒറക്ലെജാവ റോൾ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടെങ്കിൽ, ഞങ്ങൾക്ക് ഒരു ജാവ ബൈനറി എക്സിക്യൂട്ടബിൾ ഉണ്ടെന്ന് ഇൻഫ്രാസ്ട്രക്ചർ ടീമിനുള്ളിൽ ഒരു ധാരണയുണ്ട്. കാരണം ഇത് ആവശ്യമാണ് അപ്‌സ്ട്രീം റോളുകൾ ഈ സ്വഭാവത്തെ ആശ്രയിച്ചിരിക്കുന്നു; അവർ ജാവ പ്രതീക്ഷിക്കുന്നു. അതേ സമയം, ആപ്ലിക്കേഷൻ വിന്യാസത്തിന്റെ യുക്തി മാറ്റാതെ തന്നെ ഒരു ജാവ നടപ്പിലാക്കൽ/പതിപ്പ് മറ്റൊന്ന് ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കാൻ ഇത് ഞങ്ങളെ അനുവദിക്കുന്നു.

അൻസിബിളിൽ ഇത് നടപ്പിലാക്കുന്നത് അസാധ്യമാണ് എന്ന വസ്തുതയിലാണ് ഇവിടെ പ്രശ്നം സ്ഥിതിചെയ്യുന്നത്, അതിന്റെ ഫലമായി ടീമിനുള്ളിൽ ചില കരാറുകൾ പ്രത്യക്ഷപ്പെടുന്നു.

ഇന്റർഫേസ് വേർതിരിക്കൽ തത്വം

ഇന്റർഫേസ് വേർതിരിക്കൽ തത്വം: “പല ക്ലയന്റ്-നിർദ്ദിഷ്ട ഇന്റർഫേസുകളും ഒരു പൊതു-ഉദ്ദേശ്യ ഇന്റർഫേസിനേക്കാൾ മികച്ചതാണ്.

തുടക്കത്തിൽ, ആപ്ലിക്കേഷൻ വിന്യാസത്തിന്റെ എല്ലാ വ്യതിയാനങ്ങളും ഒരു അൻസിബിൾ പ്ലേബുക്കിൽ ഉൾപ്പെടുത്താൻ ഞങ്ങൾ ശ്രമിച്ചു, പക്ഷേ പിന്തുണയ്ക്കുന്നത് ബുദ്ധിമുട്ടായിരുന്നു, കൂടാതെ ഞങ്ങൾക്ക് ഒരു ബാഹ്യ ഇന്റർഫേസ് ഉള്ളപ്പോൾ സമീപനം (ക്ലയന്റ് പോർട്ട് 443 പ്രതീക്ഷിക്കുന്നു), തുടർന്ന് വ്യക്തിഗതമായി ഒരു ഇൻഫ്രാസ്ട്രക്ചർ കൂട്ടിച്ചേർക്കാൻ കഴിയും. ഒരു പ്രത്യേക നിർവ്വഹണത്തിനായി ഇഷ്ടികകൾ.

ആശ്രിതത്വ വിപരീത തത്വം

ആശ്രിതത്വ വിപരീത തത്വം. ഉയർന്ന തലത്തിലുള്ള മൊഡ്യൂളുകൾ താഴ്ന്ന തലത്തിലുള്ള മൊഡ്യൂളുകളെ ആശ്രയിക്കരുത്. രണ്ട് തരത്തിലുള്ള മൊഡ്യൂളുകളും അമൂർത്തതകളെ ആശ്രയിച്ചിരിക്കണം. സംഗ്രഹങ്ങൾ വിശദാംശങ്ങളെ ആശ്രയിക്കരുത്. വിശദാംശങ്ങൾ അമൂർത്തതകളെ ആശ്രയിച്ചിരിക്കണം.

ഇവിടെ ഉദാഹരണം ഒരു ആന്റിപാറ്റേൺ അടിസ്ഥാനമാക്കിയുള്ളതായിരിക്കും.

1. ഉപഭോക്താക്കളിൽ ഒരാൾക്ക് ഒരു സ്വകാര്യ ക്ലൗഡ് ഉണ്ടായിരുന്നു.
2. ഞങ്ങൾ ക്ലൗഡിനുള്ളിൽ വെർച്വൽ മെഷീനുകൾ ഓർഡർ ചെയ്തു.
3. എന്നാൽ ക്ലൗഡിന്റെ സ്വഭാവം കാരണം, വിഎം ഏത് ഹൈപ്പർവൈസറിലാണ് ആപ്ലിക്കേഷൻ വിന്യാസം ബന്ധിപ്പിച്ചത്.

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

ഇടപെടല്

കോഡ് എന്ന നിലയിൽ ഇൻഫ്രാസ്ട്രക്ചർ എന്നത് കോഡിനെക്കുറിച്ച് മാത്രമല്ല, കോഡും ആളുകളും തമ്മിലുള്ള ബന്ധത്തെക്കുറിച്ചും ഇൻഫ്രാസ്ട്രക്ചർ ഡെവലപ്പർമാർ തമ്മിലുള്ള ഇടപെടലുകളെക്കുറിച്ചും കൂടിയാണ്.

ബസ് ഘടകം

നിങ്ങളുടെ പ്രോജക്റ്റിൽ വാസ്യ ഉണ്ടെന്ന് നമുക്ക് അനുമാനിക്കാം. നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിനെക്കുറിച്ച് വാസ്യയ്ക്ക് എല്ലാം അറിയാം, വാസ്യ പെട്ടെന്ന് അപ്രത്യക്ഷമായാൽ എന്ത് സംഭവിക്കും? ഇത് വളരെ യഥാർത്ഥ സാഹചര്യമാണ്, കാരണം അവനെ ഒരു ബസ് ഇടിച്ചേക്കാം. ചിലപ്പോൾ അത് സംഭവിക്കുന്നു. ഇത് സംഭവിക്കുകയും കോഡ്, അതിന്റെ ഘടന, അത് എങ്ങനെ പ്രവർത്തിക്കുന്നു, രൂപഭാവങ്ങൾ, പാസ്‌വേഡുകൾ എന്നിവയെക്കുറിച്ചുള്ള അറിവ് ടീമിൽ വിതരണം ചെയ്യപ്പെടുന്നില്ലെങ്കിൽ, നിങ്ങൾക്ക് നിരവധി അസുഖകരമായ സാഹചര്യങ്ങൾ നേരിടേണ്ടി വന്നേക്കാം. ഈ അപകടസാധ്യതകൾ കുറയ്ക്കുന്നതിനും ടീമിനുള്ളിൽ അറിവ് വിതരണം ചെയ്യുന്നതിനും, നിങ്ങൾക്ക് വിവിധ സമീപനങ്ങൾ ഉപയോഗിക്കാം

ജോഡി ഡെവോപ്സിംഗ്

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

മറ്റൊരു പ്രത്യേക കേസ് ഒരു സംഭവം കോളാണ്. ഒരു പ്രശ്‌നത്തിനിടയിൽ, ഡ്യൂട്ടിയിലുള്ളവരും ഉൾപ്പെട്ടവരുമടങ്ങുന്ന ഒരു സംഘം ഒത്തുകൂടുന്നു, ഒരു നേതാവിനെ നിയമിക്കുന്നു, അവൻ തന്റെ സ്‌ക്രീൻ പങ്കിടുകയും ചിന്തയുടെ ട്രെയിനിന് ശബ്ദം നൽകുകയും ചെയ്യുന്നു. മറ്റ് പങ്കാളികൾ നേതാവിന്റെ ചിന്തകൾ പിന്തുടരുന്നു, കൺസോളിൽ നിന്നുള്ള തന്ത്രങ്ങളിൽ ചാരപ്പണി നടത്തുന്നു, ലോഗിലെ ഒരു വരിയും അവർ നഷ്ടപ്പെടുത്തിയിട്ടില്ലെന്ന് പരിശോധിക്കുക, സിസ്റ്റത്തെക്കുറിച്ച് പുതിയ കാര്യങ്ങൾ പഠിക്കുക. ഈ സമീപനം കൂടുതൽ തവണ പ്രവർത്തിച്ചു.

കോഡ് അവലോകനം

ആത്മനിഷ്ഠമായി, കോഡ് അവലോകനം ഉപയോഗിച്ച് അടിസ്ഥാന സൗകര്യങ്ങളെക്കുറിച്ചും അത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ചും അറിവ് പ്രചരിപ്പിക്കുന്നത് കൂടുതൽ ഫലപ്രദമാണ്:

• റിപ്പോസിറ്ററിയിലെ കോഡ് ഉപയോഗിച്ചാണ് ഇൻഫ്രാസ്ട്രക്ചർ വിവരിച്ചിരിക്കുന്നത്.
• ഒരു പ്രത്യേക ശാഖയിൽ മാറ്റങ്ങൾ സംഭവിക്കുന്നു.
• ഒരു ലയന അഭ്യർത്ഥന സമയത്ത്, ഇൻഫ്രാസ്ട്രക്ചറിലെ മാറ്റങ്ങളുടെ ഡെൽറ്റ നിങ്ങൾക്ക് കാണാൻ കഴിയും.

ഒരു ഷെഡ്യൂൾ അനുസരിച്ച് നിരൂപകരെ ഓരോരുത്തരായി തിരഞ്ഞെടുത്തു എന്നതാണ് ഇവിടെ ഹൈലൈറ്റ്, അതായത്. ഒരു പരിധിവരെ സംഭാവ്യതയോടെ നിങ്ങൾ ഒരു പുതിയ ഇൻഫ്രാസ്ട്രക്ചറിലേക്ക് കയറും.

കോഡ് ശൈലി

കാലക്രമേണ, അവലോകനങ്ങൾക്കിടയിൽ കലഹങ്ങൾ പ്രത്യക്ഷപ്പെടാൻ തുടങ്ങി, കാരണം... നിരൂപകർക്ക് അവരുടേതായ ശൈലി ഉണ്ടായിരുന്നു, നിരൂപകരുടെ ഭ്രമണം വ്യത്യസ്ത ശൈലികൾ കൊണ്ട് അവരെ അടുക്കി വച്ചിരിക്കുന്നു: 2 സ്‌പെയ്‌സുകൾ അല്ലെങ്കിൽ 4, ഒട്ടകകേസ് അല്ലെങ്കിൽ പാമ്പ്_കേസ്. ഇത് ഉടനടി നടപ്പിലാക്കാൻ കഴിഞ്ഞില്ല.

• ലിന്റർ ഉപയോഗിക്കാൻ ശുപാർശ ചെയ്യുക എന്നതായിരുന്നു ആദ്യ ആശയം, എല്ലാത്തിനുമുപരി, എല്ലാവരും ഒരു എഞ്ചിനീയർ ആണ്, എല്ലാവരും മിടുക്കരാണ്. എന്നാൽ വ്യത്യസ്ത എഡിറ്റർമാർ, OS, സൗകര്യപ്രദമല്ല
• ഇത് ഒരു ബോട്ടായി പരിണമിച്ചു, അത് ഓരോ പ്രശ്നമുള്ള കമ്മിറ്റിനും സ്ലാക്ക് എഴുതുകയും ലിന്റർ ഔട്ട്പുട്ട് ഘടിപ്പിക്കുകയും ചെയ്തു. എന്നാൽ മിക്ക കേസുകളിലും കൂടുതൽ പ്രധാനപ്പെട്ട കാര്യങ്ങൾ ചെയ്യാനുണ്ടായിരുന്നു, കൂടാതെ കോഡ് പരിഹരിക്കപ്പെടാതെ തുടർന്നു.

ഗ്രീൻ ബിൽഡ് മാസ്റ്റർ

സമയം കടന്നുപോകുന്നു, ചില പരീക്ഷകളിൽ വിജയിക്കാത്ത പ്രതിബദ്ധതകൾ മാസ്റ്ററിലേക്ക് അനുവദിക്കാനാവില്ല എന്ന നിഗമനത്തിലെത്തി. വോയില! ഞങ്ങൾ ഗ്രീൻ ബിൽഡ് മാസ്റ്റർ കണ്ടുപിടിച്ചു, അത് സോഫ്റ്റ്‌വെയർ വികസനത്തിൽ വളരെക്കാലമായി പരിശീലിച്ചു:

• ഒരു പ്രത്യേക ശാഖയിൽ വികസനം നടക്കുന്നു.
• ഈ ത്രെഡിൽ പരിശോധനകൾ നടക്കുന്നു.
• പരിശോധനകൾ പരാജയപ്പെട്ടാൽ, കോഡ് അത് മാസ്റ്ററിലേക്ക് മാറ്റില്ല.

ഈ തീരുമാനം വളരെ വേദനാജനകമായിരുന്നു, കാരണം... വളരെയധികം വിവാദങ്ങൾ സൃഷ്ടിച്ചു, പക്ഷേ അത് വിലമതിക്കുന്നു, കാരണം... അവലോകനങ്ങൾ ശൈലിയിൽ വ്യത്യാസമില്ലാതെ ലയനത്തിനുള്ള അഭ്യർത്ഥനകൾ സ്വീകരിക്കാൻ തുടങ്ങി, കാലക്രമേണ പ്രശ്നബാധിത മേഖലകളുടെ എണ്ണം കുറയാൻ തുടങ്ങി.

IaC ടെസ്റ്റിംഗ്

സ്റ്റൈൽ ചെക്കിംഗിനുപുറമെ, നിങ്ങൾക്ക് മറ്റ് കാര്യങ്ങൾ ഉപയോഗിക്കാം, ഉദാഹരണത്തിന്, നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിന് യഥാർത്ഥത്തിൽ വിന്യസിക്കാനാകുമോ എന്ന് പരിശോധിക്കാൻ. അല്ലെങ്കിൽ ഇൻഫ്രാസ്ട്രക്ചറിലെ മാറ്റങ്ങൾ പണം നഷ്ടപ്പെടാൻ ഇടയാക്കില്ലെന്ന് പരിശോധിക്കുക. എന്തുകൊണ്ട് ഇത് ആവശ്യമായി വന്നേക്കാം? ചോദ്യം സങ്കീർണ്ണവും ദാർശനികവുമാണ്, അതിരുകൾ പരിശോധിക്കാത്ത ഒരു ഓട്ടോ-സ്കെയിലർ Powershell-ൽ എങ്ങനെയോ ഉണ്ടെന്ന് ഒരു സ്റ്റോറി ഉപയോഗിച്ച് ഉത്തരം നൽകുന്നതാണ് നല്ലത് => ആവശ്യത്തിലധികം VM-കൾ സൃഷ്ടിക്കപ്പെട്ടു => ക്ലയന്റ് ആസൂത്രണം ചെയ്തതിലും കൂടുതൽ പണം ചെലവഴിച്ചു. ഇത് അത്ര സുഖകരമല്ല, എന്നാൽ ആദ്യ ഘട്ടങ്ങളിൽ ഈ പിശക് പിടിക്കുന്നത് തികച്ചും സാദ്ധ്യമാണ്.

സങ്കീർണ്ണമായ ഇൻഫ്രാസ്ട്രക്ചർ കൂടുതൽ സങ്കീർണ്ണമാക്കുന്നത് എന്തുകൊണ്ട് എന്ന് ഒരാൾ ചോദിച്ചേക്കാം. അടിസ്ഥാന സൗകര്യങ്ങൾക്കായുള്ള പരിശോധനകൾ, കോഡിന് വേണ്ടിയുള്ളതുപോലെ, ലളിതവൽക്കരണത്തെ കുറിച്ചല്ല, മറിച്ച് നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ എങ്ങനെ പ്രവർത്തിക്കണമെന്ന് അറിയുന്നതിനാണ്.

IaC ടെസ്റ്റിംഗ് പിരമിഡ്

IaC ടെസ്റ്റിംഗ്: സ്റ്റാറ്റിക് അനാലിസിസ്

നിങ്ങൾ മുഴുവൻ ഇൻഫ്രാസ്ട്രക്ചറും ഒരേസമയം വിന്യസിക്കുകയും അത് പ്രവർത്തിക്കുന്നുണ്ടോയെന്ന് പരിശോധിക്കുകയും ചെയ്താൽ, ഇതിന് വളരെയധികം സമയമെടുക്കുന്നതായും ധാരാളം സമയം ആവശ്യമാണെന്നും നിങ്ങൾ കണ്ടെത്തിയേക്കാം. അതിനാൽ, അടിസ്ഥാനം വേഗത്തിൽ പ്രവർത്തിക്കുന്ന ഒന്നായിരിക്കണം, അതിൽ ധാരാളം ഉണ്ട്, അത് ധാരാളം പ്രാകൃത സ്ഥലങ്ങൾ ഉൾക്കൊള്ളുന്നു.

ബാഷ് തന്ത്രപരമാണ്

നിസ്സാരമായ ഒരു ഉദാഹരണം നോക്കാം. നിലവിലെ ഡയറക്‌ടറിയിലെ എല്ലാ ഫയലുകളും തിരഞ്ഞെടുത്ത് മറ്റൊരു സ്ഥലത്തേക്ക് പകർത്തുക. ആദ്യം മനസ്സിൽ വരുന്നത്:

for i in * ; do 
    cp $i /some/path/$i.bak
done

ഫയലിന്റെ പേരിൽ ഒരു സ്പേസ് ഉണ്ടെങ്കിൽ എന്തുചെയ്യും? ശരി, ഞങ്ങൾ മിടുക്കരാണ്, ഉദ്ധരണികൾ എങ്ങനെ ഉപയോഗിക്കണമെന്ന് ഞങ്ങൾക്കറിയാം:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

നന്നായി ചെയ്തു? ഇല്ല! ഡയറക്ടറിയിൽ ഒന്നുമില്ലെങ്കിൽ എന്തുചെയ്യും, അതായത്. ഗ്ലോബിംഗ് പ്രവർത്തിക്കില്ല.

find . -type f -exec mv -v {} dst/{}.bak ;

ഇപ്പോൾ നന്നായി ചെയ്തോ? ഇല്ല... ഫയലിന്റെ പേരിൽ എന്തായിരിക്കാം എന്ന് മറന്നു n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

സ്റ്റാറ്റിക് വിശകലന ഉപകരണങ്ങൾ

ഉദ്ധരണികൾ മറക്കുമ്പോൾ മുമ്പത്തെ ഘട്ടത്തിൽ നിന്നുള്ള പ്രശ്നം പിടിപെടാം, ഇതിന് പ്രകൃതിയിൽ ധാരാളം പരിഹാരങ്ങളുണ്ട് ഷെൽ ചെക്ക്, പൊതുവെ അവയിൽ ധാരാളം ഉണ്ട്, മിക്കവാറും നിങ്ങളുടെ IDE ന് കീഴിൽ നിങ്ങളുടെ സ്റ്റാക്കിനായി ഒരു ലിന്റർ കണ്ടെത്താനാകും.

ഭാഷ
ഉപകരണം

ബാഷ്
ഷെൽ ചെക്ക്

മാണികം
റൂബോകോപ്പ്

പൈത്തൺ
പൈലിന്റ്

ഉത്തരം
അൻസിബിൾ ലിന്റ്

IaC ടെസ്റ്റിംഗ്: യൂണിറ്റ് ടെസ്റ്റുകൾ

മുമ്പത്തെ ഉദാഹരണത്തിൽ നിന്ന് നമ്മൾ കണ്ടതുപോലെ, ലിന്ററുകൾ സർവ്വശക്തനല്ല, എല്ലാ പ്രശ്ന മേഖലകളും ചൂണ്ടിക്കാണിക്കാൻ കഴിയില്ല. കൂടാതെ, സോഫ്‌റ്റ്‌വെയർ ഡെവലപ്‌മെന്റിലെ ടെസ്റ്റിംഗുമായി സാമ്യമുള്ളതിനാൽ, നമുക്ക് യൂണിറ്റ് ടെസ്റ്റുകൾ തിരിച്ചുവിളിക്കാം. ഇവിടെ പെട്ടന്ന് ഓർമ്മ വരുന്നു ഷുണിറ്റ്, ജൂണിറ്റ്, rspec, പൈറ്റെസ്റ്റ്. എന്നാൽ അൻസിബിൾ, ഷെഫ്, സാൾട്ട്സ്റ്റാക്ക് എന്നിവരെയും അവരെപ്പോലുള്ള മറ്റുള്ളവരെയും എന്തുചെയ്യണം?

തുടക്കത്തിൽ തന്നെ ഞങ്ങൾ സംസാരിച്ചു സോളിഡ് നമ്മുടെ അടിസ്ഥാന സൗകര്യങ്ങൾ ചെറിയ ഇഷ്ടികകൾ ഉൾക്കൊള്ളുന്നതായിരിക്കണം. അവരുടെ സമയം വന്നിരിക്കുന്നു.

1. ഇൻഫ്രാസ്ട്രക്ചർ ചെറിയ ഇഷ്ടികകളായി തിരിച്ചിരിക്കുന്നു, ഉദാഹരണത്തിന്, അൻസിബിൾ റോളുകൾ.
2. ഡോക്കർ ആയാലും VM ആയാലും ഒരുതരം പരിതസ്ഥിതി വിന്യസിച്ചിരിക്കുന്നു.
3. ഈ പരീക്ഷണ പരിതസ്ഥിതിയിൽ ഞങ്ങൾ ഞങ്ങളുടെ അൻസിബിൾ റോൾ പ്രയോഗിക്കുന്നു.
4. ഞങ്ങൾ പ്രതീക്ഷിച്ചതുപോലെ എല്ലാം പ്രവർത്തിച്ചുവെന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു (ഞങ്ങൾ പരിശോധനകൾ നടത്തുന്നു).
5. ശരിയാണോ അല്ലയോ എന്ന് ഞങ്ങൾ തീരുമാനിക്കും.

IaC ടെസ്റ്റിംഗ്: യൂണിറ്റ് ടെസ്റ്റിംഗ് ടൂളുകൾ

ചോദ്യം, CFM-നുള്ള ടെസ്റ്റുകൾ എന്തൊക്കെയാണ്? നിങ്ങൾക്ക് സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കാൻ കഴിയും, അല്ലെങ്കിൽ ഇതിനായി നിങ്ങൾക്ക് റെഡിമെയ്ഡ് പരിഹാരങ്ങൾ ഉപയോഗിക്കാം:

സിഎഫ്എം
ഉപകരണം

അസാധ്യം
ടെസ്റ്റിൻഫ്ര

തല
ഇൻസ്പെക്

തല
സെർവർസ്പെക്

ഉപ്പ് സ്റ്റാക്ക്
ഗോസ്

ടെസ്റ്റിൻഫ്രയുടെ ഉദാഹരണം, ഉപയോക്താക്കളെ പരിശോധിക്കുന്നു test1, test2 ഒരു ഗ്രൂപ്പിൽ നിലവിലുണ്ട് sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

എന്താണ് തിരഞ്ഞെടുക്കേണ്ടത്? ചോദ്യം സങ്കീർണ്ണവും അവ്യക്തവുമാണ്, 2018-2019 ലെ ഗിത്തബിലെ പ്രോജക്റ്റുകളിലെ മാറ്റങ്ങളുടെ ഒരു ഉദാഹരണം ഇതാ:

IaC ടെസ്റ്റിംഗ് ചട്ടക്കൂടുകൾ

ചോദ്യം ഉയർന്നുവരുന്നു: എല്ലാം ഒരുമിച്ച് എങ്ങനെ സമാരംഭിക്കാം? കഴിയും അത് എടുത്ത് സ്വയം ചെയ്യുക മതിയായ എണ്ണം എൻജിനീയർമാർ ഉണ്ടെങ്കിൽ. അല്ലെങ്കിൽ നിങ്ങൾക്ക് റെഡിമെയ്ഡ് പരിഹാരങ്ങൾ എടുക്കാം, അവയിൽ പലതും ഇല്ലെങ്കിലും:

സിഎഫ്എം
ഉപകരണം

അസാധ്യം
തന്മാത്ര

തല
ടെസ്റ്റ് അടുക്കള

ടെറഫോം
ടെറാറ്റെസ്റ്റ്

2018-2019 ലെ ഗിത്തബിലെ പ്രോജക്റ്റുകളിലെ മാറ്റങ്ങളുടെ ഉദാഹരണം:

തന്മാത്ര vs. ടെസ്റ്റ്കിച്ചൻ

തുടക്കത്തിൽ ഞങ്ങൾ ടെസ്റ്റ്കിച്ചൻ ഉപയോഗിക്കാൻ ശ്രമിച്ചു:

1. സമാന്തരമായി ഒരു VM സൃഷ്ടിക്കുക.
2. അൻസിബിൾ റോളുകൾ പ്രയോഗിക്കുക.
3. പരിശോധന നടത്തുക.

25-35 റോളുകൾക്കായി ഇത് 40-70 മിനിറ്റ് പ്രവർത്തിച്ചു, അത് ദൈർഘ്യമേറിയതാണ്.

അടുത്ത ഘട്ടം ജെൻകിൻസ്/ഡോക്കർ/ആൻസിബിൾ/മോളിക്യൂളിലേക്കുള്ള പരിവർത്തനമായിരുന്നു. പ്രത്യയശാസ്ത്രപരമായി എല്ലാം ഒന്നുതന്നെ

1. ലിന്റ് പ്ലേബുക്കുകൾ.
2. റോളുകൾ നിരത്തുക.
3. കണ്ടെയ്നർ വിക്ഷേപിക്കുക
4. അൻസിബിൾ റോളുകൾ പ്രയോഗിക്കുക.
5. ടെസ്റ്റിൻഫ്ര പ്രവർത്തിപ്പിക്കുക.
6. വൈകല്യം പരിശോധിക്കുക.

40 റോളുകൾക്കുള്ള ലിന്റിംഗും ഒരു ഡസനോളം ടെസ്റ്റുകളും ഏകദേശം 15 മിനിറ്റ് എടുക്കാൻ തുടങ്ങി.

എന്ത് തിരഞ്ഞെടുക്കണം എന്നത് ഉപയോഗിച്ച സ്റ്റാക്ക്, ടീമിലെ വൈദഗ്ദ്ധ്യം മുതലായ നിരവധി ഘടകങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു. യൂണിറ്റ് ടെസ്റ്റിംഗ് ചോദ്യം എങ്ങനെ അവസാനിപ്പിക്കണമെന്ന് ഇവിടെ എല്ലാവരും സ്വയം തീരുമാനിക്കുന്നു

IaC ടെസ്റ്റിംഗ്: ഇന്റഗ്രേഷൻ ടെസ്റ്റുകൾ

ഇൻഫ്രാസ്ട്രക്ചർ ടെസ്റ്റിംഗ് പിരമിഡിന്റെ അടുത്ത ഘട്ടം ഇന്റഗ്രേഷൻ ടെസ്റ്റുകളായിരിക്കും. അവ യൂണിറ്റ് ടെസ്റ്റുകൾക്ക് സമാനമാണ്:

1. ഇൻഫ്രാസ്ട്രക്ചർ ചെറിയ ഇഷ്ടികകളായി തിരിച്ചിരിക്കുന്നു, ഉദാഹരണത്തിന് അൻസിബിൾ റോളുകൾ.
2. ഡോക്കർ ആയാലും VM ആയാലും ഒരുതരം പരിതസ്ഥിതി വിന്യസിച്ചിരിക്കുന്നു.
3. ഈ ടെസ്റ്റ് പരിതസ്ഥിതിക്ക് ബാധകമാണ് സെറ്റ് അനുരൂപമായ വേഷങ്ങൾ.
4. ഞങ്ങൾ പ്രതീക്ഷിച്ചതുപോലെ എല്ലാം പ്രവർത്തിച്ചുവെന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു (ഞങ്ങൾ പരിശോധനകൾ നടത്തുന്നു).
5. ശരിയാണോ അല്ലയോ എന്ന് ഞങ്ങൾ തീരുമാനിക്കും.

ഏകദേശം പറഞ്ഞാൽ, യൂണിറ്റ് ടെസ്റ്റുകളിലേതുപോലെ ഞങ്ങൾ സിസ്റ്റത്തിന്റെ ഒരു വ്യക്തിഗത ഘടകത്തിന്റെ പ്രകടനം പരിശോധിക്കുന്നില്ല, സെർവർ മൊത്തത്തിൽ എങ്ങനെ ക്രമീകരിച്ചിരിക്കുന്നുവെന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു.

IaC ടെസ്റ്റിംഗ്: എൻഡ് ടു എൻഡ് ടെസ്റ്റുകൾ

പിരമിഡിന്റെ മുകളിൽ, എൻഡ് ടു എൻഡ് ടെസ്റ്റുകൾ ഞങ്ങളെ സ്വാഗതം ചെയ്യുന്നു. ആ. ഒരു പ്രത്യേക സെർവറിന്റെയോ പ്രത്യേക സ്ക്രിപ്റ്റിന്റെയോ ഞങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിന്റെ പ്രത്യേക ഇഷ്ടികയുടെയോ പ്രകടനം ഞങ്ങൾ പരിശോധിക്കുന്നില്ല. നിരവധി സെർവറുകൾ ഒരുമിച്ച് ബന്ധിപ്പിച്ചിട്ടുണ്ടോയെന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു, ഞങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നത് പോലെ പ്രവർത്തിക്കുന്നു. നിർഭാഗ്യവശാൽ, റെഡിമെയ്ഡ് ബോക്‌സ്ഡ് സൊല്യൂഷനുകൾ ഞാൻ ഒരിക്കലും കണ്ടിട്ടില്ല, ഒരുപക്ഷേ... ഇൻഫ്രാസ്ട്രക്ചർ പലപ്പോഴും സവിശേഷവും ടെംപ്ലേറ്റ് ചെയ്യാനും ടെസ്റ്റിംഗിനായി ഒരു ചട്ടക്കൂട് സൃഷ്ടിക്കാനും ബുദ്ധിമുട്ടാണ്. തൽഫലമായി, എല്ലാവരും അവരുടേതായ പരിഹാരങ്ങൾ സൃഷ്ടിക്കുന്നു. ആവശ്യമുണ്ട്, പക്ഷേ ഉത്തരമില്ല. അതിനാൽ, മറ്റുള്ളവരെ നല്ല ചിന്തകളിലേക്ക് തള്ളിവിടുന്നതിനോ എന്റെ മൂക്ക് തടവുന്നതിനോ ഉള്ളത് എന്താണെന്ന് ഞാൻ നിങ്ങളോട് പറയും, എല്ലാം നമുക്ക് മുമ്പ് വളരെക്കാലം മുമ്പ് കണ്ടുപിടിച്ചതാണ്.

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

ചട്ടക്കൂടിനുള്ളിൽ വരെ ഈ സ്കീം വളരെക്കാലം പ്രവർത്തിച്ചു ഗവേഷണം ഞങ്ങൾ ഇത് ഓപ്പൺഷിഫ്റ്റിലേക്ക് മാറ്റാൻ ശ്രമിച്ചിട്ടില്ല. കണ്ടെയ്‌നറുകൾ അതേപടി തുടരുന്നു, പക്ഷേ വിക്ഷേപണ അന്തരീക്ഷം മാറിയിരിക്കുന്നു (ഹലോ ഡ്രൈ വീണ്ടും).

ഗവേഷണ ആശയം കൂടുതൽ മുന്നോട്ട് പോയി, ഓപ്പൺഷിഫ്റ്റിൽ അവർ എപിബി (അൻസിബിൾ പ്ലേബുക്ക് ബണ്ടിൽ) പോലെയുള്ള ഒരു കാര്യം കണ്ടെത്തി, ഇത് ഒരു കണ്ടെയ്നറിൽ ഇൻഫ്രാസ്ട്രക്ചർ എങ്ങനെ വിന്യസിക്കാമെന്നതിനെക്കുറിച്ചുള്ള അറിവ് പാക്ക് ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്നു. ആ. ഇൻഫ്രാസ്ട്രക്ചർ എങ്ങനെ വിന്യസിക്കാം എന്നതിനെക്കുറിച്ചുള്ള ആവർത്തിച്ചറിയാവുന്നതും പരിശോധിക്കാവുന്നതുമായ അറിവ് ഉണ്ട്.

ഞങ്ങൾ ഒരു വൈവിധ്യമാർന്ന ഇൻഫ്രാസ്ട്രക്ചറിലേക്ക് കടക്കുന്നതുവരെ ഇതെല്ലാം നല്ലതായി തോന്നി: ടെസ്റ്റുകൾക്കായി ഞങ്ങൾക്ക് വിൻഡോസ് ആവശ്യമാണ്. തൽഫലമായി, എന്ത്, എവിടെ, എങ്ങനെ വിന്യസിക്കാം, പരീക്ഷിക്കണം എന്നതിനെക്കുറിച്ചുള്ള അറിവ് ജെങ്കിൻസിൽ ഉണ്ട്.

തീരുമാനം

കോഡ് പോലെ അടിസ്ഥാന സൗകര്യങ്ങൾ

• ശേഖരത്തിൽ കോഡ്.
• മനുഷ്യ ഇടപെടൽ.
• അടിസ്ഥാന സൗകര്യ പരിശോധന.

കണ്ണികൾ

• ഇംഗ്ലീഷ് പതിപ്പ്
• സ്വകാര്യ ബ്ലോഗിൽ നിന്നുള്ള ക്രോസ് പോസ്റ്റ്
• ഡ്രൈ റൺ 2019-04-24 SpbLUG
• DevopsConf 2019-05-28-ൽ നിന്നുള്ള വീഡിയോ(RU).
• വീഡിയോ(RU) DINS DevOps ഈവനിംഗ് 2019-06-20
• ഇൻഫ്രാസ്ട്രക്ചർ കോഡിന്റെ 300,000 വരികളിൽ നിന്ന് പഠിച്ച പാഠങ്ങൾ & ടെക്സ്റ്റ് പതിപ്പ്
• ഒരു തുടർച്ചയായ ഡെലിവറി പൈപ്പ് ലൈനിലേക്ക് അടിസ്ഥാന സൗകര്യങ്ങളെ കോഡായി സംയോജിപ്പിക്കുന്നു
• അടിസ്ഥാന സൗകര്യങ്ങൾ കോഡായി പരിശോധിക്കുന്നു
• അൻസിബിൾ റോളുകളുടെ ഫലപ്രദമായ വികസനവും പരിപാലനവും
• അൻസിബിൾ ബാഷ് അല്ല!

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