Сіз IT саласында жұмыс жасай отырып, жүйелердің өзіндік сипаты бар екенін байқай бастайсыз. Олар икемді, үнсіз, эксцентрик және қатал болуы мүмкін. Олар тарта алады немесе кері қайтара алады. Қалай болғанда да, сіз олармен «келіссөздер жүргізуге», «тұңқырлар» арасында маневр жасауға және олардың өзара әрекеттесу тізбегін құруға тура келеді.
Осылайша, біз бұлттық платформаны құру құрметіне ие болдық және ол үшін бізбен жұмыс істеуге бірнеше ішкі жүйені «көндіру» керек болды. Бақытымызға орай, бізде «API тілі», тікелей қолдар және үлкен ынта бар.
Бұл мақала техникалық тұрғыдан қиын болмайды, бірақ бұлтты құру кезінде кездесетін проблемаларды сипаттайды. Мен жүйелермен ортақ тілді қалай іздегеніміз және одан не шыққаны туралы жеңіл техникалық қиял түрінде жолымызды сипаттауды жөн көрдім.
мысыққа қош келдіңіз.
Жолды бастау
Біраз уақыт бұрын біздің командаға клиенттеріміз үшін бұлтты платформаны іске қосу тапсырылды. Бізде басқарушылық қолдау, ресурстар, аппараттық құралдар стегі және қызметтің бағдарламалық бөлігін енгізу үшін технологияларды таңдауда еркіндік болды.
Сонымен қатар бірқатар талаптар қойылды:
- қызметке ыңғайлы жеке кабинет қажет;
- платформа қолданыстағы есепшот жүйесіне біріктірілген болуы керек;
- бағдарламалық және аппараттық құрал: OpenStack + Вольфрам матасы (Open Contrail), оны біздің инженерлер «пісіруді» жақсы үйренді.
Егер Habra қауымдастығы қызығушылық танытса, топтың қалай жиналғаны, жеке кабинет интерфейсі жасалғаны және дизайн шешімдері қабылданғаны туралы тағы бір рет айтамыз.
Біз қолдануға шешім қабылдаған құралдар:
- Python + Flask + Swagger + SQLAlchemy - толығымен стандартты Python жинағы;
- Frontend үшін Vue.js;
- Біз AMQP арқылы балдыркөк арқылы құрамдас бөліктер мен қызметтер арасындағы өзара әрекеттесу туралы шешім қабылдадық.
Python таңдау туралы сұрақтарды алдын ала түсіндіремін. Біздің компанияда тіл өз орнын тапты және оның айналасында шағын, бірақ әлі де мәдениет дамыды. Сондықтан оған қызмет көрсетуді бастау туралы шешім қабылданды. Сонымен қатар, мұндай проблемалардың даму жылдамдығы көбінесе шешуші болып табылады.
Ендеше танысуымызды бастайық.
Үнсіз шот – есепшот
Біз бұл жігітті бұрыннан білеміз. Үнемі қасымда отырып, бірдеңені санап отыратын. Кейде ол бізге пайдаланушы сұрауларын жіберді, клиенттік шот-фактураларды берді және қызметтерді басқарды. Қарапайым еңбекқор жігіт. Рас, қиындықтар болды. Ол үнсіз, кейде ойланып, жиі өз ойымен жүреді.
Төлем - бұл біз достасуға тырысқан бірінші жүйе. Ал бірінші қиындық қызметтерді өңдеу кезінде кездесті.
Мысалы, жасалған немесе жойылған кезде тапсырма ішкі есепшот кезегіне өтеді. Осылайша, қызметтермен асинхронды жұмыс жүйесі жүзеге асырылады. Қызмет түрлерін өңдеу үшін бізге тапсырмаларды осы кезекке «қою» керек болды. Бұл жерде біз мәселеге тап болдық: құжаттаманың болмауы.
Бағдарламалық жасақтаманың API сипаттамасына қарағанда, бұл мәселені әлі де шешуге болады, бірақ бізде кері инженерия жасауға уақыт болмады, сондықтан біз логиканы сыртқа шығарып, RabbitMQ үстіне тапсырмалар кезегін ұйымдастырдық. Қызмет бойынша операцияны клиент өзінің жеке кабинетінен бастайды, бэкендтегі балдыркөк «тапсырмасына» айналады және есепшот пен OpenStack жағында орындалады. Балдыркөк тапсырмаларды басқаруға, қайталауларды ұйымдастыруға және күйді бақылауға өте ыңғайлы етеді. Сіз «балдыркөк» туралы көбірек оқи аласыз, мысалы, .
Сондай-ақ, есепшот таусылған жобаны тоқтатқан жоқ. Әзірлеушілермен байланыса отырып, біз статистиканы есептеу кезінде (және дәл осы логиканы енгізуіміз керек) тоқтату ережелерінің күрделі өзара байланысы бар екенін білдік. Бірақ бұл модельдер біздің шындыққа сәйкес келмейді. Сондай-ақ, біз оны Сельдерей тапсырмалары арқылы іске асырдық, қызметті басқару логикасын сервер жағына ауыстырдық.
Жоғарыда аталған екі мәселе де кодтың аздап толып кетуіне әкелді және болашақта тапсырмалармен жұмыс істеу логикасын бөлек қызметке көшіру үшін қайта өңдеуге тура келеді. Сондай-ақ осы логиканы қолдау үшін пайдаланушылар мен олардың қызметтері туралы кейбір ақпаратты кестелерімізде сақтауымыз керек.
Тағы бір мәселе - үнсіздік.
Билли кейбір API сұрауларына үнсіз «Жарайды» деп жауап береді. Бұл, мысалы, біз сынақ кезінде уәде етілген төлемдер бойынша төлемдерді жасаған кезде болды (бұл туралы кейінірек). Сұраулар дұрыс орындалды және біз қателерді көрмедік.
UI арқылы жүйемен жұмыс істеу кезінде журналдарды зерттеуге тура келді. Төлемнің өзі ұқсас сұрауларды орындайтыны белгілі болды, қолдану аясын белгілі бір пайдаланушыға өзгертеді, мысалы, әкімші, оны su параметрінде өткізеді.
Тұтастай алғанда, құжаттамадағы олқылықтар мен кішігірім API кемшіліктеріне қарамастан, бәрі жақсы өтті. Журналдар қалай құрылымдалғанын және нені іздеу керектігін түсінсеңіз, тіпті ауыр жүктеме кезінде де оқуға болады. Мәліметтер қорының құрылымы әшекейленген, бірақ өте қисынды және кейбір жағынан тіпті тартымды.
Сонымен, қорытындылайтын болсақ, өзара әрекеттесу сатысында кездесетін негізгі мәселелер белгілі бір жүйенің іске асыру ерекшеліктеріне байланысты:
- бізге қандай да бір жолмен әсер еткен құжатсыз «мүмкіндіктер»;
- жабық дереккөз (шот C++ тілінде жазылған), нәтижесінде – 1-мәселені «сынау және қателік» әдісінен басқа жолмен шешу мүмкін емес.
Бақытымызға орай, өнімде жеткілікті кең API бар және біз келесі ішкі жүйелерді жеке шотымызға біріктірдік:
- техникалық қолдау модулі - сіздің жеке кабинетіңізден сұраулар қызмет көрсету клиенттері үшін ашық түрде есепшотқа «проксиге» жіберіледі;
- қаржылық модуль – ағымдағы клиенттерге шот-фактураларды беруге, есептен шығаруды жүргізуге және төлем құжаттарын қалыптастыруға мүмкіндік береді;
- қызметті басқару модулі - бұл үшін біз өз өңдеушімізді енгізуіміз керек болды. Жүйенің кеңеюі біздің қолымызда болды және біз Биллиге қызметтің жаңа түрін «үйреттік».
Бұл біраз қиын болды, бірақ қалай болғанда да, Билли екеуміз тіл табысамыз деп ойлаймын.
Вольфрам өрістерін аралау – Вольфрам матасы
Вольфрам өрістері жүздеген сымдармен нүктеленген, олар арқылы мыңдаған бит ақпараттарды өткізеді. Ақпарат сиқырлы сияқты «пакеттерге» жиналады, талданады, күрделі маршруттар құрастырады.
Бұл біз достасуға мәжбүр болған екінші жүйенің домені - бұрын OpenContrail болатын вольфрамдық мата (TF). Оның міндеті – пайдаланушылар ретінде бізге бағдарламалық абстракцияны қамтамасыз ететін желілік жабдықты басқару. TF - SDN, желілік жабдықпен жұмыс істеудің күрделі логикасын инкапсуляциялайды. Технологияның өзі туралы жақсы мақала бар, мысалы, .
Жүйе Neutron плагині арқылы OpenStack (төменде талқыланады) бағдарламасымен біріктірілген.
OpenStack қызметтерінің өзара әрекеттесуі.
Бізді операциялық бөлімнің жігіттері осы жүйемен таныстырды. Қызметтеріміздің желілік стегін басқару үшін жүйенің API интерфейсін қолданамыз. Бұл бізге әлі ешқандай күрделі проблемалар немесе қолайсыздықтар тудырмады (мен OE жігіттері үшін айта алмаймын), бірақ өзара әрекеттесуде кейбір оғаштықтар болды.
Біріншісі келесідей болды: SSH арқылы қосылу кезінде дана консоліне деректердің үлкен көлемін шығаруды талап ететін пәрмендер қосылымды жай ғана «жабады», ал VNC арқылы бәрі дұрыс жұмыс істеді.
Мәселемен таныс емес адамдар үшін бұл өте күлкілі көрінеді: ls /root дұрыс жұмыс істейді, ал, мысалы, жоғарғы жағы толығымен «қатып қалады». Бақытымызға орай, біз бұрын да осындай проблемаларға тап болдық. Есептеу түйіндерінен маршрутизаторларға дейінгі бағытта MTU баптау арқылы шешілді. Айтпақшы, бұл TF мәселесі емес.
Келесі мәселе бұрышта болды. Бір «әдемі» сәтте маршруттың сиқыры жоғалып кетті, дәл солай. TF жабдықтағы маршруттауды басқаруды тоқтатты.
Біз Openstack-пен әкімші деңгейінен жұмыс істедік, содан кейін қажетті пайдаланушы деңгейіне көштік. SDN әрекеттерді орындайтын пайдаланушының ауқымын «басып алатын» сияқты. TF пен OpenStack-ті қосу үшін бірдей әкімші тіркелгісі пайдаланылады. Пайдаланушыға ауысу қадамында «сиқыр» жоғалып кетті. Жүйемен жұмыс істеу үшін бөлек тіркелгі жасау туралы шешім қабылданды. Бұл интеграциялық функцияларды бұзбай жұмыс істеуге мүмкіндік берді.
Silicon Lifeforms - OpenStack
Біртүрлі пішінді силикон жаратылысы вольфрам алқаптарының жанында тұрады. Бәрінен де бізді бір сермеп басып кететін өскен балаға ұқсайды, бірақ одан ешқандай агрессия байқалмайды. Ол қорқыныш тудырмайды, бірақ оның мөлшері қорқыныш тудырады. Айналада болып жатқан нәрселердің күрделілігі сияқты.
OpenStack платформамыздың өзегі болып табылады.
OpenStack-тің бірнеше ішкі жүйелері бар, олардың ішінде біз қазір Nova, Glance және Cinder-ді белсенді түрде қолданамыз. Олардың әрқайсысының өз API бар. Nova есептеу ресурстарына және даналарды жасауға жауап береді, Cinder - томдар мен олардың суреттерін басқаруға жауап береді, Glance - ОЖ үлгілерін және олардағы метаақпаратты басқаратын кескін қызметі.
Әрбір қызмет контейнерде жұмыс істейді, ал хабарлама брокері «ақ қоян» - RabbitMQ.
Бұл жүйе бізге ең күтпеген қиындықты берді.
Серверге қосымша көлемді қосуға тырысқанда, бірінші мәселе көп күттірмеді. Cinder API бұл тапсырманы орындаудан үзілді-кесілді бас тартты. Дәлірек айтқанда, егер сіз OpenStack-тің өзіне сенсеңіз, қосылым орнатылған, бірақ виртуалды серверде диск құрылғысы жоқ.
Біз айналма жолмен жүруді шештік және Nova API-дан дәл осындай әрекетті сұрадық. Нәтижесінде құрылғы дұрыс қосылып, серверде қол жетімді болады. Мәселе блок-сақтау Cinder-ге жауап бермеген кезде туындайтын сияқты.
Дискілермен жұмыс істегенде бізді тағы бір қиындық күтіп тұрды. Жүйе көлемін серверден ажырату мүмкін болмады.
Тағы да, OpenStack өзі қосылымды жойғанына «ант береді» және енді сіз дыбыспен бөлек дұрыс жұмыс істей аласыз. Бірақ API дискіде операцияларды орындағысы келмеді.
Бұл жерде біз әсіресе күресуді емес, қызметтің логикасына деген көзқарасымызды өзгертуді шештік. Егер данасы болса, жүйенің көлемі де болуы керек. Сондықтан пайдаланушы «серверді» жоймай, жүйенің «дискін» әлі алып тастай немесе өшіре алмайды.
OpenStack - бұл өзара әрекеттесу логикасы мен әсем API интерфейсі бар өте күрделі жүйелер жиынтығы. Бізге егжей-тегжейлі құжаттама және, әрине, сынақ пен қателік көмектеседі (онсыз біз қайда болар едік).
Сынақ
Біз өткен жылдың желтоқсан айында сынақты іске қостық. Негізгі міндет - техникалық жағынан және UX жағынан жобамызды жауынгерлік режимде сынау болды. Аудитория іріктеп шақырылып, тестілеу жабылды. Дегенмен, біз веб-сайтымызда тестілеуге рұқсат сұрау опциясын қалдырдық.
Сынақтың өзі, әрине, күлкілі сәттерсіз болмады, өйткені бұл жерде біздің шытырман оқиғаларымыз енді басталады.
Біріншіден, біз жобаға қызығушылықты біршама қате бағаладық және сынақ кезінде есептеу түйіндерін жылдам қосуға тура келді. Кластер үшін әдеттегі жағдай, бірақ мұнда да кейбір нюанстар болды. TF нақты нұсқасына арналған құжаттама vRouter-пен жұмыс сыналған ядроның нақты нұсқасын көрсетеді. Біз соңғы ядролары бар түйіндерді іске қосуды шештік. Нәтижесінде ТФ түйіндерден маршруттарды алмады. Маған ядроларды шұғыл түрде айналдыруға тура келді.
Тағы бір қызығушылық сіздің жеке кабинетіңіздегі «парольді өзгерту» батырмасының функционалдығымен байланысты.
Сеанстармен жұмыс істемеу үшін жеке тіркелгімізге кіруді ұйымдастыру үшін JWT пайдалануды шештік. Жүйелер алуан түрлі және кең таралғандықтан, біз өз таңбалауышты басқарамыз, онда біз есепшоттан сеанстарды және OpenStack токенінен «орап аламыз». Құпия сөз өзгертілген кезде, таңбалауыш, әрине, «жаман болады», өйткені пайдаланушы деректері енді жарамсыз және оны қайта шығару қажет.
Біз бұл тармақты ұмытып кеттік және бұл бөлікті тез аяқтау үшін ресурстар жеткіліксіз болды. Біз сынақты бастамас бұрын функцияны қысқартуға тура келді.
Құпия сөз өзгертілген болса, қазір біз пайдаланушыдан шығамыз.
Осы нюанстарға қарамастан, тестілеу жақсы өтті. Бір-екі аптаның ішінде 300-ге жуық адам тоқтады. Біз өнімді пайдаланушылардың көзімен қарап, оны іс жүзінде сынап, жоғары сапалы кері байланыс жинай алдық.
Жалғасы бар
Көпшілігіміз үшін бұл осындай ауқымдағы бірінші жоба. Біз команда болып жұмыс істеу және сәулет және дизайн шешімдерін қабылдау туралы бірнеше құнды сабақтар алдық. Аз ресурстары бар күрделі жүйелерді қалай біріктіруге және оларды өндіріске енгізуге болады.
Әрине, код тұрғысынан да, жүйе интеграциясының интерфейстерінде де жұмыс істеуге болатын нәрсе бар. Жоба өте жас, бірақ біз оны сенімді және ыңғайлы қызметке айналдыруға ұмтыламыз.
Біз жүйелерді көндіре алдық. Билл өз шкафында санау, есеп айырысу және пайдаланушы сұрауларын мұқият өңдейді. Вольфрам өрістерінің «сиқыры» бізді тұрақты байланыспен қамтамасыз етеді. Тек OpenStack кейде «'WSREP қолданбаны пайдалану үшін түйінді әлі дайындаған жоқ» деген сияқты бірдеңені айқайлай отырып, қызық болады. Бірақ бұл мүлдем басқа әңгіме...
Біз бұл қызметті жақында іске қостық.
Барлық мәліметтерді біздің сайтымыздан біле аласыз .
CLO әзірлеу тобы
Пайдалы сілтемелер
OpenStack
Вольфрам мата
Ақпарат көзі: www.habr.com