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

સાધનસામગ્રી વેચાણની ટોચના ઘણા મહિનાઓ પહેલાં સાઇટ પર આવી હતી. ઑપરેશન્સ સેવા, અલબત્ત, જાણે છે કે સર્વર્સને ઉત્પાદન વાતાવરણમાં લાવવા માટે કેવી રીતે અને શું ગોઠવવું. પરંતુ અમારે આને સ્વચાલિત કરવાની અને માનવ પરિબળને દૂર કરવાની જરૂર છે. વધુમાં, SAP સિસ્ટમના સમૂહના સ્થળાંતર પહેલા સર્વર્સ બદલવામાં આવ્યા હતા જે કંપની માટે મહત્વપૂર્ણ હતા.

નવા સર્વર્સનું કમિશનિંગ સમયમર્યાદા સાથે સખત રીતે જોડાયેલું હતું. અને તેને ખસેડવાનો અર્થ એ છે કે એક અબજ ભેટોના શિપમેન્ટ અને સિસ્ટમના સ્થળાંતરને જોખમમાં મૂકવું. ફાધર ફ્રોસ્ટ અને સાન્તાક્લોઝની બનેલી ટીમ પણ તારીખ બદલી શકી નથી - તમે વર્ષમાં માત્ર એક જ વાર વેરહાઉસ મેનેજમેન્ટ માટે SAP સિસ્ટમ ટ્રાન્સફર કરી શકો છો. 31 ડિસેમ્બરથી 1 જાન્યુઆરી સુધી, છૂટક વિક્રેતાના વિશાળ વેરહાઉસ, કુલ 20 ફૂટબોલ મેદાનના કદ, તેમનું કામ 15 કલાક માટે બંધ કરે છે. અને સિસ્ટમને ખસેડવા માટેનો આ એકમાત્ર સમયગાળો છે. સર્વર રજૂ કરતી વખતે અમારી પાસે ભૂલ માટે કોઈ જગ્યા નહોતી.

મને સ્પષ્ટ કરવા દો: મારી વાર્તા અમારી ટીમ વાપરે છે તે સાધનો અને ગોઠવણી વ્યવસ્થાપન પ્રક્રિયાને પ્રતિબિંબિત કરે છે.

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

OS ઇન્સ્ટોલેશન મેનેજમેન્ટ

પ્રથમ સ્તર એ ભૌતિક અને વર્ચ્યુઅલ સર્વર્સ પર ઑપરેટિંગ સિસ્ટમ્સના ઇન્સ્ટોલેશનને મેનેજ કરવા માટેની સિસ્ટમ છે. તે માનવ પરિબળને દૂર કરીને, મૂળભૂત OS રૂપરેખાંકનો બનાવે છે.

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

ઇન્સ્ટોલેશન મેનેજમેન્ટ સિસ્ટમ માટે "મહત્તમ" કાર્ય BIOS/ફર્મવેર સ્તરથી OS સુધી સર્વરોને આપમેળે ગોઠવવાનું છે. અહીં ઘણું બધું સાધનો અને સેટઅપ કાર્યો પર આધારિત છે. વિજાતીય સાધનો માટે, તમે ધ્યાનમાં લઈ શકો છો REDFISH API. જો તમામ હાર્ડવેર એક વિક્રેતા પાસેથી હોય, તો તે ઘણી વખત તૈયાર મેનેજમેન્ટ ટૂલ્સનો ઉપયોગ કરવા માટે વધુ અનુકૂળ હોય છે (ઉદાહરણ તરીકે, HP ILO એમ્પ્લીફાયર, DELL OpenManage, વગેરે).

