werf - કુબરનેટ્સમાં CI/CD માટે અમારું સાધન (વિહંગાવલોકન અને વિડિયો રિપોર્ટ)

ફેસ્ટિવલના ભાગ રૂપે યોજાયેલી DevOpsConf 27 કોન્ફરન્સના મુખ્ય હોલમાં 2019 મે RIT++ 2019, "સતત ડિલિવરી" વિભાગના ભાગ રૂપે, "werf - કુબરનેટ્સમાં CI/CD માટે અમારું સાધન" અહેવાલ આપવામાં આવ્યો હતો. તે તેના વિશે વાત કરે છે સમસ્યાઓ અને પડકારો કે જે કુબરનેટ્સ પર જમાવતી વખતે દરેક વ્યક્તિ સામનો કરે છે, તેમજ ઘોંઘાટ વિશે જે તરત જ ધ્યાનપાત્ર ન હોઈ શકે. સંભવિત ઉકેલોનું વિશ્લેષણ કરીને, અમે બતાવીએ છીએ કે ઓપન સોર્સ ટૂલમાં આ કેવી રીતે લાગુ કરવામાં આવે છે વર્ફ.

પ્રસ્તુતિથી, અમારી ઉપયોગિતા (અગાઉ ડીએપી તરીકે જાણીતી હતી) ની ઐતિહાસિક સીમાચિહ્ન પર પહોંચી છે GitHub પર 1000 તારા — અમે આશા રાખીએ છીએ કે તેનો વપરાશકર્તાઓનો વધતો સમુદાય ઘણા DevOps એન્જિનિયરો માટે જીવન સરળ બનાવશે.

તો, ચાલો પરિચય આપીએ અહેવાલનો વિડિયો (~47 મિનિટ, લેખ કરતાં વધુ માહિતીપ્રદ) અને તેમાંથી મુખ્ય અર્ક ટેક્સ્ટ સ્વરૂપમાં. જાઓ!

કુબરનેટ્સને કોડ વિતરિત કરી રહ્યાં છે

વાત હવે વેર્ફ વિશે નહીં, પરંતુ કુબરનેટ્સમાં CI/CD વિશે હશે, જેનો અર્થ એ છે કે અમારું સોફ્ટવેર ડોકર કન્ટેનરમાં પેક કરવામાં આવ્યું છે. (મેં આ વિશે વાત કરી હતી 2016 નો અહેવાલ), અને K8s નો ઉપયોગ તેને ઉત્પાદનમાં ચલાવવા માટે કરવામાં આવશે (આ વિશે વધુ 2017 વર્ષ).

કુબરનેટ્સમાં ડિલિવરી કેવી દેખાય છે?

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

અહીં કેટલીક મહત્વપૂર્ણ નોંધો છે:

1. કારણ કે આપણી પાસે અપરિવર્તનશીલ ઈન્ફ્રાસ્ટ્રક્ચર છે (અચલ ઈન્ફ્રાસ્ટ્રક્ચર), એપ્લીકેશન ઈમેજ કે જેનો ઉપયોગ તમામ તબક્કે થાય છે (સ્ટેજિંગ, ઉત્પાદન, વગેરે), ત્યાં એક હોવું જોઈએ. મેં આ વિશે વધુ વિગતવાર અને ઉદાહરણો સાથે વાત કરી. અહીં.
2. કારણ કે અમે ઈન્ફ્રાસ્ટ્રક્ચરને કોડ અભિગમ તરીકે અનુસરીએ છીએ (IaC), એપ્લિકેશન કોડ, તેને એસેમ્બલ કરવા અને લોંચ કરવા માટેની સૂચનાઓ હોવી જોઈએ બરાબર એક રીપોઝીટરીમાં. આ વિશે વધુ માહિતી માટે, જુઓ સમાન અહેવાલ.
3. ડિલિવરી સાંકળ (ડિલિવરી) અમે તેને સામાન્ય રીતે આના જેવા જોઈએ છીએ: એપ્લિકેશન એસેમ્બલ કરવામાં આવી હતી, પરીક્ષણ કરવામાં આવી હતી, રિલીઝ કરવામાં આવી હતી (પ્રકાશન સ્ટેજ) અને તે છે - ડિલિવરી થઈ ગઈ છે. પરંતુ વાસ્તવમાં, વપરાશકર્તાને તે મળે છે જે તમે રોલઆઉટ કર્યું છે, નથી પછી જ્યારે તમે તેને પ્રોડક્શનમાં પહોંચાડ્યું, અને જ્યારે તે ત્યાં જઈ શક્યો અને આ પ્રોડક્શન કામ કર્યું. તેથી હું માનું છું કે ડિલિવરી ચેઇન સમાપ્ત થાય છે માત્ર ઓપરેશનલ સ્ટેજ પર (દોડવું), અથવા વધુ સ્પષ્ટ રીતે, તે ક્ષણે પણ જ્યારે કોડ ઉત્પાદનમાંથી દૂર કરવામાં આવ્યો હતો (તેને નવા સાથે બદલીને).

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

