سلام و ټولو ته! زما نوم پاول اګالیتسکي دی. زه په یوه ټیم کې د ټیم مشر په توګه کار کوم چې د لاموډا تحویلي سیسټم رامینځته کوي. په 2018 کې، ما د HighLoad++ کنفرانس کې خبرې وکړې، او نن زه غواړم د خپل راپور یو نقل وړاندې کړم.

زما موضوع مختلف چاپیریالونو ته د سیسټمونو او خدماتو پلي کولو کې زموږ د شرکت تجربې ته وقف شوې ده. زموږ د تاریخي وختونو څخه پیل کول، کله چې موږ ټول سیسټمونه په عادي مجازی سرورونو کې ځای پرځای کړل، په کوبرنیټس کې له کوماډ څخه د تدریجي لیږد سره پای ته ورسید. زه به تاسو ته ووایم چې موږ ولې دا وکړل او موږ په پروسه کې کومې ستونزې درلودې.

VM ته د غوښتنلیکونو ځای په ځای کول

راځئ چې د دې حقیقت سره پیل وکړو چې 3 کاله دمخه د شرکت ټول سیسټمونه او خدمات په منظم مجازی سرورونو کې ځای په ځای شوي وو. په تخنیکي توګه، دا په داسې ډول تنظیم شوی و چې زموږ د سیسټمونو ټول کوډ د جینکنز په کارولو سره د اتوماتیک مجلس وسیلو په کارولو سره ذخیره او راټول شوي. د ځواب وړ کارولو سره، دا زموږ د نسخه کنټرول سیسټم څخه مجازی سرورونو ته لیږدول شوی. سربیره پردې ، هر سیسټم چې زموږ شرکت درلود لږترلږه 2 سرورونو ته ځای په ځای شوی و: یو یې په سر کې ، دوهم یې په لکۍ کې. دا دوه سیسټمونه د دوی په ټولو ترتیباتو، ځواک، ترتیب او نورو کې یو بل ته بالکل ورته وو. د دوی ترمنځ یوازینی توپیر دا و چې سر د کاروونکي ټرافيک ترلاسه کړ، پداسې حال کې چې پای هیڅکله د کاروونکي ټرافيک ترلاسه نه کړ.

دا د څه لپاره وه؟

کله چې موږ د خپل غوښتنلیک نوي ریلیزونه ځای په ځای کړل، موږ غوښتل چې د بې سیمه رول آوټ ډاډ ترلاسه کړو، دا د کاروونکو لپاره د پام وړ پایلو پرته. دا د دې حقیقت له امله ترلاسه شوی و چې د ځواب په کارولو سره راتلونکی تالیف شوی ریلیز پای ته رسول شوی و. هلته، هغه خلک چې په ګمارلو کې ښکیل وو کولی شي وګوري او ډاډ ترلاسه کړي چې هرڅه سم دي: ټول میټریکونه، برخې او غوښتنلیکونه کار کوي؛ اړین سکریپټونه پیل شوي. یوازې وروسته له دې چې دوی په دې قانع شول چې هرڅه سم دي، ترافیک بدل شو. دا هغه سرور ته روان شو چې مخکې یې دم و. او هغه چې دمخه سر و د کارونکي ترافیک پرته پاتې شو ، پداسې حال کې چې لاهم پدې کې زموږ د غوښتنلیک پخوانۍ نسخه شتون لري.

نو دا د کاروونکو لپاره بې ځایه وه. ځکه چې سویچ کول سمدستي دي ، ځکه چې دا په ساده ډول د بیلانس بدلول دي. تاسو کولی شئ په ساده ډول د بیلانسر بیرته بدلولو سره پخوانۍ نسخې ته بیرته راستون شئ. موږ دا هم تاییدولی شو چې غوښتنلیک د تولید وړ و حتی مخکې لدې چې د کارونکي ترافیک ترلاسه کړي ، کوم چې خورا اسانه و.

په دې ټولو کې مو کومې ګټې ولیدلې؟

1. لومړی، دا بس دی دا یوازې کار کوي. هرڅوک پوهیږي چې دا ډول ګمارنې سکیم څنګه کار کوي، ځکه چې ډیری خلک تل منظم مجازی سرورونو ته ګمارل شوي.
2. دا بس دی په ډاډ سره، ځکه چې د ګمارنې ټیکنالوژي ساده ده ، د زرګونو شرکتونو لخوا ازمول شوې. په ملیونونو سرورونه پدې توګه ځای په ځای شوي دي. د یو څه ماتول سخت دي.
3. او بالاخره موږ کولی شو ترلاسه کړو اټومي ځای پرځای کول. ګمارنې چې د کاروونکو لپاره په ورته وخت کې پیښیږي ، پرته له دې چې د زاړه نسخې او نوي نسخې ترمینځ د پام وړ مرحلې بدل شي.

مګر موږ په دې ټولو کې یو شمیر نیمګړتیاوې هم ولیدلې:

1. د تولید چاپیریال سربیره، د پراختیا چاپیریال، نور چاپیریالونه شتون لري. د مثال په توګه، qa او مخکې تولید. په هغه وخت کې موږ ډیری سرورونه او شاوخوا 60 خدمتونه درلودل. د دې لپاره دا اړینه وه د هر خدمت لپاره، د دې لپاره وروستۍ نسخه وساتئ مجازی ماشین. سربیره پردې ، که تاسو غواړئ کتابتونونه تازه کړئ یا نوي انحصارونه نصب کړئ ، نو تاسو اړتیا لرئ دا په ټولو چاپیریالونو کې وکړئ. تاسو د هغه وخت همغږي کولو ته هم اړتیا لرئ کله چې تاسو د خپل غوښتنلیک راتلونکی نوې نسخه د هغه وخت سره ځای په ځای کړئ کله چې ډیوپس اړین چاپیریال تنظیمات ترسره کوي. په دې حالت کې، دا اسانه ده چې داسې یو حالت ته ورسیږئ چیرې چې زموږ چاپیریال به په یو وخت کې په ټولو چاپیریالونو کې یو څه توپیر ولري. د مثال په توګه، د QA چاپیریال کې به د کتابتونونو ځینې نسخې وي، او د تولید چاپیریال کې به مختلف وي، کوم چې به د ستونزو لامل شي.
2. د انحصارونو په تازه کولو کې مشکل ستاسو غوښتنلیک. دا په تاسو پورې اړه نلري، مګر په بل ټیم ​​پورې اړه لري. د بیلګې په توګه، د ډیوپس ټیم څخه چې سرورونه ساتي. تاسو باید دوی ته یو مناسب دنده ورکړئ او د هغه څه توضیحات ورکړئ چې تاسو یې کول غواړئ.
3. په هغه وخت کې، موږ هم غوښتل چې هغه لوی لوی مونولیتونه چې موږ یې درلودل په جلا کوچنیو خدماتو ویشلو، ځکه چې موږ پوهیږو چې دوی به ډیر وي. په هغه وخت کې، موږ دمخه د دوی له 100 څخه ډیر درلودل، د هر نوي خدمت لپاره، دا اړینه وه چې یو جلا نوی مجازی ماشین جوړ کړو، کوم چې باید ساتل او ځای پرځای شي. سربیره پردې، تاسو یو موټر ته اړتیا نلري، مګر لږترلږه دوه. پدې ټولو کې د QA چاپیریال اضافه شوی. دا د ستونزو لامل کیږي او ستاسو لپاره د نوي سیسټمونو رامینځته کول او چلول ډیر ستونزمن کوي. پیچلې، ګران او اوږد بهیر.

له همدې امله ، موږ پریکړه وکړه چې دا به خورا اسانه وي چې د منظم مجازی ماشینونو ځای په ځای کولو څخه په ډاکر کانټینر کې زموږ غوښتنلیکونو ځای په ځای کولو لپاره حرکت وکړو. که تاسو ډاکر لرئ، تاسو داسې سیسټم ته اړتیا لرئ چې غوښتنلیک په کلستر کې پرمخ وړي، ځکه چې تاسو نشئ کولی یوازې کانټینر پورته کړئ. معمولا تاسو غواړئ تعقیب کړئ چې څومره کانټینرونه پورته شوي ترڅو دوی په اوتومات ډول پورته شي. د دې دلیل لپاره، موږ د کنټرول سیسټم غوره کولو ته اړتیا لرو.

موږ د اوږدې مودې لپاره فکر کاوه چې کوم یو یې اخیستلی شو. حقیقت دا دی چې په هغه وخت کې په منظم مجازی سرورونو کې د دې ګمارلو سټیک یو څه زوړ شوی و، ځکه چې دوی د عملیاتي سیسټمونو وروستي نسخې نه درلودې. په یو وخت کې ، حتی FreeBSD هم شتون درلود ، کوم چې د ملاتړ لپاره خورا اسانه نه و. موږ پوهیږو چې موږ باید ژر تر ژره ډاکر ته مهاجرت وکړو. زموږ ډوپس خپل موجوده تجربه د مختلف حلونو سره وڅیړله او د کوډ په څیر یو سیسټم یې غوره کړ.

کوماډ ته لاړشئ

Nomad د HashiCorp محصول دی. دوی د دوی د نورو حلونو لپاره هم پیژندل کیږي:

"قونسل" د خدماتو کشف لپاره وسیله ده.

"ټرافارم" - د سرورونو اداره کولو لپاره یو سیسټم چې تاسو ته اجازه درکوي دوی د ترتیب له لارې تنظیم کړئ، د بنسټیز جوړښت په توګه-کوډ.

"بې حرکته" تاسو ته اجازه درکوي مجازی ماشینونه ځایی یا په کلاوډ کې د ځانګړي ترتیب فایلونو له لارې ځای په ځای کړئ.

په هغه وخت کې کوچیان د یو ساده حل په څیر ښکاري چې په چټکۍ سره د بشپړ زیربنا بدلولو پرته بدلیدلی شي. برسېره پردې، دا د زده کړې لپاره خورا اسانه ده. له همدې امله موږ دا زموږ د کانټینر لپاره د فلټر کولو سیسټم په توګه غوره کړ.

تاسو څه ته اړتیا لرئ چې خپل سیسټم کوډ ته ځای په ځای کړئ؟

