„Sysadminka“ sistemos administratoriaus susitikimai vyksta Čeliabinske, o paskutiniame iš jų pateikiau ataskaitą apie mūsų sprendimą, kaip paleisti programas „1C-Bitrix“ „Kubernetes“.
Bitrix, Kubernetes, Ceph – puikus mišinys?
Papasakosiu, kaip iš viso to sukūrėme veiksmingą sprendimą.
Eikime!
Susitikimas įvyko balandžio 18 d. Čeliabinske. Apie mūsų susitikimus galite perskaityti adresu ir pažiūrėk .
Jeigu norite ateiti pas mus su reportažu ar kaip klausytojas – sveiki, rašykite el [apsaugotas el. paštu] ir Telegram t.me/vadimisakanov.
Mano ataskaita
Sprendimas „Bitrix in Kubernetes, Southbridge 1.0 versija“
Aš kalbėsiu apie mūsų sprendimą „manekenams Kubernetes“ formatu, kaip buvo padaryta susitikimo metu. Bet manau, kad žinote žodžius Bitrix, Docker, Kubernetes, Ceph bent jau Vikipedijos straipsnių lygiu.
Kas yra paruošta „Bitrix“ programoje „Kubernetes“?
Visame internete yra labai mažai informacijos apie „Bitrix“ programų veikimą „Kubernetes“.
Radau tik šias medžiagas:
Aleksandro Serbulo, 1C-Bitrix ir Antono Tuzlukovo pranešimas iš Qsoft:
Rekomenduoju pasiklausyti.
Savo sprendimo kūrimas iš vartotojo .
Surado daugiau .
Aa ir... tiesą sakant, tai viskas.
Įspėju, mes netikrinome aukščiau pateiktose nuorodose pateiktų sprendimų kokybės :)
Beje, rengdamas mūsų sprendimą kalbėjausi su Aleksandru Serbulu, tada jo ataskaita dar nebuvo pasirodžiusi, todėl mano skaidrėse yra punktas „Bitrix nenaudoja Kubernetes“.
Tačiau jau yra daug paruoštų „Docker“ vaizdų, skirtų „Bitrix“ paleisti „Docker“:
Ar to pakanka norint sukurti išsamų „Bitrix“ sprendimą „Kubernetes“?
Nr. Yra daug problemų, kurias reikia išspręsti.
Kokios yra „Bitrix“ problemos „Kubernetes“?
Pirma, paruošti vaizdai iš Dockerhub netinka Kubernetes
Jei norime sukurti mikropaslaugų architektūrą (o „Kubernetes“ mes paprastai tai darome), turime atskirti „Kubernetes“ programą į konteinerius ir kiekvienam konteineriui atlikti vieną nedidelę funkciją (ir tai padaryti gerai). Kodėl tik vienas? Trumpai tariant, kuo paprastesnis, tuo patikimesnis.
Norėdami būti konkretesni, žiūrėkite šį straipsnį ir vaizdo įrašą:
„Docker“ vaizdai „Dockerhub“ daugiausia sukurti „viskas viename“ principu, todėl vis tiek turėjome sukurti savo dviratį ir netgi kurti vaizdus nuo nulio.
Antra – svetainės kodas redaguojamas iš administratoriaus skydelio
Svetainėje sukūrėme naują skyrių – atnaujintas kodas (pridėtas katalogas su naujos skilties pavadinimu).
Jei administratoriaus skydelyje pakeitėte komponento ypatybes, kodas pasikeitė.
„Kubernetes“ pagal numatytuosius nustatymus negali dirbti su tuo; konteineriai turi būti be būsenos.
Priežastis: kiekvienas klasteryje esantis konteineris (pod) apdoroja tik dalį srauto. Jei pakeisite kodą tik viename konteineryje (pod), tada skirtingose talpyklose kodas skirsis, svetainė veiks skirtingai, o skirtingiems vartotojams bus rodomos skirtingos svetainės versijos. Jūs negalite taip gyventi.
Trečia - turite išspręsti problemą su diegimu
Jei turime monolitą ir vieną „klasikinį“ serverį, viskas gana paprasta: diegiame naują kodo bazę, migruojame duomenų bazę, perjungiame srautą į naują kodo versiją. Perjungimas įvyksta akimirksniu.
Jei turime svetainę Kubernetes, supjaustytą į mikroservisus, ten yra daug konteinerių su kodu – oh. Turite surinkti konteinerius su nauja kodo versija, juos išleisti vietoj senųjų, teisingai perkelti duomenų bazę ir geriausia tai padaryti nepastebėjus lankytojų. Laimei, „Kubernetes“ mums padeda tai padaryti, palaikydama daugybę skirtingų diegimo tipų.
Ketvirta – reikia išspręsti statikos saugojimo problemą
Jei jūsų svetainė yra „tik“ 10 gigabaitų, o ją įdiegsite vien konteineriuose, turėsite 10 gigabaitų talpos konteinerius, kuriuos įdiegti prireiks amžinai.
„Sunkiausias“ svetainės dalis turite laikyti ne konteineriuose, todėl kyla klausimas, kaip tai padaryti teisingai.
Ko trūksta mūsų sprendimui?
Visas Bitrix kodas neskirstomas į mikrofunkcijas/mikropaslaugas (kad būtų atskira registracija, atskiras internetinės parduotuvės modulis ir pan.). Kiekviename konteineryje saugome visą kodo bazę.
Mes taip pat nesaugome duomenų bazės Kubernetes (aš vis dar įdiegiau sprendimus su duomenų baze Kubernetes kūrimo aplinkoms, bet ne gamybai).
Svetainės administratoriai vis tiek pastebės, kad svetainė veikia Kubernetes. „Sistemos patikros“ funkcija neveikia tinkamai; norėdami redaguoti svetainės kodą iš administratoriaus skydelio, pirmiausia turite spustelėti mygtuką „Noriu redaguoti kodą“.
Problemos identifikuotos, mikropaslaugų diegimo poreikis nustatytas, tikslas aiškus – gauti veikiančią sistemą Bitrix programoms paleisti Kubernetes, išsaugant tiek Bitrix galimybes, tiek Kubernetes privalumus. Pradėkime įgyvendinimą.
Architektūra
Yra daug „veikiančių“ blokų su žiniatinklio serveriu (darbuotojais).
Vienas po su cron užduotimis (reikia tik vienos).
Vienas atnaujinimas skirtas svetainės kodo redagavimui iš administratoriaus skydelio (taip pat reikalingas tik vienas).
Mes sprendžiame klausimus:
- Kur laikyti seansus?
- Kur laikyti talpyklą?
- Kur laikyti statiką, o ne dėti gigabaitus statikos į krūvą konteinerių?
- Kaip veiks duomenų bazė?
Docker vaizdas
Pradedame nuo „Docker“ vaizdo kūrimo.
Idealus variantas yra tai, kad turime vieną universalų vaizdą, kurio pagrindu gauname darbininkų rinkinius, podukus su Crontasks ir atnaujinimo rinkinius.
.
Tai apima nginx, apache / php-fpm (galima pasirinkti kūrimo metu), msmtp laiškams siųsti ir cron.
Surinkus vaizdą, visa svetainės kodo bazė nukopijuojama į /app katalogą (išskyrus tas dalis, kurias perkelsime į atskirą bendrą saugyklą).
Mikropaslaugos, paslaugos
darbininkų ankštys:
- Konteineris su nginx + konteineris apache/php-fpm + msmtp
- Nepavyko perkelti msmtp į atskirą mikro paslaugą, Bitrix pradeda piktintis, kad negali siųsti laiškų tiesiogiai
- Kiekvienas konteineris turi visą kodų bazę.
- Draudimas keisti kodą konteineriuose.
cron po:
- konteineris su apache, php, cron
- įtraukta visa kodo bazė
- draudimas keisti kodą konteineriuose
atnaujinti pagal:
- nginx konteineris + apache / php-fpm konteineris + msmtp
- Draudimo keisti kodą konteineriuose nėra
seanso saugykla
Bitrix talpyklos saugykla
Kitas svarbus dalykas: slaptažodžius, skirtus prisijungti prie visko, nuo duomenų bazės iki pašto, saugome kubernetes paslaptyse. Gauname premiją: slaptažodžius mato tik tie, kuriems suteikiame prieigą prie paslapčių, o ne visi, kurie turi prieigą prie projekto kodų bazės.
Statikos saugykla
Galite naudoti bet ką: ceph, nfs (bet mes nerekomenduojame nfs gamybai), tinklo saugyklą iš debesies tiekėjų ir kt.
Saugykla turės būti sujungta konteineriuose su svetainės /upload/ katalogu ir kitais statinio turinio katalogais.
Duomenų bazė
Dėl paprastumo rekomenduojame perkelti duomenų bazę už Kubernetes ribų. Bazė Kubernetes yra atskira sudėtinga užduotis; dėl to schema bus sudėtingesnė.
Seanso saugykla
Naudojame memcached :)
Jis gerai tvarko seansų saugyklą, yra sugrupuotas ir palaikomas „natūraliai“ kaip session.save_path php. Tokia sistema ne kartą buvo išbandyta klasikinėje monolitinėje architektūroje, kai kūrėme klasterius su daugybe interneto serverių. Dislokavimui naudojame vairą.
$ helm install stable/memcached --name sessionphp.ini - čia paveikslėlyje yra nustatymai, skirti seansams saugoti atmintinėje
Naudojome aplinkos kintamuosius, kad perduotume duomenis apie pagrindinius kompiuterius su atminties talpyklomis .
Tai leidžia naudoti tą patį kodą kūrimo, stadijos, bandymo, gaminių aplinkose (atmintyje išsaugoti pagrindinio kompiuterio pavadinimai jose skirsis, todėl kiekvienai aplinkai turime perduoti unikalų seansų pagrindinio kompiuterio pavadinimą).
Bitrix talpyklos saugykla
Mums reikia gedimams atsparios saugyklos, į kurią visi blokai galėtų rašyti ir skaityti.
Taip pat naudojame memcached.
Šį sprendimą rekomenduoja pati „Bitrix“.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - čia Bitrix yra nurodyta, kur saugoma talpykla
Taip pat naudojame aplinkos kintamuosius.
Krontaski
Yra įvairių požiūrių į „Crontasks“ paleidimą „Kubernetes“.
- atskiras diegimas su priedu Crontasks paleidimui
- cronjob crontasks vykdyti (jei tai žiniatinklio programa – su wget , arba kubectl exec vienoje iš darbuotojų rinkinių ir pan.)
- ir taip toliau
Galite ginčytis dėl teisingiausio, tačiau šiuo atveju pasirinkome parinktį „atskiras diegimas su „Crontasks“ blokais“.
Kaip tai daroma:
- pridėkite cron užduotis naudodami ConfigMap arba config/addcron failą
- vienu atveju paleidžiame konteinerį, identišką darbuotojui + leidžiame jame vykdyti karūnos užduotis
- naudojama ta pati kodo bazė, suvienodinimo dėka konteinerio surinkimas yra paprastas
Ką gero gauname:
- mes turime veikiančias Crontasks aplinkoje, identiškoje kūrėjų aplinkai (dokeris)
- „Crontas“ nereikia „perrašyti“ Kubernetes, jos veikia ta pačia forma ir ta pačia kodų baze kaip ir anksčiau
- cron užduotis gali pridėti visi komandos nariai, turintys įsipareigojimo teises į gamybos šaką, ne tik administratoriai
Southbridge K8SDeploy modulis ir kodo redagavimas iš administratoriaus skydelio
Mes kalbėjome apie atnaujinimą pagal?
Kaip ten nukreipti eismą?
Hurray, parašėme tam modulį PHP :) Tai mažas klasikinis Bitrix modulis. Jis dar nėra viešai prieinamas, bet planuojame jį atidaryti.
Modulis įdiegtas kaip įprastas „Bitrix“ modulis:
O atrodo taip:
Tai leidžia nustatyti slapuką, identifikuojantį svetainės administratorių ir leidžiantį Kubernetes siųsti srautą į naujinimo bloką.
Kai pakeitimai bus baigti, turite spustelėti git push, kodo pakeitimai bus išsiųsti į git, tada sistema sukurs vaizdą su nauja kodo versija ir „išleis“ jį visame klasteryje, pakeisdama senus blokus. .
Taip, tai šiek tiek ramentas, bet tuo pačiu palaikome mikroserviso architektūrą ir neatimame iš Bitrix vartotojų mėgstamos galimybės pataisyti kodą iš administratoriaus skydelio. Galų gale, tai yra galimybė; kodo redagavimo problemą galite išspręsti kitu būdu.
Vairo diagrama
Norėdami kurti programas „Kubernetes“, paprastai naudojame „Helm“ paketų tvarkyklę.
Mūsų pagrindinis sistemos administratorius Sergejus Bondarevas parašė specialią „Helm“ diagramą mūsų „Bitrix“ sprendimui Kubernetes.
Sukuria „worker“, „ugrade“, „cron“ rinkinius, konfigūruoja įėjimus, paslaugas ir perkelia kintamuosius iš „Kubernetes“ paslapčių į „Pods“.
Mes saugome kodą „Gitlab“, taip pat vykdome „Helm“ versiją iš „Gitlab“.
Trumpai tariant, tai atrodo taip
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production„Helm“ taip pat leidžia atlikti vientisą atšaukimą, jei diegimo metu staiga kažkas negerai. Puiku, kai nepanikuojate „pataisykite kodą per ftp, nes prod nukrito“, tačiau „Kubernetes“ tai daro automatiškai ir be prastovos.
Dislokuoti
Taip, mes esame Gitlab & Gitlab CI gerbėjai, mes juo naudojamės :)
Kai „Gitlab“ prisijungia prie projekto saugyklos, „Gitlab“ paleidžia dujotiekį, kuris diegia naują aplinkos versiją.
Etapai:
- statyti (naujo „Docker“ įvaizdžio kūrimas)
- bandymas (bandymas)
- išvalyti (pašalinti bandomąją aplinką)
- stumti (siunčiame į Docker registrą)
- diegti (diegiame programą Kubernetes per Helm).
Hurray, paruošta, įgyvendinkime!
Na, arba užduokite klausimų, jei tokių yra.
Taigi, ką mes padarėme
Techniniu požiūriu:
- dokerizuotas Bitrix;
- „supjaustykite“ Bitrix į konteinerius, kurių kiekvienas atlieka minimalias funkcijas;
- pasiekta konteinerių būsena be statuso;
- išsprendė „Bitrix“ atnaujinimo „Kubernetes“ problemą;
- toliau veikė visos Bitrix funkcijos (beveik visos);
- Dirbome su Kubernetes diegimu ir versijų grąžinimu.
Verslo požiūriu:
- atsparumas gedimams;
- Kubernetes įrankiai (lengva integracija su Gitlab CI, sklandus diegimas ir kt.);
- slapti slaptažodžiai (matomi tik tiems, kuriems tiesiogiai suteikta prieiga prie slaptažodžių);
- Vienoje infrastruktūroje patogu kurti papildomas aplinkas (kūrimui, bandymams ir pan.).
Šaltinis: www.habr.com