ભૌતિક સર્વર્સ પર OS ઇન્સ્ટોલ કરવા માટે, અમે જાણીતા કોબ્લરનો ઉપયોગ કર્યો છે, જે ઑપરેશન સેવા સાથે સંમત ઇન્સ્ટોલેશન પ્રોફાઇલ્સના સમૂહને વ્યાખ્યાયિત કરે છે. ઇન્ફ્રાસ્ટ્રક્ચરમાં નવું સર્વર ઉમેરતી વખતે, એન્જિનિયરે સર્વરના MAC એડ્રેસને કોબ્બલરમાં જરૂરી પ્રોફાઇલ સાથે જોડી દીધું. પ્રથમ વખત નેટવર્ક પર બુટ કરતી વખતે, સર્વરને અસ્થાયી સરનામું અને એક નવું OS પ્રાપ્ત થયું. પછી તેને લક્ષ્ય VLAN/IP એડ્રેસિંગમાં સ્થાનાંતરિત કરવામાં આવ્યું અને ત્યાં કામ ચાલુ રાખ્યું. હા, VLAN ને બદલવામાં સમય લાગે છે અને સંકલનની જરૂર છે, પરંતુ તે ઉત્પાદન વાતાવરણમાં સર્વરના આકસ્મિક ઇન્સ્ટોલેશન સામે વધારાનું રક્ષણ પૂરું પાડે છે.

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

ચોખા. 1. ઑપરેટિંગ સિસ્ટમ્સના ઇન્સ્ટોલેશનનું સંચાલન.

મેનેજિંગ રહસ્યો

કોઈપણ રૂપરેખાંકન વ્યવસ્થાપન સિસ્ટમમાં ડેટા હોય છે જે સામાન્ય વપરાશકર્તાઓથી છુપાયેલ હોવો જોઈએ, પરંતુ સિસ્ટમ તૈયાર કરવા માટે જરૂરી છે. આ સ્થાનિક વપરાશકર્તાઓ અને સેવા એકાઉન્ટ્સ, પ્રમાણપત્ર કી, વિવિધ API ટોકન્સ વગેરે માટેના પાસવર્ડ્સ છે. તેને સામાન્ય રીતે "રહસ્યો" કહેવામાં આવે છે.

જો તમે આ રહસ્યોને ક્યાં અને કેવી રીતે સંગ્રહિત કરવા તે શરૂઆતથી જ નિર્ધારિત કરતા નથી, તો પછી, માહિતી સુરક્ષા આવશ્યકતાઓની કડકતાને આધારે, નીચેની સ્ટોરેજ પદ્ધતિઓ સંભવિત છે:

• સીધા રૂપરેખાંકન નિયંત્રણ કોડમાં અથવા રીપોઝીટરીમાં ફાઇલોમાં;
• વિશિષ્ટ રૂપરેખાંકન વ્યવસ્થાપન સાધનોમાં (ઉદાહરણ તરીકે, એન્સિબલ વૉલ્ટ);
• CI/CD સિસ્ટમમાં (Jenkins/TeamCity/GitLab/etc.) અથવા કન્ફિગરેશન મેનેજમેન્ટ સિસ્ટમ્સમાં (એન્સિબલ ટાવર/એન્સિબલ AWX);
• રહસ્યો પણ "મેન્યુઅલી" ટ્રાન્સફર કરી શકાય છે. ઉદાહરણ તરીકે, તેઓ નિર્દિષ્ટ સ્થાન પર નાખવામાં આવે છે, અને પછી તેઓ રૂપરેખાંકન વ્યવસ્થાપન સિસ્ટમો દ્વારા ઉપયોગમાં લેવાય છે;
• ઉપરના વિવિધ સંયોજનો.

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

અમે કેન્દ્રિય ગુપ્ત સ્ટોરેજ HashiCorp વૉલ્ટનો ઉપયોગ કર્યો. આ અમને મંજૂરી આપી:

• રહસ્યો સુરક્ષિત રાખો. તેઓ એન્ક્રિપ્ટેડ છે, અને જો કોઈ વ્યક્તિ વૉલ્ટ ડેટાબેઝની ઍક્સેસ મેળવે તો પણ (ઉદાહરણ તરીકે, તેને બેકઅપમાંથી પુનઃસ્થાપિત કરીને), તેઓ ત્યાં સંગ્રહિત રહસ્યો વાંચી શકશે નહીં;
• રહસ્યો સુધી પહોંચવા માટે નીતિઓ ગોઠવો. ફક્ત તેમને "ફાળવામાં" રહસ્યો વપરાશકર્તાઓ અને એપ્લિકેશનો માટે ઉપલબ્ધ છે;
• રહસ્યો માટે ઓડિટ ઍક્સેસ. રહસ્યો સાથેની કોઈપણ ક્રિયાઓ વૉલ્ટ ઓડિટ લોગમાં રેકોર્ડ કરવામાં આવે છે;
• રહસ્યો સાથે કામ કરવા માટે સંપૂર્ણ સુવિધાયુક્ત "જીવન ચક્ર" ગોઠવો. તેઓ બનાવી શકાય છે, રદ કરી શકાય છે, સમાપ્તિ તારીખ સેટ કરી શકાય છે, વગેરે.
• અન્ય સિસ્ટમો સાથે સંકલિત કરવા માટે સરળ છે જેને રહસ્યોની ઍક્સેસની જરૂર છે;
• અને એન્ડ-ટુ-એન્ડ એન્ક્રિપ્શન, OS અને ડેટાબેઝ માટે વન-ટાઇમ પાસવર્ડ્સ, અધિકૃત કેન્દ્રોના પ્રમાણપત્રો વગેરેનો પણ ઉપયોગ કરો.

હવે ચાલો કેન્દ્રિય પ્રમાણીકરણ અને અધિકૃતતા સિસ્ટમ પર આગળ વધીએ. તેના વિના કરવું શક્ય હતું, પરંતુ ઘણી સંબંધિત સિસ્ટમોમાં વપરાશકર્તાઓનું સંચાલન કરવું એ ખૂબ બિન-તુચ્છ છે. અમે LDAP સેવા દ્વારા પ્રમાણીકરણ અને અધિકૃતતા ગોઠવી છે. નહિંતર, વૉલ્ટે વપરાશકર્તાઓ માટે પ્રમાણીકરણ ટોકન્સનો સતત ઇશ્યૂ અને ટ્રૅક રાખવો પડશે. અને વપરાશકર્તાઓને કાઢી નાખવું અને ઉમેરવાનું એક શોધમાં ફેરવાઈ જશે "શું મેં આ વપરાશકર્તા ખાતું દરેક જગ્યાએ બનાવ્યું/ડીલીટ કર્યું?"

અમે અમારી સિસ્ટમમાં બીજું સ્તર ઉમેરીએ છીએ: રહસ્યોનું સંચાલન અને કેન્દ્રીય પ્રમાણીકરણ/અધિકૃતતા:

ચોખા. 2. સિક્રેટ્સ મેનેજમેન્ટ.

રૂપરેખાંકન વ્યવસ્થાપન

અમે કોર પર પહોંચ્યા - CMS સિસ્ટમ. અમારા કિસ્સામાં, આ Ansible અને Red Hat Ansible AWX નું સંયોજન છે.

Ansible ને બદલે Chef, Puppet, SaltStack નો ઉપયોગ કરી શકાય. અમે કેટલાક માપદંડોના આધારે જવાબીબલ પસંદ કર્યું છે.

• પ્રથમ, તે વર્સેટિલિટી છે. નિયંત્રણ માટે તૈયાર મોડ્યુલોનો સમૂહ એક છાપ બનાવે છે. અને જો તમારી પાસે તે પૂરતું નથી, તો તમે GitHub અને Galaxy પર સર્ચ કરી શકો છો.
• બીજું, વ્યવસ્થાપિત સાધનો પર એજન્ટોને ઇન્સ્ટોલ અને સપોર્ટ કરવાની જરૂર નથી, સાબિત કરો કે તેઓ લોડમાં દખલ કરતા નથી, અને "બુકમાર્ક્સ" ની ગેરહાજરીની પુષ્ટિ કરો.
• ત્રીજે સ્થાને, Ansible માં પ્રવેશ માટે ઓછો અવરોધ છે. એક સક્ષમ ઇજનેર ઉત્પાદન સાથે કામ કરવાના પ્રથમ દિવસે શાબ્દિક રીતે વર્કિંગ પ્લેબુક લખશે.

