એક અભિગમ આઈએસી (કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર) એ માત્ર તે કોડનો જ સમાવેશ થતો નથી જે રિપોઝીટરીમાં સંગ્રહિત હોય છે, પણ આ કોડની આસપાસના લોકો અને પ્રક્રિયાઓનો પણ સમાવેશ થાય છે. શું સોફ્ટવેર ડેવલપમેન્ટથી લઈને ઈન્ફ્રાસ્ટ્રક્ચર મેનેજમેન્ટ અને વર્ણન સુધીના અભિગમોનો ફરીથી ઉપયોગ કરવો શક્ય છે? જ્યારે તમે લેખ વાંચો ત્યારે આ વિચારને ધ્યાનમાં રાખવો સારો રહેશે.

આ મારી ટ્રાન્સક્રિપ્ટ છે પ્રદર્શન પર DevopsConf 2019-05-28.

સ્લાઇડ્સ અને વીડિયો

ઇંગલિશ આવૃત્તિ
રશિયન સંસ્કરણ
ડ્રાય રન 2019-04-24 SpbLUG
DevopsConf 2019-05-28 તરફથી વિડિઓ(RU).
DINS DevOps EVENING 2019-06-20 થી વિડિઓ(RU)
સ્લાઇડ્સ

બેશ ઇતિહાસ તરીકે ઇન્ફ્રાસ્ટ્રક્ચર

ધારો કે તમે નવા પ્રોજેક્ટ પર આવો છો, અને તેઓ તમને કહે છે: “અમારી પાસે છે કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર" વાસ્તવમાં તે બહાર આવ્યું છે બેશ ઇતિહાસ તરીકે ઇન્ફ્રાસ્ટ્રક્ચર અથવા ઉદાહરણ તરીકે બેશ ઇતિહાસ તરીકે દસ્તાવેજીકરણ. આ એક ખૂબ જ વાસ્તવિક પરિસ્થિતિ છે, ઉદાહરણ તરીકે, ડેનિસ લિસેન્કોએ ભાષણમાં સમાન કેસનું વર્ણન કર્યું હતું સમગ્ર ઈન્ફ્રાસ્ટ્રક્ચરને કેવી રીતે બદલવું અને સારી રીતે ઊંઘવાનું શરૂ કરવું, તેમણે જણાવ્યું કે કેવી રીતે તેમને બેશ ઇતિહાસમાંથી પ્રોજેક્ટ માટે સુસંગત ઇન્ફ્રાસ્ટ્રક્ચર મળ્યું.

થોડી ઇચ્છા સાથે, અમે તે કહી શકીએ છીએ બેશ ઇતિહાસ તરીકે ઇન્ફ્રાસ્ટ્રક્ચર આ કોડ જેવું છે:

પ્રજનનક્ષમતા: તમે bash ઇતિહાસ લઈ શકો છો, ત્યાંથી આદેશો ચલાવી શકો છો, અને તમે, માર્ગ દ્વારા, આઉટપુટ તરીકે કાર્યકારી રૂપરેખાંકન મેળવી શકો છો.
સંસ્કરણ: તમે જાણો છો કે કોણ અંદર આવ્યું અને તેઓએ શું કર્યું, ફરીથી, તે હકીકત નથી કે આ તમને બહાર નીકળતી વખતે કાર્યકારી ગોઠવણી તરફ દોરી જશે.
ઇતિહાસ: કોણે શું કર્યું તેની વાર્તા. જો તમે સર્વર ગુમાવશો તો જ તમે તેનો ઉપયોગ કરી શકશો નહીં.

મારે શું કરવું જોઈએ?

કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર

જેમ કે એક વિચિત્ર કેસ પણ બેશ ઇતિહાસ તરીકે ઇન્ફ્રાસ્ટ્રક્ચર તમે તેને કાન દ્વારા ખેંચી શકો છો કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર, પરંતુ જ્યારે આપણે સારા જૂના LAMP સર્વર કરતાં કંઈક વધુ જટિલ કરવા માંગીએ છીએ, ત્યારે અમે નિષ્કર્ષ પર આવીશું કે આ કોડને કોઈક રીતે સંશોધિત, બદલાયેલ, સુધારેલ કરવાની જરૂર છે. આગળ આપણે વચ્ચેની સમાનતાઓને ધ્યાનમાં લેવા માંગીએ છીએ કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર અને સોફ્ટવેર વિકાસ.