1. د ټولو نه اول تاسو ته اړتيا لري د ډاکر انځور ستاسو غوښتنلیک. تاسو اړتیا لرئ دا جوړ کړئ او د ډاکر عکس ذخیره کې یې ځای په ځای کړئ. زموږ په قضیه کې، دا یو هنري فابریکه ده - یو سیسټم چې تاسو ته اجازه درکوي چې د مختلفو ډولونو مختلف اثار په هغې کې واچوئ. دا کولی شي آرشیفونه، ډاکر انځورونه، کمپوزر پی ایچ پی کڅوړې، د NPM کڅوړې، او داسې نور ذخیره کړي.
2. هم اړین دی د ترتیب فایل، کوم چې به کوچیانو ته ووایي چې څه، چیرته او په کوم مقدار کې تاسو ځای پرځای کول غواړئ.

کله چې موږ د Nomad په اړه وغږیږو، دا د HCL ژبه د هغې د معلوماتو فایل فارمیټ په توګه کاروي، کوم چې ولاړ دی د HashiCorp ترتیب ژبه. دا د یامل یو سوپر سیټ دی چې تاسو ته اجازه درکوي خپل خدمت په کوماډ شرایطو کې تشریح کړئ.

دا تاسو ته اجازه درکوي چې ووایاست څومره کانټینرونه چې تاسو یې ځای په ځای کول غواړئ، له کومو څخه عکسونه د ګمارنې پرمهال دوی ته مختلف پیرامیټرې انتقالوي. پدې توګه ، تاسو دا فایل نوماد ته تغذیه کوئ ، او دا د هغې مطابق تولید ته کانټینرونه پیلوي.

زموږ په قضیه کې ، موږ پوهیږو چې د هر خدمت لپاره په ساده ډول د ورته HCL فایلونو لیکل به خورا اسانه نه وي ، ځکه چې ډیری خدمات شتون لري او ځینې وختونه تاسو غواړئ دوی تازه کړئ. دا پیښیږي چې یو خدمت په یو مثال کې نه ګمارل کیږي ، مګر په مختلف ډولونو کې. د مثال په توګه، یو له هغه سیسټمونو څخه چې موږ یې په تولید کې لرو په تولید کې له 100 څخه ډیر مثالونه لري. دوی د ورته عکسونو څخه تیریږي ، مګر د ترتیب تنظیماتو او ترتیب فایلونو کې توپیر لري.

له همدې امله ، موږ پریکړه وکړه چې دا به زموږ لپاره اسانه وي چې زموږ ټول تشکیلاتي فایلونه په یو عام ذخیره کې د ځای په ځای کولو لپاره ذخیره کړو. په دې توګه دوی لیدل شوي: دوی ساتل اسانه وو او موږ کولی شو وګورو چې کوم سیسټمونه لرو. که اړتیا وي، د یو څه تازه کول یا بدلول هم اسانه دي. د نوي سیسټم اضافه کول هم ستونزمن ندي - تاسو اړتیا لرئ د نوي لارښود دننه د تشکیلاتو فایل رامینځته کړئ. د دې دننه لاندې فایلونه دي: service.hcl، کوم چې زموږ د خدماتو توضیحات لري، او ځینې env فایلونه چې دا خورا خدمت ته اجازه ورکوي، په تولید کې ځای پرځای شوي، ترتیب شي.

په هرصورت ، زموږ ځینې سیسټمونه په تولید کې ځای په ځای شوي نه په یوه کاپي کې ، مګر په یوځل کې په څو کې. له همدې امله ، موږ پریکړه وکړه چې دا به زموږ لپاره اسانه وي چې تشکیلات د دوی په خالص شکل کې نه ذخیره کړئ ، مګر د دوی نمونه شوې بڼه. او موږ غوره کړه جنجا 2. په دې بڼه کې، موږ پخپله د خدمت دواړه ترتیبونه او د دې لپاره اړین env فایلونه ذخیره کوو.

سربیره پردې ، موږ په ذخیره کې د ټولو پروژو لپاره د ګمارنې سکریپټ ځای په ځای کړی ، کوم چې تاسو ته اجازه درکوي خپل خدمت په تولید کې ، مطلوب چاپیریال کې ، مطلوب هدف ته پیل او ځای په ځای کړئ. په هغه حالت کې کله چې موږ خپل HCL تشکیل په ټیمپلیټ بدل کړ ، نو د HCL فایل ، کوم چې دمخه یو منظم نوماد تشکیل و ، پدې حالت کې یو څه مختلف ښکاري.

دا دی، موږ د متغیر داخلونو سره ځینې ترتیب ځای متغیرونه بدل کړل چې د env فایلونو یا نورو سرچینو څخه اخیستل شوي. سربیره پردې ، موږ د HCL فایلونو په متحرک ډول راټولولو فرصت ترلاسه کړ ، دا دی ، موږ کولی شو نه یوازې عادي متغیر داخلونه وکاروو. څرنګه چې جنجا د لوپونو او شرایطو ملاتړ کوي، تاسو کولی شئ هلته د ترتیب کولو فایلونه هم جوړ کړئ، کوم چې د دې پورې اړه لري چې تاسو خپل غوښتنلیکونه چیرته ځای پرځای کوئ.

