دا یو څه په تاریخي ډول پیښ شوي چې د معلوماتي ټیکنالوژۍ صنعت ، د هر دلیل لپاره ، په دوه مشروط کمپونو ویشل شوی: هغه څوک چې د "لپاره" دي او هغه څوک چې "مخالف" دي. سربیره پردې، د شخړو موضوع کیدای شي په بشپړه توګه خپل سري وي. کوم OS غوره دی: وین یا لینکس؟ په Android یا iOS سمارټ فون کې؟ هرڅه په بادلونو کې ذخیره کړئ یا دا په سړه RAID ذخیره کې اپلوډ کړئ او پیچونه په خوندي کې واچوئ؟ ایا PHP-shniks حق لري چې د پروګرامرانو په نوم یاد شي؟ دا شخړې په ځینو وختونو کې یوازې په طبیعت کې شتون لري او د سپورت ګټو پرته بل اساس نلري.
دا یوازې داسې پیښ شوي چې د کانټینرونو په راتګ سره او دا ټول پخلنځي موږ د ډاکر او مشروط k8s سره مینه لرو ، د پس منظر په بیلابیلو برخو کې د نوي ب featuresو کارول د "لپاره" او "خلاف" شخړې پیل شوې. (راځئ چې مخکې له مخکې ریزرویشن وکړو چې که څه هم په دې بحث کې به اکثرا کوبرنیټس د آرکیسټریټ په توګه اشاره کیږي، د دې ځانګړي وسیلې انتخاب بنسټیز اهمیت لري. پرځای یې، تاسو کولی شئ کوم بل ځای ونیسئ چې تاسو ته خورا مناسب او پیژندل شوی وي.)
او، داسې ښکاري چې دا به د ورته سکې د دوو اړخونو ترمنځ یوه ساده شخړه وي. د وین vs لینکس ترمینځ د ابدي ټکر په څیر بې حسه او بې رحمه ، په کوم کې چې کافي خلک په مینځ کې شتون لري. مګر د کانټینر کولو په حالت کې، هرڅه دومره ساده ندي. معمولا په دې ډول شخړو کې هیڅ ښي اړخ شتون نلري، مګر د ډیټابیس کانټینرونو "استعمال" یا "نه کارولو" په صورت کې، هرڅه پورته کیږي. ځکه چې په یوه معنې کې د دې تګلارې ملاتړي او مخالفین دواړه په حقه دي.
روښانه اړخ
تاسو کولی شئ په لنډه توګه د رڼا اړخ دلیل د یوې جملې سره تشریح کړئ: "سلام، 2k19 د کړکۍ څخه بهر دی!" البته دا د پاپولیزم په څیر ښکاري ، مګر که تاسو وضعیت په تفصیل سره وڅیړئ ، دا خپلې ګټې لري. راځئ چې اوس دوی ته یو نظر وکړو.
راځئ چې ووایو تاسو یوه لویه ویب پروژه لرئ. دا په پیل کې د مایکرو سرویس تګلارې پراساس رامینځته کیدی شي ، یا په یو وخت کې دا په ارتقایی لاره کې راغلی - دا واقعیا خورا مهم ندي. تاسو زموږ پروژه په جلا مایکرو خدماتو ویشلې، آرکیسټریشن تنظیم کړئ، د بار توازن، او اندازه کول. او اوس، د روښانه وجدان سره، تاسو د زوال سرورونو د پورته کولو پر ځای د هابرا اغیزو په جریان کې موجیتوس په هاماک کې وخورئ. مګر په ټولو کړنو کې تاسو باید مطابقت ولرئ. ډیری وختونه، یوازې غوښتنلیک پخپله کانټینر شوی دی - کوډ. موږ د کوډ پرته نور څه لرو؟
دا سمه ده، ډاټا. د هرې پروژې زړه د هغې ډاټا دي: دا یا هم یو عادي DBMS - MySQL، Postgre، MongoDB، یا د لټون (ElasticSearch) لپاره کارول شوي ذخیره وي، د کیچ کولو لپاره د کلیدي ارزښت ذخیره - د بیلګې په توګه، redis، او نور. اوس موږ نه یو. موږ به د کریډ بیک اینډ پلي کولو اختیارونو په اړه وغږیږو کله چې ډیټابیس د خراب لیکلو پوښتنو له امله خرابیږي ، مګر پرځای به موږ د پیرودونکي بار لاندې د دې ډیټابیس د غلطۍ زغم ډاډ ترلاسه کولو په اړه وغږیږو. په هرصورت، کله چې موږ خپل غوښتنلیک کانټینر کړئ او دا اجازه ورکوو چې په آزاده توګه د هر ډول راتلونکو غوښتنو اداره کولو لپاره اندازه کړو، دا په طبیعي توګه په ډیټابیس کې بار زیاتوي.
په حقیقت کې ، د ډیټابیس لاسرسي چینل او سرور چې دا پرمخ ځي زموږ په ښکلي کانټینر شوي پس منظر کې د ستنې سترګې بدلیږي. په ورته وخت کې ، د کانټینر مجازی کولو اصلي انګیزه د جوړښت تحرک او پلاستیکي ده ، کوم چې دا امکان رامینځته کوي چې موږ ته د امکان تر حده مؤثره ټول زیربنا باندې د لوړ بار توزیع تنظیم کړو. دا دی، که موږ د ټول کلستر په اوږدو کې د سیسټم ټول موجود عناصر کانټینریز او رول ونلرو، موږ ډیره جدي تېروتنه کوو.
دا د کلستر کولو لپاره خورا منطقي دی نه یوازې پخپله غوښتنلیک ، بلکه د معلوماتو ذخیره کولو لپاره مسؤل خدمات هم. کله چې په k8s کې د ویب سرورونو بار په خپلواکه توګه کار کول او توزیع کول او توزیع کول ، موږ دمخه د ډیټا ترکیب کولو ستونزه حل کوو - په پوسټونو کې ورته تبصرې ، که موږ ځینې رسنۍ یا د بلاګ کولو پلیټ فارم د مثال په توګه حواله کړو. په هر حالت کې، موږ یو داخلي کلستر لرو، حتی که مجازی وي، د ډیټابیس استازیتوب د بهرنی خدمت په توګه. پوښتنه دا ده چې ډیټابیس پخپله لا تر اوسه کلستر شوی نه دی - په کیوب کې ګمارل شوي ویب سرورونه زموږ د جامد جنګي بیس څخه د بدلونونو په اړه معلومات اخلي، کوم چې په جلا توګه سپن کوي.
ایا تاسو یو چال احساس کوئ؟ موږ د بار توازن کولو او د اصلي ویب سرور د خرابیدو څخه مخنیوي لپاره k8s یا Swarm کاروو ، مګر موږ دا د ډیټابیس لپاره نه کوو. مګر له هرڅه وروسته، که ډیټابیس راټیټ شي، نو زموږ په ټول کلستر شوي زیربنا کې هیڅ معنی نشته - د خالي ویب پاڼو کارول څه دي چې ډیټابیس ته د لاسرسۍ یوه تېروتنه بیرته راولي؟
له همدې امله دا اړینه ده چې نه یوازې د ویب سرورونو کلستر کړئ، لکه څنګه چې معمولا ترسره کیږي، بلکې د ډیټابیس زیربنا هم. یوازې پدې توګه موږ کولی شو داسې جوړښت چمتو کړو چې په بشپړ ډول په یوه ټیم کې کار کوي، مګر په ورته وخت کې له یو بل څخه خپلواک وي. په ورته وخت کې، حتی که زموږ د شالید نیمایي برخه "نړیدلي" د بار لاندې وي، پاتې به ژوندي پاتې شي، او د کلستر دننه د ډیټابیس همغږي کولو سیسټم او د لامحدود اندازه کولو او نوي کلسترونو پلي کولو امکان به د اړتیا په چټکتیا سره مرسته وکړي. ظرفیتونه - د معلوماتو په مرکز کې به ریکونه وي.
برسېره پردې، په کلسترونو کې ویشل شوي ډیټابیس ماډل تاسو ته اجازه درکوي چې دا ډیټابیس چیرته چې اړتیا وي؛ که موږ د نړیوال خدماتو په اړه وغږیږو ، نو دا غیر منطقي ده چې د سان فرانسسکو په ساحه کې یو ځای د ویب کلستر سپن کړئ او په ورته وخت کې د ډیټابیس په شا او خوا کې ډیټابیس ته د لاسرسي په وخت کې کڅوړې چل کړئ.
همچنان ، د ډیټابیس کانټینر کول تاسو ته اجازه درکوي د سیسټم ټول عناصر د خلاصون په ورته کچه رامینځته کړئ. کوم چې، په بدل کې، دا ممکنه کوي چې دا سیسټم په مستقیم ډول د کوډ څخه، د پراختیا کونکو لخوا، د مدیرانو فعال ښکیلتیا پرته اداره کړي. پراختیا کونکو فکر کاوه چې دوی د نوي فرعي پروژې لپاره جلا DBMS ته اړتیا لري - اسانه! د yaml فایل لیکلی، دا کلستر ته اپلوډ کړی او تاسو بشپړ شوی.
ښه، البته، داخلي عملیات په ځینو وختونو کې ساده کیږي. ما ته ووایاست، کله چې د ټیم نوي غړي خپل لاسونه په کار کې جنګي ډیټابیس ته واچول، تاسو څو ځله سترګې پټې کړې؟ تاسو کوم یو لرئ، په حقیقت کې، یو او همدا اوس څرخي؟ البته، موږ دلته ټول لویان یو، او په کوم ځای کې موږ تازه بیک اپ لرو، او حتی نور هم لرې - د انا د ککریو او زړو سکیونو سره د المارۍ شاته - یو بل بیک اپ، شاید حتی په سړه خونه کې، ځکه چې یو وخت ستاسو دفتر اور لګیدلی و. مګر په هرصورت، د نوي ټیم غړي هر پیژندنه چې جنګي زیربنا ته لاسرسۍ لري او البته، د جګړې ډیټابیس ته د شاوخوا هرچا لپاره د اعتبار وړ بالټ دی. ښه، هغه څوک پیژني، یو نوی راغلی، شاید هغه په لاس کې وي؟ ډارونکی، موافق.
کانټینر کول او په حقیقت کې ستاسو د پروژې ډیټابیس توزیع شوي فزیکي ټوپولوژي د داسې معتبر شیبو څخه مخنیوي کې مرسته کوي. په نوي ځوان باور نه کوئ؟ سمه ده! موږ به خپل کلستر پورته کړو ترڅو دا کار وکړي او دا د ډیټابیس له پاتې کلسترونو څخه جلا کړو - یوازې د لاسي فشار او د دوه کیليونو همغږي کولو سره همغږي کول (یو د ټیم مشر لپاره ، دوهم د مدیر لپاره). او هرڅوک خوشحاله دي.
او اوس دا وخت دی چې د ډیټابیس کلسترینګ مخالفینو ته بدل شي.
تیاره اړخ
په دې بحث کول چې ولې دا د ډیټابیس کانټینر کولو ارزښت نلري او په یو مرکزي سرور کې یې سپن کولو ته دوام ورکوي ، موږ به د ارتودوکس بیاناتو او بیاناتو ته مخه ونکړو لکه "نیکا په هارډویر کې ډیټابیس چلوي ، او موږ به یې!" پرځای یې، راځئ هڅه وکړو چې د داسې وضعیت سره مخ شو چې په کوم کې کانټینر کول به واقعیا د پام وړ ګټې راوړي.
موافقه وکړئ، هغه پروژې چې واقعیا په کانټینر کې اډې ته اړتیا لري د یو لاس په ګوتو کې د غوره ملنګ ماشین نه شمیرل کیدی شي. د ډیری برخې لپاره ، حتی د k8s یا Docker Swarm کارول پخپله بې کاره دي - ډیری وختونه دا وسیلې د ټیکنالوژیو عمومي لوړتیا او د جنرونو په مقابل کې د "الله تعالی" چلند له امله کارول کیږي ترڅو هرڅه بادونو ته واړوي او کانتینرونه ښه، ځکه چې اوس دا فیشن دی او هرڅوک یې کوي.
لږترلږه په نیمایي قضیو کې ، په پروژه کې د کبرنیټس یا یوازې ډاکر کارول بې ځایه دي. مسله دا ده چې ټول ټیمونه یا د آؤټ سورسنګ شرکتونه چې د پیرودونکي زیربنا ساتلو لپاره ګمارل شوي پدې نه پوهیږي. بدتر - کله چې کانټینرونه لګول کیږي، ځکه چې دا پیرودونکي ته یو ټاکلی اندازه سکې لګښت کوي.
په عموم کې، داسې نظر شتون لري چې ډاکر / مافیا مکعب په احمقانه توګه هغه پیرودونکي ماتوي چې دا زیربنا مسلې بهر کوي. په حقیقت کې، د کلسترونو سره کار کولو لپاره، انجینرانو ته اړتیا ده چې د دې وړتیا ولري او په عمومي توګه د پلي شوي حل په جوړښت پوه شي. موږ یو څه دمخه زموږ قضیه د جمهوري نسخې سره بیان کړې - هلته موږ د پیرودونکي ټیم روزلی ترڅو د کبرنیټس واقعیتونو کې کار وکړي ، او هرڅوک راضي وو. او دا ښه وه. ډیری وختونه، د k8s "تطبیق کونکي" د پیرودونکي زیربنا یرغمل نیسي - په هرصورت، اوس یوازې دوی پوهیږي چې هر څه څنګه کار کوي، د پیرودونکي اړخ کې هیڅ متخصص شتون نلري.
اوس تصور وکړئ چې پدې توګه موږ نه یوازې د ویب سرور برخه آؤټ سورس کولو ته ورکوو ، بلکه د ډیټابیس ساتنه هم کوو. موږ وایو چې ډیټابیس زړه دی او د زړه له لاسه ورکول د هر ژوندي موجود لپاره وژونکي دي. په لنډه توګه، امکانات غوره ندي. نو، د هایپ کبرنیټیس پرځای، ډیری پروژې باید د عادي AWS تعرفې لپاره لاړ نشي، کوم چې به د دوی په سایټ / پروژې کې د بار سره ټولې ستونزې حل کړي. مګر AWS نور فیشن نه دی، او نندارې د پیسو په پرتله خورا ګران دي - له بده مرغه، د معلوماتي ټکنالوجۍ په چاپیریال کې هم.
سمه ده. شاید پروژه واقعیا کلستر کولو ته اړتیا ولري ، مګر که هرڅه د بې ریاست غوښتنلیکونو سره روښانه وي ، نو بیا څنګه د کلستر شوي ډیټابیس لپاره د ښه شبکې ارتباط تنظیم کړئ؟
که موږ د بې سیمه انجینري حل په اړه وغږیږو ، کوم چې k8s ته لیږد دی ، نو زموږ اصلي سر درد په کلستر شوي ډیټابیس کې د ډیټا نقل کول دي. ځینې DBMS په پیل کې د دوی د انفرادي مثالونو ترمینځ د معلوماتو ویش ته خورا وفادار دي. ډیری نور ډیر ښه راغلاست نه دي. او ډیری وختونه زموږ د پروژې لپاره د DBMS غوره کولو اصلي دلیل په هیڅ ډول د لږترلږه سرچینو او انجینرۍ لګښتونو سره د نقل کولو وړتیا نلري. په ځانګړې توګه که چیرې پروژه په اصل کې د مایکرو سرویس په توګه نه وه پلان شوې، مګر په ساده ډول په دې لوري کې وده شوې.
موږ فکر کوو چې د شبکې ډرایو سرعت په اړه خبرې کولو ته اړتیا نشته - دوی ورو دي. هغوی. موږ لاهم ریښتیني فرصت نلرو ، پدې حالت کې ، د DBMS مثال په کوم ځای کې بیا راپورته کړو ، چیرې چې د مثال په توګه ، د پروسیسر ډیر ځواک یا وړیا رام شتون لري. موږ به ډیر ژر د مجازی ډیسک فرعي سیسټم فعالیت ته ورسیږو. په دې اساس، DBMS باید په نږدې وخت کې د خپل شخصي ماشینونو سیټ ته کیښودل شي. یا دا اړینه ده چې په یو څه ډول د اټکل شوي زیرمو لپاره د معلوماتو کافي ګړندي همغږي جلا کړئ.
د مجازی FS موضوع ته دوام ورکول: د ډاکر حجمونه، له بده مرغه، له ستونزې څخه پاک ندي. په عموم کې ، په داسې حالت کې د اوږدې مودې معتبر ډیټا ذخیره کول ، زه غواړم د ساده تخنیکي سکیمونو سره ترلاسه کړم. او د کانټینر FS څخه د اصلي کوربه FS ته د خلاصون نوې پرت اضافه کول پخپله یو خطر دی. مګر کله چې حتی د کانټینر کولو سیسټم په کار کې د دې پرتونو ترمینځ د معلوماتو ژباړلو کې ستونزې شتون ولري ، نو دا واقعیا یو ناورین دی. په اوس وخت کې، د پرمختللو انسانانو لپاره پیژندل شوي ډیری ستونزې له منځه تللي ښکاري. مګر تاسو پخپله پوهیږئ، څومره چې میکانیزم پیچلي وي، په اسانۍ سره ماتیږي.
د دې ټولو "مشاعرو" په رڼا کې، دا خورا ګټور او اسانه دی چې ډیټابیس په یو ځای کې وساتئ، او حتی که تاسو اړتیا لرئ چې غوښتنلیک کانټینر کړئ، اجازه راکړئ چې دا پخپله وګرځوئ او د ډیټابیس سره یوځای اړیکه ترلاسه کړئ. د ویشلو دروازه، کوم چې به یوازې یو ځل لوستل او لیکل کیږي او په یو ځای کې. دا طریقه لږترلږه د غلطیو او غیر همغږي کیدو احتمال کموي.
موږ د څه په لور روان یو؟ سربیره پردې ، د ډیټابیس کانټینر کول مناسب دي چیرې چې واقعیا ورته اړتیا وي. تاسو نشئ کولی د بشپړ اپلیکیشن اډه وخورئ او دا سپن کړئ لکه تاسو دوه درجن مایکرو خدمتونه لرئ - دا پدې ډول کار نه کوي. او دا باید په واضح ډول پوه شي.
د تولید پر ځای
که تاسو د روښانه پایلې په تمه یاست "د ډیټابیس مجازی کول یا نه"، نو موږ بخښنه غواړو: دا به دلته نه وي. ځکه چې کله د زیربنا حل رامینځته کول ، یو څوک باید د فیشن او پرمختګ لخوا نه لارښود شي ، بلکه لومړی د عقل لخوا.
داسې پروژې شتون لري چې اصول او وسیلې چې د کبرنیټس سره راځي په بشپړ ډول فټ کوي، او په داسې پروژو کې سوله لږ تر لږه په شاته سیمه کې راځي. او داسې پروژې شتون لري چې کانټینر کولو ته اړتیا نلري ، مګر د نورمال سرور زیربنا ته اړتیا لري ، ځکه چې دوی اساسا نشي کولی د مایکرو سرویس کلستر ماډل ته بیرته راګرځي ، ځکه چې دوی به سقوط وکړي.
سرچینه: www.habr.com