ડ્રાય

સ્ટોરેજ સિસ્ટમ ડેવલપમેન્ટ પ્રોજેક્ટ પર, એક પેટા કાર્ય હતું સમયાંતરે SDS રૂપરેખાંકિત કરો: અમે એક નવું રીલીઝ કરી રહ્યા છીએ - તેને વધુ પરીક્ષણ માટે રોલઆઉટ કરવાની જરૂર છે. કાર્ય અત્યંત સરળ છે:

ssh દ્વારા અહીં લોગ ઇન કરો અને આદેશ ચલાવો.
ત્યાં ફાઇલની નકલ કરો.
અહીં રૂપરેખાને ઠીક કરો.
ત્યાં સેવા શરૂ કરો
...
નફો!

વર્ણવેલ તર્ક માટે, બેશ પર્યાપ્ત કરતાં વધુ છે, ખાસ કરીને પ્રોજેક્ટના પ્રારંભિક તબક્કામાં, જ્યારે તે હમણાં જ શરૂ થઈ રહ્યું છે. આ તે ખરાબ નથી કે તમે બેશનો ઉપયોગ કરો છો, પરંતુ સમય જતાં કંઈક સમાન, પરંતુ થોડું અલગ જમાવવાની વિનંતીઓ છે. સૌથી પહેલી વસ્તુ જે મનમાં આવે છે તે કોપી-પેસ્ટ છે. અને હવે અમારી પાસે પહેલેથી જ બે ખૂબ જ સમાન સ્ક્રિપ્ટો છે જે લગભગ સમાન કાર્ય કરે છે. સમય જતાં, સ્ક્રિપ્ટોની સંખ્યામાં વધારો થયો, અને અમને એ હકીકતનો સામનો કરવો પડ્યો કે ઇન્સ્ટોલેશનને જમાવવા માટે ચોક્કસ વ્યવસાયિક તર્ક છે જેને વિવિધ સ્ક્રિપ્ટો વચ્ચે સિંક્રનાઇઝ કરવાની જરૂર છે, આ એકદમ જટિલ છે.

તે તારણ આપે છે કે DRY (તમારી જાતને પુનરાવર્તિત કરશો નહીં) જેવી પ્રથા છે. હાલના કોડનો ફરીથી ઉપયોગ કરવાનો વિચાર છે. તે સરળ લાગે છે, પરંતુ અમે તરત જ આ પર આવ્યા નથી. અમારા કિસ્સામાં, તે એક મામૂલી વિચાર હતો: સ્ક્રિપ્ટોમાંથી રૂપરેખાઓને અલગ કરવા. તે. કેવી રીતે ઇન્સ્ટોલેશન અલગથી જમાવવામાં આવે છે, અલગથી રૂપરેખાંકિત થાય છે તેનો વ્યવસાય તર્ક.

CFM માટે SOLID

સમય જતાં પ્રોજેક્ટ વધ્યો અને કુદરતી ચાલુ એન્સિબલનો ઉદભવ હતો. તેના દેખાવનું મુખ્ય કારણ એ છે કે ટીમમાં નિપુણતા છે અને તે બેશ જટિલ તર્ક માટે રચાયેલ નથી. જવાબો પણ જટિલ તર્ક સમાવવા લાગ્યા. જટિલ તર્કને અરાજકતામાં ફેરવતા અટકાવવા માટે, સોફ્ટવેર ડેવલપમેન્ટમાં કોડ ગોઠવવાના સિદ્ધાંતો છે સોલિડ ઉપરાંત, ઉદાહરણ તરીકે, ગ્રિગોરી પેટ્રોવે અહેવાલમાં "આઇટી નિષ્ણાતને વ્યક્તિગત બ્રાન્ડની જરૂર કેમ છે" એ પ્રશ્ન ઉઠાવ્યો હતો કે વ્યક્તિને એવી રીતે ડિઝાઇન કરવામાં આવી છે કે તેના માટે કેટલીક સામાજિક સંસ્થાઓ સાથે કામ કરવું સરળ છે, સોફ્ટવેર ડેવલપમેન્ટમાં આ પદાર્થો છે. જો આપણે આ બે વિચારોને જોડીએ અને તેનો વિકાસ કરવાનું ચાલુ રાખીએ, તો અમે જોશું કે અમે પણ ઉપયોગ કરી શકીએ છીએ સોલિડ ભવિષ્યમાં આ તર્કને જાળવી રાખવા અને સંશોધિત કરવાનું સરળ બનાવવા માટે.