د مثال په توګه، تاسو غواړئ خپل خدمت مخکې تولید او تولید ته ځای په ځای کړئ. راځئ چې ووایو چې په پری تولید کې تاسو نه غواړئ د کرون سکریپټونه پرمخ وړئ، مګر یوازې غواړئ خدمت په جلا ډومین کې وګورئ ترڅو ډاډ ترلاسه کړئ چې دا کار کوي. د هر هغه چا لپاره چې خدمت ګماري، پروسه خورا ساده او شفافه ښکاري. ټول هغه څه چې تاسو یې کولو ته اړتیا لرئ د deploy.sh فایل اجرا کول دي ، مشخص کړئ چې کوم خدمت تاسو غواړئ ځای په ځای کړئ او کوم هدف ته. د مثال په توګه، تاسو غواړئ یو ځانګړی سیسټم په روسیه، بیلاروس یا قزاقستان کې ځای پرځای کړئ. د دې کولو لپاره، په ساده ډول د پیرامیټونو څخه یو بدل کړئ، او تاسو به د سم ترتیب کولو فایل ولرئ.

کله چې د کوچیانو خدمت لا دمخه ستاسو په کلستر کې ځای په ځای شوی وي، داسې ښکاري.

لومړی، تاسو بهر یو ډول بیلانس ته اړتیا لرئ، کوم چې به د کاروونکي ټول ټرافیک ترلاسه کړي. دا به د قونسل سره یوځای کار وکړي او له دې څخه به معلومه کړي چې چیرته، په کوم نوډ کې، په کوم IP پته کې یو ځانګړی خدمت شتون لري چې د ځانګړي ډومین نوم سره مطابقت لري. په قونسلګرۍ کې خدمتونه پخپله د کوماډ څخه راځي. څرنګه چې دا د ورته شرکت محصولات دي، دوی یو بل سره خورا تړاو لري. موږ کولی شو ووایو چې د بکس څخه بهر کوچیان کولی شي ټول هغه خدمات چې په قونسلګرۍ کې یې پیل کړي ثبت کړي.

یوځل چې ستاسو د مخکښې پای بار بیلانسر پوه شي چې کوم خدمت ته ترافیک لیږل کیږي ، نو دا مناسب کانټینر یا څو کانټینرونو ته لیږي چې ستاسو غوښتنلیک سره سمون لري. په طبیعي توګه، دا هم اړینه ده چې د خوندیتوب په اړه فکر وکړئ. که څه هم ټول خدمتونه په کانتینرونو کې په ورته مجازی ماشینونو کې پرمخ ځي، دا معمولا اړتیا لري چې بل کوم خدمت ته د وړیا لاسرسي مخه ونیسي. موږ دا د ویشلو له لارې ترلاسه کړل. هر خدمت په خپل مجازی شبکه کې پیل شوی و، په کوم کې چې نورو سیسټمونو او خدماتو ته د لاسرسي اجازه / رد کولو لپاره د روټینګ قواعد او مقررات ټاکل شوي. دوی کولی شي د دې کلستر دننه او بهر دواړه موقعیت ولري. د مثال په توګه، که تاسو غواړئ یو خدمت د یو ځانګړي ډیټابیس سره وصل کیدو څخه مخنیوی وکړئ، دا د شبکې کچې برخې برخې له لارې ترسره کیدی شي. دا ، حتی په غلطۍ سره ، تاسو نشئ کولی په ناڅاپي ډول د ازموینې چاپیریال څخه ستاسو د تولید ډیټابیس سره وصل شئ.

د بشري منابعو په برخه کې موږ ته د لیږد لګښت څومره دی؟

Nomad ته د ټول شرکت لیږد نږدې 5-6 میاشتې وخت ونیو. موږ د خدمت په اساس د خدمت په اساس حرکت وکړ، مګر په کافي اندازه ګړندی. هر ټیم باید د خدماتو لپاره خپل کانټینرونه جوړ کړي.

موږ داسې چلند غوره کړی چې هر ټیم په خپلواک ډول د دوی سیسټمونو د ډاکر عکسونو مسؤل دی. DevOps د ګمارنې لپاره اړین عمومي زیربنا چمتو کوي، دا د کلستر لپاره ملاتړ، د CI سیسټم ملاتړ، او داسې نور. او په هغه وخت کې، موږ له 60 څخه ډیر سیسټمونه کوماډ ته لیږدول شوي وو، چې شاوخوا 2 زره کانټینرونه وو.

Devops د ګمارنې او سرورونو پورې اړوند هرڅه عمومي زیربنا مسؤل دي. او هر پرمختیایی ټیم، په بدل کې، د خپل ځانګړي سیسټم لپاره د کانټینرونو پلي کولو مسولیت لري، ځکه چې دا هغه ټیم دی چې پوهیږي چې په یو ځانګړي کانټینر کې څه شی ته اړتیا لري.

د کوچیانو د پریښودو لاملونه

موږ د نورو په مینځ کې د Nomad او docker په کارولو سره ګمارنې ته د بدلولو له لارې کومې ګټې ترلاسه کړې؟