પરંતુ ઉત્પાદન વાતાવરણમાં એકલા જવાબ આપવાનું અમારા માટે પૂરતું ન હતું. નહિંતર, પ્રવેશને પ્રતિબંધિત કરવા અને સંચાલકોની ક્રિયાઓનું ઓડિટ કરવા સાથે ઘણી સમસ્યાઓ ઊભી થશે. ઍક્સેસ કેવી રીતે પ્રતિબંધિત કરવી? છેવટે, દરેક વિભાગ માટે સર્વરનો "પોતાનો" સેટ મેનેજ કરવો (વાંચો: જવાબી પ્લેબુક ચલાવો) જરૂરી હતું. માત્ર અમુક કર્મચારીઓને ચોક્કસ જવાબી પ્લેબુક ચલાવવાની મંજૂરી કેવી રીતે આપવી? અથવા Ansible ચાલતા સર્વર અને સાધનો પર સ્થાનિક જ્ઞાનની પુષ્કળ માહિતી સેટ કર્યા વિના પ્લેબુક કોણે લોન્ચ કરી તે કેવી રીતે ટ્રૅક કરવું?

આવા મુદ્દાઓનો સિંહફાળો Red Hat દ્વારા ઉકેલવામાં આવે છે જવાબી ટાવર, અથવા તેનો ઓપન-સોર્સ અપસ્ટ્રીમ પ્રોજેક્ટ જવાબી AWX. એટલા માટે અમે તેને ગ્રાહક માટે પસંદ કર્યું.

અને અમારી CMS સિસ્ટમના પોટ્રેટને વધુ એક સ્પર્શ. જવાબી પ્લેબુક કોડ રીપોઝીટરી મેનેજમેન્ટ સિસ્ટમમાં સંગ્રહિત થવી જોઈએ. અમારી પાસે છે GitLab CE.

તેથી, રૂપરેખાંકનો પોતે જ Ansible/Ansible AWX/GitLab (ફિગ. 3 જુઓ) ના સંયોજન દ્વારા સંચાલિત થાય છે. અલબત્ત, AWX/GitLab સિંગલ ઓથેન્ટિકેશન સિસ્ટમ સાથે સંકલિત છે, અને Ansible પ્લેબુક HashiCorp Vault સાથે સંકલિત છે. રૂપરેખાંકનો એન્સિબલ AWX દ્વારા જ ઉત્પાદન વાતાવરણમાં પ્રવેશ કરે છે, જેમાં તમામ "ગેમના નિયમો" સ્પષ્ટ કરેલ છે: કોણ શું ગોઠવી શકે છે, CMS માટે રૂપરેખાંકન મેનેજમેન્ટ કોડ ક્યાંથી મેળવવો વગેરે.

ચોખા. 3. રૂપરેખાંકન વ્યવસ્થાપન.

ટેસ્ટ મેનેજમેન્ટ

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

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

• દરેક ભૂમિકા એકમ પરીક્ષણો દ્વારા આવરી લેવામાં આવે છે;
• જ્યારે પણ રૂપરેખાંકનોનું સંચાલન કરતા કોડમાં કોઈ ફેરફાર થાય ત્યારે પરીક્ષણો આપમેળે ચલાવવામાં આવે છે;
• રૂપરેખાંકન વ્યવસ્થાપન કોડમાં ફેરફારો સફળતાપૂર્વક તમામ પરીક્ષણો અને કોડ સમીક્ષા પસાર કર્યા પછી જ ઉત્પાદન પર્યાવરણમાં પ્રકાશિત થાય છે.

