പരാജയപ്പെട്ട റീപബ്ലിഷ് പ്രവർത്തിക്കുന്ന ബാക്കെൻഡ് ഒരിക്കലും ഇല്ലാതാക്കുന്നില്ല

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

ഒരു ബാക്കെൻഡ് എങ്ങനെ പബ്ലിഷ് ചെയ്യപ്പെടുന്നു

നിങ്ങളുടെ Mythex ആപ്പിൽ ഒരു ബാക്കെൻഡ് ഉണ്ടെങ്കിൽ — സ്റ്റാറ്റിക് ഫയലുകൾ മാത്രമല്ല, ഒരു API അല്ലെങ്കിൽ സെർവർ — പബ്ലിഷ് ചെയ്യുമ്പോൾ അത് ഒരു Dockerfile-ൽ നിന്ന് (ആപ്പിനെ ഒരു ഇമേജായി പാക്ക് ചെയ്യാനുള്ള ഒരു പാചകക്കുറിപ്പ്) നിർമ്മിക്കപ്പെടുന്നു. തുടർന്ന് ആ ഇമേജ് ഹോസ്റ്റിംഗ് പ്ലാറ്റ്‌ഫോമിലെ മെഷീനുകളിലേക്ക് വിന്യസിക്കപ്പെടുന്നു. പുതിയ പതിപ്പ് യഥാർത്ഥത്തിൽ ഉയർന്ന് സ്ഥിരമായി നിൽക്കുന്നു എന്ന് ഒരു ഹെൽത്ത് ചെക്ക് ഉറപ്പാക്കിയ ശേഷമേ പബ്ലിഷ് തത്സമയമായി അടയാളപ്പെടുത്തുകയുള്ളൂ.

വഴിയിൽ എന്തെങ്കിലും പരാജയപ്പെട്ടാൽ, അത് പഴയപടിയാക്കാൻ ഒരു റോൾബാക്ക് ഓടുന്നു. എല്ലാ കാര്യങ്ങളിലും വെച്ച് ഏറ്റവും പ്രധാനപ്പെട്ടത് ഈ റോൾബാക്ക് ശരിയായി ചെയ്യുക എന്നതാണ്, കാരണം എന്തെങ്കിലും തെറ്റിപ്പോകുമ്പോൾ തന്നെയാണ് അത് ഓടുന്നത്.

പ്രശ്നം 1: റോൾബാക്ക് പുനഃസ്ഥാപിക്കേണ്ടത് ഇല്ലാതാക്കി

ഒരു പബ്ലിഷ് വിന്യസിച്ച സെർവർ ആപ്പുകളുടെ ഒരു പട്ടിക റോൾബാക്ക് സൂക്ഷിച്ചിരുന്നു. പരാജയപ്പെടുമ്പോൾ അതിലെ എല്ലാവയും നശിപ്പിക്കപ്പെട്ടു. ആദ്യ പബ്ലിഷിന് അത് ശരിയായിരുന്നു: ആപ്പ് ഒരു നിമിഷം മുമ്പാണ് സൃഷ്ടിക്കപ്പെട്ടത്, അതിനെ ആശ്രയിക്കുന്ന ഒന്നുമില്ല, അത് ഇല്ലാതാക്കിയാൽ കാര്യങ്ങൾ മുമ്പത്തെപ്പോലെയാകും.

റീപബ്ലിഷിന് അത് കൃത്യമായി തെറ്റായിരുന്നു. ആപ്പ് നേരത്തെ തന്നെ നിലവിലുണ്ടായിരുന്നു, യഥാർത്ഥ സന്ദർശകർക്ക് സേവനം നൽകിക്കൊണ്ടിരുന്നു. സെപ്റ്റംബർ 25-ന്, രണ്ടര മണിക്കൂറായി തത്സമയം ഉണ്ടായിരുന്ന ഒരു ആപ്പിന്റെ API, പരാജയപ്പെട്ട ഒരു റീപബ്ലിഷ് ഇല്ലാതാക്കി.

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

