نن زه پلان لرم چې د غوښتنلیکونو لیکلو څرنګوالي په اړه وغږیږم او ستاسو د غوښتنلیک اړتیاوې څه دي ترڅو په کوبرنیټس کې ښه کار وکړي. نو د دې لپاره چې د غوښتنلیک سره هیڅ سر درد شتون ونلري، نو تاسو اړتیا نلرئ د هغې په شاوخوا کې کوم "کریچ" ایجاد او جوړ کړئ - او هرڅه هغه ډول کار کوي لکه څنګه چې کوبرنیټس پخپله اراده لري.
دا لیکچر د "" تاسو کولی شئ د ماښام ښوونځي خلاص نظریاتي لیکچرونه وګورئ . د هغو کسانو لپاره چې د ویډیو پرځای متن غوره کوي، موږ دا مقاله چمتو کړې.
زما نوم پاول سیلیوانوف دی، دا مهال زه په Mail.ru کلاوډ حلونو کې د DevOps مخکښ انجنیر یم، موږ بادل جوړوو، موږ مدیریت کوبرنیټس جوړوو او داسې نور. زما په دندو کې اوس په پراختیا کې مرسته شامله ده، د دې بادلونو راوباسي، د غوښتنلیکونو راوباسي چې موږ یې لیکو او په مستقیم ډول د هغه وسیلو پراختیا چې موږ د خپلو کاروونکو لپاره چمتو کوو.
زه DevOps کوم ، زه فکر کوم د تیرو ، شاید ، دریو کلونو لپاره. مګر، په اصل کې، زه هغه څه کوم چې DevOps د شاوخوا پنځو کلونو لپاره کوي. مخکې له دې، زه ډیری د اداري توکو کې ښکیل وم. ما ډیر وخت دمخه د کبرنیټس سره کار پیل کړ - شاید شاوخوا څلور کاله تیر شوي وي کله چې ما ورسره کار پیل کړ.
په عموم کې، ما هغه وخت پیل کړ کله چې Kubernetes 1.3 نسخه وه، شاید، او شاید 1.2 - کله چې دا لاهم په ماشومتوب کې و. اوس دا نور په ماشومتوب کې نه دی - او دا څرګنده ده چې په بازار کې د انجینرانو لپاره خورا پراخه غوښتنه شتون لري څوک چې غواړي د کوبرنیټس کولو وړ وي. او شرکتونه د داسې خلکو لپاره خورا لوړه غوښتنه لري. له همدې امله، په حقیقت کې، دا لیک څرګند شو.
که موږ د هغه پلان له مخې خبرې وکړو چې زه به یې په اړه خبرې وکړم، دا داسې ښکاري، په بریکٹ کې دا لیکل شوي (TL؛ DR) - "ډیر اوږد؛ مه لولي". زما نن ورځ پریزنټشن به نه ختمیدونکي لیستونه ولري.
په حقیقت کې ، زه پخپله دا ډول پریزنټشنونه نه خوښوم کله چې دوی رامینځته کیږي ، مګر دا داسې موضوع ده چې کله ما دا پریزنټشن چمتو کاوه ، ما په ساده ډول نه پوهیده چې دا معلومات څنګه په مختلف ډول تنظیم کړم.
ځکه چې، په لویه کچه، دا معلومات "ctrl+c, ctrl+v" دي، د نورو شیانو په منځ کې، زموږ ویکي د DevOps برخه کې، چیرته چې موږ د پراختیا کونکو لپاره اړتیاوې لیکلي دي: "هلکانو، نو موږ ستاسو غوښتنلیک په کې پیل کوو. Kubernetes، دا باید داسې وي."
له همدې امله پریزنټشن دومره لوی لیست شو. اوبخښه. زه به هڅه وکړم څومره چې امکان ولري ووایم ترڅو دا د امکان په صورت کې ستړي نه وي.
هغه څه چې موږ یې اوس ګورو:
- دا دي، لومړی، لاګونه (د غوښتنلیک لاګ؟)، په کبرنیټس کې د دوی سره څه وکړي، د دوی سره څه وکړي، دوی باید څه وي؛
- په Kubernetes کې د ترتیباتو سره څه وکړي، د Kubernetes لپاره د غوښتنلیک تنظیم کولو غوره او بدې لارې کومې دي؛
- راځئ چې په دې اړه وغږیږو چې د لاسرسي چیکونه په عمومي ډول څه دي، دوی باید څه ډول ښکاري؛
- راځئ چې په دې اړه وغږیږو چې ښکلی بند څه شی دی؛
- راځئ چې د سرچینو په اړه بیا خبرې وکړو؛
- راځئ چې یو ځل بیا د معلوماتو ذخیره کولو موضوع ته ورسوو؛
- او په پای کې به زه تاسو ته ووایم چې د دې پراسرار بادل اصلي غوښتنلیک اصطلاح څه ده. Cloudnativeness، د دې اصطلاح د صفت په توګه.
لوګو
زه د لاګونو سره پیل کولو وړاندیز کوم - چیرې چې دا لاګونه باید په کوبرنیټس کې وغورځول شي. اوس تاسو په Kubernetes کې یو اپلیکیشن پیل کړی دی. د کلاسیکونو په وینا، پخوا غوښتنلیکونه تل په فایل کې یو ځای لاګونه لیکل. خراب غوښتنلیکونه د پراختیا کونکي کور لارښود کې فایل ته لاګونه لیکلي چې غوښتنلیک یې پیل کړی. ښه غوښتنلیکونه په کوم ځای کې فایل ته لاګونه لیکلي /var/log.
په همدې اساس، ښه مدیرانو په خپلو زیربناوو کې ځینې شیان ترتیب کړي وو چې دا لاګونه یې گردش کولی شي - ورته rsyslog، کوم چې دا لاګونه ګوري او کله چې دوی ته یو څه پیښیږي، ډیری یې شتون لري، دا بیک اپ کاپي جوړوي، لاګونه هلته اچوي. ، زاړه فایلونه حذف کوي ، له یوې اونۍ څخه ډیر ، شپږ میاشتې او ځینې نور وخت. په تیوري کې، موږ باید شرایط ولرو ترڅو په ساده ډول د دې لپاره چې غوښتنلیک لاګونه لیکي، د تولید سرورونو (جګړی سرورونو؟) ځای پای ته نه رسیږي. او، په وینا، ټول تولید د لوګو له امله ودرېد.
کله چې موږ د کوبرنیټس نړۍ ته لاړ شو او هلته ورته شی چلوو، لومړی شی چې تاسو یې پام کولی شئ هغه حقیقت دی چې خلک، لکه څنګه چې دوی په فایل کې لاګونه لیکلي، دوی لیکلو ته دوام ورکوي.
دا معلومه شوه چې که موږ د کوبرنیټس په اړه وغږیږو ، د ډاکر کانټینر څخه چیرې د لاګونو لیکلو لپاره سم ځای په ساده ډول دا دی چې دوی د غوښتنلیک څخه تش په نامه Stdout/Stderr ته ولیکي ، دا د عامل سیسټم معیاري محصول جریان ، معیاري تېروتنه محصول دا په ډاکر او په ځانګړي ډول په کبرنیټس کې د اصولو سره د لاګونو ایښودلو ترټولو سمه ، ساده او خورا منطقي لاره ده. ځکه چې که ستاسو غوښتنلیک Stdout/Stderr ته لاګونه لیکي، نو دا د Docker او Kubernetes Add-on پورې اړه لري ترڅو پریکړه وکړي چې د دې لاګونو سره څه وکړي. ډاکر به په ډیفالټ ډول خپل ځانګړي فایلونه د JSON ب formatه کې رامینځته کړي.
دلته پوښتنه راپورته کیږي چې تاسو به د دې لاګونو سره څه وکړئ؟ اسانه لار روښانه ده، موږ یې وړتیا لرو kubectl logs او د دې "پوډونو" دې لاګونو ته وګورئ. مګر، شاید، دا خورا ښه انتخاب نه دی - بل څه باید د لاګونو سره ترسره شي.
د اوس لپاره ، راځئ چې په ورته وخت کې وغږیږو ، ځکه چې موږ د لاګ موضوع ته لاس اچولی ، د داسې شی په اړه چې لاګ باید ورته ښکاري. دا په مستقیم ډول په کبرنیټس باندې نه پلي کیږي ، مګر کله چې موږ د لاګونو سره د څه کولو په اړه فکر پیل کړو ، نو ښه به وي چې پدې اړه هم فکر وکړو.
موږ یو ډول وسیلې ته اړتیا لرو ، په دوستانه ډول ، دا به دا لاګونه واخلي چې زموږ ډاکر په خپلو فایلونو کې ځای په ځای کوي او چیرې یې لیږو. په لویه کچه، موږ معمولا د ډیمون سیټ په بڼه د کوبرنیټس دننه یو ډول اجنټ په لاره اچوو - د لاګ راټولونکی، کوم چې په ساده ډول ویل کیږي چې هغه لاګونه چیرې دي چې ډاکر راټولوي. او دا راټولونکی اجنټ په ساده ډول دوی اخلي ، شاید حتی په یو ډول یې د لارې په اوږدو کې تجزیه کړي ، شاید دوی د ځینې اضافي میټا معلوماتو سره بډایه کړي او په نهایت کې یې د ذخیره کولو لپاره کوم ځای ته واستوي. تغیرات لا دمخه شتون لري. ترټولو عام شاید Elasticsearch دی، چیرې چې تاسو کولی شئ لاګونه ذخیره کړئ او تاسو کولی شئ په اسانۍ سره له هغه ځای څخه ترلاسه کړئ. بیا، د غوښتنې په کارولو سره، د کبانا کارول، د بیلګې په توګه، د دوی پر بنسټ ګرافونه جوړ کړئ، د دوی پر بنسټ خبرتیاوې جوړې کړئ، او داسې نور.
ترټولو مهم نظر ، زه غواړم دا یوځل بیا تکرار کړم ، دا دی چې د ډاکر دننه ، په ځانګړي توګه د کوبرنیټس دننه ، په فایل کې ستاسو د لاګونو ذخیره کول خورا خراب نظر دی.
ځکه چې لومړی ، په فایل کې د کانټینر دننه لاګونه ترلاسه کول ستونزمن دي. تاسو باید لومړی کانټینر ته لاړ شئ، هلته یې اجرا کړئ، او بیا لوګو ته وګورئ. بل ټکی دا دی چې که تاسو په فایل کې لاګونه لرئ، نو کانټینرونه معمولا لږترلږه چاپیریال لري او داسې اسانتیاوې شتون نلري چې معمولا د لاګونو سره د عادي کار لپاره اړین وي. دوی ښخ کړئ ، دوی ته وګورئ ، په متن ایډیټر کې یې خلاص کړئ. بله شیبه هغه وخت دی چې موږ په کانټینر کې دننه په فایل کې لاګونه لرو، که دا کانټینر حذف شي، تاسو پوهیږئ، لاګونه به ورسره مړه شي. په دې اساس، د کانټینر هر ډول بیا پیل کول پدې معنی دي چې نور لاګونه شتون نلري. یو ځل بیا، بد انتخاب.
او وروستی ټکی دا دی چې د کانټینرونو دننه تاسو معمولا خپل غوښتنلیک لرئ او دا دی - دا معمولا یوازینۍ پروسه ده. د هرې پروسې په اړه هیڅ خبرې نشته چې ستاسو د لاګونو سره فایلونه وګرځوي. هرڅومره ژر چې لاګونه فایل ته لیکل کیږي ، پدې معنی چې ، بخښنه غواړم ، موږ به د تولید سرور له لاسه ورکول پیل کړو. ځکه، لومړی، د دوی موندل ستونزمن دي، هیڅوک یې نه تعقیبوي، او هیڅوک یې کنټرول نه کوي - په وینا، فایل په پای کې وده کوي تر هغه چې په سرور کې ځای په ساده ډول پای ته ورسیږي. له همدې امله ، زه بیا وایم چې په ډاکر کې ننوتل ، په ځانګړي توګه په کبرنیټس کې ، فایل ته یو بد نظر دی.
بل ټکی، دلته زه غواړم په دې اړه یو ځل بیا خبرې وکړم - ځکه چې موږ د لوګو په موضوع خبرې کوو، نو دا به ښه وي چې په دې اړه وغږیږو چې لاګونه باید څنګه ښکاري ترڅو د دوی سره کار کول اسانه کړي. لکه څنګه چې ما وویل، موضوع په مستقیم ډول د Kubernetes سره تړاو نلري، مګر دا د DevOps موضوع سره خورا ښه تړاو لري. د دې دوه مختلف څانګو - دیو او اوپس تر مینځ د پراختیا کلتور او ملګرتیا موضوع باندې ، ترڅو هرڅوک راحته وي.
دا پدې مانا ده چې په مثالي توګه، نن ورځ، لاګونه باید د JSON بڼه کې ولیکل شي. که تاسو خپل یو څه د پوهیدو وړ اپلیکیشن لرئ، کوم چې د نه پوهیدو وړ فارمیټونو کې لاګونه لیکي ځکه چې تاسو یو ډول چاپ یا داسې یو څه داخل کړئ، نو دا وخت دی چې یو ډول چوکاټ ګوګل کړئ، یو ډول ریپر چې تاسو ته اجازه درکوي نورمال لاګنګ پلي کړئ؛ هلته په JSON کې د ننوتلو پیرامیټونه فعال کړئ، ځکه چې JSON یو ساده بڼه ده، د دې تحلیل کول ساده دي.
که ستاسو JSON د ځینو معیارونو سره سم کار نه کوي، هیڅوک نه پوهیږي څه، بیا لږترلږه په داسې بڼه کې لاګونه ولیکئ چې تحلیل کیدی شي. دلته، بلکه، دا د دې حقیقت په اړه فکر کولو ارزښت لري چې، د بیلګې په توګه، که تاسو د کانټینرونو یوه ډله پرمخ وړئ یا یوازې د نګینکس سره پروسس کوئ، او هر یو خپل د ننوتلو ترتیبات لري، نو داسې ښکاري چې دا به ستاسو لپاره خورا ستونزمن وي. هغوی تجزیه کړئ. ځکه چې د هر نوي نګینکس مثال لپاره تاسو اړتیا لرئ خپل پارسر ولیکئ ، ځکه چې دوی لاګونه په مختلف ډول لیکي. یوځل بیا ، دا شاید د دې ډاډ ترلاسه کولو په اړه فکر کولو ارزښت ولري چې دا ټولې نګینکس مثالونه ورته د ننوتلو ترتیب لري ، او د دوی ټول لاګونه یې په بشپړ ډول یوشان لیکلي. ورته په بشپړ ډول ټولو غوښتنلیکونو باندې تطبیق کیږي.
په پاى کې، زه غواړم اور ته د سونګ توکي اضافه کړم چې په مثالي توګه، د څو لاين فارمټ لاګونو څخه بايد ډډه وشي. دلته خبره ده، که تاسو کله هم د لاګ راټولونکو سره کار کړی وي، نو ډیری احتمال تاسو لیدلي وي چې دوی تاسو سره څه ژمنه کوي، چې دوی کولی شي د څو لاین لاګونو سره کار وکړي، پوهیږي چې څنګه یې راټول کړي، او داسې نور. په حقیقت کې ، زما په نظر ، نن ورځ یو واحد راټولونکی نشي کولی په نورمال ډول ، په بشپړ ډول او پرته له غلطیو څو لاین لاګونه راټول کړي. په انساني طریقه، ترڅو دا اسانه او له خطا پاک وي.
مګر د سټیک ټریس تل څو لاین لاګونه دي او څنګه یې مخنیوی وشي. دلته پوښتنه دا ده چې log د پیښې ریکارډ دی، او stactrace په حقیقت کې لاګ نه دی. که موږ لاګونه راټول کړو او په Elasticsearch کې یې ځای په ځای کړو او بیا یې له دوی څخه ګرافونه راوباسئ، ستاسو په سایټ کې د کاروونکي فعالیت ځینې راپورونه جوړ کړئ، نو کله چې تاسو د سټیک ټریس ترلاسه کوئ، نو دا پدې مانا ده چې یو څه ناڅاپي پیښیږي، ستاسو په غوښتنلیک کې یو ناڅاپه وضعیت. او دا معنی لري چې په اتوماتيک ډول یو سیسټم ته د سټیک ټریس اپلوډ کړئ چې کولی شي دوی تعقیب کړي.
دا سافټویر دی (ورته سینټری) چې په ځانګړې توګه د سټیک ټریس سره کار کولو لپاره جوړ شوی. دا کولی شي سمدلاسه اتوماتیک دندې رامینځته کړي ، یو چا ته یې وټاکي ، خبرتیا ورکړي کله چې سټیټ ټریسونه پیښ شي ، دا سټیټټریسونه د یو ډول لخوا ګروپ کړئ ، او داسې نور. په اصولو کې، دا د سټیټریس په اړه خبرې کول ډیر معنی نلري کله چې موږ د لاګونو په اړه وغږیږو، ځکه چې دا په هرصورت، د مختلفو موخو سره مختلف شیان دي.
شکل بندي
بیا موږ په کوبرنیټس کې د تنظیم کولو په اړه وغږیږو: د دې سره څه وکړي او څنګه د کوبرنیټس دننه غوښتنلیکونه باید تنظیم شي. په عموم کې، زه معمولا وایم چې ډاکر د کانټینرونو په اړه ندي. هرڅوک پوهیږي چې ډاکر د کانټینرونو په اړه دی، حتی هغه څوک چې د ډاکر سره ډیر کار نه دی کړی. زه تکراروم ، ډاکر د کانټینرونو په اړه ندي.
ډاکر، زما په نظر، د معیارونو په اړه دی. او په عملي توګه د هرڅه لپاره معیارونه شتون لري: ستاسو د غوښتنلیک جوړولو لپاره معیارونه، ستاسو د غوښتنلیک نصبولو معیارونه.
او دا شی - موږ دا دمخه کارولی و ، دا یوازې د کانټینرونو په راتګ سره په ځانګړي ډول مشهور شو - دې شی ته د ENV (چاپیریال) متغیرونه ویل کیږي ، دا د چاپیریال متغیرونه چې ستاسو په عملیاتي سیسټم کې دي. دا عموما ستاسو د غوښتنلیک تنظیم کولو لپاره یوه غوره لاره ده، ځکه که تاسو په JAVA، Python، Go، Perl کې غوښتنلیکونه لرئ، خدای منع کوي، او دوی ټول کولی شي د ډیټابیس کوربه، ډیټابیس کاروونکي، د ډیټابیس پاسورډ تغیرات ولولي، نو دا غوره ده. تاسو په څلورو مختلفو ژبو کې غوښتنلیکونه لرئ چې په ډیټابیس پلان کې ورته ترتیب شوي. نور مختلف تشکیلات شتون نلري.
هرڅه د ENV متغیرونو په کارولو سره تنظیم کیدی شي. کله چې موږ د Kubernetes په اړه وغږیږو، د ځای په ځای کولو کې دننه د ENV متغیر اعلانولو لپاره یوه ښه لار شتون لري. په دې اساس، که موږ د پټو معلوماتو په اړه وغږیږو، نو موږ کولی شو په سمدستي توګه د ENV متغیرونو (ډېټابیسونو ته پاسورډونه، او نور) څخه پټ معلومات پټ کړو، یو پټ کلستر جوړ کړو او په ځای پرځای کولو کې د ENV توضیحاتو کې اشاره وکړو چې موږ مستقیم نه اعلان کوو. د دې متغیر ارزښت، او د دې ډیټابیس پاسورډ متغیر ارزښت به له راز څخه لوستل شي. دا معیاري Kubernetes چلند دی. او دا ستاسو د غوښتنلیکونو تنظیم کولو لپاره ترټولو غوره اختیار دی. یوازې د کوډ په کچه، بیا دا په پراختیا کونکو باندې تطبیق کیږي. که تاسو DevOps یاست، تاسو کولی شئ پوښتنه وکړئ: "ملګرو، مهرباني وکړئ خپل غوښتنلیک د چاپیریال متغیرونو لوستلو ته درس ورکړئ. او موږ ټول به خوشحاله یو."
که په شرکت کې هرڅوک ورته نومول شوي چاپیریال متغیرونه ولولي ، نو دا خورا ښه دی. نو داسې نه کیږي چې ځینې د پوسټ ګریس ډیټابیس ته انتظار باسي ، نور د ډیټابیس نوم ته انتظار باسي ، نور د یو څه لپاره انتظار باسي ، نور د یو ډول dbn په تمه دي ، نو په دې اساس ، یوشانوالی شتون لري.
ستونزه هغه وخت راځي کله چې تاسو ډیری چاپیریال متغیرونه لرئ چې تاسو یوازې ځای پرځای کول خلاص کړئ - او د چاپیریال متغیرونو پنځه سوه لینونه شتون لري. په دې حالت کې، تاسو په ساده ډول د چاپیریال تغیرات لرئ - او تاسو نور اړتیا نلرئ خپل ځان شکنجه کړئ. پدې حالت کې ، دا به معنی ولري چې د تشکیلاتو کارول پیل کړئ. دا دی ، خپل غوښتنلیک د تشکیلاتو کارولو لپاره وروزل.
یوازینۍ پوښتنه دا ده چې تشکیلات هغه څه ندي چې تاسو یې فکر کوئ. Config.pi یو ترتیب ندی چې کارول یې اسانه وي. یا ستاسو په خپل ب formatه کې ځینې تشکیلات ، په بدیل ډول ډالۍ - دا هم هغه تشکیل ندی چې زما مطلب دی.
د هغه څه په اړه چې زه یې په اړه خبرې کوم د منلو وړ فارمیټونو کې ترتیب دی، دا دی چې تر ټولو مشهور معیار د .yaml معیار دی. دا روښانه ده چې دا څنګه لوستل کیږي، دا د انسان د لوستلو وړ دی، دا روښانه ده چې دا څنګه د غوښتنلیک څخه لوستل کیږي.
په دې اساس، د YAML سربیره، تاسو هم کولی شئ، د بیلګې په توګه، JSON وکاروئ، پارس کول د هغه ځای څخه د غوښتنلیک ترتیباتو لوستلو شرایطو کې د YAML په څیر اسانه دي. دا د خلکو لوستلو لپاره د پام وړ ډیر تکلیف دی. تاسو کولی شئ د دې بڼه هڅه وکړئ. دا د انسان له نظره لوستل خورا اسانه دي ، مګر دا په اتوماتيک ډول پروسس کول ناشونی کیدی شي ، پدې معنی چې که تاسو کله هم غواړئ خپل تشکیلات رامینځته کړئ ، د ini بڼه ممکن دمخه رامینځته کولو کې ناامنه وي.
مګر په هر حالت کې، هر هغه بڼه چې تاسو یې غوره کوئ، نقطه دا ده چې د Kubernetes له نظره دا خورا مناسب دی. تاسو کولی شئ خپل ټول تشکیلات په کوبرنیټس کې دننه کړئ ، په ConfigMap کې. او بیا دا ترتیب نقشه واخلئ او وغواړئ چې دا ستاسو په پوډ کې په یو ځانګړي ډایرکټر کې نصب شي، چیرې چې ستاسو غوښتنلیک به د دې ترتیب نقشه څخه تشکیلات ولوستل شي لکه څنګه چې دا یوازې یو فایل وي. دا، په حقیقت کې، هغه څه دي چې ترسره کول یې ښه دي کله چې تاسو په خپل غوښتنلیک کې د ترتیب کولو ډیری اختیارونه لرئ. یا دا یوازې یو ډول پیچلی جوړښت دی، ځړول شتون لري.
که تاسو د ترتیب نقشه لرئ، نو تاسو کولی شئ خپل غوښتنلیک خورا ښه زده کړئ، د بیلګې په توګه، په اتوماتيک ډول په فایل کې بدلونونه تعقیب کړئ چیرې چې configmap نصب شوی وي، او همدارنګه ستاسو غوښتنلیک په اتوماتيک ډول بیا پورته کړئ کله چې تشکیلات بدل شي. دا به عموما یو غوره انتخاب وي.
یوځل بیا ، ما دمخه پدې اړه خبرې وکړې - پټ معلومات په ترتیب کې ندي ، پټ معلومات په متغیرونو کې ندي ، پټ معلومات په رازونو کې ندي. له هغه ځایه، دا پټ معلومات د ډیپلوماسۍ سره وصل کړئ. معمولا موږ په ګیټ کې د Kubernetes شیانو ټول توضیحات ، ځای پرځای کول ، ترتیب نقشه ، خدمات ذخیره کوو. په دې اساس، په ګیټ کې ډیټابیس ته د پټنوم ایښودل، حتی که دا ستاسو ګیټ وي، کوم چې تاسو په شرکت کې دننه لرئ، یو بد نظر دی. ځکه چې ، لږترلږه ، git هرڅه په یاد ساتي او په ساده ډول له هغه ځایه د پاسورډونو لرې کول دومره اسانه ندي.
د روغتیا معاینه
بل ټکی دا شی دی چې د روغتیا معاینه بلل کیږي. په عموم کې، د روغتیا معاینه په ساده ډول چک کول دي چې ستاسو غوښتنلیک کار کوي. په ورته وخت کې ، موږ ډیری وختونه د ځینې ویب غوښتنلیکونو په اړه خبرې کوو ، د کوم لپاره چې د روغتیا معاینې له نظره (دا غوره ده چې دلته وژباړئ او نور) دا به یو څه ځانګړي URL وي ، کوم چې دوی پروسس کوي. معیاري، دوی معمولا کوي /health.
کله چې دې URL ته لاسرسی ومومئ، په دې اساس، زموږ غوښتنلیک وايي "هو، سمه ده، زما سره هرڅه سم دي، 200" یا "نه، هر څه زما سره سم ندي، ځینې 500." په دې اساس، که زموږ غوښتنلیک http نه وي، ویب اپلیکیشن نه وي، موږ اوس د یو ډول ډیمون په اړه خبرې کوو، موږ کولی شو معلومه کړو چې څنګه روغتیایی معاینات ترسره کړو. دا اړینه نده ، که غوښتنلیک http نه وي ، نو هرڅه د روغتیایی معاینې پرته کار کوي او دا په هیڅ ډول نشي ترسره کیدی. تاسو کولی شئ په وخت سره په فایل کې ځینې معلومات تازه کړئ، تاسو کولی شئ د خپل ډیمون لپاره ځینې ځانګړي کمانډ سره راشي، لکه، daemon status، کوم چې به ووایی "هو ، هرڅه سم دي ، ډیمون کار کوي ، دا ژوندی دی."
دا د څه لپاره دی؟ لومړی او خورا څرګند شی شاید دا وي چې ولې روغتیایی معایناتو ته اړتیا ده - ترڅو پوه شي چې غوښتنلیک کار کوي. زما مطلب دی، دا یوازې احمق دی، کله چې دا اوس پورته شي، داسې ښکاري چې دا کار کوي، نو تاسو ډاډه یاست چې دا کار کوي. او دا معلومه شوه چې اپلیکیشن روان دی، کانټینر روان دی، مثال کار کوي، هرڅه سم دي - او بیا کاروونکو لا دمخه د تخنیکي مالتړ څخه د تلیفون ټولې شمیرې قطع کړي او وايي "تاسو څه یاست ...، تاسو؟ ویده شوم، هیڅ کار نه کوي.»
د روغتیا معاینه یوازې داسې یوه لاره ده چې د کارونکي له نظره وګورئ چې دا کار کوي. یو له میتودونو څخه. راځئ چې دا په دې ډول واچوو. د کوبرنیټس له نظره ، دا د پوهیدو یوه لاره هم ده کله چې غوښتنلیک پیل کیږي ، ځکه چې موږ پوهیږو چې کله کانټینر پیل شوی ، رامینځته شوی او پیل شوی ، او کله چې غوښتنلیک مستقیم په دې کانټینر کې پیل شوی و توپیر شتون لري. ځکه چې که موږ یو څه اوسط جاوا اپلیکیشن واخلو او په ډاک کې یې د پیلولو هڅه وکړو، نو د څلویښت ثانیو، یا حتی یوې دقیقې، یا حتی لسو لپاره، دا یوازې ښه پیل کیدی شي. په دې حالت کې، تاسو کولی شئ لږترلږه د هغې په بندرونو کې ټک وکړئ، دا به هلته ځواب ورنکړي، دا دی، دا لاهم د ټرافیک ترلاسه کولو لپاره چمتو نه دی.
یوځل بیا ، د صحي معاینې په مرسته او د دې حقیقت په مرسته چې موږ دلته راګرځو ، موږ کولی شو په کوبرنیټس پوه شو چې نه یوازې په غوښتنلیک کې کانټینر راپورته شوی ، بلکه غوښتنلیک پخپله پیل شوی ، دا دمخه ځواب ورکوي. د روغتیا معاینه، پدې معنی چې موږ کولی شو هلته ټرافيک ولیږو.
هغه څه چې زه یې اوس په اړه خبرې کوم د کوبرنیټس دننه د چمتووالي/ژوندۍ ازموینې په نوم یادیږي؛ په دې اساس، زموږ د چمتووالي ازموینې په توازن کې د غوښتنلیک شتون لپاره مسؤل دي. دا دی ، که چیرې په غوښتنلیک کې د چمتووالي ازموینې ترسره شي ، نو هرڅه سم دي ، د پیرودونکي ترافیک غوښتنلیک ته ځي. که د چمتووالي ازموینې ترسره نه شي ، نو غوښتنلیک په ساده ډول برخه نه اخلي ، دا ځانګړی مثال په توازن کې برخه نه اخلي ، دا له توازن څخه لرې کیږي ، د پیرودونکي ترافیک نه تیریږي. په دې اساس، په کبرنیټس کې د ژوندانه ازموینې ته اړتیا ده نو که چیرې غوښتنلیک ودریږي نو بیا پیل شي. که چیرې د ژوندیتوب ازموینه د هغه غوښتنلیک لپاره کار ونکړي چې په کوبرنیټس کې اعلان شوی وي ، نو بیا غوښتنلیک یوازې له توازن څخه نه لرې کیږي ، دا بیا پیل کیږي.
او دلته یو مهم ټکی دی چې زه یې غواړم یادونه وکړم: د عملي نظر څخه، د چمتووالي ازموینه معمولا ډیر ځله کارول کیږي او د ژوندانه ازموینې په پرتله ډیر ځله اړین دی. دا دی، په ساده ډول بې فکره د چمتووالي او ژوندۍ ازموینې دواړه اعلان کول، ځکه چې کوبرنیټس کولی شي دا وکړي، او راځئ چې هرڅه وکاروو چې دا یې کولی شي، خورا ښه نظر نه دی. زه به تشریح کړم چې ولې. ځکه چې په ازموینه کې دوهم ټکی دا دی چې دا به ښه نظر وي چې ستاسو په روغتیایی معایناتو کې اصلي خدمت چیک کړئ. دا پدې مانا ده چې که تاسو یو ویب اپلیکیشن لرئ چې ځینې معلومات وړاندې کوي، کوم چې په پایله کې، په طبیعي توګه، باید له کوم ځای څخه واخلي. په ډیټابیس کې، د بیلګې په توګه. ښه ، دا هغه معلومات خوندي کوي چې پدې REST API کې ورته ډیټابیس کې راځي. بیا، په دې اساس، که ستاسو روغتیا چک په ساده ډول د تماس شوي سلیش روغتیا په څیر ځواب ورکړي، غوښتنلیک وايي "200، سمه ده، هرڅه سم دي" او په ورته وخت کې ستاسو د غوښتنلیک ډیټابیس د لاسرسي وړ نه دی، او د روغتیا چک غوښتنلیک وايي "200، سمه ده، هرڅه سم دي. "- دا یو خراب روغتیایی معاینه ده. دا داسې نه ده چې دا څنګه کار وکړي.
دا ستاسو غوښتنلیک دی، کله چې غوښتنه ورته راځي /health، دا یوازې ځواب نه ورکوي، "200، ښه"، دا لومړی د مثال په توګه ډیټابیس ته ځي، هڅه کوي له هغې سره وصل شي، هلته یو څه خورا بنسټیز کار کوي، لکه یو غوره کړئ، یوازې وګورئ چې په ډیټابیس کې اړیکه شتون لري. ډیټابیس او تاسو کولی شئ ډیټابیس پوښتنه وکړئ. که دا ټول بریالي وو، نو ځواب دی "200، ښه." که دا بریالی نه وي، دا وايي چې یوه تېروتنه ده، ډیټابیس شتون نلري.
له همدې امله، په دې اړه، زه یو ځل بیا د چمتووالي/ژوندۍ ازموینې ته راګرځم - ولې تاسو ډیری احتمال د چمتووالي ازموینې ته اړتیا لرئ، مګر د ژوندانه ازموینه تر پوښتنې لاندې ده. ځکه که تاسو د روغتیا معاینات په سمه توګه تشریح کړئ لکه څنګه چې ما وویل، نو دا به معلومه شي چې دا د مثال په برخه کې شتون نلريв или со всех instanceپه ډیټابیس کې، د بیلګې په توګه. کله چې تاسو د چمتووالي ازموینه اعلان کړه ، زموږ روغتیایی معاینات ناکامیدل پیل کړل ، او په دې اساس ټول هغه غوښتنلیکونه چې ډیټابیس ته د لاسرسي وړ ندي ، دوی په ساده ډول له توازن څخه بند شوي او په حقیقت کې یوازې په غفلت شوي حالت کې "ځړول" او د دوی ډیټابیس ته انتظار باسي. کار
که موږ د ژوندانه ازموینه اعلان کړه، نو تصور وکړئ، زموږ ډیټابیس مات شوی، او ستاسو په کوبرنیټس کې نیمایي هرڅه بیا پیل کیږي ځکه چې د ژوند ازموینه ناکامه شوه. دا پدې مانا ده چې تاسو اړتیا لرئ بیا پیل کړئ. دا هغه څه ندي چې تاسو یې غواړئ، ما حتی په عمل کې شخصي تجربه درلوده. موږ د چیٹ غوښتنلیک درلود چې په JS کې لیکل شوی و او د مونګو ډیټابیس ته ورکړل شوی و. او ستونزه دا وه چې دا د کبرنیټس سره زما د کار په پیل کې و ، موږ د ازموینې چمتووالي ، ژوندیتوب په اصولو کې بیان کړ چې کوبرنیټس کولی شي دا ترسره کړي ، نو موږ به یې وکاروو. په دې اساس، په یو وخت کې مونګو یو څه "خراب" شو او نمونه ناکامه شوه. په دې اساس، د باران ازموینې سره سم، پوزې د "وژنې" پیل وکړ.
لکه څنګه چې تاسو پوهیږئ، کله چې دوی "وژل شوي" وي، دا یو چیٹ دی، دا د پیرودونکو څخه ډیری اړیکې شتون لري چې پدې کې ځړول کیږي. دوی هم "وژل شوي" دي - نه، پیرودونکي نه، یوازې اړیکې - ټول په ورته وخت کې ندي، او د دې حقیقت له امله چې دوی په ورته وخت کې نه وژل کیږي، ځینې مخکې، ځینې وروسته، دوی په ورته وخت کې نه پیل کیږي. وخت پلس معیاري تصادفي، موږ نشو کولی هر ځل د غوښتنلیک د پیل وخت د ملیسیکنډ دقت سره وړاندوینه وکړو، نو دوی دا په یو وخت کې یو ځل ترسره کوي. یو انفاسپاټ راپورته کیږي ، توازن ته اضافه کیږي ، ټول پیرودونکي هلته راځي ، دا نشي کولی دومره بار سره مقاومت وکړي ، ځکه چې دا یوازې دی ، او په لنډه توګه ، په لسګونو یې هلته کار کوي ، او ښکته کیږي. بل پورته کیږي، ټول بار د هغه په غاړه دی، هغه هم ښکته کیږي. ښه، دا زوالونه یوازې cascade ته دوام ورکوي. په نهایت کې ، دا څنګه حل شو - موږ باید دې اپلیکیشن ته د کارونکي ترافیک په کلکه ودروو ، پریږدو چې ټولې پیښې راپورته شي او بیا په یوځل کې ټول کارونکي ترافیک پیل کړي ترڅو دا دمخه په ټولو لسو مواردو کې ویشل شوي وي.
که دا د دې ژوندۍ ازموینې اعلان شوی نه و ، کوم چې دا به ټول بیا پیل کولو ته اړ کړي ، نو غوښتنلیک به یې ښه اداره کړي. مګر د توازن څخه هرڅه زموږ لپاره معیوب دي ، ځکه چې ډیټابیسونه د لاسرسي وړ ندي او ټول کارونکي "لیدلي" دي. بیا ، کله چې دا ډیټابیس شتون ولري ، هرڅه په توازن کې شامل دي ، مګر غوښتنلیکونه بیا پیل کولو ته اړتیا نلري ، او پدې کې د وخت او سرچینو ضایع کولو ته اړتیا نشته. دوی ټول لا دمخه دلته دي ، دوی د ترافیک لپاره چمتو دي ، نو ترافیک خلاصیږي ، هرڅه سم دي - غوښتنلیک په ځای دی ، هرڅه کار ته دوام ورکوي.
له همدې امله، د چمتووالي او ژوند کولو ازموینې مختلف دي، حتی د دې سربیره، تاسو کولی شئ په تیوریکي ډول مختلف روغتیایی معاینات ترسره کړئ، یو ډول ریډی، یو ډول ژوند، د بیلګې په توګه، او مختلف شیان چیک کړئ. د چمتووالي ازموینې په جریان کې ، خپل شاتنۍ معاینه وکړئ. او د ژوندانه ازموینې کې، د بیلګې په توګه، تاسو د دې نظر څخه نه ګورئ چې د ژوندانه ازموینه عموما یوازې یو غوښتنلیک دی چې ځواب ووایي، که دا د ځواب ورکولو توان ولري.
ځکه چې د ژوندانه ازموینه، په لویه کچه، هغه وخت دی چې موږ "بند" یو. یو نه ختمیدونکی لوپ پیل شوی یا بل څه - او نور غوښتنې نه پروسس کیږي. له همدې امله، دا معنی لري چې حتی دوی جلا کړئ - او په دوی کې مختلف منطق پلي کړئ.
د هغه څه په اړه چې تاسو اړتیا لرئ ځواب ورکړئ کله چې تاسو ازموینه لرئ ، کله چې تاسو روغتیایی معاینات کوئ. دا یوازې واقعیا درد دی. هغه څوک چې له دې سره اشنا دي شاید وخاندي - مګر په جدي توګه، ما په خپل ژوند کې داسې خدمتونه لیدلي چې په 200٪ قضیو کې "XNUMX" ځوابوي. يعنې څوک بريالی دی. مګر په ورته وخت کې د غبرګون په بدن کې دوی "داسې او داسې تېروتنه" لیکي.
دا دی، د غبرګون حالت تاسو ته راځي - هرڅه بریالي دي. مګر په ورته وخت کې، تاسو باید بدن تجزیه کړئ، ځکه چې بدن وايي "بخښنه، غوښتنه د تېروتنې سره پای ته ورسیده" او دا یوازې واقعیت دی. ما دا په ریښتیني ژوند کې ولیدل.
او د دې لپاره چې ځینې خلک دا مسخره نه کړي، او نور یې خورا دردناک وي، دا لاهم د ساده قواعدو پیروي کولو ارزښت لري. په روغتیایی چکونو کې، او په اصولو کې کله چې د ویب غوښتنلیکونو سره کار کوي.
که هر څه سم شول، نو دوه سوه ځواب ورکړئ. په اصولو کې، هر دوه سوه ځواب به تاسو ته مناسب وي. که تاسو ریګسي ډیر ښه لوستلئ او پوهیږئ چې د ځواب ځینې حالتونه له نورو څخه توپیر لري، د مناسبو سره ځواب ورکړئ: 204، 5، 10، 15، هر څه. که دا خورا ښه نه وي، نو یوازې "دوه صفر صفر." که هر څه خراب شي او صحي معاینه ځواب نه ورکوي، نو په هر پنځه سوه سره ځواب ورکړئ. بیا بیا، که تاسو پوهیږئ چې څنګه ځواب ووایاست، څنګه د مختلف غبرګون حالتونه د یو بل څخه توپیر لري. که تاسو نه پوهیږئ، نو 502 ستاسو اختیار دی چې روغتیایی چکونو ته ځواب ووایی که چیرې یو څه غلط شي.
دا یو بل ټکی دی، زه غواړم د اصلي خدماتو چک کولو په اړه لږ څه بیرته راګرځم. که تاسو پیل کړئ، د بیلګې په توګه، ټول هغه بنسټیز خدمتونه وګورئ چې ستاسو د غوښتنلیک تر شا ولاړ دي - په عمومي توګه هرڅه. هغه څه چې موږ د مایکرو سرویس معمارۍ له لید څخه ترلاسه کوو ، موږ د "ټیټ جوړه" په څیر داسې مفهوم لرو - دا هغه وخت دی چې ستاسو خدمات لږترلږه په یو بل پورې تړلي وي. که یو له دوی څخه ناکام شي، د دې فعالیت پرته نور ټول به په ساده ډول کار ته دوام ورکړي. ځینې فعالیتونه یوازې کار نه کوي. په دې اساس، که تاسو ټول روغتیایی معاینات یو بل سره وتړئ، نو تاسو به په زیربنا کې د یو شی د راټیټیدو سره پای ته ورسیږئ، او ځکه چې دا راوتلی، د ټولو خدماتو ټول روغتیایی معاینات هم په ناکامۍ پیل کوي - او په عمومي توګه د دې لپاره ډیر زیربنا شتون لري. د ټول مایکرو سرویس جوړښت نمبر. هلته هر څه تیاره شول.
له همدې امله ، زه غواړم دا یوځل بیا تکرار کړم چې تاسو اړتیا لرئ لاندې خدمات چیک کړئ ، هغه پرته لدې چې ستاسو غوښتنلیک په سل په سلو کې قضیه نشي کولی خپل دنده ترسره کړي. دا منطقي ده چې که تاسو یو REST API ولرئ چې له لارې کاروونکي ډیټابیس ته خوندي کوي یا له ډیټابیس څخه بیرته ترلاسه کوي ، نو د ډیټابیس په نشتوالي کې ، تاسو نشئ کولی د خپلو کاروونکو سره کار تضمین کړئ.
مګر که ستاسو کاروونکي، کله چې تاسو یې له ډیټابیس څخه وباسئ، د یو بل بیک انډ څخه د یو بل میټاډاټا سره بډایه شوي، کوم چې تاسو د فرنټ انډ ته د ځواب لیږلو دمخه داخل کړئ - او دا بیکینډ شتون نلري، پدې معنی چې تاسو خپل د میټاډاټا کومې برخې پرته ځواب ورکړئ.
بل، موږ یو له دردناک مسلو څخه هم لرو کله چې غوښتنلیکونه پیل کړو.
په حقیقت کې ، دا یوازې په لوی او لوی کبرنیټس باندې نه پلي کیږي؛ دا یوازې داسې پیښ شوي چې د یو ډول ډله ایز پرمختګ کلتور او په ځانګړي توګه د ډی او اوپس په ورته وخت کې د کوبرنیټس په څیر خپریدل پیل شوي. له همدې امله، په لویه کچه، دا معلومه شوه چې تاسو اړتیا لرئ چې د کوبرنیټس پرته خپل غوښتنلیک په ښه توګه وتړئ. حتی د کبرنیټس څخه دمخه ، خلکو دا کار کړی و ، مګر د کبرنیټس په راتګ سره موږ په ډله ایزه توګه د هغې په اړه خبرې پیل کړې.
په زړه پوری تړل
په عموم کې، د زړه پورې تړل څه شی دی او ولې ورته اړتیا ده؟ دا هغه وخت دی کله چې ستاسو غوښتنلیک د کوم دلیل لپاره خراب شي، تاسو باید ترسره کړئ app stop - یا تاسو د مثال په توګه د عملیاتي سیسټم څخه سیګنال ترلاسه کوئ، ستاسو غوښتنلیک باید پدې پوه شي او د هغې په اړه یو څه وکړي. ترټولو بد حالت سناریو، البته، کله چې ستاسو غوښتنلیک SIGTERM ترلاسه کوي او د "SIGTERM، راځئ چې ودریږو، کار وکړو، هیڅ کار ونه کړو." دا یو ښه بد انتخاب دی.
نږدې مساوي بد انتخاب هغه وخت دی کله چې ستاسو غوښتنلیک SIGTERM ترلاسه کوي او داسې وي لکه "دوی وویل segterm، دا پدې مانا ده چې موږ پای ته رسیږو، ما نه دی لیدلی، زه د کوم کاروونکي غوښتنې نه پوهیږم، زه نه پوهیږم کوم ډول هغه غوښتنې چې زه اوس کار کوم، دوی SIGTERM وویل، دا پدې مانا ده چې موږ پای ته رسیدو " دا هم یو بد انتخاب دی.
کوم انتخاب ښه دی؟ لومړی ټکی دا دی چې د عملیاتو بشپړولو ته پام وکړئ. یو ښه اختیار ستاسو د سرور لپاره دی چې لاهم په پام کې ونیسي چې دا څه کوي که چیرې دا SIGTERM ترلاسه کړي.
SIGTERM یو نرم بند دی، دا په ځانګړي ډول ډیزاین شوی، دا د کوډ په کچه کې مداخله کیدی شي، دا پروسس کیدی شي، ووایه چې اوس انتظار وکړئ، موږ به لومړی هغه کار پای ته ورسوو چې موږ یې لرو، بیا به موږ وځو.
د Kubernetes له نظره، دا هغه څه دي چې داسې ښکاري. کله چې موږ یو پوډ ته ووایو چې د کوبرنیټس کلستر کې روان دی، "مهرباني وکړئ ودریږئ، لاړ شئ" یا موږ بیا پیل کوو، یا یو تازه واقع کیږي کله چې کوبرنیټس پوډونه بیا جوړ کړي، کوبرنیټس پوډ ته ورته SIGTERM پیغام لیږي، انتظار کوي. ځینې وخت، او، دا هغه وخت دی چې هغه انتظار کوي، دا هم ترتیب شوی، په ډیپلومونو کې داسې یو ځانګړی پیرامیټر شتون لري او دا د Graceful ShutdownTimeout په نوم یادیږي. لکه څنګه چې تاسو پوهیږئ، دا د هیڅ شی لپاره نه ویل کیږي، او دا د هیڅ شی لپاره ندي چې موږ یې اوس په اړه خبرې کوو.
هلته موږ کولی شو په ځانګړې توګه ووایو چې موږ د غوښتنلیک ته د SIGTERM لیږلو تر مینځ څومره انتظار ته اړتیا لرو او کله چې موږ پوهیږو چې غوښتنلیک داسې ښکاري چې د یو څه لپاره لیونۍ شوی یا "بند شوی" دی او پای ته نه رسیږي - او موږ اړتیا لرو دا SIGKILL واستوئ، یعني په سختۍ سره خپل کار بشپړ کړئ. دا، په دې اساس، موږ یو ډول ډیمون لرو، دا عملیات پروسس کوي. موږ پوهیږو چې په اوسط ډول زموږ عملیات چې ډیمون کار کوي په یو وخت کې له 30 ثانیو څخه ډیر دوام نه کوي. په دې اساس، کله چې SIGTERM راشي، موږ پوهیږو چې زموږ ډیمون کولی شي، لږترلږه، د SIGTERM وروسته 30 ثانیې پای ته ورسوي. موږ دا لیکو، د بیلګې په توګه، یوازې په قضیه کې 45 ثانیې او ووایو چې SIGTERM. له هغې وروسته موږ 45 ثانیې انتظار کوو. په تیوري کې، پدې وخت کې شیطان باید خپل کار بشپړ کړي او خپل ځان پای ته ورسوي. مګر که ناڅاپه دا نشي کولی، دا پدې مانا ده چې دا خورا احتمالي پاتې دی - دا نور زموږ غوښتنې په نورمال ډول نه پروسس کوي. او په 45 ثانیو کې تاسو کولی شئ په خوندي ډول، په حقیقت کې، هغه په نښه کړئ.
او دلته، په حقیقت کې، حتی 2 اړخونه په پام کې نیول کیدی شي. لومړی، پوه شئ چې که تاسو غوښتنه ترلاسه کړې، تاسو په یو ډول کار پیل کړی او کارونکي ته یې ځواب نه دی ورکړی، مګر تاسو د مثال په توګه SIGTERM ترلاسه کړی. دا معنی لري چې دا پاک کړئ او کارونکي ته ځواب ورکړئ. دا په دې برخه کې لومړی ټکی دی. دلته دوهم ټکی دا دی چې که تاسو خپل اپلیکیشن ولیکئ، په عمومي ډول جوړښت په داسې ډول جوړ کړئ چې تاسو د خپل غوښتنلیک لپاره غوښتنه ترلاسه کوئ، بیا تاسو یو څه کار پیل کوئ، د فایلونو ډاونلوډ کول له کوم ځای څخه پیل کړئ، د ډیټابیس ډاونلوډ کړئ، او نور څه. هغه. په عموم کې، ستاسو کاروونکي، ستاسو غوښتنه د نیم ساعت لپاره ځړول کیږي او تاسو ته د هغه ځواب لپاره انتظار کوي - بیا، ډیری احتمال، تاسو اړتیا لرئ چې په جوړښت کې کار وکړئ. دا دی، یوازې حتی عام احساس په پام کې ونیسئ چې که ستاسو عملیات لنډ وي، نو دا د SIGTERM له پامه غورځول او تعدیل کول معنی لري. که ستاسو عملیات اوږد وي، نو پدې حالت کې د SIGTERM څخه سترګې پټول هیڅ معنی نلري. دا د داسې اوږد عملیاتو څخه مخنیوي لپاره د معمارۍ له سره ډیزاین کول معنی لري. نو ځکه چې کاروونکي یوازې شاوخوا ځړول او انتظار نه کوي. زه نه پوهیږم، هلته یو ډول ویب ساکټ جوړ کړئ، ریورس هکونه جوړ کړئ چې ستاسو سرور به دمخه پیرودونکي ته واستوي، بل څه، مګر کاروونکي دې ته مجبور نه کړئ چې د نیم ساعت لپاره ځړول شي او یوازې د ناستې لپاره انتظار وکړئ تر هغه چې تاسو ځواب یې ورکړ. ځکه چې دا د اټکل وړ نه ده چیرې چې مات شي.
کله چې ستاسو غوښتنلیک پای ته ورسیږي، تاسو باید د وتلو مناسب کوډ چمتو کړئ. دا دی ، که ستاسو غوښتنلیک د بندولو ، ودرولو غوښتنه شوې وه ، او دا په نورمال ډول د ځان ودرولو توان درلود ، نو تاسو اړتیا نلرئ یو ډول د وتلو کوډ 1,5,255 او داسې نور بیرته ورکړئ. هر هغه څه چې صفر کوډ نه وي، لږترلږه د لینکس سیسټمونو کې، زه پدې باور یم، ناکام ګڼل کیږي. دا دی، داسې انګیرل کیږي چې پدې قضیه کې ستاسو غوښتنلیک د خطا سره پای ته رسیدلی. په دې اساس، په دوستانه ډول، که ستاسو غوښتنلیک پرته له کومې خطا بشپړ شي، تاسو په محصول کې 0 ووایاست. که ستاسو غوښتنلیک د کوم دلیل لپاره ناکام شي، تاسو په محصول کې غیر 0 ووایاست. او تاسو کولی شئ د دې معلوماتو سره کار وکړئ.
او وروستی اختیار. دا خراب دی کله چې ستاسو کاروونکي غوښتنه واستوي او د نیم ساعت لپاره ځړول پداسې حال کې چې تاسو یې پروسس کوئ. مګر په عموم کې، زه غواړم د هغه څه په اړه هم ووایم چې په عمومي ډول د پیرودونکي اړخ څخه ارزښت لري. دا مهمه نده چې تاسو د ګرځنده غوښتنلیک لرئ، مخکینۍ پای، او نور. دا اړینه ده چې په پام کې ونیول شي چې په عموم کې د کارونکي ناسته لغوه کیدی شي ، هرڅه پیښ کیدی شي. یوه غوښتنه کیدای شي واستول شي، د بیلګې په توګه، کم پروسس شوی او هیڅ ځواب بیرته نه دی راغلی. ستاسو فرنټ اینډ یا ستاسو د ګرځنده اپلیکیشن - په عموم کې کوم فرنټ اینډ ، راځئ چې ورته ورته واوسو - دا باید په پام کې ونیول شي. که تاسو د ویب ساکټونو سره کار کوئ، دا عموما ترټولو بد درد دی چې ما یې درلود.
کله چې د ځینې منظم چیټونو پراختیا کونکي پدې نه پوهیږي ، نو دا وګرځي ، ویب ساکټ مات کیدی شي. د دوی لپاره، کله چې په پراکسي کې یو څه پیښیږي، موږ یوازې ترتیب بدلوو، او دا بیا پورته کوي. په طبیعي توګه، په دې قضیه کې ټول اوږدمهاله ناستې مات شوي. پرمخ وړونکي موږ ته په منډه راځي او وايي: "هلکانو، تاسو څه کوئ، زموږ د ټولو پیرودونکو لپاره چیټ مات شوی!" موږ ورته وایو: "تاسو څه کوئ؟ ایا ستاسو پیرودونکي نشي کولی بیرته وصل شي؟ دوی وايي: "نه، موږ غونډې ته اړتیا لرو چې مات نه شي." په لنډه توګه، دا په حقیقت کې بې مانا ده. د پیرودونکي اړخ باید په پام کې ونیول شي. په ځانګړي توګه ، لکه څنګه چې زه وایم ، د اوږدې مودې ناستې لکه ویب ساکټونو سره ، دا مات کیدی شي او د کارونکي لخوا نه په پام کې نیول شوي ، تاسو اړتیا لرئ د دې ډول غونډو له سره نصبولو وړ اوسئ. او بیا هرڅه سم دي.
سرچینې
په حقیقت کې، زه به تاسو ته یو مستقیم کیسه ووایم. بیا له ریښتیني ژوند څخه. ترټولو ناروغ شی چې ما کله هم د سرچینو په اړه اوریدلی دی.
پدې حالت کې سرچینې، زما مطلب دی، یو ډول غوښتنې، محدودیتونه چې تاسو کولی شئ په خپل کوبرنیټس کلسترونو کې پوډونه واچوئ. ترټولو په زړه پورې شی چې ما د یو پراختیا کونکي څخه اوریدلی ... زما یو ملګري پراختیا کونکي د کار په مخکیني ځای کې یو ځل وویل: "زما غوښتنلیک به په کلستر کې پیل نشي." ما ولیدل چې دا پیل نه و، مګر یا دا په سرچینو کې مناسب نه و، یا دوی خورا کوچني محدودیتونه ټاکلي وو. په لنډه توګه، غوښتنلیک نشي کولی د سرچینو له امله پیل شي. زه وایم: "دا به د سرچینو له امله نه پیل کیږي، تاسو پریکړه کوئ چې څومره اړتیا لرئ او مناسب ارزښت وټاکئ." هغه وايي: "څه ډول سرچینې؟" ما هغه ته تشریح پیل کړه چې کبرنیټس، د غوښتنو محدودیتونه او بله، بله، بله باید ټاکل شي. سړي د پنځو دقیقو لپاره غوږ ونیول، سر یې وخوځاوه او ویې ویل: "زه دلته د پراختیا کونکي په توګه کار کولو لپاره راغلی یم، زه نه غواړم د کومې سرچینې په اړه څه پوه شم. زه دلته د کوډ لیکلو لپاره راغلی یم او بس.» دا غمجن دی. دا د پراختیا کونکي له نظره خورا غمجن مفهوم دی. په ځانګړې توګه په عصري نړۍ کې، نو د پرمختللو عقیدو په اړه.
ولې سرچینې ته اړتیا ده؟ په Kubernetes کې 2 ډوله سرچینې شتون لري. ځینې یې غوښتنې بلل کیږي، نور یې محدودیتونه بلل کیږي. د سرچینو په واسطه موږ به پوه شو چې په بنسټیز ډول تل یوازې دوه بنسټیز محدودیتونه شتون لري. دا دی، د CPU وخت محدودیتونه او د RAM محدودیتونه د کانټینر لپاره چې په Kubernetes کې روان دي.
یو حد یو لوړ حد لري چې ستاسو په غوښتنلیک کې سرچینې څنګه کارول کیدی شي. دا په دې اساس، که تاسو په حدودو کې د 1GB RAM ووایاست، نو ستاسو غوښتنلیک به د 1GB څخه زیات RAM ونه کاروي. او که هغه ناڅاپه وغواړي او هڅه وکړي دا کار وکړي، نو د اووم قاتل په نوم یو پروسه، د حافظې څخه بهر، دا به راشي او ستاسو غوښتنلیک وژني - دا به په ساده ډول بیا پیل شي. غوښتنلیکونه به د CPU پراساس بیا پیل نشي. د CPU په شرایطو کې، که یو اپلیکیشن هڅه وکړي چې د حد څخه زیات، د ټاکل شوي حد څخه ډیر، CPU به په ساده ډول په کلکه وټاکل شي. دا د بیا پیل کیدو لامل نه کیږي. دا حد دی - دا لوړ حد دی.
او یوه غوښتنه ده. یوه غوښتنه دا ده چې Kubernetes څنګه پوهیږي چې څنګه ستاسو د Kubernetes کلستر کې نوډونه د غوښتنلیکونو سره ډک شوي. دا ، غوښتنه ستاسو د غوښتنلیک یو ډول ژمنتیا ده. دا هغه څه وايي چې زه یې کارول غواړم: "زه غواړم تاسو زما لپاره دومره CPU او دومره حافظه خوندي کړئ." داسې ساده مشابهت. څه شی که موږ یو نوډ ولرو چې لري، زه نه پوهیږم، په مجموع کې 8 CPUs. او یو پوډ هلته راځي، چې غوښتنې یې 1 CPU وايي، پدې معنی چې نوډ 7 CPUs پاتې دي. دا ، په دې اساس ، هرڅومره ژر چې 8 پوډونه دې نوډ ته راشي ، چې هر یو یې په خپلو غوښتنو کې 1 CPU لري ، نوډ ، لکه څنګه چې د کوبرنیټس له نظره ، له CPU څخه وتلی او د غوښتنو سره نور پوډونه نشي کیدی. په دې نوډ کې پیل شوی. که چیرې ټول نوډونه د CPU څخه تیر شي ، نو کوبرنیټس به ویل پیل کړي چې ستاسو د پوډونو چلولو لپاره په کلستر کې هیڅ مناسب نوډونه شتون نلري ځکه چې CPU پای ته رسیدلی.
ولې غوښتنې ته اړتیا ده او ولې پرته له غوښتنو، زه فکر کوم چې په کوبرنیټس کې هیڅ شی پیل کولو ته اړتیا نشته؟ راځئ چې یو فرضي حالت تصور کړو. تاسو خپل غوښتنلیک پرته له غوښتنې پیل کړئ، کوبرنیټس نه پوهیږي چې تاسو څومره څه لرئ، کوم نوډونه چې تاسو یې فشارولی شئ. ښه، هغه په نوډونو باندې فشار راوړي، ټوپونه وهي. په یو وخت کې، تاسو به ستاسو غوښتنلیک ته ټرافیک ترلاسه کول پیل کړئ. او یو غوښتنلیک ناڅاپه د سرچینو کارول پیل کوي تر حدونو پورې چې دا د محدودیتونو سره سم لري. دا معلومه شوه چې نږدې یو بل غوښتنلیک شتون لري او سرچینو ته هم اړتیا لري. نوډ په حقیقت کې په فزیکي توګه د سرچینو څخه تیریږي، د بیلګې په توګه، OP. نوډ په حقیقت کې په فزیکي توګه د سرچینو څخه تیریږي، د بیلګې په توګه، د تصادفي لاسرسي حافظه (RAM). کله چې یو نوډ د بریښنا څخه تیریږي ، نو لومړی به ډاکر غبرګون ودروي ، بیا کیوبیلټ ، بیا OS. دوی به په ساده ډول بې هوښه شي او هرڅه به خامخا ستاسو لپاره کار ودروي. دا دی، دا به ستاسو نوډ ودریږي او تاسو به یې بیا پیلولو ته اړتیا ولرئ. په لنډه توګه، وضعیت ډیر ښه نه دی.
او کله چې تاسو غوښتنې لرئ ، حدود خورا توپیر نلري ، لږترلږه د حدونو یا غوښتنو څخه څو ځله ډیر ندي ، نو تاسو کولی شئ د کوبرنیټس کلسترونو نوډونو کې د غوښتنلیکونو داسې نورمال ، معقول ډکول ولرئ. په ورته وخت کې، Kubernetes نږدې پوهیږي چې دا څومره څه چې چیرته یې اچوي، څومره څه چې چیرته کارول کیږي. دا، دا یوازې یوه شیبه ده. دا مهمه ده چې پوه شي. او دا مهمه ده چې کنټرول شي چې دا اشاره شوې.
د معلوماتو ذخیره
زموږ راتلونکی ټکی د معلوماتو ذخیره کولو په اړه دی. د دوی سره څه وکړي او په عموم کې، په کبرنیټس کې د دوام سره څه وکړي؟
زه فکر کوم، یو ځل بیا، زموږ دننه په Kubernetes کې د ډیټابیس په اړه یوه موضوع وه. او ماته داسې ښکاري چې زه حتی پوهیږم چې ستاسو همکارانو تاسو ته څه وویل کله چې وپوښتل شول: "ایا دا ممکنه ده چې په کوبرنیټس کې ډیټابیس چل کړئ؟" د یو دلیل لپاره ، ماته داسې بریښي چې ستاسو همکارانو باید تاسو ته ویلي وي چې که تاسو دا پوښتنه کوئ چې ایا په کوبرنیټس کې د ډیټابیس چلول امکان لري ، نو دا ناممکن دی.
دلته منطق ساده دی. یوازې په دې حالت کې ، زه به یوځل بیا تشریح کړم ، که تاسو واقعیا ښه سړی یاست چې کولی شئ د توزیع شوي شبکې ذخیره کولو کافي غلط - زغمونکی سیسټم رامینځته کړئ ، پدې پوه شئ چې څنګه پدې قضیه کې ډیټابیس فټ کړئ ، په کانټینرونو کې د بادل اصلي ځای باید څنګه کار وکړي. په عمومي توګه په ډیټابیس کې. ډیری احتمال، تاسو د دې د چلولو په اړه هیڅ پوښتنه نلرئ. که تاسو داسې پوښتنه لرئ، او تاسو غواړئ ډاډ ترلاسه کړئ چې دا ټول په تولید کې د مرګ سره سم ودریږي او هیڅکله نه راټیټیږي، نو داسې نه کیږي. تاسو تضمین یاست چې د دې تګلارې سره په پښو کې ځان ډزې وکړئ. له همدې امله، دا غوره نه ده.
موږ باید د هغه ډیټا سره څه وکړو چې زموږ اپلیکیشن یې ذخیره کول غواړي، ځینې عکسونه چې کاروونکي یې اپلوډ کوي، ځینې شیان چې زموږ اپلیکیشن د فعالیت په جریان کې تولیدوي، د مثال په توګه؟ په Kubernetes کې د دوی سره څه وکړي؟
په عموم کې، په مثالي توګه، هو، البته، Kubernetes خورا ښه ډیزاین شوی او په عموم ډول په پیل کې د بې ځایه غوښتنلیکونو لپاره تصور شوی و. دا د هغو غوښتنلیکونو لپاره دی چې هیڅ معلومات نه ذخیره کوي. دا مثالی دی.
مګر، البته، مثالی اختیار تل شتون نلري. نو څه؟ لومړی او ساده ټکی دا دی چې یو ډول S3 واخلئ، نه یوازې د کور جوړ شوی، کوم چې دا هم روښانه نده چې دا څنګه کار کوي، مګر د ځینې چمتو کونکي څخه. یو ښه، نورمال چمتو کونکی - او د S3 کارولو لپاره خپل غوښتنلیک درس ورکړئ. دا دی، کله چې ستاسو کاروونکي غواړي یو فایل اپلوډ کړي، ووایه "دلته، مهرباني وکړئ، دا S3 ته پورته کړئ." کله چې هغه غواړي دا ترلاسه کړي، ووایه: "دلته د S3 لپاره یو لینک دی او له دې ځایه یې واخلئ." دا مثالی دی.
که ناڅاپه د کوم دلیل لپاره دا مثالی اختیار مناسب نه وي، تاسو یو غوښتنلیک لرئ چې تاسو یې نه وي لیکلی، تاسو وده نه کوئ، یا دا یو ډول ناوړه میراث دی، دا د S3 پروتوکول نشي کارولی، مګر باید د ځایی لارښودونو سره کار وکړي. محلي فولډرې یو څه لږ یا لږ ساده واخلئ، کوبرنیټس ځای په ځای کړئ. دا دی ، سمدلاسه د ځینې لږترلږه دندو لپاره د سیف باړ کول ، زما په اند دا یو بد نظر دی. ځکه چې Ceph، البته، ښه او فیشن دی. مګر که تاسو واقعیا نه پوهیږئ چې تاسو څه کوئ ، نو یوځل چې تاسو په سیف کې یو څه واچوئ ، نو تاسو کولی شئ په اسانۍ سره او په ساده ډول هیڅکله له هغه څخه بهر نه شئ. ځکه، لکه څنګه چې تاسو پوهیږئ، سیف په خپل کلستر کې په بائنری بڼه کې ډاټا ذخیره کوي، نه د ساده فایلونو په بڼه. له همدې امله ، که ناڅاپه د سیف کلستر مات شي ، نو بشپړ او لوړ احتمال شتون لري چې تاسو به هیڅکله له هغه ځایه خپل معلومات ترلاسه نه کړئ.
موږ به د سیف په اړه یو کورس ولرو، تاسو کولی شئ .
له همدې امله ، دا غوره ده چې یو څه ساده وکړئ لکه د NFS سرور. Kubernetes کولی شي د دوی سره کار وکړي، تاسو کولی شئ د NFS سرور لاندې لارښود نصب کړئ - ستاسو غوښتنلیک یوازې د محلي لارښود په څیر دی. په عین حال کې، په طبیعي توګه، تاسو اړتیا لرئ چې پوه شئ، یو ځل بیا، تاسو اړتیا لرئ چې د خپل NFS سره یو څه وکړئ، تاسو اړتیا لرئ پوه شئ چې ځینې وختونه دا ممکن د لاسرسي وړ نه وي او د دې پوښتنې په اړه فکر وکړئ چې تاسو به پدې قضیه کې څه وکړئ. شاید دا باید په یو جلا ماشین کې یو ځای بیک اپ شي.
بل ټکی چې ما یې په اړه خبرې وکړې هغه څه دي که ستاسو غوښتنلیک د عملیاتو پرمهال ځینې فایلونه رامینځته کړي. د مثال په توګه، کله چې دا پیل شي، دا یو څه جامد فایل تولیدوي، کوم چې د ځینو معلوماتو پراساس دی چې غوښتنلیک یوازې د پیل کولو په وخت کې ترلاسه کوي. څه شیبه. که چیرې داسې ډیر معلومات شتون ونلري، نو تاسو اړتیا نلرئ چې هیڅ شی مه کوئ، یوازې دا اپلیکیشن د ځان لپاره نصب کړئ او کار وکړئ. دلته یوازینۍ پوښتنه دا ده چې وګورئ. ډیری وختونه، د میراث ټول ډوله سیسټمونه، لکه ورڈپریس او داسې نور، په ځانګړې توګه د ځینې ډوله چالاک پلگ انونو سره، د پی ایچ پی پرمخ وړونکو سره، دوی ډیری وختونه پوهیږي چې دا څنګه جوړ کړي ترڅو دوی د ځان لپاره یو ډول فایل تولید کړي. په دې اساس، یو یو فایل تولیدوي، دویم دویم دویم فایل تولیدوي. دوی مختلف دي. انډول کول د پیرودونکو په کوبرنیټس کلستر کې په ساده ډول په تصادفي ډول پیښیږي. په دې اساس، دا معلومه شوه چې دوی نه پوهیږي چې څنګه د مثال په توګه یوځای کار وکړي. یو یو معلومات ورکوي، بل کارونکي ته بل معلومات ورکوي. دا هغه څه دي چې تاسو یې باید مخنیوی وکړئ. دا دی، په کبرنیټس کې، هر هغه څه چې تاسو یې پیل کوئ تضمین دی چې په ډیری مواردو کې د کار کولو وړ وي. ځکه چې Kubernetes یو خوځنده شی دی. په دې اساس، هغه کولی شي هر څه حرکت وکړي، هرکله چې وغواړي، پرته له دې چې د چا پوښتنه وکړي. له همدې امله، تاسو اړتیا لرئ په دې حساب وکړئ. هرڅه چې په یوه مثال کې پیل شوي ژر یا وروسته به ناکام شي. څومره چې تاسو ډیر تحفظات لرئ، ښه. مګر بیا، زه وایم، که تاسو یو څو داسې فایلونه لرئ، نو تاسو کولی شئ هغه ستاسو لاندې وساتئ، دوی یو څه لږ وزن لري. که چیرې یو څه نور هم شتون ولري ، نو تاسو شاید دوی په کانټینر کې مه فشاروئ.
زه به مشوره ورکړم چې په کوبرنیټس کې دومره په زړه پوري شی شتون لري ، تاسو کولی شئ حجم وکاروئ. په ځانګړې توګه، د ډول خالي ډایر حجم شتون لري. دا یوازې دا دی چې کوبرنیټس به په اوتومات ډول په سرور کې د دې خدماتو لارښودونو کې لارښود رامینځته کړي چیرې چې تاسو پیل کړی. او هغه به تاسو ته درکړي ترڅو تاسو ترې ګټه پورته کړئ. یوازې یو مهم ټکی شتون لري. دا دی، ستاسو معلومات به په کانټینر کې زیرمه نشي، بلکه په هغه کوربه کې چې تاسو یې چلوئ. سربیره پردې، Kubernetes کولی شي دا ډول خالي ډایرونه د نورمال ترتیب لاندې کنټرول کړي او د دې وړتیا لري چې د دوی اعظمي اندازه کنټرول کړي او اجازه ورنکړي چې له حد څخه تیر شي. یوازینی ټکی دا دی چې هغه څه چې تاسو په خالي ډایر کې لیکلي دي د پوډ بیا پیل کولو پرمهال له لاسه نه ورکول کیږي. دا دی، که ستاسو پوډ په غلطۍ سره راښکته شي او بیا راپورته شي، په خالي ډایر کې معلومات به چیرته لاړ نشي. هغه کولی شي دا په نوي پیل کې بیا وکاروي - او دا ښه دی. که ستاسو پوډ کوم ځای پریږدي، نو په طبیعي توګه هغه به د معلوماتو پرته پریږدي. دا ، هرڅومره ژر چې د نوډ څخه پوډ چیرې چې دا د خالي ډایر سره پیل شوی و ورک شي ، خالي ډایر حذف کیږي.
د خالي ډایر په اړه نور څه ښه دي؟ د مثال په توګه، دا د کیچ په توګه کارول کیدی شي. راځئ تصور وکړو چې زموږ غوښتنلیک په الوتنه کې یو څه رامینځته کوي ، کاروونکو ته یې ورکوي او د اوږدې مودې لپاره یې کوي. نو ځکه، غوښتنلیک، د بیلګې په توګه، تولیدوي او کاروونکو ته یې ورکوي، او په ورته وخت کې دا په یو ځای کې ذخیره کوي، ترڅو بل ځل چې کاروونکي د ورته شی لپاره راشي، دا په چټکۍ سره چمتو کیدی شي. په حافظه کې د جوړولو لپاره د کوبرنیټس څخه خالي ډایرونه وغوښتل شي. او پدې توګه ، ستاسو کیچونه عموما د بریښنا په سرعت کې کار کولی شي - د ډیسک لاسرسي سرعت په شرایطو کې. دا دی ، تاسو په حافظه کې یو خالي ډایر لرئ ، په OS کې دا په حافظه کې زیرمه شوی ، مګر ستاسو لپاره ، د پوډ دننه کارونکي لپاره ، دا یوازې د ځایی لارښود په څیر ښکاري. تاسو ایپ ته اړتیا نلرئ په ځانګړي ډول کوم جادو زده کړئ. تاسو یوازې په مستقیم ډول خپل فایل په ډایرکټر کې واخلئ او وساتئ، مګر، په حقیقت کې، په OS کې په حافظه کې. دا د Kubernetes په شرایطو کې هم خورا اسانه ځانګړتیا ده.
مینیو کومې ستونزې لري؟ د مینیو سره اصلي ستونزه دا ده چې د دې شیانو د کار کولو لپاره ، دا باید په کوم ځای کې چلولو ته اړتیا ولري ، او باید یو ډول فایل سیسټم شتون ولري ، دا دی ، ذخیره. او دلته موږ د ورته ستونزو سره مخ یو چې سیف لري. دا دی، مینیو باید خپل فایلونه چیرته ذخیره کړي. دا په ساده ډول ستاسو فایلونو ته HTTP انٹرفیس دی. سربیره پردې، فعالیت په ښکاره ډول د ایمیزون S3 په پرتله خورا خراب دی. پخوا، دا د دې توان نه درلود چې په سمه توګه کاروونکي ته اجازه ورکړي. اوس، تر هغه ځایه چې زه پوهیږم، دا کولی شي دمخه د مختلف واکونو سره بالټونه جوړ کړي، مګر بیا، ما ته داسې ښکاري چې اصلي ستونزه ده، نو د خبرو کولو لپاره، لږترلږه د زیرمه کولو زیرمه سیسټم.
په حافظه کې خالي ډایر څنګه محدودیتونه اغیزه کوي؟ په هیڅ ډول محدودیتونه اغیزه نه کوي. دا د کوربه په حافظه کې دی، نه ستاسو د کانټینر په حافظه کې. دا دی، ستاسو کانټینر په حافظه کې خالي ډایر د خپل نیول شوي حافظې برخې په توګه نه ګوري. کوربه دا ګوري. په دې اساس، هو، د کبرنیټس له نظره، کله چې تاسو د دې کارول پیل کړئ، نو دا به ښه وي چې پوه شئ چې تاسو د خپلې حافظې یوه برخه خالي ډایر ته وقف کوئ. او په دې اساس، پوه شئ چې حافظه نه یوازې د غوښتنلیکونو له امله پای ته رسیږي، بلکې د دې لپاره چې یو څوک دې خالي ډایرونو ته لیکي.
Cloudnativeness
او وروستۍ فرعي موضوع هغه څه ده چې Cloudnative ده. ولې ورته اړتیا ده؟ Cloudnativeness او داسې نور.
دا هغه غوښتنلیکونه دي چې په عصري کلاوډ زیربنا کې د کار کولو لپاره وړ او لیکل شوي. مګر، په حقیقت کې، Cloudnative یو بل اړخ لري. دا نه یوازې یو غوښتنلیک دی چې د عصري کلاوډ زیربنا ټولې اړتیاوې په پام کې نیسي ، بلکه پدې هم پوهیږي چې څنګه د دې عصري کلاوډ زیربنا سره کار وکړي ، د دې حقیقت له ګټو او زیانونو څخه ګټه پورته کړئ چې دا پدې بادلونو کې کار کوي. یوازې په ورېځو کې کار مه کوئ ، مګر په بادل کې د کار کولو ګټو څخه ګټه واخلئ.
راځئ چې یوازې Kubernetes د مثال په توګه واخلو. ستاسو غوښتنلیک په Kubernetes کې روان دی. ستاسو غوښتنلیک تل کولی شي ، یا ستاسو د غوښتنلیک مدیران تل کولی شي د خدماتو حساب رامینځته کړي. دا دی، پخپله په خپل سرور کې په Kubernetes کې د واک لپاره حساب. ځینې حقونه اضافه کړئ چې موږ ورته اړتیا لرو. او تاسو کولی شئ د خپل غوښتنلیک دننه څخه Kubernetes ته لاسرسی ومومئ. تاسو په دې طریقه څه کولی شئ؟ د مثال په توګه، د اپلیکیشن څخه، د دې په اړه معلومات ترلاسه کړئ چې ستاسو نور غوښتنلیکونه، نور ورته مثالونه موقعیت لري، او په یوځای کې د کوبرنیټس په سر کې کلستر کړئ، که ورته اړتیا وي.
یوځل بیا ، موږ واقعیا پدې وروستیو کې قضیه درلوده. موږ یو کنټرولر لرو چې قطار څارنه کوي. او کله چې په دې کتار کې ځینې نوي کارونه ښکاره شي، دا Kubernetes ته ځي - او د Kubernetes دننه دا یو نوی پوډ جوړوي. دې پوډ ته یو څه نوې دنده ورکوي او د دې پوډ په چوکاټ کې ، پوډ دنده ترسره کوي ، پخپله کنټرولر ته ځواب لیږي ، او کنټرولر بیا د دې معلوماتو سره یو څه کوي. د مثال په توګه، دا یو ډیټابیس اضافه کوي. دا ، بیا ، دا د حقیقت یو پلس دی چې زموږ غوښتنلیک په کوبرنیټس کې پرمخ ځي. موږ کولی شو پخپله د کبرنیټس جوړ شوی فعالیت وکاروو ترڅو په یو ډول زموږ د غوښتنلیک فعالیت پراخه او اسانه کړي. دا دی ، د غوښتنلیک لانچ کولو څرنګوالي په اړه یو ډول جادو مه پټوئ ، څنګه کارګر پیل کړئ. په کوبرنیټس کې ، تاسو په ساده ډول په اپلیکیشن کې غوښتنه لیږئ که چیرې غوښتنلیک په Python کې لیکل شوی وي.
ورته تطبیق کیږي که موږ د کوبرنیټس هاخوا لاړ شو. موږ خپل کوبرنیټس یو چیرې روان یو - دا ښه ده که دا په یو ډول بادل کې وي. یوځل بیا ، موږ کولی شو وکاروو ، او حتی باید ، زه باور لرم ، پخپله د بادل ظرفیتونه وکاروئ چیرې چې موږ روان یو. د لومړنیو شیانو څخه چې بادل موږ ته چمتو کوي. توازن کول، دا دی، موږ کولی شو د بادل توازن جوړ کړو او وکاروو. دا د هغه څه مستقیم ګټه ده چې موږ یې کارولی شو. ځکه چې د بادل توازن، لومړی، په ساده ډول په ساده ډول زموږ څخه مسؤلیت لرې کوي چې دا څنګه کار کوي، دا څنګه تنظیم شوی. برسیره پردې دا خورا اسانه دی، ځکه چې منظم کبرنیټ کولی شي د ورېځو سره مدغم شي.
ورته د اندازه کولو لپاره ځي. منظم کبرنیټس کولی شي د بادل چمتو کونکو سره مدغم شي. پوهیږي چې څنګه پوه شي چې که کلستر د نوډونو څخه تیریږي ، دا د نوډ ځای پای ته رسیدلی ، نو تاسو اړتیا لرئ اضافه کړئ - کوبرنیټس به پخپله ستاسو په کلستر کې نوي نوډونه اضافه کړي او په دوی باندې د پوډونو پیل کول پیل کړي. دا دی، کله چې ستاسو بار راشي، د حوزو شمیر ډیریږي. کله چې په کلستر کې نوډونه د دې پوډونو لپاره پای ته ورسیږي ، نو کوبرنیټس نوي نوډونه پیلوي او په وینا یې ، د پوډونو شمیر لاهم وده کولی شي. او دا خورا اسانه ده. دا په الوتنه کې د کلستر اندازه کولو لپاره مستقیم فرصت دی. ډیر ګړندی ندی ، پدې معنی چې دا یوه ثانیه نه ده ، دا د نوي نوډونو اضافه کولو لپاره د یوې دقیقې په څیر دی.
مګر زما د تجربې څخه، بیا، دا ترټولو ښه شی دی چې ما کله هم لیدلی دی. کله چې د Cloudnative کلستر د ورځې د وخت پر بنسټ اندازه شوی. دا یو شاته خدمت و چې د شا په دفتر کې د خلکو لخوا کارول کیده. دا دی، دوی د سهار په 9 بجو کار ته راځي، سیسټم ته ننوتل پیل کوي، او په وینا، د Cloudnative کلستر، چیرته چې دا ټول روان دي، پړسوب پیل کوي، نوي پوډونه پیلوي ترڅو هرڅوک چې کار ته راشي د غوښتنلیک سره کار وکړي. کله چې دوی د ماښام په 8 یا 6 بجو کار پریږدي ، د کبرنیټ کلسترونه ګوري چې هیڅوک نور غوښتنلیک نه کاروي او کمیدل پیل کوي. تر 30 سلنې پورې سپما تضمین شوي. دا په هغه وخت کې په ایمیزون کې کار کاوه؛ په هغه وخت کې په روسیه کې هیڅوک نه و چې دا په ښه توګه ترسره کړي.
زه به تاسو ته مستقیم ووایم ، سپما 30 سلنه ساده دي ځکه چې موږ کوبرنیټس کاروو او د بادل وړتیاو څخه ګټه پورته کوو. اوس دا په روسیه کې ترسره کیدی شي. زه به هیچا ته اعلان ونه کړم، البته، مګر اجازه راکړئ یوازې ووایم چې داسې چمتو کونکي شتون لري چې دا کار کولی شي، دا د بکس څخه سم د تڼۍ سره چمتو کړئ.
یو وروستی ټکی دی چې زه غواړم ستاسو پام هم ورته واړوم. ستاسو د غوښتنلیک لپاره، ستاسو زیربنا د Cloudnative وي، دا معنی لري چې په پای کې د بنسټیز جوړښت په نوم د کوډ په توګه د تګلارې تطبیق پیل کړئ. دا پدې مانا ده چې ستاسو غوښتنلیک، یا ستاسو زیربنا په سمه توګه ورته اړتیا لري. کوډ ستاسو غوښتنلیک، ستاسو د سوداګرۍ منطق د کوډ په بڼه تشریح کړئ. او د دې سره د کوډ په توګه کار وکړئ، دا دی، دا ازموینه وکړئ، دا رول کړئ، په ګیټ کې یې ذخیره کړئ، CICD یې پلي کړئ.
او دا هغه څه دي چې تاسو ته اجازه درکوي، لومړی، تل په خپل زیربنا باندې کنټرول ولرئ، ترڅو تل پوه شئ چې دا په کوم حالت کې دی. دوهم، د لاسي عملیاتو څخه ډډه وکړئ چې د خطا لامل کیږي. دریم، په ساده ډول د هغه څه څخه ډډه وکړئ چې د تبادلې په نوم یادیږي، کله چې تاسو په دوامداره توګه ورته لاسي دندې ترسره کولو ته اړتیا لرئ. څلورم، دا تاسو ته اجازه درکوي چې د ناکامۍ په صورت کې ډیر ګړندی بیرته ترلاسه کړئ. په روسیه کې، هرکله چې زه د دې په اړه خبرې کوم، تل یو لوی شمیر خلک شتون لري چې وايي: "هو، دا روښانه ده، مګر تاسو طریقې لرئ، په لنډه توګه، هیڅ شی حل کولو ته اړتیا نشته." خو دا رښتیا ده. که ستاسو په زیربنا کې یو څه مات شوی وي ، نو د Cloudnative چلند له نظره او د کوډ په توګه د زیربنا له نظره ، د دې د حل کولو پرځای ، سرور ته لاړشئ ، معلوم کړئ چې څه مات شوي او اصلاح کول یې اسانه دي. د سرور ړنګولو لپاره او بیا یې جوړ کړئ. او زه به دا ټول بحال کړم.
دا ټول مسایل په تفصیل سره په تفصیل سره بحث شوي . د لینک په تعقیب تاسو کولی شئ خپل ځان د برنامه او شرایطو سره آشنا کړئ. اسانه خبره دا ده چې تاسو کولی شئ د کور څخه مطالعې یا په ورځ کې د 1-2 ساعتونو لپاره کار کولو سره کوبرنیټس ماسټر کړئ.
سرچینه: www.habr.com