1. موږ یو برابر شرایط برابر کړي د ټولو چاپیریال لپاره. په پراختیا کې، د QA چاپیریال، مخکې تولید، تولید، ورته کانټینر انځورونه کارول کیږي، د ورته انحصار سره. په دې اساس، تاسو واقعیا هیڅ چانس نلرئ چې څه به په تولید کې پای ته ورسیږي هغه څه ندي چې تاسو دمخه په محلي یا ستاسو د ازموینې چاپیریال کې ازموینه کړې.
2. موږ دا هم وموندله چې دا کافي ده د نوي خدمت اضافه کول اسانه دي. د ځای پرځای کولو له نظره، کوم نوي سیسټمونه په ساده ډول پیل شوي. یوازې هغه ذخیره ته لاړ شئ چې تشکیلات ذخیره کوي، هلته ستاسو د سیسټم لپاره بل ترتیب اضافه کړئ، او تاسو ټول چمتو یاست. تاسو کولی شئ خپل سیسټم تولید ته پرته له کوم اضافي هڅو څخه د ډیوپس څخه ځای په ځای کړئ.
3. ټول د تشکیلاتو فایلونه په یوه ګډ ذخیره کې د بیا کتنې لاندې ثابت شو. په هغه وخت کې چې موږ خپل سیسټمونه د مجازی سرورونو په کارولو سره ځای په ځای کړل، موږ ځواب ورکوو، په کوم کې چې تشکیلات په ورته ذخیره کې وو. په هرصورت، د ډیری پراختیا کونکو لپاره دا د کار کولو لپاره یو څه ډیر ستونزمن و. دلته د تشکیلاتو او کوډ حجم چې تاسو اړتیا لرئ د خدمت پلي کولو لپاره اضافه کړئ خورا کوچنی شوی. برسیره پردې، دا د ډیوپس لپاره خورا اسانه دی چې دا سم کړي یا بدل کړي. د لیږد په حالت کې، د بیلګې په توګه، د Nomad نوي نسخه ته، دوی کولی شي په ورته ځای کې موجود ټول عملیاتي فایلونه واخلي او تازه کړي.

مګر موږ د ډیری زیانونو سره هم مخ شو:

دا معلومه شوه چې موږ نه شو کولای چې بې ځایه ګمارنې ترلاسه کړي د کوچیانو په قضیه کې. کله چې په مختلفو شرایطو کې کانټینرونه راوباسئ، دا کیدای شي د چلولو په حال کې وي، او نوماد دا د ټرافیک ترلاسه کولو لپاره چمتو شوي کانټینر په توګه وپیژندل. دا مخکې له دې چې په دې کې دننه غوښتنلیک حتی د پیل کولو چانس ولري پیښ شو. د دې دلیل لپاره، سیسټم د لنډې مودې لپاره د 500 غلطیو تولید پیل کړ، ځکه چې ټرافيک یو کانټینر ته ځي چې لا تر اوسه د منلو لپاره چمتو نه و.

موږ له ځینو سره مخ شو کیګونه. ترټولو د پام وړ ستونزه دا ده چې Nomad یو لوی کلستر په ښه توګه نه اداره کوي که تاسو ډیری سیسټمونه او کانټینرونه لرئ. کله چې تاسو غواړئ یو له هغه سرورونو څخه وباسئ چې د ساتنې لپاره په نومډ کلستر کې شامل وي ، نو خورا لوړ احتمال شتون لري چې کلستر به ډیر ښه احساس ونکړي او له مینځه ولاړ شي. ځینې ​​​​کانټینرونه ممکن د مثال په توګه راښکته شي او پورته نشي - دا به تاسو ډیر وروسته مصرف کړي که ستاسو ټول تولید سیسټمونه د کوماډ لخوا اداره کیږي په کلستر کې موقعیت ولري.

نو موږ پریکړه وکړه چې فکر وکړو چې چیرته باید لاړ شو. په دې وخت کې، موږ د هغه څه په اړه ډیر پوه شو چې موږ یې ترلاسه کول غواړو. د مثال په توګه: موږ اعتبار غواړو، د Nomad په پرتله یو څه نور فعالیتونه، او یو ډیر بالغ، ډیر باثباته سیسټم.

په دې اړه، زموږ انتخاب د کلسترونو په لاره اچولو لپاره د خورا مشهور پلیټ فارم په توګه په Kubernetes باندې راوتلی. په ځانګړي توګه ورکړل شوي چې زموږ د کانټینرونو اندازه او شمیر خورا لوی و. د داسې موخو لپاره، Kubernetes داسې ښکاري چې ترټولو مناسب سیسټم وي چې موږ یې وګورو.

Kubernetes ته لیږد

زه به تاسو ته د Kubernetes د بنسټیزو مفکورو په اړه لږ څه ووایم او دا چې څنګه دوی د کوماډ څخه توپیر لري.

تر ټولو لومړی، په Kubernetes کې ترټولو بنسټیز مفهوم د پوډ مفهوم دی. پوډ د یو یا ډیرو کانټینرونو یوه ډله ده چې تل یوځای چلیږي. او دوی تل کار کوي لکه څنګه چې په یو مجازی ماشین کې سخت وي. دوی په مختلفو بندرونو کې د IP 127.0.0.1 له لارې یو بل ته د لاسرسي وړ دي.

راځئ فرض کړئ چې تاسو د PHP غوښتنلیک لرئ چې پکې شامل دي nginx او php-fpm - کلاسیک سکیم. ډیری احتمال، تاسو غواړئ دواړه نګینکس او php-fpm کانتینرونه په هر وخت کې یوځای وساتئ. Kubernetes تاسو ته اجازه درکوي چې دا د یو عام پوډ په توګه تشریح کولو سره ترلاسه کړئ. دا په حقیقت کې هغه څه دي چې موږ نشو کولی د کوچیانو سره ترلاسه کړو.