പരിഹാരം: സൃഷ്ടിച്ചത് മാത്രം നശിപ്പിക്കുക, ബാക്കിയുള്ളത് പുനഃസ്ഥാപിക്കുക

ഓരോ പബ്ലിഷും, അത് തൊടുന്ന ഓരോ സെർവർ ആപ്പിനും ഇവ രേഖപ്പെടുത്തുന്നു:

• ഈ പബ്ലിഷ് അത് സൃഷ്ടിച്ചതാണോ, കൂടാതെ
• അല്ലെങ്കിൽ, അതിന് മുമ്പ് ഏത് ഇമേജിലായിരുന്നു അത് ഓടിക്കൊണ്ടിരുന്നത്.

പരാജയപ്പെടുമ്പോൾ, ഓരോ ആപ്പിനും മൂന്നിൽ ഒരു ചികിത്സ ലഭിക്കുന്നു:

1. ഈ പബ്ലിഷ് സൃഷ്ടിച്ചത്: മുമ്പത്തെപ്പോലെ നശിപ്പിക്കുക.
2. നിലവിലുണ്ടായിരുന്നു, മുമ്പത്തെ ഇമേജ് അറിയാം: അതേ കോൺഫിഗറേഷനോടെ മുമ്പത്തെ ഇമേജ് വീണ്ടും വിന്യസിക്കുക. ബിൽഡ് ഇല്ല — ഇമേജ് മാത്രം തിരികെ നീങ്ങുന്നു.
3. നിലവിലുണ്ടായിരുന്നു, മുമ്പത്തെ ഇമേജ് അജ്ഞാതം: അതിനെ തൊടാതെ വിടുക. നിലവിലുള്ള ആപ്പ് ഒരിക്കലും ഇല്ലാതാക്കപ്പെടില്ല, അതിനെ പുനഃസ്ഥാപിക്കാൻ കഴിയാത്തപ്പോഴും.

ഈ നിയമങ്ങൾ സ്വന്തം ടെസ്റ്റുകളോടു കൂടിയ ഒരു ചെറിയ ശുദ്ധ ഫംഗ്ഷനാണ്. അതിനാൽ "എല്ലാം നശിപ്പിക്കുക" എന്ന തീരുമാനത്തിലേക്ക് ഒരിക്കലും തിരികെ പോകാൻ കഴിയില്ല — ടെസ്റ്റ് പരാജയപ്പെടാതെ.

പ്രശ്നം 2: ഡിപ്ലോയ് ടൂളിന് പഴയപടിയാക്കൽ എങ്ങനെയെന്ന് എഴുതിവെക്കുന്നതിന് മുമ്പേ പരാജയപ്പെടാം

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

ടൂൾ വിജയകരമായി തിരിച്ചുവരുമ്പോൾ മാത്രമാണ് ഞങ്ങളുടെ കോഡ് ഒരു ആപ്പിനെ റോൾബാക്ക് പട്ടികയിൽ ചേർത്തിരുന്നത്. ടൂൾ തന്നെ ഡിപ്ലോയ് പരാജയപ്പെടുത്തിയപ്പോൾ, ആപ്പ് ഇതുവരെ പട്ടികയിൽ ഉണ്ടായിരുന്നില്ല, അതിനാൽ ഒന്നും പുനഃസ്ഥാപിക്കപ്പെട്ടില്ല. ഞങ്ങളുടെ സ്റ്റേജിംഗ് പരിസ്ഥിതിയിൽ, തകർന്ന ഒരു റീപബ്ലിഷ് തകർന്ന ഇമേജ് തന്നെ സേവനം നൽകുന്നതായി അവശേഷിപ്പിച്ചു.

പരിഹാരം: തുടങ്ങുന്നതിന് മുമ്പേ പഴയപടിയാക്കൽ രജിസ്റ്റർ ചെയ്യുക

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

പ്രശ്നം 3: ഉറങ്ങിക്കിടന്ന ആപ്പ് "ഒരിക്കലും ആരംഭിച്ചില്ല" എന്ന് പരാജയപ്പെട്ടു

