Амжилтгүй дахин нийтлэлт ажиллаж буй backend-ийг хэзээ ч устгахгүй

9-р сарын 25-нд амжилтгүй дахин нийтлэлт аппын ажиллаж байсан backend-ийг устгасан. Тэр backend нэлээд хугацаанд, бараг 2.5 цаг, найдвартай ажиллаж байсан. Амжилтгүй нийтлэлтийг буцаадаг код нийтлэлт эхлэхээс өмнөөс аль хэдийн үйлчилж байсан server app-уудыг нь бүгдийг устгасан. Одоо зөвхөн нийтлэлтийн явцад шинээр үүсгэсэн app-уудыг л устгадаг; аль хэдийн байсан app нь нийтлэлтийн өмнөх яг тэр хувилбартаа буцаж тавигддаг. Тэр өдрийн дараагийн хоёр засвар нь буцаалт хостингийн платформын deploy хэрэгсэл бүтэлгүйтэх үед ч ажилладаг болгож, унтсан app-ыг "эхлээгүй" гэж буруугаар бүтэлгүйтүүлдэггүй болгосон.

Backend хэрхэн нийтлэгддэг вэ

Мythex аппад backend байвал (API эсвэл сервер, зөвхөн статик файл биш бол) нийтлэх үед тэрийг Dockerfile-аас (аппыг image болгон багцлах заавар) бүтээж, хостингийн платформын машинууд дээр суулгадаг. Дараа нь эрүүл мэндийн шалгалт шинэ хувилбар бүрэн асаж, тогтвортой ажиллаж байгааг хүлээгээд нийтлэлтийг "идэвхтэй" гэж тэмдэглэдэг.

Аль нэг алхам бүтэлгүйтвэл буцаалт ажиллаж, хийсэн зүйлээ буцаадаг. Буцаалт яг юу буруугаар явж байгаа үед ажилладаг тул нийтлэлтийн бүх зүйлээс хамгийн чухал нь бөгөөд зөв хийх ёстой зүйл юм.

Асуудал 1: буцаалт сэргээх ёстой зүйлээ устгасан

Буцаалт нийтлэлт ямар server app-уудад байрлуулсныг жагсаалтаар хадгалдаг байсан бөгөөд бүтэлгүйтэх үед тэр бүгдийг устгадаг байв. Анхны нийтлэлтийн хувьд энэ зөв: app саяхан үүссэн, юунд ч хамааралгүй тул устгаж хоосон байдалд буцаах нь зөв.

Харин дахин нийтлэлтийн хувьд яг эсрэгээрээ буруу. App аль хэдийн байсан, жинхэнэ зочдод үйлчилж байсан. 9-р сарын 25-нд нэг app-ын хувьд 2.5 цаг ажиллаж байсан API нь амжилтгүй дахин нийтлэлтээр устгагдсан.

Мөн нэг өөр алдаа ижил кодонд байсан. Устгал амжилтгүй болбол эвдэрсэн шинэ image машинууд дээр үлдэж байсан, гэтэл эзэнд нь одоогийн сайт нь ажиллаж байгаа гэж хэлсэн. Эрүүл мэндийн шалгалт бүтэлгүйтэх үед шинэ image аль хэдийн бүх машин дээр суучихсан байдаг. Юу ч хийгээгүй байх нь буцаахтай адил биш.

Засвар: зөвхөн өөрийн үүсгэсэнг устга, бусдыг сэргээ

Одоо нийтлэлт бүр touch хийсэн server app бүрийн хувьд дараахыг бүртгэдэг:

• энэ нийтлэлт үүсгэсэн эсэх, мөн
• үүсээгүй бол нийтлэлтийн өмнө ямар image ажиллаж байсан.

Бүтэлгүйтэхэд app бүр гурван аргын аль нэгээр боловсруулагдана:

1. Энэ нийтлэлт үүсгэсэн: өмнөх шигээ устгана.
2. Аль хэдийн байсан, өмнөх image мэдэгдэж байгаа: тэр image-ийг ижил тохиргоотойгоор дахин тавина. Бүтээлт хийхгүй, зөвхөн image буцна.
3. Аль хэдийн байсан, өмнөх image мэдэгдэхгүй: хөндөхгүй. Одоо байгаа app-ыг сэргээж чадахгүй байсан ч устгахгүй.

Эдгээр дүрмийг жижиг, цэвэр функц болгож, тусдаа тестүүдтэй болгосон тул "бүгдийг устга" гэсэн зан дахин гарч ирвэл тест алдана.

Асуудал 2: deploy хэрэгсэл буцаах аргаа бичихээс өмнө бүтэлгүйтэж болзошгүй байсан

