Susreti administratora sustava Sysadminka održavaju se u Čeljabinsku, a na posljednjem sam izvijestio o našem rješenju za pokretanje aplikacija na 1C-Bitrixu u Kubernetesu.
Bitrix, Kubernetes, Ceph - odlična mješavina?
Reći ću vam kako smo od svega ovoga sastavili radno rješenje.
Idemo!
Susret se održao 18. travnja u Čeljabinsku. O našim susretima možete čitati na i pogledaj .
Ako nam želite doći s izvješćem ili kao slušatelj - dobrodošli, pišite nam [e-pošta zaštićena] i na Telegramu t.me/vadimisakanov.
Moj izvještaj
Rješenje "Bitrix u Kubernetesu, verzija Southbridge 1.0"
Govorit ću o našem rješenju u formatu “for dummies in Kubernetes”, kao što je učinjeno na susretu. Ali pretpostavljam da znate riječi Bitrix, Docker, Kubernetes, Ceph barem na razini članaka na Wikipediji.
Što je gotovo u vezi Bitrixa u Kubernetesu?
O radu Bitrix aplikacija u Kubernetesu postoji vrlo malo informacija na cijelom internetu.
Našao sam samo ove materijale:
Izvješće Alexandera Serbula, 1C-Bitrix i Antona Tuzlukova iz Qsofta:
Preporučam poslušati.
Razvijanje vlastitog rješenja od korisnika .
Pronađeno više .
Aaa... zapravo, to je sve.
Upozoravam vas, nismo provjerili kvalitetu rješenja na gornjim linkovima :)
Usput, kada sam pripremao naše rješenje, razgovarao sam s Alexanderom Serbulom, tada se njegovo izvješće još nije pojavilo, pa u mojim slajdovima postoji stavka "Bitrix ne koristi Kubernetes."
Ali već postoji puno gotovih Docker slika za pokretanje Bitrixa u Dockeru:
Je li to dovoljno za stvaranje cjelovitog rješenja za Bitrix u Kubernetesu?
Ne. Postoji veliki broj problema koje treba riješiti.
Koji su problemi s Bitrixom u Kubernetesu?
Prvo, gotove slike iz Dockerhuba nisu prikladne za Kubernetes
Ako želimo izgraditi arhitekturu mikroservisa (a u Kubernetesu to obično radimo), moramo odvojiti našu Kubernetes aplikaciju u spremnike i neka svaki spremnik obavlja jednu malu funkciju (i to dobro). Zašto samo jedan? Ukratko, što jednostavniji to pouzdaniji.
Da budemo precizniji, pogledajte ovaj članak i video, molimo:
Docker slike u Dockerhub-u uglavnom su izgrađene na principu sve-u-jednom, tako da smo ipak morali napraviti vlastiti bicikl, pa čak i stvoriti slike od nule.
Drugo - kod web-mjesta se uređuje s administratorske ploče
Napravili smo novu sekciju na stranici - kod je ažuriran (dodan je direktorij s nazivom nove sekcije).
Ako ste promijenili svojstva komponente na administrativnoj ploči, kod se promijenio.
Kubernetes "prema zadanim postavkama" ne može raditi s ovim; spremnici moraju biti bez stanja.
Razlog: Svaki spremnik (pod) u klasteru obrađuje samo dio prometa. Ako promijenite kod samo u jednom spremniku (podu), kod će biti različit u različitim podovima, stranica će raditi drugačije, a različite verzije stranice će se prikazivati različitim korisnicima. Ne možeš tako živjeti.
Treće - morate riješiti problem s implementacijom
Ako imamo monolit i jedan “klasični” poslužitelj, sve je vrlo jednostavno: postavimo novu bazu koda, migriramo bazu podataka, prebacimo promet na novu verziju koda. Prebacivanje se događa trenutno.
Ako imamo stranicu u Kubernetesu, izrezanu na mikroservise, ima puno spremnika s kodom - oh. Morate prikupiti spremnike s novom verzijom koda, uvesti ih umjesto starih, ispravno migrirati bazu podataka i idealno učiniti to neprimjetno za posjetitelje. Srećom, Kubernetes nam u tome pomaže, podržavajući čitav niz različitih vrsta implementacija.
Četvrto - morate riješiti pitanje pohranjivanja statike
Ako vaša web stranica ima "samo" 10 gigabajta i u potpunosti je postavite u spremnike, dobit ćete spremnike od 10 gigabajta za čije postavljanje treba vječnost.
Morate pohraniti "najteže" dijelove mjesta izvan spremnika i postavlja se pitanje kako to učiniti ispravno
Što nedostaje našem rješenju?
Cjelokupni Bitrix kod nije podijeljen na mikrofunkcije/mikroservise (tako da je odvojena registracija, odvojen modul online trgovine itd.). U svakom spremniku pohranjujemo cijelu bazu kodova.
Također ne pohranjujemo bazu podataka u Kubernetes (i dalje sam implementirao rješenja s bazom podataka u Kubernetesu za razvojna okruženja, ali ne i za proizvodnju).
Administratorima stranice i dalje će biti vidljivo da stranica radi na Kubernetesu. Funkcija "Provjera sustava" ne radi ispravno; da biste uredili kod stranice s administratorske ploče, prvo morate kliknuti gumb "Želim urediti kod".
Problemi su identificirani, potreba za implementacijom mikroservisa je utvrđena, cilj je jasan - dobiti radni sustav za pokretanje aplikacija na Bitrixu u Kubernetesu, uz očuvanje i mogućnosti Bitrixa i prednosti Kubernetesa. Krenimo s implementacijom.
arhitektura
Postoji mnogo "radnih" mahuna s web poslužiteljem (radnici).
Jedan pod s cron zadacima (potreban je samo jedan).
Jedna nadogradnja za uređivanje koda stranice s administratorske ploče (također je potrebna samo jedna).
Rješavamo pitanja:
- Gdje pohraniti sesije?
- Gdje pohraniti predmemoriju?
- Gdje pohraniti statiku, a ne smjestiti gigabajte statike u hrpu spremnika?
- Kako će baza podataka funkcionirati?
Docker slika
Počinjemo izgradnjom Docker slike.
Idealna opcija je da imamo jednu univerzalnu sliku, na temelju koje dobivamo radničke podove, podove s Crontaskovima i nadogradne podove.
.
Uključuje nginx, apache/php-fpm (može se odabrati tijekom izgradnje), msmtp za slanje pošte i cron.
Prilikom sastavljanja slike, cijela baza koda stranice kopira se u direktorij /app (osim onih dijelova koje ćemo premjestiti u zasebnu zajedničku pohranu).
Mikroservisi, usluge
radničke mahune:
- Spremnik s nginxom + spremnik apache/php-fpm + msmtp
- Nije uspjelo premjestiti msmtp u zasebnu mikroservis, Bitrix počinje biti ogorčen što ne može izravno poslati poštu
- Svaki spremnik ima kompletnu bazu koda.
- Zabrana mijenjanja šifre u kontejnerima.
cron pod:
- spremnik s apacheom, php-om, cronom
- kompletna baza koda uključena
- zabrana mijenjanja koda u kontejnerima
nadogradnja pod:
- nginx spremnik + apache/php-fpm spremnik + msmtp
- Ne postoji zabrana mijenjanja šifre u kontejnerima
pohranjivanje sesije
Bitrix predmemorija za pohranu
Još jedna važna stvar: u kubernetes secrets pohranjujemo lozinke za spajanje na sve, od baze podataka do pošte. Dobivamo bonus: lozinke su vidljive samo onima kojima damo pristup tajnama, a ne svima koji imaju pristup bazi koda projekta.
Spremište za statiku
Možete koristiti bilo što: ceph, nfs (ali ne preporučujemo nfs za proizvodnju), mrežnu pohranu od pružatelja usluga oblaka itd.
Skladište će morati biti povezano u spremnicima s /upload/ direktorijom stranice i drugim direktorijima sa statičnim sadržajem.
Baza podataka
Radi jednostavnosti, preporučujemo premještanje baze podataka izvan Kubernetesa. Baza u Kubernetesu zaseban je složeni zadatak; shemu će učiniti složenijom za red veličine.
Pohrana sesije
Koristimo memcached :)
Dobro upravlja pohranom sesije, klasteriran je i podržan je "nativno" kao session.save_path u php-u. Takav sustav je više puta testiran u klasičnoj monolitnoj arhitekturi, kada smo gradili klastere s velikim brojem web servera. Za raspoređivanje koristimo kormilo.
$ helm install stable/memcached --name sessionphp.ini - ovdje slika sadrži postavke za spremanje sesija u memcached
Koristili smo varijable okruženja za prijenos podataka o hostovima s memcached-om .
To vam omogućuje korištenje istog koda u dev, stage, test, prod okruženjima (memcachirana imena hostova u njima bit će različita, tako da moramo proslijediti jedinstveni naziv hosta za sesije svakom okruženju).
Bitrix predmemorija za pohranu
Trebamo pohranu otpornu na pogreške u koju sve jedinice mogu pisati i čitati.
Također koristimo memcached.
Ovo rješenje preporučuje sam Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - ovdje u Bitrixu je navedeno gdje je pohranjena predmemorija
Također koristimo varijable okruženja.
Krontaski
Postoje različiti pristupi pokretanju Crontasksa u Kubernetesu.
- odvojena implementacija s podom za pokretanje Crontaskova
- cronjob za izvršavanje crontaskova (ako je ovo web aplikacija - s wget , ili kubectl exec unutar jednog od radnih modula itd.)
- i tako dalje
Možete se raspravljati oko najispravnijeg, ali u ovom slučaju odabrali smo opciju "odvojena implementacija s podovima za Crontasks"
Kako se to radi:
- dodajte cron zadatke putem ConfigMapa ili putem datoteke config/addcron
- u jednoj instanci pokrećemo spremnik identičan radničkom modulu + dopuštamo izvršavanje krunskih zadataka u njemu
- koristi se ista baza koda, zahvaljujući unificiranju, montaža spremnika je jednostavna
Što dobro dobivamo:
- imamo Crontasks koji radi u okruženju identičnom okruženju programera (docker)
- Crontasks ne treba "prepisivati" za Kubernetes, rade u istom obliku i u istoj bazi koda kao i prije
- cron zadatke mogu dodati svi članovi tima s pravima predaje u proizvodnu granu, a ne samo administratori
Southbridge K8SDeploy modul i uređivanje koda s administratorske ploče
Govorili smo o nadogradnji pod?
Kako tamo usmjeriti promet?
Hura, napisali smo modul za ovo u PHP-u :) Ovo je mali klasični modul za Bitrix. Još nije javno dostupan, ali planiramo ga otvoriti.
Modul se instalira kao obični modul u Bitrixu:
A to izgleda ovako:
Omogućuje vam da postavite kolačić koji identificira administratora stranice i omogućuje Kubernetesu slanje prometa u nadogradnju.
Kada su promjene dovršene, trebate kliknuti git push, promjene koda bit će poslane git-u, a zatim će sustav izgraditi sliku s novom verzijom koda i "razviti" je po klasteru, zamjenjujući stare mahune .
Da, malo je to štaka, ali u isto vrijeme održavamo arhitekturu mikroservisa i ne oduzimamo korisnicima Bitrixa njihovu omiljenu priliku da isprave kod iz administratorske ploče. Na kraju, ovo je opcija, problem uređivanja koda možete riješiti na drugačiji način.
Shema kormila
Za izradu aplikacija na Kubernetesu obično koristimo upravitelj paketa Helm.
Za naše Bitrix rješenje u Kubernetesu, Sergey Bondarev, naš vodeći administrator sustava, napisao je poseban Helm grafikon.
Gradi worker, nadogradnju, cron podove, konfigurira ulaze, usluge i prenosi varijable iz Kubernetes tajni u podove.
Pohranjujemo kod u Gitlabu, a također pokrećemo Helm build iz Gitlaba.
Ukratko to izgleda ovako
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm vam također omogućuje "bešavno" vraćanje ako iznenada nešto pođe po zlu tijekom postavljanja. Lijepo je kad niste u panici "popravite kod preko ftp-a jer je prod pao", nego Kubernetes to radi automatski, i bez zastoja.
Rasporedi
Da, obožavatelji smo Gitlaba i Gitlaba CI, koristimo ga :)
Prilikom predaje u Gitlabu u repozitorij projekta, Gitlab pokreće cjevovod koji postavlja novu verziju okruženja.
faze:
- build (izrada nove Docker slike)
- test (testiranje)
- čišćenje (uklanjanje testnog okruženja)
- push (šaljemo u Docker registar)
- deploy (mi implementiramo aplikaciju u Kubernetes preko Helma).
Hura, spremno je, implementirajmo ga!
Pa, ili postavite pitanja ako ih ima.
Pa što smo učinili
S tehničkog gledišta:
- dokerizirani Bitrix;
- "izrezati" Bitrix u spremnike, od kojih svaki obavlja minimalne funkcije;
- postignuto stanje kontejnera bez stanja;
- riješen problem s ažuriranjem Bitrixa u Kubernetesu;
- sve funkcije Bitrixa nastavile su raditi (gotovo sve);
- Radili smo na implementaciji na Kubernetes i vraćanju između verzija.
S poslovnog gledišta:
- tolerancija kvarova;
- Kubernetes alati (jednostavna integracija s Gitlab CI, besprijekorna implementacija, itd.);
- tajne lozinke (vidljive samo onima kojima je izravno odobren pristup lozinkama);
- Prikladno je stvoriti dodatna okruženja (za razvoj, testove itd.) unutar jedne infrastrukture.
Izvor: www.habr.com