دوهم مفهوم دا دی ګمارل. حقیقت دا دی چې پوډ پخپله یو لنډمهاله شی دی؛ دا پیل کیږي او ورک کیږي. ایا تاسو غواړئ خپل ټول پخواني کانټینرونه لومړی ووژنئ، او بیا په یو وخت کې نوې نسخې پیل کړئ، یا تاسو غواړئ چې په تدریجي توګه یې وګرځوئ؟ دا تشریح کوي چې تاسو څنګه خپل پوډونه ځای په ځای کوئ، په کوم مقدار کې او څنګه یې تازه کړئ.

دریم مفهوم دی خدمت. ستاسو خدمت په حقیقت کې ستاسو سیسټم دی، کوم چې یو څه ټرافیک ترلاسه کوي او بیا یې ستاسو د خدماتو سره سم یو یا ډیرو پوډونو ته لیږدوي. دا دی، دا تاسو ته اجازه درکوي چې ووایاست چې د داسې او داسې یو خدمت ته ټول راتلونکی ټرافیک د داسې او داسې نوم سره باید دې ځانګړي پوډونو ته واستول شي. او په ورته وخت کې دا تاسو ته د ترافیک توازن چمتو کوي. دا دی، تاسو کولی شئ د خپل غوښتنلیک دوه پوډونه پیل کړئ، او ټول راتلونکی ټرافیک به په مساوي ډول د دې خدمت پورې اړوند پوډونو ترمنځ متوازن وي.

او څلورم بنسټیز مفهوم دی برید. دا یو خدمت دی چې د Kubernetes کلستر کې پرمخ ځي. دا د بهرني بار توازن کونکي په توګه کار کوي چې ټولې غوښتنې په غاړه اخلي. د Kubernetes API په کارولو سره، Ingress کولی شي معلومه کړي چې دا غوښتنې چیرته لیږل کیږي. سربیره پردې ، هغه دا خورا انعطاف منونکي کوي. تاسو کولی شئ ووایئ چې دې کوربه ته ټولې غوښتنې او داسې یو آر ایل دې خدمت ته لیږل کیږي. او دا غوښتنې چې دې کوربه ته راځي او بل URL ته بل خدمت ته لیږل کیږي.

د هغه چا له نظره ترټولو ښه شی چې غوښتنلیک رامینځته کوي دا دی چې تاسو کولی شئ دا ټول پخپله اداره کړئ. د Ingress config په ترتیب کولو سره، تاسو کولی شئ ټول ټرافيک داسې او داسې API ته واستوئ چې لیکل شوي جلا کانټینرونو ته، د بیلګې په توګه، په Go کې. مګر دا ټرافیک، ورته ډومین ته راځي، مګر یو بل یو آر ایل ته، باید په پی ایچ پی کې لیکل شوي کانټینرونو ته واستول شي، چیرته چې ډیر منطق شتون لري، مګر دوی خورا ګړندي ندي.

که موږ دا ټول مفاهیم له کوچیانو سره پرتله کړو، موږ کولی شو ووایو چې لومړی درې مفکورې ټول یوځای خدمت دي. او وروستنی مفهوم پخپله په کوچیانو کې شتون نلري. موږ د دې په څیر یو بهرنی بیلانس کاروو: دا کیدای شي هاپروکسی، نګینکس، نګینکس +، او داسې نور وي. د مکعب په حالت کې، تاسو اړتیا نلرئ دا اضافي مفهوم په جلا توګه معرفي کړئ. په هرصورت، که تاسو په داخلي توګه انګریس ته وګورئ، دا یا نګینکس، هاپروکسي، یا ټرافیک دی، مګر په کوبرنیټس کې جوړ شوی.

ټول هغه مفکورې چې ما تشریح کړې، په حقیقت کې، هغه سرچینې دي چې د Kubernetes کلستر کې شتون لري. په مکعب کې د دوی د تشریح کولو لپاره، د yaml بڼه کارول کیږي، کوم چې د Nomad په قضیه کې د HCL فایلونو څخه ډیر د لوستلو وړ او پیژندل شوی. مګر په ساختماني ډول دوی ورته شی په قضیه کې بیانوي، د بیلګې په توګه، پوډ. دوی وايي - زه غواړم چې دلته داسې او داسې پوزې ځای په ځای کړم، د داسې او داسې عکسونو سره، په دومره مقدار کې.

برسېره پر دې، موږ پوهیږو چې موږ نه غوښتل د لاس په واسطه هره انفرادي سرچینه جوړه کړو: ځای پرځای کول، خدمتونه، ننوتل، او نور. پرځای یې، موږ غوښتل چې د ګمارلو په جریان کې د کوبرنیټس په شرایطو کې زموږ هر سیسټم تشریح کړو، نو موږ به په لاسي ډول د ټولو اړینو سرچینو انحصارونه په سم ترتیب کې بیا جوړ نه کړو. هیلم د هغه سیسټم په توګه غوره شوی و چې موږ ته یې د دې کولو اجازه ورکړه.

په هیلم کې بنسټیز مفهومونه