એકલ જવાબદારી સિદ્ધાંત

દરેક વર્ગ માત્ર એક જ કાર્ય કરે છે.

કોડને મિક્સ કરીને મોનોલિથિક ડિવાઈન સ્પાઘેટ્ટી રાક્ષસો બનાવવાની જરૂર નથી. ઈન્ફ્રાસ્ટ્રક્ચરમાં સાદી ઈંટો હોવી જોઈએ. તે તારણ આપે છે કે જો તમે જવાબી પ્લેબુકને નાના ટુકડાઓમાં વિભાજિત કરો છો, જવાબી ભૂમિકાઓ વાંચો છો, તો તે જાળવવામાં સરળ છે.

ખુલ્લા બંધ સિદ્ધાંત

ખુલ્લા/બંધ સિદ્ધાંત.

એક્સ્ટેંશન માટે ખુલ્લું: એટલે કે એન્ટિટીના વર્તનને નવા એન્ટિટી પ્રકારો બનાવીને વિસ્તૃત કરી શકાય છે.
ફેરફાર માટે બંધ: એક એન્ટિટીના વર્તનને વિસ્તૃત કરવાના પરિણામે, તે એન્ટિટીનો ઉપયોગ કરતા કોડમાં કોઈ ફેરફાર થવો જોઈએ નહીં.

શરૂઆતમાં, અમે વર્ચ્યુઅલ મશીનો પર ટેસ્ટ ઈન્ફ્રાસ્ટ્રક્ચર જમાવ્યું હતું, પરંતુ એ હકીકતને કારણે કે ડિપ્લોયમેન્ટનો વ્યવસાયિક તર્ક અમલીકરણથી અલગ હતો, અમે કોઈપણ સમસ્યા વિના baremetall માં રોલ આઉટ ઉમેર્યું.

લિસ્કોવ અવેજી સિદ્ધાંત

બાર્બરા લિસ્કોવના અવેજી સિદ્ધાંત. પ્રોગ્રામના ઑબ્જેક્ટ્સ પ્રોગ્રામના યોગ્ય અમલને બદલ્યા વિના તેમના પેટાપ્રકારના ઉદાહરણો સાથે બદલી શકાય તેવા હોવા જોઈએ

જો તમે તેને વધુ વ્યાપક રીતે જુઓ, તો તે કોઈ ચોક્કસ પ્રોજેક્ટની વિશેષતા નથી કે જે ત્યાં લાગુ કરી શકાય સોલિડ, તે સામાન્ય રીતે CFM વિશે છે, ઉદાહરણ તરીકે, અન્ય પ્રોજેક્ટ પર વિવિધ Java, એપ્લિકેશન સર્વર્સ, ડેટાબેસેસ, OS, વગેરેની ટોચ પર બોક્સવાળી Java એપ્લિકેશન જમાવવી જરૂરી છે. આ ઉદાહરણનો ઉપયોગ કરીને, હું આગળના સિદ્ધાંતો પર વિચાર કરીશ સોલિડ

અમારા કિસ્સામાં, ઇન્ફ્રાસ્ટ્રક્ચર ટીમમાં એક કરાર છે કે જો અમે imbjava અથવા oraclejava રોલ ઇન્સ્ટોલ કર્યો છે, તો અમારી પાસે જાવા બાઈનરી એક્ઝિક્યુટેબલ છે. આ જરૂરી છે કારણ કે અપસ્ટ્રીમ ભૂમિકાઓ આ વર્તન પર આધાર રાખે છે; તેઓ જાવાની અપેક્ષા રાખે છે. તે જ સમયે, આ અમને એપ્લિકેશન ડિપ્લોયમેન્ટ લોજિક બદલ્યા વિના એક જાવા અમલીકરણ/સંસ્કરણને બીજા સાથે બદલવાની મંજૂરી આપે છે.

અહીં સમસ્યા એ હકીકતમાં રહેલી છે કે જવાબમાં આને અમલમાં મૂકવું અશક્ય છે, જેના પરિણામે ટીમમાં કેટલાક કરારો દેખાય છે.

