{"id":35581,"date":"2019-10-31T22:05:09","date_gmt":"2019-10-31T19:05:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/southbridge-v-chelyabinske-i-bitriks-v-kubernetes\/"},"modified":"2019-10-31T22:05:09","modified_gmt":"2019-10-31T19:05:09","slug":"southbridge-v-chelyabinske-i-bitriks-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/southbridge-v-chelyabinske-i-bitriks-v-kubernetes","title":{"rendered":"Southbridge i Tsjeljabinsk og Bitrix i Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I Tsjeljabinsk holdes det m\u00f8ter for systemadministratoren Sysadminka, og p\u00e5 det siste m\u00f8tet presenterte jeg v\u00e5r l\u00f8sning for \u00e5 kj\u00f8re applikasjoner p\u00e5 1\u0421-Bitrix i Kubernetes.<\/p>\n

<\/p>\n

Bitrix, Kubernetes, Ceph \u2013 en utmerket kombinasjon?<\/p>\n

<\/p>\n

Jeg vil fortelle hvordan vi bygde en fungerende l\u00f8sning ut av alt dette.<\/p>\n

<\/p>\n

La oss g\u00e5!<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

<\/a><\/noindex><\/p>\n

M\u00f8tet fant sted 18. april i Tsjeljabinsk. Du kan lese om v\u00e5re m\u00f8ter i Timepad<\/a><\/noindex> og se dem p\u00e5 YouTube<\/a><\/noindex>.<\/p>\n

<\/p>\n

Hvis du \u00f8nsker \u00e5 komme til oss med en presentasjon eller som lytter \u2013 velkommen, skriv til vadim.isakanov@gmail.com og p\u00e5 Telegram t.me\/vadimisakanov. <\/p>\n

<\/p>\n

Min presentasjon<\/h2>\n

<\/p>\n

\"Southbridge<\/a><\/noindex><\/p>\n

<\/p>\n

Lysbilder<\/a><\/noindex><\/p>\n

<\/p>\n

L\u00f8sningen \u00abBitrix i Kubernetes, versjon Southbridge 1.0\u00bb<\/h2>\n

<\/p>\n

Jeg vil fortelle om v\u00e5r l\u00f8sning i formatet \u00abfor nybegynnere i Kubernetes\u00bb, slik det ble gjort p\u00e5 m\u00f8tet. Men jeg antar at ordene Bitrix, Docker, Kubernetes, Ceph er kjent for deg, om ikke annet p\u00e5 niv\u00e5et av artikler p\u00e5 Wikipedia.<\/p>\n

<\/p>\n

Hva finnes egentlig av klare l\u00f8sninger for Bitrix i Kubernetes?<\/h4>\n

<\/p>\n

Det finnes veldig lite informasjon p\u00e5 internett om kj\u00f8ring av applikasjoner p\u00e5 Bitrix i Kubernetes.
\nJeg fant bare disse materialene:<\/p>\n

<\/p>\n

Presentasjonen til Alexander Serbul, 1\u0421-Bitrix, og Anton Tuzlukov fra Qsoft: <\/p>\n

\n

\r\n \"Spill\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Jeg anbefaler \u00e5 h\u00f8re p\u00e5 den.<\/p>\n

<\/p>\n

Utvikling av en egen l\u00f8sning fra brukeren serkyron<\/a><\/noindex> p\u00e5 Habr\u00e9<\/a><\/noindex>.
\nFant ogs\u00e5 slike l\u00f8sninger<\/a><\/noindex>.<\/p>\n

<\/p>\n

Og\u2026 faktisk, det er alt.<\/p>\n

<\/p>\n

Jeg advarer, kvaliteten p\u00e5 l\u00f8sningene i lenkene ovenfor har vi ikke sjekket \ud83d\ude42
\nForresten, under forberedelsen av v\u00e5r l\u00f8sning snakket jeg med Alexander Serbul, da hans presentasjon enn\u00e5 ikke var tilgjengelig, s\u00e5 i lysbildene mine er det et punkt som sier \u00abBitrix bruker ikke Kubernetes\u00bb.<\/p>\n

<\/p>\n

Men det finnes allerede mange klare Docker-bilder for \u00e5 jobbe med Bitrix i Docker: https:\/\/hub.docker.com\/search?q=bitrix&type=image<\/a><\/noindex> <\/p>\n

<\/p>\n

Er dette nok for \u00e5 lage en fullverdig l\u00f8sning for Bitrix i Kubernetes?
\nNei. Det er mange problemer som m\u00e5 l\u00f8ses.<\/p>\n

<\/p>\n

Hva er problemene med Bitrix i Kubernetes?<\/h4>\n

<\/p>\n

Det f\u00f8rste \u2013 klare bilder fra Dockerhub er ikke egnet for Kubernetes<\/strong><\/p>\n

<\/p>\n

Hvis vi \u00f8nsker \u00e5 bygge en mikrotjenestearkitektur (som vi vanligvis \u00f8nsker i Kubernetes), m\u00e5 applikasjonen i Kubernetes deles inn i containere og s\u00f8rge for at hver container utf\u00f8rer en liten funksjon (og gj\u00f8r det godt). Hvorfor bare en? Kort sagt \u2013 jo enklere, jo mer p\u00e5litelig.
\nFor en lengre forklaring \u2013 vennligst sjekk denne artikkelen og videoen: https:\/\/habr.com\/ru\/company\/southbridge\/blog\/426637\/<\/a><\/noindex> <\/p>\n

<\/p>\n

Docker-bildene i Dockerhub er hovedsakelig bygget etter prinsippet \u00abalt i ett\u00bb, derfor m\u00e5tte vi faktisk lage v\u00e5r egen l\u00f8sning og til og med bygge bildene fra bunnen av.<\/p>\n

<\/p>\n

Det andre \u2013 koden til nettsiden blir endret fra administrasjonspanelet<\/strong><\/p>\n

<\/p>\n

Vi har opprettet en ny seksjon p\u00e5 nettstedet \u2014 koden har blitt oppdatert (en katalog med navnet p\u00e5 den nye seksjonen har blitt lagt til).<\/p>\n

<\/p>\n

Vi har endret egenskapene til komponenten fra administrasjonspanelet \u2014 koden har endret seg.<\/p>\n

<\/p>\n

Kubernetes kan ikke jobbe med dette \u00absom standard\u00bb, containere m\u00e5 v\u00e6re uforanderlige (Stateless).<\/p>\n

<\/p>\n

\u00c5rsaken: hver container (pod) i klyngen h\u00e5ndterer bare en del av trafikken. Hvis koden bare endres i \u00e9n container (pod), vil koden v\u00e6re forskjellig i forskjellige podder, nettstedet vil fungere forskjellig, og forskjellige brukere vil se forskjellige versjoner av nettstedet. Dette er ikke b\u00e6rekraftig.<\/p>\n

<\/p>\n

Det tredje \u2014 vi m\u00e5 l\u00f8se problemet med deploy.<\/strong><\/p>\n

<\/p>\n

Hvis vi har et monolithisk system og \u00e9n \u00abklassisk\u00bb server, er alt ganske enkelt: vi distribuerer den nye kodebasen, gjennomf\u00f8rer databasemigrering, og omdirigerer trafikken til den nye koden. Omdirigeringen skjer umiddelbart.
\nHvis vi har et nettsted i Kubernetes, delt opp i mikrotjenester, og det er mange containere med kode \u2014 \u00e5h. Vi m\u00e5 bygge containere med den nye versjonen av koden, rulle dem ut i stedet for de gamle, utf\u00f8re databasemigreringen riktig, og ideelt sett gj\u00f8re dette uten at bes\u00f8kende merker det. Heldigvis hjelper Kubernetes oss med dette, og st\u00f8tter en rekke forskjellige typer deploy.<\/p>\n

<\/p>\n

Det fjerde \u2014 vi m\u00e5 l\u00f8se lagringsproblemene for statisk innhold.<\/strong><\/p>\n

<\/p>\n

Hvis nettstedet ditt bare veier \u00ab10 gigabyte\u00bb, og du distribuerer det helt i containere, f\u00e5r du containere som veier 10 gigabyte, som vil bli deployet i en evighet.
\nVi m\u00e5 lagre de \u00abtyngste\u00bb delene av nettstedet utenfor containerne, og sp\u00f8rsm\u00e5let oppst\u00e5r om hvordan vi skal gj\u00f8re dette p\u00e5 riktig m\u00e5te.<\/p>\n

<\/p>\n

Hva som ikke er inkludert i v\u00e5r l\u00f8sning.<\/h4>\n

<\/p>\n

Hele Bitrix-koden er ikke delt opp i mikrofunksjoner\/mikrotjenester (for eksempel er registrering separat, modulen for nettbutikken separat, osv.). Vi lagrer hele kodebasen i hver container i sin helhet.<\/p>\n

<\/p>\n

Vi lagrer heller ikke databasen i Kubernetes (jeg har faktisk implementert l\u00f8sninger med databasen i Kubernetes for utviklermilj\u00f8er, men ikke for produksjon).<\/p>\n

<\/p>\n

Administratorene p\u00e5 nettstedet vil likevel merke at nettstedet kj\u00f8rer p\u00e5 Kubernetes. Funksjonen \u00absystemkontroll\u00bb fungerer ikke korrekt, og for \u00e5 redigere nettstedets kode fra administrasjonspanelet m\u00e5 du f\u00f8rst trykke p\u00e5 knappen \u00abjeg vil redigere koden\u00bb.<\/p>\n

<\/p>\n

Vi har identifisert problemene, vi har bestemt n\u00f8dvendigheten av mikrotjenester, m\u00e5let er klart - \u00e5 f\u00e5 et fungerende system for applikasjoner p\u00e5 Bitrix i Kubernetes, samtidig som vi opprettholder mulighetene fra Bitrix og fordelene ved Kubernetes. Vi begynner implementeringen.<\/p>\n

<\/p>\n

Arkitektur<\/h4>\n

<\/p>\n

Mange \u00abarbeids\u00bb podder med webserver (worker'ene).
\n\u00c9n pod med cron-jobber (kun \u00e9n er obligatorisk).
\n\u00c9n upgrade pod for redigering av nettstedkode fra administrasjonspanelet (kun \u00e9n er ogs\u00e5 obligatorisk).<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

<\/p>\n

Vi l\u00f8ser sp\u00f8rsm\u00e5lene:<\/p>\n

<\/p>\n