هیلم دی د بسته بندۍ مدیر د Kubernetes لپاره. دا د پروګرام کولو ژبو کې د بسته بندي مدیران څنګه کار کوي خورا ورته دی. دوی تاسو ته اجازه درکوي چې یو خدمت ذخیره کړئ چې پکې شامل دي، د بیلګې په توګه، د ګمارنې nginx، php-fpm ځای پرځای کول، د Ingress لپاره config، configmaps (دا هغه اداره ده چې تاسو ته اجازه درکوي د خپل سیسټم لپاره env او نور پیرامیټونه تنظیم کړئ) په بڼه کې. چارټونه بلل کیږي. په ورته وخت کې هیلم د Kubernetes په سر کې تیریږي. دا دی، دا یو ډول سیسټم نه دی چې څنګ ته ولاړ دی، مګر یوازې یو بل خدمت چې د کیوب دننه پیل شوی. تاسو د دې د API له لارې د کنسول کمانډ له لارې ورسره اړیکه ونیسئ. د هغې اسانتیا او ښکلا دا ده چې حتی که هیلم مات شي یا تاسو یې له کلستر څخه لرې کړئ، ستاسو خدمتونه به ورک نشي، ځکه چې هیلم په اصل کې یوازې د سیسټم پیل کولو لپاره کار کوي. Kubernetes پخپله بیا د فعالیت او خدماتو حالت مسؤل دی.

موږ هم په دې پوه شو کينډۍ کول، کوم چې موږ دمخه په خپلو تشکیلاتو کې د جنجا په معرفي کولو سره د ځان کولو لپاره مجبور شوي یو ، د هیلم یو له اصلي ځانګړتیاو څخه دی. ټول هغه تشکیلات چې تاسو یې د خپلو سیسټمونو لپاره رامینځته کوئ په هیلم کې د ټیمپلیټونو په شکل کې زیرمه شوي ، یو څه د جنجا سره ورته دي ، مګر په حقیقت کې د ګو ژبې د ټیمپلینګ په کارولو سره ، په کوم کې چې هیلم لیکل شوی ، لکه کوبرنیټس.

هیلم زموږ لپاره یو څو نور مفکورې اضافه کوي.

چارټ - دا ستاسو د خدمت تفصیل دی. په نورو کڅوړو مدیرانو کې دا به د کڅوړې، بنډل یا ورته ورته بل شي. دلته ورته چارټ ویل کیږي.

ارزښتونه هغه متغیرونه دي چې تاسو غواړئ د ټیمپلیټونو څخه خپل تشکیلات رامینځته کولو لپاره وکاروئ.

اعلامیه. هرکله چې یو خدمت چې د هیلم په کارولو سره ځای په ځای شوی وي د خوشې کیدو زیاتیدونکي نسخه ترلاسه کوي. هیلم په یاد لري چې په تیرو خپرونو کې د خدماتو ترتیب څه و، د هغې څخه وړاندې خوشې کول، او داسې نور. له همدې امله ، که تاسو رول بیک ته اړتیا لرئ ، یوازې د هیلم کال بیک کمانډ پرمخ وړئ ، دا مخکینۍ خوشې نسخې ته په ګوته کوي. حتی که ستاسو په ذخیره کې ورته ترتیب د رول بیک په وخت کې شتون ونلري، هیلم به لاهم په یاد ولري چې دا څه وو او ستاسو سیسټم به هغه حالت ته وګرځوي چې دا په تیرو خپرونو کې و.

په هغه حالت کې چې موږ هیلم وکاروو، د کوبرنیټس لپاره منظم تشکیلات هم په ټیمپلیټونو بدلیږي چیرې چې دا ممکنه ده چې متغیرات، افعال وکاروئ، او شرطي بیانات پلي کړئ. پدې توګه تاسو کولی شئ د چاپیریال پورې اړوند خپل خدمت ترتیب راټول کړئ.

په عمل کې، موږ پریکړه وکړه چې شیان د کوچیانو په پرتله لږ توپیر سره ترسره کړو. که په Nomad کې دواړه د ګمارنې ترتیب او n- متغیرات چې زموږ د خدماتو پلي کولو لپاره اړین وو په یوه ذخیره کې زیرمه شوي ، دلته موږ پریکړه کړې چې دوی په دوه جلا ذخیره کې وویشو. د "ګمارلو" ذخیره یوازې د ځای پرځای کولو لپاره اړین n- متغیرات ذخیره کوي ، او د "هیلم" ذخیره ترتیبونه یا چارټونه ذخیره کوي.

دې موږ ته څه راکړل؟

د دې حقیقت سره سره چې موږ پخپله د تشکیلاتو فایلونو کې هیڅ واقعیا حساس معلومات نه ذخیره کوو. د مثال په توګه، ډیټابیس ته پاسورډونه. دوی په کوبرنیټس کې د رازونو په توګه زیرمه شوي ، مګر سره له دې ، لاهم دلته ځینې شیان شتون لري چې موږ نه غواړو هرڅوک ته لاسرسی ورکړو. له همدې امله، د "ځای پرځای کولو" ذخیره ته لاسرسی ډیر محدود دی، او د "هیلم" ذخیره په ساده ډول د خدماتو توضیحات لري. د دې دلیل لپاره، دا د ډیرو خلکو لخوا په خوندي توګه لاسرسی کیدی شي.

له هغه ځایه چې موږ نه یوازې تولید لرو ، بلکه نور چاپیریالونه هم لرو ، د دې جلا کیدو څخه مننه موږ کولی شو خپل هیلم چارټونه بیا وکاروو ترڅو خدمات نه یوازې تولید ته ځای په ځای کړو ، بلکه د مثال په توګه ، د QA چاپیریال ته هم. حتی د دوی په ځایی توګه د کارولو لپاره ځای پرځای کول مینیکیوب - دا په ځایی توګه د کوبرنیټس چلولو لپاره یو شی دی.