ઇન્ટરફેસ સેગ્રિગેશન સિદ્ધાંત

ઈન્ટરફેસ વિભાજન સિદ્ધાંત: “ઘણા ક્લાયંટ-વિશિષ્ટ ઈન્ટરફેસ એક સામાન્ય હેતુ ઈન્ટરફેસ કરતાં વધુ સારા છે.

શરૂઆતમાં, અમે એપ્લીકેશન ડિપ્લોયમેન્ટની તમામ વેરીએબિલિટીને એક જ એન્સિબલ પ્લેબુકમાં મૂકવાનો પ્રયાસ કર્યો, પરંતુ તેને ટેકો આપવો મુશ્કેલ હતો, અને જ્યારે અમારી પાસે એક્સટર્નલ ઈન્ટરફેસ નિર્દિષ્ટ હોય ત્યારે અભિગમ (ક્લાયન્ટ પોર્ટ 443ની અપેક્ષા રાખે છે), પછી ઈન્ફ્રાસ્ટ્રક્ચર વ્યક્તિગત રીતે એસેમ્બલ કરી શકાય છે. ચોક્કસ અમલીકરણ માટે ઇંટો.

અવલંબન વ્યુત્ક્રમ સિદ્ધાંત

નિર્ભરતા વ્યુત્ક્રમનો સિદ્ધાંત. ઉચ્ચ સ્તર પરના મોડ્યુલો નીચલા સ્તરના મોડ્યુલો પર આધારિત ન હોવા જોઈએ. બંને પ્રકારના મોડ્યુલો એબ્સ્ટ્રેક્શન પર આધારિત હોવા જોઈએ. અમૂર્ત વિગતો પર આધાર રાખવો જોઈએ નહીં. વિગતો એબ્સ્ટ્રેક્શન પર આધારિત હોવી જોઈએ.

અહીં ઉદાહરણ એન્ટીપેટર્ન પર આધારિત હશે.

એક ગ્રાહક પાસે ખાનગી ક્લાઉડ હતો.
અમે ક્લાઉડની અંદર વર્ચ્યુઅલ મશીનોનો ઓર્ડર આપ્યો.
પરંતુ ક્લાઉડના સ્વભાવને કારણે, એપ્લિકેશન ડિપ્લોયમેન્ટને VM કયા હાઇપરવાઇઝર સાથે જોડવામાં આવ્યું હતું.

તે. હાઇ-લેવલ એપ્લીકેશન ડિપ્લોયમેન્ટ લોજિક હાઇપરવાઇઝરના નીચલા સ્તરો પર નિર્ભરતા સાથે વહેતું હતું, અને આનો અર્થ આ તર્કનો ફરીથી ઉપયોગ કરતી વખતે સમસ્યાઓ હતી. આ રીતે ન કરો.

ઇન્ટરેક્શન

કોડ તરીકે ઇન્ફ્રાસ્ટ્રક્ચર માત્ર કોડ વિશે જ નથી, પરંતુ કોડ અને લોકો વચ્ચેના સંબંધ વિશે, ઇન્ફ્રાસ્ટ્રક્ચર ડેવલપર્સ વચ્ચેની ક્રિયાપ્રતિક્રિયાઓ વિશે પણ છે.

બસ પરિબળ

ચાલો ધારીએ કે તમારી પાસે તમારા પ્રોજેક્ટ પર વાસ્ય છે. વાસ્ય તમારા ઈન્ફ્રાસ્ટ્રક્ચર વિશે બધું જ જાણે છે, જો વાસ્ય અચાનક ગાયબ થઈ જાય તો શું થશે? આ એક ખૂબ જ વાસ્તવિક પરિસ્થિતિ છે, કારણ કે તેને બસ દ્વારા ટક્કર મારી શકાય છે. ક્યારેક તે થાય છે. જો આવું થાય અને કોડ, તેનું માળખું, તે કેવી રીતે કાર્ય કરે છે, દેખાવ અને પાસવર્ડ્સ વિશેની જાણકારી ટીમમાં વહેંચવામાં આવતી નથી, તો પછી તમને ઘણી અપ્રિય પરિસ્થિતિઓનો સામનો કરવો પડી શકે છે. આ જોખમોને ઘટાડવા અને ટીમમાં જ્ઞાનનું વિતરણ કરવા માટે, તમે વિવિધ અભિગમોનો ઉપયોગ કરી શકો છો