Тэр засварын дараа бид түүний нэг цоорхойг олсон. Хостингийн платформын deploy хэрэгсэл өөрийн smoke шалгалтуудыг хийдэг: шинэ машин унавал алдаа буцаадаг. Гэхдээ энэ нь шинэ image машин дээр суусны дараа болдог.

Манай код app-ыг буцаалтын жагсаалтад зөвхөн deploy хэрэгсэл амжилттай буцаасны дараа бүртгэдэг байв. Хэрэгсэл өөрөө deploy-ийг бүтэлгүйтүүлэхэд app жагсаалтад орж амжаагүй байсан тул юу ч сэргээгдэхгүй байв. Staging орчиндоо эвдэрсэн дахин нийтлэлт эвдэрсэн image-ийг үйлчилсээр байсан.

Засвар: undo-гоо эхлэхээс өмнө бүртгэ

App-ыг бэлтгэж, машин дээр юу ч суулгахаас өмнө буцаалтад бүртгэдэг болсон. Үүсгэсэн эсэх болон аль image ажиллаж байсныг нь хамт бүртгэнэ. Дараа нь юу ч бүтэлгүйтсэн ч буцаалт юу сэргээх ёстойгоо мэддэг. Бид үүнийг орон нутагт баталсан: эвдэрсэн дахин нийтлэлт deploy хэрэгслийн smoke шалгалтанд унасан ба өмнөх хувилбар үйлчилсээр байв.

Асуудал 3: унтсан app-ыг "хэзээ ч эхлээгүй" гэж бүтэлгүйтүүлсэн

Mythex дээрх нийтлэгдсэн app-ууд зайлшгүй хэрэглэгдээгүй үед кредитээ хэмнэхийн тулд унтдаг. Дахин нийтлэлт унтсан машиныг зогсоосон хэвээр орхидог тул эрүүл мэндийн шалгалт түүнийг сэрээх ёстой. Гэтэл энэ нь платформоос машиныг эхлүүлэхийг нэг удаа хүсээд, хариултыг нь үл тоодог байв.

9-р сарын 25-нд тэр нэг эхлүүлэх хүсэлт ямар ч үр дүнгүй болсон. Эрүүл API зогсолтонд байж, эрүүл мэндийн шалгалтын таван минутын бүх хугацаанд "1 машин хэзээ ч эхлээгүй (сүүлийн төлөв: зогссон)" гэж бүтэлгүйтсэн.

Платформ заримдаа эхлүүлэхээс татгалздаг. Энэ асуудлыг давтах үед платформ "lease одоо эзэлсэн байна" гэсэн зөрчил буцааж байсан, мөн машин шинэчлэгдэж байх үед эхлүүлэхээс татгалздаг.

Засвар: дахин асуу, хаалга тогш

Эрүүл мэндийн шалгалт одоо:

• хүлээх явцдаа зогссон машиныг эхлүүлэхийг 20 секунд тутам дахин асуудаг,
• платформ татгалзахад юу гэж хариулснаа бүртгэдэг, мөн
• аппд нэг энгийн хүсэлт илгээдэг, яг зочин шиг. Платформын proxy унтсан машиныг хүсэлт ирэхэд сэрээдэг.

Бид энэ асуудлыг жинхэнэ платформ дээр, эхний эхлүүлэлтээ татгалзсан туршилтын app-аар дахин гаргаж үзсэн. Засвараас өмнө нийтлэлт 91 секундын дараа бүтэлгүйтэж байсан. Засварын дараа 20 секундэд амжилттай нийтлэгдсэн. Жинхэнэ байдлаар эхлэх үедээ бүтэлгүйтдэг app одоо ч бүтэлгүйтэх ёстой хэвээр байна.

Бидний сурсан зүйл

• Буцаалт шинэ ба аль хэдийн байсныг ялгах ёстой. Өөрийн үүсгэсэн зүйлийн "буцаах" нь устгах; аль хэдийн байсан зүйлийнх нь "буцаах" нь сэргээх. Хоёрыг адилхан авч үзэх нь аюулгүй байдлын механизм ажиллаж байгаа app-ыг устгах болдог.
• Юунд хүрэхээсээ өмнө буцаах аргаа бичиж тэмдэглэ. Буцаах заавар зөвхөн алхам амжилттай болсны дараа бүртгэгдвэл, дунд нь бүтэлгүйтсэн алхам буцаах юу ч үлдээдэггүй.
• Найдаж буй хүсэлтийнхээ хариултыг хэзээ ч бүү алга болго. Нэг үл тоосон "үгүй" эрүүл app-ыг бүтэлгүйтсэн нийтлэлт болгосон.

Тэр өдрийн холбоотой нэг засвар: нийтлэлтийн дараа шууд унадаг app-уудыг илрүүлэх. Нийтлэлт таны талд бүтэлгүйтэх үед юу болдгийн талаар нийтлэлтийн алдааг шийдэх гарын авлагыг docs-оос үзнэ үү.