Қалай болғанда да, тарихи тұрғыдан алғанда, IT-индустрия кез келген себеппен екі шартты лагерьге бөлінген: «жақтағандар» және «қарсы» болғандар. Оның үстіне, даулардың тақырыбы толығымен ерікті болуы мүмкін. Қай операциялық жүйе жақсы: Win немесе Linux? Android немесе iOS смартфонында ма? Барлығын бұлттарда сақтау керек пе, әлде салқын RAID қоймасына салып, бұрандаларды сейфке салу керек пе? РНР адамдарының бағдарламашы деп аталу құқығы бар ма? Бұл даулар кейде тек қана экзистенциалды сипатта болады және спорттық қызығушылықтан басқа негізі жоқ.
Контейнерлердің пайда болуымен және докер және шартты k8s бар осы сүйікті асхананың пайда болуымен бэкендтің әртүрлі салаларында жаңа мүмкіндіктерді пайдалануға «жақтау» және «қарсы» пікірталастары басталды. (Алдын ала ескертейік, бұл талқылауда Кубернетес көбінесе оркестр ретінде көрсетілсе де, бұл арнайы құралды таңдау маңызды емес. Оның орнына сіз өзіңізге ыңғайлы және таныс болып көрінетін кез келген басқасын ауыстыра аласыз. .)
Бұл бір тиынның екі жағы арасындағы қарапайым дау болар еді. Ортасында лайықты адамдар бар Win пен Linux арасындағы мәңгілік текетірес сияқты мағынасыз және аяусыз. Бірақ контейнерлік жағдайда бәрі оңай емес. Әдетте мұндай дауларда оң жақ болмайды, бірақ дерекқорды сақтауға арналған контейнерлерді «пайдалану» немесе «пайдаланбау» жағдайында бәрі төңкеріледі. Өйткені белгілі бір мағынада бұл тәсілді жақтаушылар да, қарсылар да дұрыс.
Жарқын жақ
Жарық жағының дәлелін бір сөзбен қысқаша сипаттауға болады: «Сәлеметсіз бе, 2k19 терезенің сыртында!» Бұл популизм сияқты естіледі, әрине, бірақ жағдайға егжей-тегжейлі үңілсеңіз, оның жақсы жақтары бар. Енді оларды сұрыптайық.
Сізде үлкен веб-жоба бар делік. Ол бастапқыда микросервис тәсілінің негізінде салынуы мүмкін еді, немесе бір сәтте ол эволюциялық жолмен келді - бұл өте маңызды емес, шын мәнінде. Сіз біздің жобаны бөлек микросервистерге тараттыңыз, оркестрлеуді, жүктемені теңестіруді және масштабтауды орнаттыңыз. Ал енді, таза ар-ұжданмен сіз құлаған серверлерді көтерудің орнына хабра эффектілері кезінде гамакта мохито жұтып отырсыз. Бірақ сіз барлық әрекеттерде дәйекті болуыңыз керек. Көбінесе, тек қолданбаның өзі — код — контейнерде болады. Бізде кодтан басқа не бар?
Дұрыс, деректер. Кез келген жобаның жүрегі оның деректері болып табылады: бұл әдеттегі ДҚБЖ – MySQL, Postgre, MongoDB немесе іздеу үшін пайдаланылатын жад (ElasticSearch), кэштеу үшін кілттер-мәнді сақтау орны – мысалы, redis және т.б. болуы мүмкін. Қазіргі уақытта біз бұлай емеспіз. нашар жазылған сұрауларға байланысты дерекқор бұзылған кезде қисық серверді іске асыру опциялары туралы сөйлесетін боламыз және оның орнына клиент жүктемесі кезінде дәл осы дерекқордың ақауларға төзімділігін қамтамасыз ету туралы айтатын боламыз. Ақыр соңында, біз қолданбамызды контейнерге салсақ және оған кіріс сұраулардың кез келген санын өңдеу үшін еркін масштабтауға рұқсат етсек, бұл дерекқордағы жүктемені табиғи түрде арттырады.
Шын мәнінде, дерекқорға қол жеткізу арнасы және ол жұмыс істейтін сервер біздің әдемі контейнерлік сервердегі иненің көзі болады. Сонымен қатар, контейнерлік виртуализацияның негізгі мотиві құрылымның ұтқырлығы мен икемділігі болып табылады, бұл бізге қол жетімді барлық инфрақұрылым бойынша ең жоғары жүктемелерді бөлуді мүмкіндігінше тиімді ұйымдастыруға мүмкіндік береді. Яғни, жүйенің барлық бар элементтерін кластер бойынша контейнерге салмасақ және таратпасақ, біз өте күрделі қателік жасаймыз.
Қолданбаның өзін ғана емес, деректерді сақтауға жауапты қызметтерді де кластерлеу әлдеқайда қисынды. K8-де дербес жұмыс істейтін және жүктемені бір-біріне тарататын веб-серверлерді кластерлеу және орналастыру арқылы біз деректерді синхрондау мәселесін шешіп жатырмыз - егер мысал ретінде кейбір медиа немесе блог платформасын алсақ, жазбалардағы бірдей пікірлер. Кез келген жағдайда бізде дерекқордың ExternalService ретінде кластер ішіндегі, тіпті виртуалды көрінісі бар. Мәселе мынада, дерекқордың өзі әлі кластерленбеген - текшеде орналастырылған веб-серверлер жеке айналатын тұрақты жауынгерлік дерекқорымыздан өзгерістер туралы ақпаратты алады.
Сіз ұстап алғаныңызды сезесіз бе? Жүктемені тарату және негізгі веб-серверді бұзбау үшін k8s немесе Swarm пайдаланамыз, бірақ біз мұны дерекқор үшін жасамаймыз. Бірақ егер дерекқор бұзылса, онда біздің бүкіл кластерлік инфрақұрылымымыздың мағынасы жоқ - дерекқорға кіру қатесін қайтаратын бос веб-беттердің не пайдасы бар?
Сондықтан әдеттегідей тек веб-серверлерді ғана емес, сонымен қатар деректер қорының инфрақұрылымын да кластерлеу қажет. Тек осылай ғана біз бір командада толық жұмыс істейтін, бірақ сонымен бірге бір-бірінен тәуелсіз құрылымды қамтамасыз ете аламыз. Сонымен қатар, егер біздің серверіміздің жартысы жүктеме кезінде «құласа» да, қалғандары аман қалады, ал кластердегі дерекқорларды бір-бірімен синхрондау жүйесі және жаңа кластерлерді шексіз масштабтау және орналастыру мүмкіндігі қажетті сыйымдылыққа тез жетуге көмектеседі - егер деректер орталығында тіректер болса.
Сонымен қатар, кластерлерде таратылған деректер базасының үлгісі дәл осы дерекқорды қажет жерге апаруға мүмкіндік береді; Егер біз жаһандық қызмет туралы айтатын болсақ, онда Сан-Франциско аймағындағы бір жерде веб-кластерді айналдыру және сонымен бірге Мәскеу аймағындағы және кері дерекқорға кіру кезінде пакеттерді жіберу қисынсыз.
Сондай-ақ дерекқорды контейнерлеу жүйенің барлық элементтерін абстракцияның бірдей деңгейінде құруға мүмкіндік береді. Бұл, өз кезегінде, әкімшілердің белсенді қатысуынсыз осы жүйені тікелей кодтан әзірлеушілер арқылы басқаруға мүмкіндік береді. Әзірлеушілер жаңа қосалқы жоба үшін жеке ДҚБЖ қажет деп ойлады - оңай! yaml файлын жазды, оны кластерге жүктеп салды және сіз аяқтадыңыз.
Және, әрине, ішкі жұмыс айтарлықтай жеңілдетілген. Айтыңызшы, команданың жаңа мүшесі жұмысқа қолдарын жауынгерлік деректер базасына салғанда, сіз қанша рет көзіңізді жұмыдыңыз? Шын мәнінде, сізде бар және дәл қазір айналатын жалғыз қайсысы? Әрине, біз мұнда бәріміз ересекпіз, және бір жерде бізде жаңа резерв бар, тіпті одан да алыс - әженің қиярлары мен ескі шаңғылары бар сөренің артында - тағы бір резервтік көшірме, мүмкін тіпті салқындатқышта, өйткені сіздің кеңсеңіз бір кездері өртеніп кеткен. Дегенмен, жауынгерлік инфрақұрылымға және, әрине, жауынгерлік деректер базасына қол жеткізе алатын жаңа команда мүшесінің әрбір енгізілуі айналадағылардың барлығы үшін валидол шелек болып табылады. Оны кім біледі, жаңадан келген адам, мүмкін ол айқас болған шығар? Бұл қорқынышты, сіз келісесіз.
Контейнерлеу және, шын мәнінде, жобаңыздың дерекқорының бөлінген физикалық топологиясы мұндай тексеру сәттерін болдырмауға көмектеседі. Жаңадан келген адамға сенбейсіз бе? ЖАРАЙДЫ МА! Оған жұмыс істеу және басқа кластерлерден дерекқорды ажырату үшін өз кластерін берейік - тек қолмен басу және екі пернені синхронды айналдыру арқылы синхрондау (біреуі топ жетекшісі үшін, екіншісі әкімші үшін). Және бәрі бақытты.
Енді дерекқорды кластерлеудің қарсыластарына ауысатын кез келді.
Қараңғы жағы
Неліктен дерекқорды контейнерлеуге және оны бір орталық серверде жұмыс істеуді жалғастыруға тұрарлық емес екенін дәлелдей отырып, біз православиелердің риторикасына және «бабалар дерекқорларды аппараттық құралда басқарған, біз де солай істейміз!» сияқты мәлімдемелерге көнбейміз. Оның орнына контейнерлеу нақты дивидендтер беретін жағдайды ойлап көрейік.
Келісіңіз, контейнерде негізді қажет ететін жобаларды ең жақсы фрезерлік станокшы емес, бір қолмен санай алады. Көбінесе, тіпті k8s немесе Docker Swarm-ді пайдаланудың өзі артық - бұл құралдар көбінесе технологиялардың жалпы дүрбелеңіне және жыныстағы «құдіретті Құдайдың» барлығын итермелеуіне байланысты қолданылады. бұлттар мен контейнерлер. Өйткені, қазір бұл сәнді және оны бәрі жасайды.
Жағдайлардың кем дегенде жартысында жобада Kubernetis немесе жай ғана Docker пайдалану артық. Мәселе мынада, бұл туралы клиенттің инфрақұрылымын қолдау үшін жалданған барлық командалар немесе аутсорсингтік компаниялар біле бермейді. Контейнерлер салынған кезде бұл нашар, өйткені ол клиентке белгілі бір монеталардың құнына түседі.
Тұтастай алғанда, докер/куб мафиясы осы инфрақұрылымдық мәселелерді аутсорсингке жіберетін клиенттерді ақымақтықпен қиратады деген пікір бар. Өйткені, кластерлермен жұмыс істеу үшін бізге бұған қабілетті және жалпы қабылданған шешімнің архитектурасын түсінетін инженерлер қажет. Біз бір кездері Республика басылымымен өз ісімізді сипаттаған болатынбыз - сонда біз клиент командасын Кубернетистің шынайылығында жұмыс істеуге үйреттік және барлығы риза болды. Және бұл лайықты болды. Көбінесе k8s «іске асырушылары» клиенттің инфрақұрылымын кепілге алады - өйткені қазір олар бәрі қалай жұмыс істейтінін түсінеді, клиент жағында мамандар жоқ.
Енді елестетіп көріңізші, осылайша біз веб-сервер бөлігін ғана емес, сонымен қатар дерекқорға техникалық қызмет көрсетуді де аутсорсингке аламыз. БД жүрек, ал жүректің жоғалуы кез келген тірі ағза үшін өлімге әкелетінін айттық. Бір сөзбен айтқанда, перспективалар жақсы емес. Сонымен, Kubernetis-ті дүрліктірудің орнына, көптеген жобалар AWS үшін қалыпты тарифпен алаңдамауы керек, бұл олардың сайтындағы/жобасындағы жүктемемен байланысты барлық мәселелерді шешеді. Бірақ AWS енді сәнді емес, ал шоулар ақшадан да қымбат - өкінішке орай, IT ортасында да.
ЖАРАЙДЫ МА. Мүмкін, жоба шынымен кластерлеуді қажет етеді, бірақ азаматтығы жоқ қолданбалармен бәрі түсінікті болса, кластерленген дерекқор үшін лайықты желілік қосылымды қалай ұйымдастыруға болады?
Егер біз k8s-ке көшу деген біркелкі инженерлік шешім туралы айтатын болсақ, онда біздің басты бас ауруымыз - кластерленген дерекқордағы деректерді репликациялау. Кейбір ДҚБЖ бастапқыда жеке даналары арасында деректерді таратуға өте адал. Көптеген басқалар онша қарсы емес. Біздің жобамыз үшін ДҚБЖ таңдаудағы негізгі аргумент жиі ресурс пен инженерлік шығындарды азайта отырып көшіру мүмкіндігі емес. Әсіресе, жоба бастапқыда микросервис ретінде жоспарланбаған болса, жай ғана осы бағытта дамыса.
Желілік дискілердің жылдамдығы туралы айтудың қажеті жоқ деп ойлаймыз - олар баяу. Анау. Егер бірдеңе болса, ДҚБЖ данасын көбірек, мысалы, процессор қуаты немесе бос ЖЖҚ бар жерде қайта іске қосуға бізде әлі нақты мүмкіндік жоқ. Виртуализацияланған дискінің ішкі жүйесінің өнімділігіне өте жылдам кірісеміз. Тиісінше, ДҚБЖ жақын жерде орналасқан жеке машиналар жиынтығына шегеленген болуы керек. Немесе болжамды резервтер үшін жеткілікті жылдам деректерді синхрондауды бөлек салқындату қажет.
Виртуалды файлдық жүйелер тақырыбын жалғастыру: Docker томдары, өкінішке орай, проблемасыз емес. Тұтастай алғанда, деректерді ұзақ мерзімді сенімді сақтау сияқты мәселеде мен техникалық қарапайым схемалармен айналысқым келеді. Контейнердің FS-тен ата-аналық хосттың FS-ге жаңа абстракциялық қабатын қосудың өзі тәуекел болып табылады. Бірақ контейнерлеуді қолдау жүйесінің жұмысы осы қабаттар арасында деректерді беруде қиындықтарға тап болған кезде, бұл шынымен апат. Қазіргі уақытта прогрессивті адамзатқа белгілі мәселелердің көпшілігі жойылған сияқты. Бірақ сіз түсінесіз, механизм неғұрлым күрделі болса, соғұрлым оңай бұзылады.
В свете всех этих «приключений» намного выгоднее и проще держать БД в одном месте, и даже если вам потребовалась контейнеризация приложения — пусть оно крутится само по себе и через распределительный шлюз получает одновременную связь с БД, которая будет читаться и писаться лишь один раз и бір жерде. Бұл тәсіл қателер мен десинхронизация ықтималдығын минимумға дейін азайтады.
Біз неге апарып жатырмыз? Сонымен қатар, дерекқорды контейнерлеу оған нақты қажеттілік бар жерде орынды. Сіз толық қолданбалы дерекқорды толтыра алмайсыз және оны екі ондаған микросервисіңіз бар сияқты айналдыра алмайсыз - ол осылай жұмыс істемейді. Және бұл анық түсіну керек.
Шығудың орнына
Егер сіз «деректер базасын виртуализациялау немесе жасамау» туралы нақты қорытындыны күтсеңіз, біз сізді ренжітеміз: бұл жерде болмайды. Өйткені кез келген инфрақұрылымдық шешімді жасау кезінде сән мен прогресс емес, ең алдымен парасаттылықты басшылыққа алу керек.
Кубернетиспен бірге келетін принциптер мен құралдар тамаша сәйкес келетін жобалар бар және мұндай жобаларда кем дегенде бэкенд аймағында тыныштық бар. Контейнерлеуді қажет етпейтін, бірақ қалыпты серверлік инфрақұрылымды қажет ететін жобалар бар, өйткені олар микросервис кластерінің үлгісіне түбегейлі қайта масштабталмайды, өйткені олар құлдырай бастайды.
Ақпарат көзі: www.habr.com