જોડી Devopsing

એવું નથી મજાક તરીકે, કે સંચાલકોએ બીયર પીધું, પાસવર્ડ બદલ્યો અને જોડી પ્રોગ્રામિંગનું એનાલોગ. તે. બે એન્જીનિયરો એક કોમ્પ્યુટર, એક કીબોર્ડ પર બેસીને તમારું ઈન્ફ્રાસ્ટ્રક્ચર એકસાથે સેટ કરવાનું શરૂ કરે છે: સર્વર સેટ કરવું, જવાબી ભૂમિકા લખવી વગેરે. તે સરસ લાગે છે, પરંતુ તે અમારા માટે કામ કરતું નથી. પરંતુ આ પ્રથાના વિશેષ કિસ્સાઓ કામ કર્યું. એક નવો કર્મચારી આવે છે, તેના માર્ગદર્શક તેની સાથે વાસ્તવિક કાર્ય કરે છે, કાર્ય કરે છે અને જ્ઞાન સ્થાનાંતરિત કરે છે.

અન્ય વિશેષ કેસ એક ઘટના કોલ છે. સમસ્યા દરમિયાન, ફરજ પરના લોકો અને તેમાં સામેલ લોકોનું એક જૂથ એકત્ર થાય છે, એક નેતાની નિમણૂક કરવામાં આવે છે, જે તેની સ્ક્રીન શેર કરે છે અને વિચારોની ટ્રેનને અવાજ આપે છે. અન્ય સહભાગીઓ નેતાના વિચારોને અનુસરે છે, કન્સોલમાંથી યુક્તિઓ પર જાસૂસી કરે છે, તપાસો કે તેઓ લોગમાં એક લીટી ચૂકી ગયા નથી અને સિસ્ટમ વિશે નવી વસ્તુઓ શીખે છે. આ અભિગમ વધુ વખત કામ કરતું નથી.

કોડ સમીક્ષા

વ્યક્તિલક્ષી રીતે, તે ઇન્ફ્રાસ્ટ્રક્ચર અને તે કોડ સમીક્ષાનો ઉપયોગ કરીને કેવી રીતે કાર્ય કરે છે તેના વિશે જ્ઞાનનો પ્રસાર કરવો વધુ અસરકારક હતું:

રિપોઝીટરીમાં કોડ દ્વારા ઈન્ફ્રાસ્ટ્રક્ચરનું વર્ણન કરવામાં આવ્યું છે.
અલગ શાખામાં ફેરફારો થાય છે.
મર્જ વિનંતી દરમિયાન, તમે ઇન્ફ્રાસ્ટ્રક્ચરમાં ફેરફારોનો ડેલ્ટા જોઈ શકો છો.

અહીંની વિશેષતા એ હતી કે સમીક્ષકોને એક પછી એક શેડ્યૂલ અનુસાર પસંદ કરવામાં આવ્યા હતા, એટલે કે. અમુક અંશે સંભાવના સાથે તમે ઇન્ફ્રાસ્ટ્રક્ચરના નવા ભાગમાં ચઢી જશો.

કોડ શૈલી

સમય જતાં, સમીક્ષાઓ દરમિયાન ઝઘડાઓ દેખાવા લાગ્યા, કારણ કે... સમીક્ષકોની પોતાની શૈલી હતી અને સમીક્ષકોના પરિભ્રમણએ તેમને વિવિધ શૈલીઓ સાથે સ્ટેક કર્યા: 2 જગ્યાઓ અથવા 4, કેમલકેસ અથવા સ્નેક_કેસ. આનો તરત અમલ કરવો શક્ય ન હતો.

પહેલો વિચાર લિન્ટરનો ઉપયોગ કરવાની ભલામણ કરવાનો હતો, છેવટે, દરેક જણ એન્જિનિયર છે, દરેક સ્માર્ટ છે. પરંતુ વિવિધ સંપાદકો, OS, અનુકૂળ નથી
આ એક બૉટમાં વિકસિત થયું જેણે દરેક સમસ્યારૂપ કમિટ માટે સ્લૅક લખ્યું અને લિંટર આઉટપુટ જોડ્યું. પરંતુ મોટા ભાગના કિસ્સાઓમાં કરવા માટે વધુ મહત્વની બાબતો હતી અને કોડ અનફિક્સ્ડ રહ્યો હતો.