કોડ ડેવલપમેન્ટ અને કન્ફિગરેશન મેનેજમેન્ટ શાંત અને વધુ અનુમાનિત બની ગયું છે. સતત પરીક્ષણનું આયોજન કરવા માટે, અમે GitLab CI/CD ટૂલકિટનો ઉપયોગ કર્યો અને લીધો જવાબી અણુ.

જ્યારે પણ કન્ફિગરેશન મેનેજમેન્ટ કોડમાં ફેરફાર થાય છે, ત્યારે GitLab CI/CD મોલેક્યુલને કૉલ કરે છે:

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

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

ચોખા. 4. GitLab CI/CD માં ભૂમિકાઓનું સ્વચાલિત પરીક્ષણ.

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

પરિણામે, મેન્યુઅલ ફેરફારોને લીધે, સમાન પ્રકારના સાધનો પરના રૂપરેખાંકનમાં વિસંગતતાઓ દેખાય છે (ઉદાહરણ તરીકે, એચએ ક્લસ્ટર નોડ્સ પર sysctl સેટિંગ્સ અલગ રીતે ગોઠવેલ છે). અથવા સાધનો પરનું વાસ્તવિક રૂપરેખાંકન CMS કોડમાં ઉલ્લેખિત કરતા અલગ છે.

તેથી, સતત પરીક્ષણ ઉપરાંત, અમે રૂપરેખાંકન વિસંગતતાઓ માટે ઉત્પાદન વાતાવરણ તપાસીએ છીએ. અમે સૌથી સરળ વિકલ્પ પસંદ કર્યો: CMS રૂપરેખાંકન કોડને "ડ્રાય રન" મોડમાં ચલાવો, એટલે કે, ફેરફારો લાગુ કર્યા વિના, પરંતુ આયોજિત અને વાસ્તવિક ગોઠવણી વચ્ચેની તમામ વિસંગતતાઓની સૂચના સાથે. અમે સમયાંતરે પ્રોડક્શન સર્વર્સ પર “—ચેક” વિકલ્પ સાથે તમામ જવાબી પ્લેબુક ચલાવીને આનો અમલ કર્યો છે. હંમેશની જેમ, પ્લેબુકને લોન્ચ કરવા અને અપ ટુ ડેટ રાખવા માટે Ansible AWX જવાબદાર છે (જુઓ આકૃતિ 5):

ચોખા. 5. જવાબી AWX માં રૂપરેખાંકન વિસંગતતાઓ માટે તપાસે છે.

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

અમારી પાસે હવે એન્સિબલ AWX/GitLab/મોલેક્યુલ (આકૃતિ 6) નો સમાવેશ કરતું મહત્વનું પરીક્ષણ સ્તર છે.

ચોખા. 6. ટેસ્ટ મેનેજમેન્ટ.

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

આજે સર્વર અને વાતાવરણની સેટિંગ્સમાં કોઈ "ગુપ્ત જ્ઞાન" નથી. તમામ જરૂરી સુવિધાઓ પ્લેબુકમાં પ્રતિબિંબિત થાય છે. વધુ સર્જનાત્મકતા અને અસ્પષ્ટ સૂચનાઓ નથી: “તેને નિયમિત ઓરેકલની જેમ ઇન્સ્ટોલ કરો, પરંતુ તમારે કેટલાક sysctl સેટિંગ્સનો ઉલ્લેખ કરવાની અને જરૂરી UID સાથે વપરાશકર્તાઓ ઉમેરવાની જરૂર છે. ઓપરેશનમાં છોકરાઓને પૂછો, તેઓ જાણે છે».

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

અને અલબત્ત, અમે કેટલાક દિવસોથી કલાકો સુધી ઑપરેશનમાં સર્વર્સના પ્રક્ષેપણને વેગ આપ્યો.

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

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

લેખક: સેર્ગેઈ આર્ટેમોવ, વિભાગના આર્કિટેક્ટ DevOps ઉકેલો "જેટ ઇન્ફોસિસ્ટમ્સ"

સોર્સ: www.habr.com