નિષ્ફળ રીપબ્લિશ ક્યારેય કામ કરતા બેકએન્ડને ડિલીટ નથી કરતું

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

બેકએન્ડ કેવી રીતે પબ્લિશ થાય છે

જ્યારે તમારી Mythex એપમાં બેકએન્ડ હોય — API અથવા સર્વર, ફક્ત સ્ટેટિક ફાઇલો નહીં — ત્યારે પબ્લિશ તેને Dockerfile (એપને ઇમેજમાં પેક કરવાની રેસિપી) પરથી બનાવે છે અને તે ઇમેજને અમારા હોસ્ટિંગ પ્લેટફોર્મની મશીનો પર રોલ આઉટ કરે છે. પછી હેલ્થ ચેક રાહ જુએ છે કે નવું વર્ઝન ખરેખર શરૂ થાય અને ચાલુ રહે, ત્યારબાદ જ પબ્લિશને લાઇવ ગણવામાં આવે છે.

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

સમસ્યા 1: રોલબેકે જે પાછું મૂકવાનું હતું તે ડિલીટ કર્યું

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

રીપબ્લિશ માટે આ બિલકુલ ખોટું છે. એપ પહેલેથી હતી અને વાસ્તવિક મુલાકાતીઓને સેવા આપી રહી હતી. 25 સપ્ટેમ્બરે, લગભગ અઢી કલાકથી લાઇવ એક એપનો API એક નિષ્ફળ રીપબ્લિશે ડિલીટ કરી નાખ્યો.

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

ફિક્સ: તમે બનાવેલું ડિલીટ કરો, બાકીનું પાછું મૂકો

દરેક પબ્લિશ હવે, તે સ્પર્શેલી દરેક સર્વર એપ માટે, નોંધે છે:

• શું આ પબ્લિશે તેને બનાવી, અને
• જો નહીં, તો કઈ ઇમેજ ચાલતી હતી તે પહેલાં.

નિષ્ફળતા વખતે દરેક એપને ત્રણમાંથી એક રીતે હેન્ડલ કરવામાં આવે છે:

1. આ પબ્લિશે બનાવેલી: પહેલાંની જેમ ડિલીટ કરો.
2. પહેલેથી હતી, અગાઉની ઇમેજ જાણીતી: સમાન કન્ફિગરેશન સાથે અગાઉની ઇમેજ ફરી ડિપ્લોય કરો. કોઈ બિલ્ડ નહીં — ફક્ત ઇમેજ પાછી ખસે છે.
3. પહેલેથી હતી, અગાઉની ઇમેજ અજાણી: એકલી છોડી દો. હાલની એપ ક્યારેય ડિલીટ થતી નથી, ભલે અમે તેને પાછી ન મૂકી શકીએ.

આ નિયમો એક નાનું પ્યોર ફંક્શન છે, જેની પોતાની ટેસ્ટ છે, જેથી નિર્ણય ફરી “બધું ડિલીટ” તરફ સરકે તો ટેસ્ટ નિષ્ફળ જાય.

સમસ્યા 2: પાછું વાળવાનું લખાતા પહેલાં ડિપ્લોય ટૂલ નિષ્ફળ જઈ શકતું

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

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

ફિક્સ: શરૂ કરતા પહેલાં પાછું વાળવાનું નોંધો

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

સમસ્યા 3: સ્લીપ મોડમાં રહેલી એપને “ક્યારેય શરૂ ન થઈ” તરીકે નિષ્ફળ ગણવામાં આવી

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

25 સપ્ટેમ્બરે, તે એક શરૂઆતની વિનંતી ક્યાંય ન પહોંચી. એક હેલ્ધી API પૂરા પાંચ મિનિટના હેલ્થ ચેક દરમિયાન બંધ પડી રહ્યો, અને “1 machine never started (last state: stopped)” સાથે તેને નિષ્ફળ ગણવામાં આવ્યો.

પ્લેટફોર્મ ક્યારેક શરૂઆતને નકારે છે. આ સમસ્યા ફરી બનાવતી વખતે, અમે ઉશ્કેર્યા વિના જ તેણે “lease currently held” કોન્ફ્લિક્ટ પરત કર્યો, અને મશીન અપડેટ થઈ રહી હોય ત્યારે તે શરૂઆતને નકારે છે.

ફિક્સ: સતત પૂછતા રહો, અને દરવાજો ખખડાવો

હેલ્થ ચેક હવે:

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

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

અમે શું શીખ્યા

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

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