V Čeljabinsku potekajo srečanja sistemskih administratorjev Sysadminka in na zadnjem sem poročal o naši rešitvi za izvajanje aplikacij na 1C-Bitrix v Kubernetesu.
Bitrix, Kubernetes, Ceph - odlična mešanica?
Povedal vam bom, kako smo iz vsega tega sestavili delujočo rešitev.
Gremo!
Srečanje je potekalo 18. aprila v Čeljabinsku. O naših srečanjih lahko preberete na in poglej .
Če želite priti k nam s poročilom ali kot poslušalec - dobrodošli, pišite [e-pošta zaščitena] in na Telegram t.me/vadimisakanov.
Moje poročilo
Rešitev "Bitrix v Kubernetesu, različica Southbridge 1.0"
O naši rešitvi bom govoril v obliki »za telebane v Kubernetesu«, kot je bilo storjeno na srečanju. Predvidevam pa, da poznaš besede Bitrix, Docker, Kubernetes, Ceph vsaj na nivoju člankov na Wikipediji.
Kaj je pripravljeno za Bitrix v Kubernetesu?
O delovanju Bitrix aplikacij v Kubernetesu je na celotnem internetu zelo malo informacij.
Našel sem samo te materiale:
Poročilo Aleksandra Serbula, 1C-Bitrix, in Antona Tuzlukova iz Qsofta:
Priporočam poslušanje.
Razvijanje lastne rešitve od uporabnika .
Našli več .
Aaa... pravzaprav je to vse.
Opozarjam vas, nismo preverili kakovosti rešitev na zgornjih povezavah :)
Mimogrede, ko sem pripravljal našo rešitev, sem se pogovarjal z Aleksandrom Serbulom, potem se njegovo poročilo še ni pojavilo, zato je na mojih diapozitivih postavka »Bitrix ne uporablja Kubernetesa«.
Toda že obstaja veliko pripravljenih slik Dockerja za zagon Bitrixa v Dockerju:
Je to dovolj za ustvarjanje popolne rešitve za Bitrix v Kubernetesu?
št. Obstaja veliko problemov, ki jih je treba rešiti.
Kakšne so težave z Bitrixom v Kubernetesu?
Prvič, že pripravljene slike iz Dockerhuba niso primerne za Kubernetes
Če želimo zgraditi arhitekturo mikrostoritev (in v Kubernetesu običajno počnemo), moramo našo aplikacijo Kubernetes razdeliti na vsebnike in naj vsak vsebnik izvaja eno majhno funkcijo (in to dobro). Zakaj le enega? Skratka, enostavnejše, bolj zanesljivo.
Če želite biti natančnejši, si oglejte ta članek in videoposnetek:
Docker slike v Dockerhubu so v glavnem zgrajene po načelu vse-v-enem, tako da smo vseeno morali izdelati lastno kolo in celo ustvariti slike iz nič.
Drugič - koda spletnega mesta se ureja na skrbniški plošči
Na spletnem mestu smo ustvarili novo rubriko - posodobljena koda (dodan imenik z imenom nove rubrike).
Če ste spremenili lastnosti komponente na skrbniški plošči, se je koda spremenila.
Kubernetes »privzeto« ne more delovati s tem; vsebniki morajo biti brez stanja.
Razlog: Vsak vsebnik (pod) v gruči obdela samo del prometa. Če kodo spremenite samo v enem vsebniku (podu), bo koda v različnih podih drugačna, stran bo delovala drugače in različnim uporabnikom bodo prikazane različne različice strani. Tako ne moreš živeti.
Tretjič - rešiti morate težavo z uvajanjem
Če imamo monolit in en “klasični” strežnik, je vse zelo preprosto: postavimo novo kodno bazo, preselimo bazo, preklopimo promet na novo različico kode. Preklop se zgodi takoj.
Če imamo spletno mesto v Kubernetesu, razrezano na mikrostoritve, je veliko vsebnikov s kodo - oh. Zbrati morate vsebnike z novo različico kode, jih razviti namesto starih, pravilno preseliti bazo podatkov in v idealnem primeru to narediti neopaženo za obiskovalce. Na srečo nam pri tem pomaga Kubernetes, ki podpira cel kup različnih vrst uvajanj.
Četrtič - rešiti morate vprašanje shranjevanja statike
Če ima vaše spletno mesto »samo« 10 gigabajtov in ga v celoti namestite v vsebnike, boste na koncu imeli 10 gigabajtne vsebnike, katerih uvedba traja večno.
"Najtežje" dele mesta morate shraniti zunaj zabojnikov in postavlja se vprašanje, kako to storiti pravilno
Kaj manjka naši rešitvi?
Celotna Bitrix koda ni razdeljena na mikrofunkcije/mikrostoritve (tako da je registracija ločena, modul spletne trgovine ločen ipd.). V vsakem vsebniku shranimo celotno kodno bazo.
Prav tako baze ne hranimo v Kubernetesu (še vedno sem implementiral rešitve z bazo v Kubernetesu za razvojna okolja, ne pa tudi za produkcijo).
Skrbniki spletnega mesta bodo še vedno opazili, da spletno mesto deluje na Kubernetesu. Funkcija »preverjanje sistema« ne deluje pravilno; če želite urediti kodo spletnega mesta na skrbniški plošči, morate najprej klikniti gumb »Želim urediti kodo«.
Težave so bile identificirane, potreba po implementaciji mikrostoritev je bila določena, cilj je jasen - dobiti delujoč sistem za izvajanje aplikacij na Bitrixu v Kubernetesu, pri čemer se ohranijo tako zmogljivosti Bitrixa kot prednosti Kubernetesa. Začnimo z izvajanjem.
arhitektura
Obstaja veliko "delujočih" podov s spletnim strežnikom (delavci).
Ena pod z nalogami cron (potrebna je le ena).
Ena nadgradnja za urejanje kode spletnega mesta iz skrbniške plošče (potrebna je tudi samo ena).
Rešujemo vprašanja:
- Kam shraniti seje?
- Kje shraniti predpomnilnik?
- Kam shraniti statiko, ne pa gigabajte statike nalagati v kup posod?
- Kako bo baza podatkov delovala?
Dockerjeva slika
Začnemo z izdelavo slike Docker.
Idealna možnost je, da imamo eno univerzalno sliko, na njeni osnovi dobimo delavske pode, pode s Crontaski in nadgradne pode.
.
Vključuje nginx, apache/php-fpm (lahko ga izberete med gradnjo), msmtp za pošiljanje pošte in cron.
Pri sestavljanju slike se celotna kodna baza spletnega mesta prekopira v imenik /app (z izjemo tistih delov, ki jih bomo premaknili v ločeno skupno shrambo).
Mikrostoritve, storitve
delavski stroki:
- Vsebnik z nginx + vsebnik apache/php-fpm + msmtp
- Ni uspelo premakniti msmtp v ločeno mikrostoritev, Bitrix se začne jeziti, da ne more neposredno pošiljati pošte
- Vsak vsebnik ima celotno zbirko kod.
- Prepoved spreminjanja kode v kontejnerjih.
kron pod:
- vsebnik z apache, php, cron
- vključena celotna kodna baza
- prepoved spreminjanja kode v kontejnerjih
nadgradnja pod:
- vsebnik nginx + vsebnik apache/php-fpm + msmtp
- V zabojnikih ni prepovedi spreminjanja kode
shranjevanje seje
Bitrix predpomnilnik
Še ena pomembna stvar: v kubernetes secrets hranimo gesla za povezavo do vsega, od baze do pošte. Dobimo bonus: gesla so vidna samo tistim, ki jim omogočimo dostop do skrivnosti, in ne vsem, ki imajo dostop do kodne baze projekta.
Shramba za statiko
Uporabite lahko kar koli: ceph, nfs (vendar ne priporočamo nfs za produkcijo), omrežno shranjevanje ponudnikov v oblaku itd.
Shrambo bo treba v vsebnikih povezati z imenikom /upload/ spletnega mesta in drugimi imeniki s statično vsebino.
Baza podatkov
Zaradi enostavnosti priporočamo, da bazo podatkov premaknete izven Kubernetesa. Osnova v Kubernetesu je ločena zapletena naloga, zaradi katere bo shema postala veliko bolj zapletena.
Shranjevanje sej
Uporabljamo memcached :)
Dobro upravlja s shranjevanjem sej, je združen v gruče in je podprt »nativno« kot session.save_path v php. Takšen sistem je bil večkrat preizkušen v klasični monolitni arhitekturi, ko smo gradili grozde z velikim številom spletnih strežnikov. Za razporeditev uporabljamo krmilo.
$ helm install stable/memcached --name sessionphp.ini - tukaj slika vsebuje nastavitve za shranjevanje sej v memcached
Spremenljivke okolja smo uporabili za posredovanje podatkov o gostiteljih z memcached .
To vam omogoča uporabo iste kode v okoljih dev, stage, test, prod (ime gostiteljev v predpomnjenem pomnilniku bodo drugačna, zato moramo vsakemu okolju posredovati edinstveno ime gostitelja za seje).
Bitrix predpomnilnik
Potrebujemo shrambo, odporno na napake, v katero lahko pišejo in berejo vsi sklopi.
Uporabljamo tudi memcached.
To rešitev priporoča sam Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - tukaj v Bitrixu je določeno, kje je shranjen predpomnilnik
Uporabljamo tudi spremenljivke okolja.
Krontaski
Obstajajo različni pristopi za izvajanje Crontasks v Kubernetesu.
- ločeno uvajanje s podom za izvajanje Crontaskov
- cronjob za izvajanje crontasks (če je to spletna aplikacija - z wget , ali kubectl exec znotraj enega od delovnih podov itd.)
- in tako naprej
Lahko se prepirate o najbolj pravilnem, vendar smo v tem primeru izbrali možnost »ločena uvedba s podi za Crontasks«
Kako se to naredi:
- dodajte opravila cron prek ConfigMap ali prek datoteke config/addcron
- v enem primeru zaženemo vsebnik, ki je enak podu delavca + omogočimo izvajanje kronskih nalog v njem
- uporabljena je ista kodna baza, zahvaljujoč poenotenju je sestavljanje posode preprosto
Kaj dobrega dobimo:
- imamo delujoče Crontaske v okolju, ki je identično okolju razvijalcev (docker)
- Crontasks ni treba "prepisati" za Kubernetes, delujejo v isti obliki in v isti kodni bazi kot prej
- opravila cron lahko dodajajo vsi člani ekipe s pravicami doveljanja v produkcijsko vejo, ne le skrbniki
Modul Southbridge K8SDeploy in urejanje kode iz skrbniške plošče
Govorili smo o nadgradnji?
Kako tja usmeriti promet?
Hura, za to smo napisali modul v PHP :) To je majhen klasičen modul za Bitrix. Ni še javno dostopen, vendar ga nameravamo odpreti.
Modul je nameščen kot običajni modul v Bitrixu:
In izgleda takole:
Omogoča vam nastavitev piškotka, ki identificira skrbnika spletnega mesta in Kubernetesu omogoča pošiljanje prometa v nadgradnjo.
Ko so spremembe končane, morate klikniti git push, spremembe kode bodo poslane git-u, nato bo sistem zgradil sliko z novo različico kode in jo "razširil" po gruči ter zamenjal stare pode .
Da, to je malo bergla, a hkrati ohranjamo arhitekturo mikrostoritve in uporabnikom Bitrixa ne jemljemo njihove najljubše priložnosti, da popravijo kodo iz skrbniške plošče. Konec koncev je to možnost, problem urejanja kode lahko rešite na drugačen način.
Shema krmila
Za gradnjo aplikacij na Kubernetesu običajno uporabljamo upravitelja paketov Helm.
Za našo rešitev Bitrix v Kubernetesu je Sergey Bondarev, naš vodilni sistemski skrbnik, napisal posebno shemo Helm.
Gradi pode worker, nadgradnjo, cron, konfigurira vstope, storitve in prenaša spremenljivke iz skrivnosti Kubernetes v pode.
Kodo hranimo v Gitlabu, iz Gitlaba pa izvajamo tudi gradnjo Helm.
Na kratko zgleda takole
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm vam omogoča tudi "nemoteno" povrnitev nazaj, če gre nenadoma kaj narobe med uvajanjem. Lepo je, ko nisi v paniki "popravi kodo preko ftp-ja, ker je prod padel," ampak Kubernetes to naredi samodejno in brez izpadov.
Razporedi
Da, smo oboževalci Gitlab & Gitlab CI, uporabljamo ju :)
Ko se v Gitlabu zaveže v repozitorij projekta, Gitlab zažene cevovod, ki razmesti novo različico okolja.
Faze:
- build (gradnja nove Dockerjeve slike)
- test (testiranje)
- čiščenje (odstranitev testnega okolja)
- push (pošljemo ga v register Docker)
- deploy (aplikacijo razmestimo v Kubernetes prek Helma).
Hura, pripravljeno je, izvedimo ga!
No, ali postavite vprašanja, če obstajajo.
Torej, kaj smo naredili
S tehničnega vidika:
- dokkeriziran Bitrix;
- "razrežite" Bitrix na vsebnike, od katerih vsak opravlja najmanj funkcij;
- doseženo stanje zabojnikov brez stanja;
- rešil težavo s posodabljanjem Bitrixa v Kubernetesu;
- vse funkcije Bitrixa so še naprej delovale (skoraj vse);
- Delali smo na uvajanju v Kubernetes in povrnitvi med različicami.
S poslovnega vidika:
- toleranca napak;
- Orodja Kubernetes (enostavna integracija z Gitlab CI, brezhibna uvedba itd.);
- skrivna gesla (vidna samo tistim, ki imajo neposreden dostop do gesel);
- Priročno je ustvariti dodatna okolja (za razvoj, teste itd.) znotraj ene same infrastrukture.
Vir: www.habr.com