د هر ذخیره کې دننه، موږ د هر خدمت لپاره په جلا لارښودونو کې یوه څانګه پریښوده. دا دی، د هرې ډایرکټر دننه د اړوند چارټ پورې اړوند ټیمپلیټونه شتون لري او هغه سرچینې تشریح کوي چې زموږ د سیسټم پیل کولو لپاره ځای پرځای کولو ته اړتیا لري. موږ یوازې د "ځای پرځای کولو" ذخیره کې envs پریښود. په دې حالت کې، موږ د جینجا په کارولو سره ټیمپلینګ نه کاروو، ځکه چې هیلم پخپله د بکس څخه بهر ټیمپلینګ چمتو کوي - دا یو له اصلي دندو څخه دی.

موږ د پلي کولو سکریپټ پریښود - deploy.sh، کوم چې د هیلم په کارولو سره د ځای پرځای کولو لپاره لانچ ساده او معیاري کوي. نو، د هر هغه چا لپاره چې غواړي ځای په ځای کړي، د ګمارنې انٹرفیس په سمه توګه ورته ښکاري لکه څنګه چې د کوماډ له لارې ګمارل شوي. ورته deploy.sh، ستاسو د خدمت نوم، او چیرې چې تاسو غواړئ دا ځای په ځای کړئ. دا د دې لامل کیږي چې هیلم په داخلي توګه پیل شي. دا، په بدل کې، د ټیمپلیټونو څخه تشکیلات راټولوي، د اړین ارزښتونو فایلونه په دوی کې داخلوي، بیا یې ځای پرځای کوي، په Kubernetes کې یې پیلوي.

موندنو

د کوبرنیټس خدمت د کوماډ په پرتله خورا پیچلی ښکاري.

دلته بهر روان ترافیک انګریس ته راځي. دا یوازې مخکښ کنټرولر دی ، کوم چې ټولې غوښتنې په غاړه اخلي او وروسته یې د غوښتنې ډیټا سره مطابقت خدماتو ته لیږي. دا دوی د تشکیلاتو پراساس ټاکي چې په هیلم کې ستاسو د غوښتنلیک توضیحاتو برخه ده او کوم پراختیا کونکي پخپله تنظیم کوي. خدمت خپلو پوډونو ته غوښتنې لیږي ، یعني ځانګړي کانټینرونه ، د ټولو کانټینرونو ترمینځ د راتلونکي ترافیک توازن کول چې پدې خدمت پورې اړه لري. او البته، موږ باید هیر نکړو چې موږ باید د شبکې په کچه د امنیت څخه هیڅ ځای ته لاړ نه شو. له همدې امله، قطع کول په Kubernetes کلستر کې کار کوي، کوم چې د ټګ کولو پر بنسټ والړ دی. ټول خدمتونه ځانګړي ټاګونه لري چې د کلستر دننه یا بهر ځینې بهرني / داخلي سرچینو ته د خدماتو لاسرسي حقونه تړاو لري.

لکه څنګه چې موږ لیږد وکړ، موږ ولیدل چې کوبرنیټس د کومار ټول وړتیاوې درلودې، کوم چې موږ مخکې کارولي وو، او ډیری نوي شیان یې هم اضافه کړل. دا د پلگ انونو له لارې پراخ کیدی شي، او په حقیقت کې د دودیز سرچینو ډولونو له لارې. دا دی ، تاسو فرصت لرئ نه یوازې هغه څه وکاروئ چې د بکس څخه بهر د کوبرنیټس سره راځي ، مګر خپله سرچینه او خدمت رامینځته کړئ چې ستاسو سرچینه به ولولي. دا تاسو ته اضافي اختیارونه درکوي خپل سیسټم پراخ کړئ پرته لدې چې د کوبرنیټس له سره نصب کړئ او پرته له تعدیلاتو ته اړتیا ولرئ.

د دې ډول کارونې یوه بیلګه پرومیتیس دی ، کوم چې زموږ د کوبرنیټس کلستر دننه تیریږي. د دې لپاره چې دا د یو ځانګړي خدمت څخه د میټریکونو راټولول پیل کړي ، موږ اړتیا لرو د خدماتو توضیحاتو ته د اضافي ډول سرچینې ، تش په نامه خدمت مانیټر اضافه کړو. پرومیتیوس، د دې حقیقت له امله چې دا کولی شي د دودیز سرچینې ډول ولولي کله چې په کوبرنیټس کې پیل شي، په اتوماتيک ډول د نوي سیسټم څخه د میټریکونو راټولول پیل کوي. دا خورا اسانه ده.

لومړی ګمارنه چې موږ کبرنیټس ته کړې وه د مارچ په 2018 کې وه. او د دې وخت په جریان کې موږ هیڅکله د دې سره کومه ستونزه تجربه نه کړه. دا د پام وړ بګ پرته په کافي اندازه کار کوي. سربیره پردې ، موږ کولی شو دا نور هم پراخه کړو. نن ورځ موږ کافي ظرفیتونه لرو چې دا یې لري، او موږ واقعیا د کوبرنیټس د پرمختګ سرعت خوښوو. اوس مهال، له 3000 څخه ډیر کانټینرونه په کبرنیټس کې دي. کلستر څو نوډونه نیسي. په ورته وخت کې، دا د خدمت وړ، باثباته او خورا کنټرول وړ دی.

سرچینه: www.habr.com