Sastanci sistem administratora Sysadminka se održavaju u Čeljabinsku, a na posljednjem sam dao izvještaj 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 iz svega ovoga napravili radno rješenje.
Idemo!
Sastanak je održan 18. aprila u Čeljabinsku. O našim susretima možete pročitati na i pogledajte .
Ako želite da nam dođete sa izveštajem ili kao slušalac - dobrodošli, pišite [email zaštićen] i na Telegramu t.me/vadimisakanov.
Moj izveštaj
Rješenje "Bitrix u Kubernetesu, verzija Southbridge 1.0"
Govoriću o našem rješenju u formatu “za lutke u Kubernetes”, kao što je i urađeno na sastanku. Ali pretpostavljam da znate riječi Bitrix, Docker, Kubernetes, Ceph barem na nivou članaka na Wikipediji.
Šta je spremno za Bitrix u Kubernetesu?
Na cijelom Internetu ima vrlo malo informacija o radu Bitrix aplikacija u Kubernetesu.
Našao sam samo ove materijale:
Izvještaj Aleksandra Serbula, 1C-Bitrix, i Antona Tuzlukova iz Qsofta:
Preporučujem da ga poslušate.
Razvijanje vlastitog rješenja od korisnika .
Pronađeno više .
Aaa... zapravo, to je sve.
Upozoravam vas, nismo provjerili kvalitet rješenja na gornjim linkovima :)
Inače, kada sam pripremao naše rešenje, razgovarao sam sa Aleksandrom Serbulom, tada se njegov izveštaj još nije pojavio, tako da u mojim slajdovima postoji stavka „Bitrix ne koristi Kubernetes“.
Ali već postoji mnogo gotovih Docker slika za pokretanje Bitrixa u Dockeru:
Da li je ovo dovoljno za kreiranje kompletnog rješenja za Bitrix u Kubernetesu?
br. Postoji veliki broj problema koje treba riješiti.
Koji su problemi sa Bitrixom u Kubernetesu?
Prvo, gotove slike iz Dockerhub-a nisu prikladne za Kubernetes
Ako želimo da izgradimo arhitekturu mikroservisa (a u Kubernetesu to obično radimo), moramo da odvojimo našu Kubernetes aplikaciju u kontejnere i da svaki kontejner izvrši jednu malu funkciju (i to dobro). Zašto samo jedan? Ukratko, što jednostavnije to pouzdanije.
Da budete precizniji, pogledajte ovaj članak i video, molimo:
Docker slike u Dockerhub-u su uglavnom izgrađene na principu sve-u-jednom, tako da smo ipak morali napraviti vlastiti bicikl, pa čak i kreirati slike od nule.
Drugo - kod web mjesta se uređuje sa administrativnog panela
Napravili smo novi odjeljak na stranici - kod je ažuriran (dodan je direktorij s imenom novog odjeljka).
Ako ste promijenili svojstva komponente na admin panelu, kod se promijenio.
Kubernetes “podrazumevano” ne može raditi s ovim; kontejneri moraju biti bez državljanstva.
Razlog: Svaki kontejner (pod) u klasteru obrađuje samo dio prometa. Ako promijenite kod samo u jednom spremniku (pod), tada će kod biti drugačiji u različitim podovima, stranica će raditi drugačije, a različite verzije stranice će biti prikazane različitim korisnicima. Ne možeš tako da živiš.
Treće - morate riješiti problem s implementacijom
Ako imamo monolit i jedan “klasični” server, sve je prilično jednostavno: postavljamo novu bazu koda, migriramo bazu podataka, prebacimo promet na novu verziju koda. Prebacivanje se dešava trenutno.
Ako imamo lokaciju u Kubernetesu, isečenu na mikroservise, ima puno kontejnera sa kodom - oh. Morate prikupiti kontejnere s novom verzijom koda, izbaciti ih umjesto starih, ispravno migrirati bazu podataka i idealno to učiniti neprimijećeno od strane posjetitelja. Srećom, Kubernetes nam pomaže u tome, podržavajući čitav niz različitih tipova implementacije.
Četvrto - morate riješiti pitanje pohranjivanja statike
Ako vaša stranica ima “samo” 10 gigabajta i u potpunosti je implementirate u kontejnerima, na kraju ćete imati 10 gigabajt kontejnera za koje je potrebno vječno da se implementiraju.
"Najteže" dijelove stranice morate pohraniti izvan kontejnera i postavlja se pitanje kako to ispravno učiniti
Šta nedostaje našem rješenju?
Cijeli Bitrix kod nije podijeljen na mikrofunkcije/mikroservise (tako da je registracija odvojena, modul online trgovine odvojen, itd.). Cijelu bazu koda pohranjujemo u svaki kontejner.
Takođe ne pohranjujemo bazu podataka u Kubernetes (ja sam još implementirao rješenja sa bazom podataka u Kubernetes za razvojna okruženja, ali ne i za proizvodnju).
Administratori sajta će i dalje moći da primete da sajt radi na Kubernetesu. Funkcija “provjere sistema” ne radi ispravno; da biste uredili kod web-mjesta na administrativnom panelu, prvo morate kliknuti na dugme “Želim urediti kod”.
Problemi su identifikovani, potreba za implementacijom mikroservisa je utvrđena, cilj je jasan - dobiti radni sistem za pokretanje aplikacija na Bitrixu u Kubernetesu, uz očuvanje kako mogućnosti Bitrixa, tako i prednosti Kubernetesa. Počnimo sa implementacijom.
arhitektura
Postoji mnogo "radnih" podova sa web serverom (radnici).
Jedan ispod sa cron zadacima (samo jedan je potreban).
Jedna nadogradnja za uređivanje koda stranice sa admin panela (također je potrebna samo jedna).
Rješavamo pitanja:
- Gdje pohraniti sesije?
- Gdje pohraniti keš memoriju?
- Gdje pohraniti statiku, a ne staviti gigabajte statike u gomilu kontejnera?
- Kako će baza podataka raditi?
Docker slika
Počinjemo izgradnjom Docker slike.
Idealna opcija je da imamo jednu univerzalnu sliku, na osnovu koje dobijamo worker podove, podove sa Crontasks i upgrade podove.
.
Uključuje nginx, apache/php-fpm (može se odabrati tokom izgradnje), msmtp za slanje pošte i cron.
Prilikom sastavljanja slike, cjelokupna baza koda stranice se kopira u /app direktorij (s izuzetkom onih dijelova koje ćemo premjestiti u zasebno zajedničko skladište).
Mikrousluge, usluge
radničke mahune:
- Kontejner sa nginx + kontejner apache/php-fpm + msmtp
- Nije uspjelo premjestiti msmtp u zasebnu mikroservis, Bitrix počinje da se ljuti što ne može direktno slati poštu
- Svaki kontejner ima kompletnu kodnu bazu.
- Zabrana promjene koda u kontejnerima.
cron ispod:
- kontejner sa apache, php, cron
- kompletna baza kodova uključena
- zabrana promjene koda u kontejnerima
nadogradite pod:
- nginx kontejner + apache/php-fpm kontejner + msmtp
- Ne postoji zabrana promjene koda u kontejnerima
skladištenje sesije
Bitrix keš memorija
Još jedna važna stvar: čuvamo lozinke za povezivanje sa svime, od baze podataka do pošte, u kubernetes tajne. Dobijamo bonus: lozinke su vidljive samo onima kojima damo pristup tajnama, a ne svima koji imaju pristup bazi kodova projekta.
Skladište za statiku
Možete koristiti bilo što: ceph, nfs (ali ne preporučujemo nfs za proizvodnju), mrežnu pohranu od dobavljača u oblaku, itd.
Skladište će morati biti povezano u kontejnerima na /upload/ direktorij stranice i druge direktorije sa statičnim sadržajem.
Baza podataka
Radi jednostavnosti, preporučujemo premještanje baze podataka izvan Kubernetesa. Baza u Kubernetesu je zaseban složen zadatak; to će shemu učiniti za red veličine složenijom.
Skladištenje sesije
Koristimo memcached :)
Dobro rukuje skladištenjem sesije, grupiran je i podržan je „prirodno“ kao session.save_path u php-u. Ovakav sistem je mnogo puta testiran u klasičnoj monolitnoj arhitekturi, kada smo gradili klastere sa velikim brojem web servera. Za raspoređivanje koristimo kormilo.
$ helm install stable/memcached --name sessionphp.ini - ovdje slika sadrži postavke za pohranjivanje sesija u memcached
Koristili smo varijable okruženja za prosljeđivanje podataka o hostovima s memcached-om .
Ovo vam omogućava da koristite isti kod u dev, stage, test, prod okruženjima (memcached imena hostova u njima će biti različita, tako da moramo proslijediti jedinstveno ime hosta za sesije svakom okruženju).
Bitrix keš memorija
Trebamo skladište otporno na greške u koje svi podovi mogu pisati i čitati iz njih.
Takođe koristimo memcached.
Ovo rješenje preporučuje sam Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - ovdje u Bitrix-u je navedeno gdje se pohranjuje keš memorija
Takođe koristimo varijable okruženja.
Krontaski
Postoje različiti pristupi pokretanju Crontasksa u Kubernetesu.
- odvojena implementacija sa podom za pokretanje Crontasksa
- cronjob za izvršavanje crontasksa (ako je ovo web aplikacija - sa wget , ili kubectl exec unutar jednog od radnih modula, itd.)
- itd
Možete se svađati oko najispravnijeg, ali u ovom slučaju smo odabrali opciju “odvojena implementacija sa podovima za Crontasks”
Kako se to radi:
- dodajte cron zadatke preko ConfigMap-a ili putem datoteke config/addcron
- u jednom slučaju pokrećemo kontejner identičan Worker pod + dozvoljavamo izvršavanje krunskih zadataka u njemu
- koristi se ista baza koda, zahvaljujući unificiranju, montaža kontejnera je jednostavna
Šta dobro dobijamo:
- imamo Crontasks koji radi u okruženju identičnom okruženju programera (docker)
- Crontasks ne treba "prepisivati" za Kubernetes, oni rade u istom obliku i u istoj bazi koda kao i prije
- cron zadatke mogu dodati svi članovi tima s pravima urezivanja u produkcijsku granu, a ne samo administratori
Southbridge K8SDeploy modul i uređivanje koda sa admin panela
Razgovarali smo o nadogradnji ispod?
Kako tamo usmjeriti saobraćaj?
Ura, napisali smo modul za ovo u PHP-u :) Ovo je mali klasični modul za Bitrix. Još nije javno dostupan, ali planiramo da ga otvorimo.
Modul se instalira kao običan modul u Bitrix-u:
A to izgleda ovako:
Omogućava vam da postavite kolačić koji identifikuje administratora stranice i omogućava Kubernetesu da šalje promet na modul za nadogradnju.
Kada se promjene dovrše, trebate kliknuti na git push, promjene koda će biti poslane u git, a zatim će sistem napraviti sliku s novom verzijom koda i "razvući" je po cijelom klasteru, zamjenjujući stare podove. .
Da, to je malo štaka, ali u isto vrijeme održavamo mikroservisnu arhitekturu i ne oduzimamo korisnicima Bitrixa njihovu omiljenu priliku da isprave kod s admin panela. Na kraju, ovo je opcija; problem uređivanja koda možete riješiti na drugačiji način.
Helm chart
Da bismo napravili aplikacije na Kubernetesu, obično koristimo Helm menadžer paketa.
Za naše Bitrix rešenje u Kubernetesu, Sergej Bondarev, naš vodeći sistem administrator, napisao je poseban Helm grafikon.
Pravi worker, ugrade, cron podove, konfiguriše ulaze, usluge i prenosi varijable iz Kubernetes tajni u podove.
Kod pohranjujemo u Gitlab, 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đe omogućava da izvršite „bešavno“ vraćanje unatrag ako iznenada nešto pođe naopako tokom implementacije. Lijepo je kada niste u panici "popravite kod preko ftp-a jer je prod pao", ali Kubernetes to radi automatski i bez zastoja.
Razviti
Da, mi smo fanovi Gitlaba & Gitlab CI, koristimo ga :)
Kada se u Gitlabu predaje u repozitorijum projekta, Gitlab pokreće cevovod koji postavlja novu verziju okruženja.
Faze:
- build (izgradnja nove Docker slike)
- test (testiranje)
- očistiti (uklanjanje testnog okruženja)
- push (šaljemo ga u Docker registar)
- deploy (mi implementiramo aplikaciju u Kubernetes preko Helma).
Ura, spremno je, implementirajmo!
Pa, ili postavljajte pitanja ako ih ima.
Pa šta smo uradili
Sa tehničke tačke gledišta:
- dockerized Bitrix;
- "izrezati" Bitrix u kontejnere, od kojih svaki obavlja minimum funkcija;
- postignuto stanje kontejnera bez državljanstva;
- riješen problem sa ažuriranjem Bitrix-a u Kubernetesu;
- sve Bitrix funkcije su nastavile raditi (skoro sve);
- Radili smo na implementaciji na Kubernetes i vraćanju između verzija.
Sa poslovnog stanovišta:
- tolerancije grešaka;
- Kubernetes alati (jednostavna integracija sa Gitlab CI, besprekorna implementacija, itd.);
- tajne lozinke (vidljive samo onima kojima je direktno odobren pristup lozinkama);
- Pogodno je kreirati dodatna okruženja (za razvoj, testove, itd.) unutar jedne infrastrukture.
izvor: www.habr.com