સ્ટેજ બનાવો

એવું લાગે છે કે તમે 2019 માં ડોકર ઇમેજ બનાવવા વિશે વાત કરી શકો છો, જ્યારે દરેક જાણે છે કે ડોકરફાઇલ્સ કેવી રીતે લખવી અને ચલાવવી docker build?.. અહીં એવી ઘોંઘાટ છે કે જેના પર હું ધ્યાન આપવા માંગુ છું:

1. છબી વજન બાબતો, તેથી ઉપયોગ કરો બહુ-તબક્કાઇમેજમાં ફક્ત તે જ એપ્લિકેશન છોડો જે ખરેખર ઓપરેશન માટે જરૂરી છે.
2. સ્તરોની સંખ્યા ની સાંકળો સંયોજિત કરીને ઘટાડવી આવશ્યક છે RUN- અર્થ અનુસાર આદેશો.
3. જો કે, આ સમસ્યાઓ ઉમેરે છે ડિબગીંગ, કારણ કે જ્યારે એસેમ્બલી ક્રેશ થાય છે, ત્યારે તમારે સમસ્યા ઊભી કરનાર સાંકળમાંથી યોગ્ય આદેશ શોધવો પડશે.
4. એસેમ્બલી ઝડપ મહત્વપૂર્ણ કારણ કે અમે ફેરફારોને ઝડપથી બહાર લાવવા અને પરિણામો જોવા માંગીએ છીએ. ઉદાહરણ તરીકે, જ્યારે પણ તમે એપ્લિકેશન બનાવો ત્યારે તમે ભાષા લાઇબ્રેરીઓમાં નિર્ભરતા પુનઃબીલ્ડ કરવા માંગતા નથી.
5. ઘણીવાર એક ગિટ રિપોઝીટરીમાંથી તમને જરૂર હોય છે ઘણી છબીઓ, જે ડોકરફાઇલ્સના સમૂહ (અથવા એક ફાઇલમાં નામાંકિત તબક્કાઓ) અને તેમની અનુક્રમિક એસેમ્બલી સાથે બેશ સ્ક્રિપ્ટ દ્વારા ઉકેલી શકાય છે.

આ ફક્ત આઇસબર્ગની ટોચ હતી જેનો દરેક વ્યક્તિ સામનો કરે છે. પરંતુ ત્યાં અન્ય સમસ્યાઓ છે, ખાસ કરીને:

1. ઘણીવાર એસેમ્બલીના તબક્કે આપણને કંઈકની જરૂર હોય છે માઉન્ટ (ઉદાહરણ તરીકે, તૃતીય-પક્ષ નિર્દેશિકામાં apt જેવા આદેશનું પરિણામ કેશ કરો).
2. અમે ઈચ્છીએ છીએ Ansible શેલમાં લખવાને બદલે.
3. અમે ઈચ્છીએ છીએ ડોકર વગર બિલ્ડ કરો (આપણે શા માટે વધારાના વર્ચ્યુઅલ મશીનની જરૂર છે જેમાં આપણે આ માટે બધું ગોઠવવાની જરૂર છે, જ્યારે આપણી પાસે પહેલેથી જ કુબરનેટ્સ ક્લસ્ટર છે જેમાં આપણે કન્ટેનર ચલાવી શકીએ?).
4. સમાંતર એસેમ્બલી, જે જુદી જુદી રીતે સમજી શકાય છે: ડોકરફાઈલમાંથી અલગ-અલગ આદેશો (જો મલ્ટી-સ્ટેજનો ઉપયોગ કરવામાં આવે છે), એક જ રીપોઝીટરીના અનેક કમિટ, ઘણી ડોકરફાઈલ.
5. વિતરિત એસેમ્બલી: અમે શીંગોમાં વસ્તુઓ એકત્રિત કરવા માંગીએ છીએ જે "ક્ષણિક" છે કારણ કે તેમની કેશ અદૃશ્ય થઈ જાય છે, જેનો અર્થ છે કે તેને ક્યાંક અલગથી સંગ્રહિત કરવાની જરૂર છે.
6. અંતે, મેં ઇચ્છાઓના પરાકાષ્ઠાને નામ આપ્યું સ્વચાલિત: રીપોઝીટરીમાં જઈને અમુક આદેશ લખો અને કેવી રીતે અને શું યોગ્ય રીતે કરવું તેની સમજ સાથે એસેમ્બલ કરેલી તૈયાર ઈમેજ મેળવવી યોગ્ય રહેશે. જો કે, મને વ્યક્તિગત રીતે ખાતરી નથી કે બધી ઘોંઘાટ આ રીતે જોઈ શકાય છે.

અને અહીં પ્રોજેક્ટ્સ છે:

• મોબી/બિલ્ડકિટ — ડોકર ઇન્કના બિલ્ડર (પહેલેથી જ ડોકરના વર્તમાન સંસ્કરણોમાં સંકલિત), જે આ બધી સમસ્યાઓ હલ કરવાનો પ્રયાસ કરી રહ્યો છે;
• કનિકો - Google તરફથી બિલ્ડર કે જે તમને ડોકર વિના બિલ્ડ કરવાની મંજૂરી આપે છે;
• Buildpacks.io - સીએનસીએફનો સ્વયંસંચાલિત જાદુ બનાવવાનો પ્રયાસ અને ખાસ કરીને, સ્તરો માટે રિબેઝ સાથે એક રસપ્રદ ઉકેલ;
• અને અન્ય ઉપયોગિતાઓનો સમૂહ, જેમ કે બિલ્ડહ, genuinetools/img...

...અને જુઓ GitHub પર તેમની પાસે કેટલા સ્ટાર છે. એટલે કે, એક તરફ, docker build અસ્તિત્વમાં છે અને કંઈક કરી શકે છે, પરંતુ વાસ્તવમાં સમસ્યા સંપૂર્ણપણે ઉકેલાઈ નથી - આનો પુરાવો વૈકલ્પિક કલેક્ટર્સનો સમાંતર વિકાસ છે, જેમાંથી દરેક સમસ્યાઓના કેટલાક ભાગને હલ કરે છે.

werf માં એસેમ્બલી

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

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

રજિસ્ટ્રીમાં પ્રકાશનનો તબક્કો (પ્રકાશિત કરો)

અમે ડાયલ કર્યું docker push... - રજિસ્ટ્રીમાં છબી અપલોડ કરવામાં શું મુશ્કેલ હોઈ શકે? અને પછી પ્રશ્ન ઊભો થાય છે: "મારે છબી પર કયો ટેગ મૂકવો જોઈએ?" તે આપણી પાસે છે તે કારણોસર ઉદ્ભવે છે ગિટફ્લો (અથવા અન્ય ગિટ વ્યૂહરચના) અને કુબરનેટ્સ, અને ઉદ્યોગ એ સુનિશ્ચિત કરવાનો પ્રયાસ કરી રહ્યો છે કે કુબરનેટ્સમાં જે થાય છે તે ગિટમાં જે થાય છે તેને અનુસરે છે. છેવટે, ગિટ એ આપણું સત્યનો એકમાત્ર સ્ત્રોત છે.