ગ્રીન બિલ્ડ માસ્ટર

સમય પસાર થાય છે, અને અમે એવા નિષ્કર્ષ પર આવ્યા છીએ કે જે ચોક્કસ કસોટીઓ પાસ ન કરે તેને માસ્ટરમાં પ્રવેશની મંજૂરી આપી શકાતી નથી. વોઇલા! અમે ગ્રીન બિલ્ડ માસ્ટરની શોધ કરી છે, જે લાંબા સમયથી સોફ્ટવેર ડેવલપમેન્ટમાં પ્રેક્ટિસ કરવામાં આવે છે:

અલગ શાખામાં વિકાસ ચાલુ છે.
આ થ્રેડ પર ટેસ્ટ ચાલી રહી છે.
જો પરીક્ષણો નિષ્ફળ જાય, તો કોડ તેને માસ્ટરમાં બનાવશે નહીં.

આ નિર્ણય લેવો ખૂબ જ પીડાદાયક હતો, કારણ કે ... ઘણો વિવાદ થયો, પરંતુ તે મૂલ્યવાન હતું, કારણ કે... સમીક્ષાઓ શૈલીમાં તફાવત વિના વિલીનીકરણ માટેની વિનંતીઓ પ્રાપ્ત કરવાનું શરૂ કર્યું, અને સમય જતાં સમસ્યાવાળા વિસ્તારોની સંખ્યામાં ઘટાડો થવા લાગ્યો.

IaC પરીક્ષણ

સ્ટાઈલ ચેકિંગ ઉપરાંત, તમે અન્ય વસ્તુઓનો ઉપયોગ કરી શકો છો, ઉદાહરણ તરીકે, તમારું ઈન્ફ્રાસ્ટ્રક્ચર ખરેખર જમાવી શકે છે કે નહીં તે તપાસવા માટે. અથવા તપાસો કે ઇન્ફ્રાસ્ટ્રક્ચરમાં ફેરફારથી નાણાંની ખોટ નહીં થાય. આની જરૂર કેમ પડી શકે? પ્રશ્ન જટિલ અને દાર્શનિક છે, એક વાર્તા સાથે જવાબ આપવાનું વધુ સારું છે કે કોઈક રીતે પાવરશેલ પર એક ઓટો-સ્કેલર હતું જેણે સીમાની સ્થિતિ તપાસી ન હતી => જરૂરી કરતાં વધુ 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, પાઇસ્ટ. પરંતુ જવાબી, રસોઇયા, સોલ્ટસ્ટેક અને તેમના જેવા અન્ય લોકોનું શું કરવું?

ખૂબ જ શરૂઆતમાં અમે વિશે વાત કરી હતી સોલિડ અને આપણા ઈન્ફ્રાસ્ટ્રક્ચરમાં નાની ઈંટો હોવી જોઈએ. તેમનો સમય આવી ગયો છે.

ઇન્ફ્રાસ્ટ્રક્ચર નાની ઇંટોમાં વિભાજિત થયેલ છે, ઉદાહરણ તરીકે, જવાબદાર ભૂમિકાઓ.
અમુક પ્રકારનું વાતાવરણ જમાવવામાં આવે છે, પછી તે ડોકર હોય કે VM.
અમે આ પરીક્ષણ વાતાવરણમાં અમારી જવાબી ભૂમિકા લાગુ કરીએ છીએ.
અમે તપાસીએ છીએ કે બધું અમારી અપેક્ષા મુજબ કામ કરે છે (અમે પરીક્ષણો ચલાવીએ છીએ).
ઠીક છે કે નહીં તે આપણે નક્કી કરીએ છીએ.

IaC પરીક્ષણ: એકમ પરીક્ષણ સાધનો

પ્રશ્ન, CFM માટે પરીક્ષણો શું છે? તમે ફક્ત સ્ક્રિપ્ટ ચલાવી શકો છો, અથવા તમે આ માટે તૈયાર ઉકેલોનો ઉપયોગ કરી શકો છો:

સીએફએમ
ટૂલ

Ansible
ટેસ્ટિનફ્રા

વડા
નિરીક્ષક

