"کلاؤډ اصلي" یا په ساده ډول "بادل" غوښتنلیکونه په ځانګړي ډول د کلاوډ زیربنا کې کار کولو لپاره رامینځته شوي. دوی عموما په کانټینرونو کې بسته شوي د نرم جوړ شوي مایکرو خدماتو سیټ په توګه رامینځته شوي ، کوم چې په پایله کې د بادل پلیټ فارم لخوا اداره کیږي. دا ډول غوښتنلیکونه د ډیفالټ لخوا د ناکامۍ لپاره چمتو شوي ، پدې معنی چې دوی په اعتبار سره کار کوي او حتی د جدي زیربنا کچې ناکامیو په صورت کې اندازه کوي. د سکې بل اړخ د محدودیتونو (قراردادونو) سیټ دی چې د کلاوډ پلیټ فارم د کانټینر غوښتنلیکونو باندې پلي کوي ترڅو وکولی شي په اوتومات ډول اداره کړي.
پداسې حال کې چې د کلاوډ میشته غوښتنلیکونو ته د تګ اړتیا او اهمیت څخه په بشپړ ډول خبر دي ، ډیری سازمانونه لاهم نه پوهیږي چې چیرې یې پیل کړي. پدې پوسټ کې ، موږ به یو شمیر اصول وګورو چې که چیرې د کانټینر شوي غوښتنلیکونو رامینځته کولو پرمهال تعقیب شي ، نو تاسو ته به اجازه درکړي د کلاوډ پلیټ فارمونو احتمال درک کړئ او د اعتبار وړ عملیات او د غوښتنلیکونو اندازه کول ترلاسه کړئ حتی د IT زیربنا کې د جدي ناکامیو په حالت کې. کچه د دې اصولو نهایی هدف دا دی چې د غوښتنلیکونو رامینځته کولو څرنګوالی زده کړئ چې د کلاوډ پلیټ فارمونو لکه کبرنیټس لخوا په اوتومات ډول اداره کیدی شي.
د سافټویر ډیزاین اصول
د برنامه کولو نړۍ کې ، اصول په کافي اندازه عمومي قواعدو ته اشاره کوي چې باید د سافټویر رامینځته کولو پرمهال تعقیب شي. دوی کارول کیدی شي کله چې د هرې برنامې ژبې سره کار کوي. هر اصول خپل اهداف لري، د ترلاسه کولو لپاره وسایل چې معمولا ټیمپلیټونه او عملونه دي. د لوړ کیفیت سافټویر جوړولو لپاره یو شمیر بنسټیز اصول هم شتون لري، له کوم څخه چې نور ټول تیریږي. دلته د بنسټیزو اصولو ځینې مثالونه دي:
- (دا ساده وساتئ، احمق) - دا پیچلې مه کوئ؛
- (خپل ځان مه تکراروئ) - خپل ځان مه تکراروئ؛
- (تاسو دې ته اړتیا نه لرئ) - هغه څه مه جوړوئ چې سمدستي ورته اړتیا نلري؛
- د اندیښنو جلا کول - مسولیتونه شریکول.
لکه څنګه چې تاسو لیدلی شئ، دا اصول کوم ځانګړي مقررات نه ټاکي، مګر د عملي تجربې پراساس د تش په نامه عام احساس نظرونو کټګورۍ پورې اړه لري، کوم چې د ډیری پراختیا کونکو لخوا شریک شوي او په منظمه توګه ورته اشاره کوي.
سربیره پردې ، شتون لري - د اعتراض پر بنسټ پروګرام کولو او ډیزاین د لومړیو پنځو اصولو یوه مجموعه، د رابرټ مارټین لخوا جوړه شوې. SOLID کې پراخ، پرانیستي، بشپړونکي اصول شامل دي - کله چې یوځای پلي کیږي - د ښه سافټویر سیسټمونو رامینځته کولو کې مرسته کوي او د اوږدې مودې لپاره یې ښه ساتي.
د سولیډ اصول د OOP په ساحه پورې اړه لري او د داسې مفاهیمو او مفاهیمو په ژبه کې جوړ شوي لکه ټولګي، انٹرفیس او میراث. د قیاس په واسطه، د بادل غوښتنلیکونو لپاره د پراختیا اصول هم جوړ کیدی شي، دلته یوازې اساسي عنصر به ټولګي نه وي، مګر یو کانټینر وي. د دې اصولو په تعقیب ، تاسو کولی شئ کانټینر شوي غوښتنلیکونه رامینځته کړئ چې د کلاوډ پلیټ فارمونو لکه کبرنیټس اهداف او اهداف په ښه توګه پوره کوي.
د کلاوډ اصلي کانټینرونه: د ریډ هټ طریقه
نن ورځ، نږدې هر غوښتنلیک په نسبتا اسانۍ سره په کانتینرونو کې بسته کیدی شي. مګر د دې لپاره چې غوښتنلیکونه په مؤثره توګه اتومات شي او د کلاوډ پلیټ فارم کې لکه کبرنیټس کې تنظیم شوي ، اضافي هڅې ته اړتیا ده.
د لاندې ذکر شوي نظرونو اساس میتودولوژي وه او ډیری نور کارونه د ویب غوښتنلیکونو د جوړولو په مختلفو اړخونو کې، د سرچینې کوډ مدیریت څخه د اندازه کولو ماډلونو پورې. بیان شوي اصول یوازې د کانټینر شوي غوښتنلیکونو پراختیا باندې پلي کیږي چې د مایکرو خدماتو په سر کې جوړ شوي او د کلاوډ پلیټ فارمونو لکه کبرنیټس لپاره ډیزاین شوي. زموږ په بحث کې بنسټیز عنصر د کانټینر عکس دی، او د هدف کانټینر چلولو وخت د کانټینر آرکیسټریشن پلیټ فارم دی. د وړاندیز شوي اصولو هدف د کانټینرونو رامینځته کول دي د کوم لپاره چې مهالویش کول ، اندازه کول ، او نظارت دندې په ډیری آرکیسټریشن پلیټ فارمونو کې اتومات کیدی شي. اصول په کوم ځانګړي ترتیب کې نه وړاندې کیږي.
د واحد اندیښنې اصول (SCP)
دا اصول په ډیری لارو کې د واحد مسؤلیت اصول سره ورته دی. )، کوم چې د SOLID سیټ برخه ده او وایي چې هر څیز باید یو مسؤلیت ولري، او دا مسؤلیت باید په ټولګي کې په بشپړه توګه پوښل شي. د SRP ټکی دا دی چې هر مسؤلیت د بدلون لپاره یو دلیل دی، او ټولګی باید د بدلون لپاره یو او یوازې یو دلیل ولري.
په SCP کې، موږ د "مسؤلیت" کلمې پر ځای د "اندیښنې" کلمه کاروو ترڅو د OOP ټولګي په پرتله د کانټینر د لوړې کچې خلاصون او پراخ هدف په ګوته کړي. او که د SRP هدف د بدلون لپاره یوازې یو دلیل وي، نو د SCP تر شا د کانټینرونو د بیا کارولو او ځای په ځای کولو وړتیا پراخولو هیله ده. د SRP په تعقیب او د یو کانټینر رامینځته کولو سره چې یو واحد ستونزه حل کوي او دا په فعال ډول په بشپړ ډول ترسره کوي ، تاسو د غوښتنلیک مختلف شرایطو کې د دې کانټینر عکس د بیا کارولو امکانات ډیروئ.
د SCP اصول وايي چې هر کانټینر باید یو واحد ستونزه حل کړي او دا په ښه توګه ترسره کړي. سربیره پردې، د کانټینر نړۍ کې SCP د OOP نړۍ کې د SRP په پرتله ترلاسه کول اسانه دي ، ځکه چې کانټینرونه معمولا یو واحد پروسه پرمخ وړي ، او ډیری وختونه دا پروسه یو واحد کار حل کوي.
که چیرې د کانټینر مایکرو سرویس باید په یوځل کې ډیری ستونزې حل کړي ، نو بیا دا په واحد کاري کانټینرونو ویشل کیدی شي او د سایډ کار او انیټ کانټینر ټیمپلیټونو په کارولو سره په یو پوډ (د کانټینر پلیټ فارم پلي کولو واحد) کې یوځای کیدی شي. برسېره پردې، SCP دا اسانه کوي چې زاړه کانټینر (لکه د ویب سرور یا پیغام بروکر) د نوي سره ځای په ځای کړي چې ورته ستونزه حل کوي مګر د فعالیت پراخول یا پیمانه ښه کړي.
د لوړ کتنې اصول (HOP)
کله چې کانټینرونه د غوښتنلیکونو بسته کولو او چلولو لپاره د متحدې لارې په توګه کارول کیږي، غوښتنلیکونه پخپله د تور بکس په توګه چلند کیږي. په هرصورت، که دا کلاوډ کانټینرونه وي، نو دوی باید د کانټینرونو روغتیا څارنه لپاره ځانګړي APIs چمتو کړي او که اړتیا وي، مناسب اقدام وکړي. له دې پرته، دا به ممکنه نه وي چې د کانټینرونو د تازه کولو اتوماتیک متحد کړئ او د دوی د ژوند دوره اداره کړئ، کوم چې په پایله کې به د سافټویر سیسټم ثبات او کارونې خراب کړي.
په عمل کې، یو کانټینر شوی غوښتنلیک باید لږترلږه، د مختلفو ډولونو روغتیا چکونو لپاره API ولري: د ژوندانه ازموینې او چمتووالي ازموینې. که یو غوښتنلیک د ډیر څه کولو ادعا وکړي، دا باید د خپل حالت د څارنې نورې وسیلې چمتو کړي. د مثال په توګه، د Fluentd، Logstash او نورو ورته وسیلو په کارولو سره د لوګو راټولولو لپاره د STDERR او STDOUT له لارې د مهمو پیښو ثبت کول. همدارنګه د تعقیب او میټریک راټولولو کتابتونونو سره ادغام، لکه OpenTracing، Prometheus، او نور.
په عموم کې ، غوښتنلیک لاهم د تور بکس په توګه درملنه کیدی شي ، مګر دا باید د ټولو APIs سره چمتو شي چې پلیټ فارم ورته اړتیا لري ترڅو دا په غوره ممکنه طریقه نظارت او اداره کړي.
د ژوند دوره د موافقت اصول (LCP)
LCP د HOP ضد دی. پداسې حال کې چې HOP وايي چې کانټینر باید پلیټ فارم ته د لوستلو APIs افشا کړي ، LCP غوښتنلیک ته اړتیا لري ترڅو د پلیټ فارم څخه د معلوماتو منلو وړ وي. سربیره پردې ، کانټینر باید نه یوازې پیښې ترلاسه کړي ، بلکه په بل عبارت ، دوی ته عکس العمل هم تطبیق کړي. له همدې امله د اصولو نوم، کوم چې د APIs لیکلو سره پلیټ فارم چمتو کولو لپاره د اړتیا په توګه ګڼل کیدی شي.
پلیټ فارمونه د کانټینر د ژوند دورې اداره کولو کې د مرستې لپاره مختلف ډوله پیښې لري. مګر دا پخپله غوښتنلیک پورې اړه لري چې پریکړه وکړي چې کوم یو یې درک کړي او څنګه عکس العمل وکړي.
دا روښانه ده چې ځینې پیښې د نورو په پرتله خورا مهم دي. د مثال په توګه، که یو اپلیکیشن کریشونه ښه برداشت نه کړي، دا باید سیګنال ومني: (SIGTERM) پیغامونه پای ته ورسوي او د سیګنال د نیولو لپاره ژر تر ژره د هغې د ختمولو معمول پیل کړي: وژنه (SIGKILL) چې د SIGTERM څخه وروسته راځي.
سربیره پردې ، پیښې لکه پوسټ سټارټ او پری سټاپ د غوښتنلیک د ژوند دورې لپاره مهم کیدی شي. د مثال په توګه، د غوښتنلیک پیل کولو وروسته، دا ممکن یو څه ګرم وخت ته اړتیا ولري مخکې لدې چې غوښتنو ته ځواب ووایی. یا غوښتنلیک باید په یو ځانګړي ډول سرچینې خوشې کړي کله چې بند شي.
د انځور د بدلون اصول (IIP)
دا عموما منل شوي چې کانټینر شوي غوښتنلیکونه باید د جوړیدو وروسته بدل نشي ، حتی که دوی په مختلف چاپیریال کې پرمخ وړل کیږي. دا د رن ټایم په وخت کې د ډیټا ذخیره کولو بهرنۍ کولو اړتیا ته اړتیا لري (په بل عبارت ، د دې لپاره د بهرني وسیلو کارولو لپاره) او د هر چاپیریال لپاره ځانګړي کانټینرونو ترمیم یا رامینځته کولو پرځای په بهرني ، د چلولو ځانګړي ترتیبونو باندې تکیه کول. په غوښتنلیک کې د هر ډول بدلونونو وروسته، د کانټینر عکس باید بیا جوړ شي او په ټولو کارول شویو چاپیریالونو کې ځای په ځای شي. د لارې په توګه، کله چې د معلوماتي ټیکنالوژۍ سیسټمونو اداره کول، ورته اصول کارول کیږي، چې د سرورونو او زیربناوو د بې ثباتۍ په توګه پیژندل کیږي.
د IIP هدف دا دی چې د مختلف چلولو چاپیریال لپاره د جلا کانټینر عکسونو رامینځته کولو مخه ونیسي او د مناسب چاپیریال ځانګړي ترتیب سره په هر ځای کې ورته عکس وکاروئ. د دې اصول تعقیب تاسو ته اجازه درکوي د کلاوډ سیسټمونو اتومات کولو له نظره داسې مهم عملونه پلي کړئ لکه څنګه چې د غوښتنلیک تازه کولو رول بیک او رول فارورډ.
د پروسې د ضایع کولو اصول (PDP)
د کانټینر یو له خورا مهم ځانګړتیاو څخه د هغې لنډیز دی: د کانټینر مثال رامینځته کول اسانه دي او ویجاړول یې اسانه دي ، نو دا په اسانۍ سره په هر وخت کې د بل مثال سره بدل کیدی شي. د داسې بدیل لپاره ډیری دلیلونه شتون لري: د خدمت وړتیا ازموینې ناکامي ، د غوښتنلیک اندازه کول ، بل کوربه ته لیږدول ، د پلیټ فارم سرچینو ستړیا ، یا نور شرایط.
د پایلې په توګه ، کانټینر شوي غوښتنلیکونه باید د ځینې بهرني وسیلو په کارولو سره خپل حالت وساتي ، یا د دې لپاره د بې ځایه کیدو سره داخلي توزیع شوي سکیمونه وکاروي. سربیره پردې ، غوښتنلیک باید ژر تر ژره پیل او وتړل شي ، او د ناڅاپي وژونکي هارډویر ناکامۍ لپاره چمتو اوسئ.
یو تمرین چې د دې اصولو پلي کولو کې مرسته کوي د کانټینرونو کوچني ساتل دي. د کلاوډ چاپیریالونه کولی شي په اوتومات ډول یو کوربه غوره کړي ترڅو د کانټینر مثال په لاره واچوي ، نو هرڅومره چې کانټینر کوچنی وي ، ګړندی به یې پیل شي - دا به په ساده ډول په شبکه کې د هدف کوربه ته ګړندي کاپي کړي.
د ځان ساتلو اصول (S-CP)
د دې اصولو له مخې، د مجلس په مرحله کې، ټول اړین اجزا په کانتینر کې شامل دي. کانټینر باید په دې انګیرنه کې جوړ شي چې سیسټم یوازې یو خالص لینکس کرنل لري، نو ټول اړین اضافي کتابتونونه باید پخپله کانټینر کې ځای پرځای شي. دا باید هغه شیان هم ولري لکه د اړونده برنامې ژبې لپاره د وخت وخت ، د غوښتنلیک پلیټ فارم (که اړتیا وي) ، او نور انحصارونه چې د کانټینر غوښتنلیک چلولو پرمهال به ورته اړتیا وي.
استثناوې د تشکیلاتو لپاره رامینځته شوي چې له چاپیریال څخه چاپیریال ته توپیر لري او باید د چلولو په وخت کې چمتو شي ، د مثال په توګه د کوبرنیټس کنفیګ میپ له لارې.
یو غوښتنلیک ممکن ډیری کانټینر شوي برخې ولري، د بیلګې په توګه، د کانټینر شوي ویب غوښتنلیک دننه د DBMS جلا کانټینر. د S-CP اصولو سره سم، دا کانټینرونه باید په یو کې یوځای نشي، مګر باید داسې جوړ شي چې د DBMS کانټینر د ډیټابیس د عملیاتو لپاره اړین هرڅه لري، او د ویب غوښتنلیک کانټینر د ویب عملیات لپاره اړین هرڅه لري. غوښتنلیک، ورته ویب سرور. د پایلې په توګه، د چلولو په وخت کې د ویب غوښتنلیک کانټینر به د DBMS کانټینر پورې اړه ولري او د اړتیا سره سم ورته لاسرسی ومومي.
د وخت د بندولو اصول (RCP)
د S-CP اصول دا تعریفوي چې کانټینر باید څنګه جوړ شي او د عکس بائنری باید څه شی ولري. مګر کانټینر یوازې یو "تور بکس" ندی چې یوازې یو ځانګړتیا لري - د فایل اندازه. د اجرا کولو په جریان کې، کانټینر نور ابعاد اخلي: د کارول شوي حافظې مقدار، د CPU وخت، او د سیسټم نورې سرچینې.
او دلته د RCP اصول په کار کې راځي، چې له مخې یې کانټینر باید د سیسټم سرچینو لپاره خپلې اړتیاوې پرې کړي او پلیټ فارم ته یې انتقال کړي. د هر کانټینر د سرچینو پروفایلونو سره (څومره CPU، حافظه، شبکه، او ډیسک سرچینې ورته اړتیا لري)، پلیټ فارم کولی شي په مناسب ډول مهالویش او اتوماتیک کولو ترسره کړي، د IT ظرفیت اداره کړي، او د کانټینرونو لپاره د SLA کچه وساتي.
د کانټینر د سرچینو اړتیاو پوره کولو سربیره، دا د غوښتنلیک لپاره هم مهم دی چې د خپل حد څخه بهر نه ځي. که نه نو، کله چې د سرچینې کمښت واقع شي، پلیټ فارم ډیر احتمال لري چې دا د غوښتنلیکونو په لیست کې شامل کړي چې باید لغوه یا مهاجرت ته اړتیا ولري.
کله چې موږ د بادل لومړی کیدو په اړه خبرې کوو، موږ د هغه طریقې په اړه خبرې کوو چې موږ کار کوو.
پورته، موږ یو شمیر عمومي اصول جوړ کړل چې د بادل چاپیریال لپاره د لوړ کیفیت کانټینر غوښتنلیکونو جوړولو لپاره میتودولوژیکي بنسټ جوړوي.
په یاد ولرئ چې د دې عمومي اصولو سربیره، تاسو به د کانټینرونو سره کار کولو لپاره اضافي پرمختللي میتودونو او تخنیکونو ته هم اړتیا ولرئ. برسېره پردې، موږ یو څو لنډ وړاندیزونه لرو چې ډیر مشخص دي او باید پلي شي (یا نه پلي کیږي) د وضعیت پورې اړه لري:
- هڅه وکړئ د عکسونو اندازه کمه کړئ: لنډمهاله فایلونه ړنګ کړئ او غیر ضروري کڅوړې مه نصب کړئ - د کانټینر اندازه کوچنۍ وي ، هومره ګړندۍ راټولیږي او په شبکه کې د هدف کوربه ته کاپي کیږي.
- په خپل سري کارن IDs باندې تمرکز وکړئ: د خپلو کانټینرونو لانچ کولو لپاره د sudo کمانډ یا کوم ځانګړي یوزرایډ مه کاروئ.
- مهم بندرونه په نښه کړئ: تاسو کولی شئ د چلولو په وخت کې د پورټ شمیرې تنظیم کړئ، مګر دا غوره ده چې د EXPOSE کمانډ په کارولو سره یې مشخص کړئ - دا به د نورو خلکو او برنامو لپاره ستاسو د عکسونو کارول اسانه کړي.
- په حجمونو کې دوامداره ډاټا ذخیره کړئ: هغه معلومات چې د کانټینر له مینځه وړلو وروسته پاتې شي باید حجمونو ته ولیکل شي.
- د عکس میټاډاټا ولیکئ: ټاګونه ، لیبلونه او تشریحات د عکسونو کارول اسانه کوي - نور پراختیا کونکي به مننه وکړي.
- کوربه او عکسونه همغږي کړئ: ځینې کانټینر شوي غوښتنلیکونه کانټینر ته اړتیا لري چې د کوربه سره په ځانګړو ځانګړتیاو کې همغږي شي ، لکه وخت یا ماشین ID.
- په پایله کې، موږ ټیمپلیټونه او غوره تمرینونه شریکوو چې تاسو سره به د پورته لیست شوي اصولو په اغیزمنه توګه پلي کولو کې مرسته وکړي:
د جون 11 په 11.00 کې
تاسو به څه زده کړئ:
- د بدلیدو وړ Red Hat Enterprise Linux CoreOS
- د OpenShift خدمت میش
- د چلونکي چوکاټ
- د نوښت چوکاټ
سرچینه: www.habr.com