આમાં શું મુશ્કેલ છે? પ્રજનનક્ષમતા સુનિશ્ચિત કરો: Git માં પ્રતિબદ્ધતામાંથી, જે પ્રકૃતિમાં અપરિવર્તનશીલ છે (અપરિવર્તનશીલ), એક ડોકર ઈમેજ માટે, જે સમાન રાખવી જોઈએ.

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

ટૅગિંગ વ્યૂહરચનાઓ

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

આ અભિગમ સાથે સમસ્યા એ છે કે અમે પ્રથમ ટેગ મૂક્યો, અને તે પછી જ તેનું પરીક્ષણ અને રોલઆઉટ કર્યું. શા માટે? સૌપ્રથમ, તે ફક્ત અતાર્કિક છે: અમે સૉફ્ટવેરનું એક સંસ્કરણ જારી કરી રહ્યા છીએ જેનું અમે હજી પરીક્ષણ પણ કર્યું નથી (અમે અન્યથા કરી શકતા નથી, કારણ કે તપાસ કરવા માટે, અમારે ટેગ મૂકવાની જરૂર છે). બીજું, આ પાથ Gitflow સાથે સુસંગત નથી.

બીજો વિકલ્પ છે git કમિટ + ટેગ. મુખ્ય શાખામાં ટેગ છે 1.0; તેના માટે રજિસ્ટ્રીમાં - ઉત્પાદનમાં જમાવવામાં આવેલી એક છબી. વધુમાં, કુબરનેટ્સ ક્લસ્ટરમાં પૂર્વાવલોકન અને સ્ટેજીંગ રૂપરેખા છે. આગળ આપણે ગિટફ્લોને અનુસરીએ છીએ: વિકાસ માટેની મુખ્ય શાખામાં (develop) અમે નવી સુવિધાઓ બનાવીએ છીએ, પરિણામે ઓળખકર્તા સાથે કમિટ થાય છે #c1. અમે તેને એકત્રિત કરીએ છીએ અને આ ઓળખકર્તાનો ઉપયોગ કરીને તેને રજિસ્ટ્રીમાં પ્રકાશિત કરીએ છીએ (#c1). સમાન ઓળખકર્તા સાથે અમે પૂર્વાવલોકન માટે રોલ આઉટ કરીએ છીએ. અમે કમિટ સાથે પણ આવું જ કરીએ છીએ #c2 и #c3.