વડા
સર્વરસ્પેક

ક્ષાર
ગોસ

ટેસ્ટિનફ્રા માટેનું ઉદાહરણ, તે વપરાશકર્તાઓને તપાસી રહ્યાં છે 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 પરીક્ષણ ફ્રેમવર્ક

પ્રશ્ન ઊભો થાય છે: તે બધું એકસાથે કેવી રીતે મૂકવું અને તેને કેવી રીતે શરૂ કરવું? કરી શકે છે તેને લો અને તે જાતે કરો જો ત્યાં પૂરતી સંખ્યામાં ઇજનેરો હોય. અથવા તમે તૈયાર સોલ્યુશન્સ લઈ શકો છો, જો કે તેમાંના ઘણા બધા નથી:

સીએફએમ
ટૂલ

Ansible
અણુ

વડા
ટેસ્ટ કિચન

ટેરાફોર્મ
ટેરેટેસ્ટ

2018-2019 માટે ગીથબ પરના પ્રોજેક્ટ્સમાં ફેરફારોનું ઉદાહરણ:

પરમાણુ વિ. ટેસ્ટકિચન

શરૂઆતમાં અમે ટેસ્ટકિચનનો ઉપયોગ કરવાનો પ્રયાસ કર્યો:

સમાંતર એક VM બનાવો.
જવાબી ભૂમિકાઓ લાગુ કરો.
નિરીક્ષણ ચલાવો.

25-35 ભૂમિકાઓ માટે તેણે 40-70 મિનિટ કામ કર્યું, જે લાંબુ હતું.

આગળનું પગલું જેનકિન્સ/ડોકર/એન્સિબલ/મોલેક્યુલનું સંક્રમણ હતું. વૈચારિક રીતે બધું સમાન છે

લિન્ટ પ્લેબુક્સ.
ભૂમિકાઓને લાઇન અપ કરો.
કન્ટેનર લોંચ કરો
જવાબી ભૂમિકાઓ લાગુ કરો.
ટેસ્ટિનફ્રા ચલાવો.
આડેધડતા તપાસો.

40 ભૂમિકાઓ માટે લિંટિંગ અને એક ડઝન માટે પરીક્ષણો લગભગ 15 મિનિટ લેવા લાગ્યા.

શું પસંદ કરવું તે ઘણા પરિબળો પર આધાર રાખે છે, જેમ કે વપરાયેલ સ્ટેક, ટીમમાં કુશળતા વગેરે. અહીં દરેક વ્યક્તિ જાતે નક્કી કરે છે કે યુનિટ ટેસ્ટિંગ પ્રશ્ન કેવી રીતે બંધ કરવો

IaC પરીક્ષણ: એકીકરણ પરીક્ષણો

ઇન્ફ્રાસ્ટ્રક્ચર પરીક્ષણ પિરામિડમાં આગળનું પગલું એકીકરણ પરીક્ષણો હશે. તેઓ એકમ પરીક્ષણો જેવા જ છે:

ઇન્ફ્રાસ્ટ્રક્ચર નાની ઇંટોમાં વિભાજિત થયેલ છે, ઉદાહરણ તરીકે જવાબી ભૂમિકાઓ.
અમુક પ્રકારનું વાતાવરણ જમાવવામાં આવે છે, પછી તે ડોકર હોય કે VM.
આ પરીક્ષણ વાતાવરણ માટે અરજી કરો એક ટોળું જવાબદાર ભૂમિકાઓ.
અમે તપાસીએ છીએ કે બધું અમારી અપેક્ષા મુજબ કામ કરે છે (અમે પરીક્ષણો ચલાવીએ છીએ).
ઠીક છે કે નહીં તે આપણે નક્કી કરીએ છીએ.

સામાન્ય રીતે કહીએ તો, અમે એકમ પરીક્ષણોની જેમ સિસ્ટમના વ્યક્તિગત તત્વનું પ્રદર્શન તપાસતા નથી, અમે તપાસીએ છીએ કે સર્વર સંપૂર્ણ રીતે કેવી રીતે ગોઠવાયેલ છે.

IaC ટેસ્ટિંગ: એન્ડ ટુ એન્ડ ટેસ્ટ