ഉപയോഗത്തിലില്ലാത്തപ്പോൾ ക്രെഡിറ്റ് ലാഭിക്കാൻ Mythex-ലെ പബ്ലിഷ് ചെയ്ത ആപ്പുകൾ ഉറങ്ങുന്നു. റീപബ്ലിഷ് നിർത്തിയിരിക്കുന്ന ഒരു ഉറങ്ങുന്ന മെഷീൻ അവശേഷിപ്പിക്കുന്നു, അതിനാൽ ഹെൽത്ത് ചെക്ക് അതിനെ ഉണർത്തേണ്ടതുണ്ട്. ഒരിക്കൽ മാത്രം മെഷീൻ ആരംഭിക്കാൻ അത് പ്ലാറ്റ്‌ഫോമിനോട് ആവശ്യപ്പെട്ടു, ഉത്തരം അവഗണിച്ചു.

സെപ്റ്റംബർ 25-ന്, ആ ഒറ്റ ആരംഭ അഭ്യർത്ഥന എവിടെയും എത്തിയില്ല. ആരോഗ്യമുള്ള ഒരു API നിശ്ചിത അഞ്ച് മിനിറ്റിലെ ഹെൽത്ത് ചെക്ക് മുഴുവൻ നിർത്തിയ നിലയിൽ കിടന്നു, "1 മെഷീൻ ഒരിക്കലും ആരംഭിച്ചില്ല (അവസാന നില: stopped)" എന്ന് പറഞ്ഞ് പരാജയപ്പെടുത്തപ്പെട്ടു.

പ്ലാറ്റ്‌ഫോം ചിലപ്പോൾ ആരംഭിക്കുന്നത് നിരസിക്കാറുണ്ട്. ഇത് പുനരുത്പാദിപ്പിക്കുമ്പോൾ, ഞങ്ങൾ പ്രേരിപ്പിക്കാതെ തന്നെ അത് "lease currently held" എന്ന തർക്കം മടക്കി നൽകി, ഒരു മെഷീൻ അപ്‌ഡേറ്റ് ചെയ്യപ്പെടുമ്പോൾ അത് ആരംഭങ്ങൾ നിരസിക്കുകയും ചെയ്യുന്നു.

പരിഹാരം: ചോദിച്ചുകൊണ്ടിരിക്കുക, വാതിലിൽ മുട്ടുക

ഹെൽത്ത് ചെക്ക് ഇപ്പോൾ ഇവ ചെയ്യുന്നു:

• കാത്തിരിക്കുമ്പോൾ, നിർത്തിയ ഒരു മെഷീനെ ആരംഭിക്കാൻ ഓരോ 20 സെക്കൻഡിലും വീണ്ടും ചോദിക്കുന്നു,
• പ്ലാറ്റ്‌ഫോം നിരസിക്കുമ്പോൾ അത് മറുപടി എന്തായിരുന്നുവെന്ന് രേഖപ്പെടുത്തുന്നു, കൂടാതെ
• ഒരു സന്ദർശകൻ ചെയ്യുന്നതുപോലെ ആപ്പിലേക്ക് ഒരു സാധാരണ അഭ്യർത്ഥന അയയ്ക്കുന്നു — ഒരു അഭ്യർത്ഥന എത്തുമ്പോൾ പ്ലാറ്റ്‌ഫോമിന്റെ പ്രോക്സി ഉറങ്ങുന്ന മെഷീനെ ഉണർത്തുന്നു.

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

ഞങ്ങൾ പഠിച്ചത്

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

അന്നേ ദിവസം വന്ന അനുബന്ധ പരിഹാരം: പബ്ലിഷ് ചെയ്ത ഉടനെ തകരുന്ന ആപ്പുകളെ പിടികൂടുന്നത്. നിങ്ങളുടെ ഭാഗത്ത് ഒരു പബ്ലിഷ് പരാജയപ്പെടുമ്പോൾ എന്ത് സംഭവിക്കുന്നു എന്നതിന്, ഡോക്സിലെ പബ്ലിഷ് പ്രശ്നപരിഹാരം കാണുക.