જ્યારે અમને સમજાયું કે ત્યાં પૂરતી સુવિધાઓ છે, અમે બધું સ્થિર કરવાનું શરૂ કરીએ છીએ. Git માં એક શાખા બનાવો release_1.1 (આધાર પર #c3 થી develop). આ પ્રકાશન એકત્રિત કરવાની કોઈ જરૂર નથી, કારણ કે... આ પાછલા પગલામાં કરવામાં આવ્યું હતું. તેથી, અમે તેને સ્ટેજીંગમાં સરળતાથી રોલ આઉટ કરી શકીએ છીએ. અમે ભૂલોને ઠીક કરીએ છીએ #c4 અને એ જ રીતે સ્ટેજીંગ માટે રોલ આઉટ કરો. તે જ સમયે, વિકાસ ચાલુ છે develop, જ્યાંથી સમયાંતરે ફેરફારો લેવામાં આવે છે release_1.1. અમુક સમયે, અમે એક કમિટ કમ્પાઈલ અને સ્ટેજીંગ પર અપલોડ કરીએ છીએ, જેનાથી અમે ખુશ છીએ (#c25).

પછી અમે પ્રકાશન શાખાને (ફાસ્ટ-ફોરવર્ડ સાથે) મર્જ કરીએ છીએ (release_1.1) માસ્ટર માં. અમે આ પ્રતિબદ્ધતા પર નવા સંસ્કરણ સાથે ટેગ મૂકીએ છીએ (1.1). પરંતુ આ છબી પહેલેથી જ રજિસ્ટ્રીમાં એકત્રિત કરવામાં આવી છે, તેથી તેને ફરીથી એકત્રિત ન કરવા માટે, અમે હાલની છબી પર બીજું ટેગ ઉમેરીએ છીએ (હવે તે રજિસ્ટ્રીમાં ટૅગ ધરાવે છે. #c25 и 1.1). તે પછી, અમે તેને ઉત્પાદન માટે રોલઆઉટ કરીએ છીએ.

ત્યાં એક ખામી છે કે સ્ટેજિંગ પર માત્ર એક જ છબી અપલોડ કરવામાં આવી છે (#c25), અને ઉત્પાદનમાં તે અલગ પ્રકારનું છે (1.1), પરંતુ આપણે જાણીએ છીએ કે "શારીરિક રીતે" આ રજિસ્ટ્રીમાંથી સમાન છબી છે.

વાસ્તવિક ગેરલાભ એ છે કે મર્જ કમિટ માટે કોઈ સપોર્ટ નથી, તમારે ફાસ્ટ-ફોરવર્ડ કરવું પડશે.

આપણે આગળ જઈને એક યુક્તિ કરી શકીએ છીએ... ચાલો એક સરળ ડોકરફાઈલનું ઉદાહરણ જોઈએ:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

ચાલો તેમાંથી નીચેના સિદ્ધાંત મુજબ ફાઇલ બનાવીએ:

• વપરાયેલ છબીઓના ઓળખકર્તાઓમાંથી SHA256 (ruby:2.3 и nginx:alpine), જે તેમની સામગ્રીના ચેકસમ છે;
• બધી ટીમો (RUN, CMD અને તેથી વધુ.);
• SHA256 ફાઇલોમાંથી જે ઉમેરવામાં આવી હતી.

... અને આવી ફાઇલમાંથી ચેકસમ (ફરીથી SHA256) લો. આ સહી બધું જે ડોકર ઈમેજની સામગ્રીને વ્યાખ્યાયિત કરે છે.

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

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

ગેરલાભ એ છે કે હવે તે નિર્ધારિત કરવું શક્ય નથી કે કયા પ્રકારની પ્રતિબદ્ધતાને ઉત્પાદન માટે દબાણ કરવામાં આવ્યું હતું - ચેકસમ ફક્ત એક દિશામાં કાર્ય કરે છે. આ સમસ્યાને મેટાડેટા સાથે વધારાના સ્તર દ્વારા ઉકેલવામાં આવે છે - હું તમને પછીથી વધુ કહીશ.

werf માં ટેગીંગ

werf માં અમે હજી પણ આગળ ગયા અને એક મશીન પર સંગ્રહિત ન હોય તેવા કેશ સાથે વિતરિત બિલ્ડ કરવાની તૈયારી કરી રહ્યા છીએ... તેથી, અમે બે પ્રકારની ડોકર છબીઓ બનાવી રહ્યા છીએ, અમે તેમને કૉલ કરીએ છીએ મંચ и છબી.

werf Git રિપોઝીટરી બિલ્ડ-વિશિષ્ટ સૂચનાઓ સ્ટોર કરે છે જે બિલ્ડના વિવિધ તબક્કાઓનું વર્ણન કરે છે (ઇન્સ્ટોલ કરતા પહેલા, ઇન્સ્ટોલ કરો, સેટઅપ પહેલાં, સ્થાપના). અમે પ્રથમ તબક્કાની છબીને પ્રથમ પગલાના ચેકસમ તરીકે વ્યાખ્યાયિત હસ્તાક્ષર સાથે એકત્રિત કરીએ છીએ. પછી અમે સ્રોત કોડ ઉમેરીએ છીએ, નવી સ્ટેજ ઇમેજ માટે અમે તેના ચેકસમની ગણતરી કરીએ છીએ... આ ઑપરેશન્સ તમામ તબક્કાઓ માટે પુનરાવર્તિત થાય છે, જેના પરિણામે અમને સ્ટેજની છબીઓનો સમૂહ મળે છે. પછી અમે અંતિમ છબી બનાવીએ છીએ, જેમાં તેના મૂળ વિશે મેટાડેટા પણ છે. અને અમે આ છબીને અલગ અલગ રીતે ટેગ કરીએ છીએ (વિગતો પછીથી).

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

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

રજિસ્ટ્રીની સફાઈ

અમે એવા સ્તરોને કાઢી નાખવા વિશે વાત કરી રહ્યા નથી જે કાઢી નાખેલા ટૅગ્સ પછી અટકી ગયા હતા - આ ડોકર રજિસ્ટ્રીનું પ્રમાણભૂત લક્ષણ છે. અમે એવી પરિસ્થિતિ વિશે વાત કરી રહ્યા છીએ જ્યારે ઘણા બધા ડોકર ટૅગ્સ એકઠા થાય છે અને અમે સમજીએ છીએ કે અમને હવે તેમાંથી કેટલાકની જરૂર નથી, પરંતુ તેઓ જગ્યા લે છે (અને/અથવા અમે તેના માટે ચૂકવણી કરીએ છીએ).

સફાઈ વ્યૂહરચના શું છે?

1. તમે માત્ર કંઈ કરી શકતા નથી સાફ કરશો નહીં. કેટલીકવાર ટૅગ્સની વિશાળ ગૂંચને ઉકેલવા કરતાં વધારાની જગ્યા માટે થોડી ચૂકવણી કરવી ખરેખર સરળ છે. પરંતુ આ માત્ર એક ચોક્કસ બિંદુ સુધી કામ કરે છે.
2. સંપૂર્ણ રીસેટ. જો તમે બધી છબીઓ કાઢી નાખો છો અને CI સિસ્ટમમાં ફક્ત વર્તમાન છબીઓને ફરીથી બનાવો છો, તો સમસ્યા ઊભી થઈ શકે છે. જો કન્ટેનર ઉત્પાદનમાં પુનઃપ્રારંભ થાય છે, તો તેના માટે એક નવી છબી લોડ કરવામાં આવશે - એક કે જે હજુ સુધી કોઈએ પરીક્ષણ કર્યું નથી. આ અપરિવર્તનશીલ ઇન્ફ્રાસ્ટ્રક્ચરના વિચારને મારી નાખે છે.
3. વાદળી, લીલી. એક રજિસ્ટ્રી ઓવરફ્લો થવા લાગી - અમે બીજી પર છબીઓ અપલોડ કરીએ છીએ. અગાઉની પદ્ધતિની જેમ જ સમસ્યા: તમે કયા સમયે રજિસ્ટ્રીને સાફ કરી શકો છો જે ઓવરફ્લો થવાનું શરૂ થયું છે?
4. સમય પ્રમાણે. 1 મહિના કરતાં જૂની બધી છબીઓ કાઢી નાખીએ? પરંતુ ચોક્કસપણે એક એવી સેવા હશે જે એક મહિનાથી અપડેટ ન થઈ હોય...
5. જાતે પહેલાથી શું કાઢી શકાય છે તે નક્કી કરો.

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

આપણે શું કરવા આવ્યા છીએ વર્ફ? અમે એકત્રિત કરીએ છીએ:

1. ગિટ હેડ: બધા ટૅગ્સ, બધી શાખાઓ - ધારીએ છીએ કે અમને છબીઓમાં ગિટમાં ટૅગ કરેલી દરેક વસ્તુની જરૂર છે (અને જો નહીં, તો આપણે તેને ગિટમાં જ કાઢી નાખવાની જરૂર છે);
2. તમામ શીંગો કે જે હાલમાં કુબરનેટ્સમાં પમ્પ કરવામાં આવે છે;
3. જૂની રેપ્લિકાસેટ્સ (જે તાજેતરમાં બહાર પાડવામાં આવ્યું હતું), અને અમે હેલ્મ રીલીઝને સ્કેન કરવાની અને ત્યાં નવીનતમ છબીઓ પસંદ કરવાની પણ યોજના બનાવીએ છીએ.

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

તૈનાત સ્ટેજ

વિશ્વસનીય ઘોષણાત્મકતા

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

1. ઓળખકર્તા;
2. સેવા માહિતી;
3. ઘણા મૂળભૂત મૂલ્યો;
4. વર્તમાન સ્થિતિ સાથે વિભાગ;
5. એડમિશન વેબહૂકના ભાગ રૂપે કરવામાં આવેલ ફેરફારો;
6. વિવિધ નિયંત્રકો (અને શેડ્યૂલર) ના કાર્યનું પરિણામ.

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

આ અભિગમ કહેવામાં આવે છે 2-વે મર્જ. તેનો ઉપયોગ થાય છે, ઉદાહરણ તરીકે, હેલ્મમાં.

ત્યાં પણ છે 3-વે મર્જ, જે તેમાં ભિન્ન છે:

• સરખામણી છેલ્લે લાગુ и નવા, અમે શું કાઢી નાખ્યું હતું તે જોઈએ છીએ;
• સરખામણી નવા и રહેવા, અમે જોઈએ છીએ કે શું ઉમેરવામાં આવ્યું છે અથવા બદલાયું છે;
• સરવાળો પેચ લાગુ પડે છે રહેવા.

અમે હેલ્મ સાથે 1000+ એપ્લિકેશનો જમાવીએ છીએ, તેથી અમે વાસ્તવમાં 2-વે મર્જ સાથે જીવીએ છીએ. જો કે, તેમાં અસંખ્ય સમસ્યાઓ છે જે અમે અમારા પેચ સાથે ઉકેલી છે, જે હેલ્મને સામાન્ય રીતે કામ કરવામાં મદદ કરે છે.

વાસ્તવિક રોલઆઉટ સ્થિતિ

અમારી CI સિસ્ટમ આગલી ઇવેન્ટના આધારે કુબરનેટ્સ માટે નવું રૂપરેખાંકન જનરેટ કરે તે પછી, તે તેને ઉપયોગ માટે ટ્રાન્સમિટ કરે છે (લાગુ કરો) ક્લસ્ટરમાં - હેલ્મનો ઉપયોગ કરીને અથવા kubectl apply. આગળ, પહેલેથી જ વર્ણવેલ N-વે મર્જ થાય છે, જેના માટે કુબરનેટ્સ API CI સિસ્ટમને અને તેના વપરાશકર્તાને મંજૂર રીતે પ્રતિસાદ આપે છે.

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

બધું યોગ્ય રીતે કરવા માટે, આ સ્કીમને વધારાની લિંકની જરૂર છે - એક વિશેષ ટ્રેકર જે કુબરનેટ્સ API પાસેથી સ્થિતિની માહિતી મેળવશે અને વસ્તુઓની વાસ્તવિક સ્થિતિના વધુ વિશ્લેષણ માટે તેને પ્રસારિત કરશે. અમે ગોમાં એક ઓપન સોર્સ લાઇબ્રેરી બનાવી છે - ક્યુબડોગ (તેની જાહેરાત જુઓ અહીં), જે આ સમસ્યાને હલ કરે છે અને werf માં બનેલ છે.

werf સ્તર પર આ ટ્રેકરની વર્તણૂક એનોટેશન્સનો ઉપયોગ કરીને ગોઠવવામાં આવે છે જે ડિપ્લોયમેન્ટ્સ અથવા સ્ટેટફુલસેટ્સ પર મૂકવામાં આવે છે. મુખ્ય ટીકા - fail-mode - નીચેના અર્થો સમજે છે:

• IgnoreAndContinueDeployProcess — અમે આ ઘટકને રોલઆઉટ કરવાની સમસ્યાઓને અવગણીએ છીએ અને જમાવટ ચાલુ રાખીએ છીએ;
• FailWholeDeployProcessImmediately — આ ઘટકમાં ભૂલ જમાવટ પ્રક્રિયાને અટકાવે છે;
• HopeUntilEndOfDeployProcess - અમે આશા રાખીએ છીએ કે આ ઘટક જમાવટના અંત સુધીમાં કામ કરશે.

ઉદાહરણ તરીકે, સંસાધનો અને ટીકા મૂલ્યોનું આ સંયોજન fail-mode:

જ્યારે અમે પ્રથમ વખત જમાવટ કરીએ છીએ, ત્યારે ડેટાબેઝ (MongoDB) હજી તૈયાર ન હોઈ શકે - જમાવટ નિષ્ફળ જશે. પરંતુ તમે તે શરૂ થવાની ક્ષણની રાહ જોઈ શકો છો, અને જમાવટ હજુ પણ થશે.

વર્ફમાં કુબેડોગ માટે વધુ બે ટીકાઓ છે:

• failures-allowed-per-replica - દરેક પ્રતિકૃતિ માટે મંજૂર ફોલ્સની સંખ્યા;
• show-logs-until — તે ક્ષણને નિયંત્રિત કરે છે જ્યાં સુધી werf તમામ રોલઆઉટ પોડ્સમાંથી લોગ (stdout માં) બતાવે છે. મૂળભૂત છે PodIsReady (જ્યારે ટ્રાફિક પોડ પર આવવાનું શરૂ થાય ત્યારે આપણે કદાચ ન જોઈતા હોય તેવા સંદેશાઓને અવગણવા), પરંતુ મૂલ્યો પણ માન્ય છે: ControllerIsReady и EndOfDeploy.

જમાવટમાંથી આપણે બીજું શું જોઈએ છે?

પહેલાથી વર્ણવેલ બે મુદ્દાઓ ઉપરાંત, અમે ઇચ્છીએ છીએ:

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

પરિણામો

એક કંપની તરીકે અમારા માટે, ડિલિવરીના વિવિધ તબક્કા (બિલ્ડ, પ્રકાશિત, જમાવટ) પર વર્ણવેલ તમામ ઘોંઘાટને અમલમાં મૂકવા માટે, એક CI સિસ્ટમ અને ઉપયોગિતા પૂરતી છે. વર્ફ.

નિષ્કર્ષને બદલે:

werf ની મદદથી, અમે DevOps ઇજનેરો માટે મોટી સંખ્યામાં સમસ્યાઓ ઉકેલવામાં સારી પ્રગતિ કરી છે અને જો વ્યાપક સમુદાય ઓછામાં ઓછા આ ઉપયોગિતાને કાર્યમાં અજમાવશે તો અમને આનંદ થશે. એકસાથે સારું પરિણામ પ્રાપ્ત કરવું સરળ બનશે.

વિડિઓઝ અને સ્લાઇડ્સ

પ્રદર્શનમાંથી વિડિઓ (~47 મિનિટ):

અહેવાલની રજૂઆત:

PS

અમારા બ્લોગ પર કુબરનેટ્સ વિશેના અન્ય અહેવાલો:

• «કુબરનેટ્સમાં ઓટોસ્કેલિંગ અને રિસોર્સ મેનેજમેન્ટ» (દિમિત્રી સ્ટોલ્યારોવ; 27 એપ્રિલ, 2019 “સ્ટ્રાઈક” પર);
• «કુબરનેટ્સનું વિસ્તરણ અને પૂરક» (આન્દ્રે પોલોવોવ; 8 એપ્રિલ, 2019 સેન્ટ હાઈલોડ++ પર);
• «ડેટાબેસેસ અને કુબરનેટ્સ» (દિમિત્રી સ્ટોલ્યારોવ; હાઇલોડ++ પર નવેમ્બર 8, 2018);
• «મોનિટરિંગ અને કુબરનેટ્સ» (દિમિત્રી સ્ટોલ્યારોવ; રૂટકોન્ફ ખાતે 28 મે, 2018);
• «કુબરનેટ્સ અને ગિટલેબ સાથે CI/CD શ્રેષ્ઠ વ્યવહારો» (દિમિત્રી સ્ટોલ્યારોવ; હાઇલોડ++ પર નવેમ્બર 7, 2017);
• «નાના પ્રોજેક્ટ્સમાં કુબરનેટ્સ સાથેનો અમારો અનુભવ» (દિમિત્રી સ્ટોલ્યારોવ; રૂટકોન્ફ ખાતે જૂન 6, 2017).

સોર્સ: www.habr.com