પિરામિડની ટોચ પર અમને એન્ડ ટુ એન્ડ ટેસ્ટ દ્વારા આવકારવામાં આવે છે. તે. અમે અલગ સર્વર, એક અલગ સ્ક્રિપ્ટ અથવા અમારા ઈન્ફ્રાસ્ટ્રક્ચરની અલગ ઈંટની કામગીરી તપાસતા નથી. અમે તપાસીએ છીએ કે ઘણા સર્વર્સ એકસાથે જોડાયેલા છે, અમારી ઇન્ફ્રાસ્ટ્રક્ચર અમારી અપેક્ષા મુજબ કામ કરે છે. કમનસીબે, મેં ક્યારેય તૈયાર બોક્સવાળા સોલ્યુશન્સ જોયા નથી, કદાચ કારણ કે... ઇન્ફ્રાસ્ટ્રક્ચર ઘણીવાર અનન્ય અને નમૂનારૂપ અને પરીક્ષણ માટે ફ્રેમવર્ક બનાવવા માટે મુશ્કેલ હોય છે. પરિણામે, દરેક વ્યક્તિ પોતાના ઉકેલો બનાવે છે. માંગ છે, પણ જવાબ નથી. તેથી, હું તમને કહીશ કે અન્યને વિચારોને ધ્વનિ કરવા અથવા મારા નાકને ઘસવા માટે શું છે તે હકીકતમાં કે દરેક વસ્તુની શોધ આપણા પહેલાં ખૂબ પહેલા થઈ હતી.

સમૃદ્ધ ઇતિહાસ સાથેનો પ્રોજેક્ટ. તેનો ઉપયોગ મોટી સંસ્થાઓમાં થાય છે અને સંભવતઃ તમારામાંના દરેકે તેની સાથે પરોક્ષ રીતે પાથ ઓળંગ્યા છે. એપ્લિકેશન ઘણા ડેટાબેસેસ, એકીકરણ વગેરેને સપોર્ટ કરે છે. ઈન્ફ્રાસ્ટ્રક્ચર કેવું દેખાઈ શકે છે તે જાણવું એ ઘણી બધી ડોકર-કંપોઝ ફાઈલો છે, અને જેનકિન્સ કયા વાતાવરણમાં કયા પરીક્ષણો ચલાવવાના છે તે જાણવું.

આ યોજના ફ્રેમવર્કની અંદર સુધી લાંબા સમય સુધી કામ કરતી હતી સંશોધન અમે આને Openshift માં સ્થાનાંતરિત કરવાનો પ્રયાસ કર્યો નથી. કન્ટેનર એ જ રહે છે, પરંતુ પ્રક્ષેપણ વાતાવરણ બદલાઈ ગયું છે (હેલો ડ્રાય ફરીથી).

સંશોધનનો વિચાર આગળ વધ્યો, અને ઓપનશિફ્ટમાં તેમને APB (એન્સિબલ પ્લેબુક બંડલ) જેવી વસ્તુ મળી, જે તમને કન્ટેનરમાં ઈન્ફ્રાસ્ટ્રક્ચર કેવી રીતે જમાવવું તે અંગેના જ્ઞાનને પેક કરવાની મંજૂરી આપે છે. તે. ઇન્ફ્રાસ્ટ્રક્ચર કેવી રીતે ગોઠવવું તે અંગે જ્ઞાનનો એક પુનરાવર્તિત, પરીક્ષણ કરવા યોગ્ય મુદ્દો છે.

જ્યાં સુધી આપણે વિજાતીય ઈન્ફ્રાસ્ટ્રક્ચરમાં ન પહોંચીએ ત્યાં સુધી આ બધું સારું લાગતું હતું: અમને પરીક્ષણો માટે વિન્ડોઝની જરૂર હતી. પરિણામે, શું, ક્યાં, કેવી રીતે જમાવવું અને પરીક્ષણનું જ્ઞાન જેનકિન્સમાં છે.

ઉપસંહાર

ઈન્ફ્રાસ્ટ્રક્ચર કોડ છે

રીપોઝીટરીમાં કોડ.
માનવ ક્રિયાપ્રતિક્રિયા.
ઇન્ફ્રાસ્ટ્રક્ચર પરીક્ષણ.

કડીઓ

સોર્સ: www.habr.com

ઇન્ફ્રાસ્ટ્રક્ચર કોડની 200 લાઇનના પરીક્ષણમાંથી હું શું શીખ્યો