Sysadminka-järjestelmänvalvojatapaamisia järjestetään Tšeljabinskissa, ja viimeisessä raportoin ratkaisustamme Kubernetesin 1C-Bitrixin sovellusten ajamiseen.
Bitrix, Kubernetes, Ceph - loistava sekoitus?
Kerron sinulle, kuinka koomme tästä kaikesta toimivan ratkaisun.
Mennään!
Tapaaminen pidettiin 18. huhtikuuta Tšeljabinskissa. Tapaamisistamme voit lukea osoitteessa ja katsoa .
Jos haluat tulla meille raportin kanssa tai kuuntelijaksi - tervetuloa, kirjoita osoitteeseen [sähköposti suojattu] ja Telegramissa t.me/vadimisakanov.
Raporttini
Ratkaisu "Bitrix in Kubernetes, versio Southbridge 1.0"
Puhun ratkaisustamme "kubernetes-nukkeille" -muodossa, kuten tapaamisessa tehtiin. Mutta oletan, että tiedät sanat Bitrix, Docker, Kubernetes, Ceph ainakin Wikipedian artikkelien tasolla.
Mitä Bitrixistä on valmista Kubernetesissa?
Koko Internetissä on hyvin vähän tietoa Bitrix-sovellusten toiminnasta Kubernetesissa.
Löysin vain nämä materiaalit:
Alexander Serbulin, 1C-Bitrixin ja Anton Tuzlukovin raportti Qsoftilta:
Suosittelen kuuntelemaan.
Oman ratkaisun kehittäminen käyttäjältä .
Löytyi lisää .
Aaand... oikeastaan, siinä kaikki.
Varoitan, emme ole tarkistaneet yllä olevien linkkien ratkaisujen laatua :)
Muuten, kun valmistelimme ratkaisuamme, puhuin Alexander Serbulin kanssa, silloin hänen raporttinsa ei ollut vielä ilmestynyt, joten dioissani on kohta "Bitrix ei käytä Kubernetesia".
Mutta Bitrixin käyttämiseen Dockerissa on jo paljon valmiita Docker-kuvia:
Riittääkö tämä täydellisen ratkaisun luomiseen Bitrixille Kubernetesissa?
Ei. On olemassa suuri määrä ongelmia, jotka on ratkaistava.
Mitä ongelmia Bitrixin kanssa on Kubernetesissa?
Ensinnäkin Dockerhubin valmiit kuvat eivät sovellu Kubernetesille
Jos haluamme rakentaa mikropalveluarkkitehtuurin (ja Kubernetesissa teemme yleensä), meidän on erotettava Kubernetes-sovelluksemme säilöihin ja jokaisen säiliön on suoritettava yksi pieni toiminto (ja tehtävä se hyvin). Miksi vain yksi? Lyhyesti sanottuna mitä yksinkertaisempi, sitä luotettavampi.
Jos haluat olla tarkempi, katso tämä artikkeli ja video:
Dockerhubin Docker-kuvat on rakennettu pääasiassa all-in-one-periaatteella, joten meidän piti silti tehdä oma pyörämme ja jopa luoda kuvia tyhjästä.
Toinen - sivuston koodia muokataan hallintapaneelista
Loimme sivustolle uuden osion - koodi päivitettiin (lisättiin hakemisto uuden osion nimellä).
Jos muutit komponentin ominaisuuksia hallintapaneelista, koodi muuttui.
Kubernetes "oletuksena" ei voi toimia tämän kanssa; säilöjen on oltava valtiottomia.
Syy: Jokainen klusterin säilö (pod) käsittelee vain osan liikenteestä. Jos muutat koodia vain yhdessä säilössä (pod), koodi on erilainen eri ryhmissä, sivusto toimii eri tavalla ja sivuston eri versiot näytetään eri käyttäjille. Et voi elää niin.
Kolmanneksi sinun on ratkaistava ongelma käyttöönoton avulla
Jos meillä on monoliitti ja yksi "klassinen" palvelin, kaikki on melko yksinkertaista: otamme käyttöön uuden koodikannan, siirrämme tietokannan, siirrämme liikenteen koodin uuteen versioon. Vaihto tapahtuu välittömästi.
Jos meillä on Kubernetesissä mikropalveluiksi leikattu sivusto, siellä on paljon kontteja koodilla - oh. Sinun on kerättävä säilöjä uudella koodiversiolla, otettava ne käyttöön vanhojen sijasta, siirrettävä tietokanta oikein ja mieluiten tehdä tämä vierailijoiden huomaamatta. Onneksi Kubernetes auttaa meitä tässä tukemalla koko joukkoa erilaisia käyttöönottoja.
Neljänneksi - sinun on ratkaistava staattisen sähkön tallentamista koskeva kysymys
Jos sivustosi on "vain" 10 gigatavua ja otat sen käyttöön kokonaan säilöissä, saat 10 gigatavun säilöjä, joiden käyttöönotto kestää ikuisuuden.
Sinun on säilytettävä sivuston "raskaimmat" osat konttien ulkopuolella, ja herää kysymys, kuinka tämä tehdään oikein
Mitä ratkaisustamme puuttuu?
Koko Bitrix-koodia ei ole jaettu mikrotoimintoihin/mikropalveluihin (joten rekisteröinti on erillinen, verkkokauppamoduuli on erillinen jne.). Säilytämme koko koodikannan jokaiseen säiliöön.
Emme myöskään tallenna tietokantaa Kubernetesiin (toteutin edelleen Kubernetesin tietokannan avulla olevia ratkaisuja kehitysympäristöihin, mutta en tuotantoon).
Sivuston ylläpitäjät huomaavat edelleen, että sivusto toimii Kubernetesissa. "Järjestelmän tarkistus" -toiminto ei toimi oikein; muokataksesi sivuston koodia hallintapaneelista, sinun on ensin napsautettava "Haluan muokata koodia" -painiketta.
Ongelmat on tunnistettu, mikropalveluiden käyttöönottotarve on selvitetty, tavoite on selvä - saada toimiva järjestelmä Bitrixin sovellusten ajamiseen Kubernetesissa säilyttäen sekä Bitrixin ominaisuudet että Kubernetesin edut. Aloitetaan toteutus.
Arkkitehtuuri
On monia "toimivia" podeja, joissa on verkkopalvelin (työntekijät).
One under cron-tehtävillä (vain yksi vaaditaan).
Yksi päivitys sivustokoodin muokkaamiseen hallintapaneelista (myös vain yksi vaaditaan).
Ratkaisemme kysymyksiä:
- Mihin istunnot tallennetaan?
- Missä välimuisti säilytetään?
- Mihin staattista materiaalia säilytetään, ei gigatavujen staattisen koon sijoittamiseen astioihin?
- Miten tietokanta toimii?
Docker-kuva
Aloitamme rakentamalla Docker-kuvan.
Ihanteellinen vaihtoehto on, että meillä on yksi universaali kuva, jonka perusteella saamme worker podeja, podeja Crontasksilla ja päivitystyyppejä.
.
Se sisältää nginx:n, apache/php-fpm:n (voidaan valita rakentamisen aikana), msmtp:n sähköpostin lähettämiseen ja cronin.
Kuvaa koottaessa koko sivuston koodikanta kopioidaan /app-hakemistoon (lukuun ottamatta niitä osia, jotka siirrämme erilliseen jaettuun tallennustilaan).
Mikropalvelut, palvelut
työntekijäpalot:
- Säiliö, jossa on nginx + kontti apache/php-fpm + msmtp
- Msmtp:n siirtäminen erilliseen mikropalveluun ei onnistunut, Bitrix alkaa olla närkästynyt, ettei se pysty lähettämään postia suoraan
- Jokaisella säiliöllä on täydellinen koodikanta.
- Kielto muuttaa koodia säiliöissä.
cron alla:
- kontti, jossa apache, php, cron
- täydellinen koodikanta mukana
- koodin vaihtamisen kielto konteissa
päivitys alla:
- nginx-säilö + apache/php-fpm-säilö + msmtp
- Säiliöiden koodin vaihtaminen ei ole kiellettyä
istunnon tallennustila
Bitrix-välimuisti
Toinen tärkeä asia: tallennamme salasanoja kubernetes-salaisuuksiin yhteyden muodostamista varten kaikkeen tietokannasta sähköpostiin. Saamme bonuksen: salasanat näkyvät vain niille, joille annamme pääsyn salaisuuksiin, eivätkä kaikki, joilla on pääsy projektin koodikantaan.
Statiikan säilytystilaa
Voit käyttää mitä tahansa: cephiä, nfs:ää (mutta emme suosittele nfs:ää tuotantoon), verkkotallennustilaa pilvipalveluntarjoajilta jne.
Tallennus on yhdistettävä konteissa sivuston /upload/-hakemistoon ja muihin staattista sisältöä sisältäviin hakemistoihin.
tietokanta
Yksinkertaisuuden vuoksi suosittelemme tietokannan siirtämistä Kubernetesin ulkopuolelle. Kubernetesin tukikohta on erillinen monimutkainen tehtävä, joka tekee suunnitelmasta suuruusluokkaa monimutkaisemman.
Istunnon tallennus
Käytämme memcachedia :)
Se käsittelee istunnon tallennusta hyvin, on klusteroitu ja sitä tuetaan "natiivisti" nimellä session.save_path php:ssä. Tällaista järjestelmää on testattu monta kertaa klassisessa monoliittisessa arkkitehtuurissa, kun rakensimme klustereita suurella määrällä web-palvelimia. Käyttöönottoa varten käytämme ruoria.
$ helm install stable/memcached --name sessionphp.ini - tässä kuva sisältää asetukset istuntojen tallentamiseksi memcachediin
Käytimme ympäristömuuttujia välittämään tietoja isännistä, joissa on memcached .
Tämän ansiosta voit käyttää samaa koodia kehitys-, vaihe-, testi- ja tuotantoympäristöissä (välimuistissa olevat isäntänimet niissä ovat erilaisia, joten meidän on välitettävä yksilöllinen isäntänimi istuntoja varten kullekin ympäristölle).
Bitrix-välimuisti
Tarvitsemme vikasietoisen tallennustilan, johon kaikki podit voivat kirjoittaa ja josta lukea.
Käytämme myös memcachedia.
Tätä ratkaisua suosittelee itse Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - tässä Bitrixissä määritellään, mihin välimuisti on tallennettu
Käytämme myös ympäristömuuttujia.
Krontaski
Crontaskin suorittamiseen Kubernetesissa on erilaisia lähestymistapoja.
- erillinen käyttöönotto podilla Crontaskin suorittamista varten
- cronjob crontaskien suorittamiseen (jos tämä on verkkosovellus - wget , tai kubectl exec jossakin worker podissa jne.)
- ja niin edelleen
Voit kiistellä oikeasta, mutta tässä tapauksessa valitsimme vaihtoehdon "erillinen käyttöönotto podilla Crontasksille"
Kuinka se tehdään:
- Lisää cron-tehtäviä ConfigMapin tai config/addcron-tiedoston kautta
- Yhdessä tapauksessa käynnistämme kontin, joka on identtinen worker podin kanssa + sallimme kruunutehtävien suorittamisen siinä
- käytetään samaa koodipohjaa, yhdistämisen ansiosta säiliön kokoaminen on yksinkertaista
Mitä hyvää saamme:
- meillä on toimivat Crontaskit ympäristössä, joka on identtinen kehittäjien ympäristön kanssa (docker)
- Crontesia ei tarvitse “kirjoittaa uudelleen” Kubernetesille, ne toimivat samassa muodossa ja samassa koodikannassa kuin ennenkin.
- cron-tehtäviä voivat lisätä kaikki tiimin jäsenet, joilla on sitoutumisoikeudet tuotantohaaraan, eivät vain järjestelmänvalvojat
Southbridge K8SDeploy moduulin ja koodin muokkaus hallintapaneelista
Puhuimme päivityksestä alle?
Kuinka ohjata liikennettä sinne?
Hurraa, kirjoitimme tälle moduulin PHP:llä :) Tämä on pieni klassinen moduuli Bitrixille. Se ei ole vielä julkisesti saatavilla, mutta aiomme avata sen.
Moduuli asennetaan kuten tavallinen moduuli Bitrixiin:
Ja se näyttää tältä:
Sen avulla voit asettaa evästeen, joka tunnistaa sivuston ylläpitäjän ja sallii Kubernetesin lähettää liikennettä päivityskoteloon.
Kun muutokset on tehty, sinun on napsautettava git push, koodimuutokset lähetetään gitille, sitten järjestelmä rakentaa kuvan uudella koodiversiolla ja "vieroittaa" sen klusterin poikki korvaten vanhat podit. .
Kyllä, se on hieman haarukka, mutta samalla ylläpidämme mikropalveluarkkitehtuuria emmekä vie Bitrixin käyttäjiltä heidän suosikkimahdollisuuttaan korjata koodia hallintapaneelista. Loppujen lopuksi tämä on vaihtoehto; voit ratkaista koodin muokkaamisen ongelman eri tavalla.
Ruorikaavio
Sovellusten rakentamiseen Kubernetesille käytämme yleensä Helm-pakettienhallintaa.
Kubernetesin Bitrix-ratkaisullemme Sergey Bondarev, johtava järjestelmänvalvojamme, kirjoitti erityisen Helm-kaavion.
Se rakentaa worker-, ugrade-, cron-podeja, määrittää sisääntulot, palvelut ja siirtää muuttujat Kubernetes-salaisuuksista podeihin.
Tallennamme koodin Gitlabiin ja suoritamme myös Helm-koontiversion Gitlabista.
Lyhyesti sanottuna se näyttää tältä
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelmin avulla voit myös tehdä "saumattoman" palautuksen, jos jokin menee yhtäkkiä vikaan käyttöönoton aikana. On mukavaa, kun et ole paniikissa "korjaa koodi ftp:n kautta, koska tuote putosi", mutta Kubernetes tekee sen automaattisesti ja ilman seisokkeja.
Ota käyttöön
Kyllä, olemme Gitlab & Gitlab CI:n faneja, käytämme sitä :)
Sitoutuessaan Gitlabissa projektivarastoon Gitlab käynnistää putkilinjan, joka ottaa käyttöön uuden version ympäristöstä.
vaiheet:
- rakentaa (uusi Docker-kuvan rakentaminen)
- testi (testaus)
- siivoaminen (testiympäristön poistaminen)
- push (lähetämme sen Docker-rekisteriin)
- käyttöönotto (otamme sovelluksen käyttöön Kubernetesiin Helmin kautta).
Hurraa, se on valmis, toteutetaan se!
No, tai kysy kysymyksiä, jos niitä on.
Joten mitä teimme
Teknisestä näkökulmasta:
- telakoitu Bitrix;
- "leikkaa" Bitrix säiliöihin, joista jokainen suorittaa vähimmäistoiminnot;
- saavutettu konttien valtioton tila;
- ratkaisi ongelman Bitrixin päivittämisellä Kubernetesissa;
- kaikki Bitrix-toiminnot jatkoivat toimintaansa (melkein kaikki);
- Työskentelimme Kubernetesin käyttöönoton ja versioiden välisen palautuksen parissa.
Liiketoiminnan näkökulmasta:
- vikasietoisuus;
- Kubernetes-työkalut (helppo integrointi Gitlab CI:n kanssa, saumaton käyttöönotto jne.);
- salaiset salasanat (näkyy vain niille, joilla on suora pääsy salasanoihin);
- On kätevää luoda lisäympäristöjä (kehitystä, testausta jne.) varten yhdessä infrastruktuurissa.
Lähde: will.com