{"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\/da\/blog\/administrirovanie\/southbridge-v-chelyabinske-i-bitriks-v-kubernetes","title":{"rendered":"Southbridge i Tjeljabinsk og Bitrix i Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I Charkov afholdes der meetups for systemadministratorer, og p\u00e5 det seneste lavede jeg et opl\u00e6g om vores l\u00f8sning til at k\u00f8re applikationer p\u00e5 1C-Bitrix i Kubernetes.<\/p>\n

<\/p>\n

Bitrix, Kubernetes, Ceph \u2014 en fremragende kombination?<\/p>\n

<\/p>\n

Jeg vil fort\u00e6lle, hvordan vi samlet viste en fungerende l\u00f8sning ud af alt dette.<\/p>\n

<\/p>\n

Lad os komme i gang!<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

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

Meetup'en fandt sted den 18. april i Charkov. Om vores meetups kan du l\u00e6se i Timepad<\/a><\/noindex> og se p\u00e5 YouTube<\/a><\/noindex>.<\/p>\n

<\/p>\n

Hvis du \u00f8nsker at komme til os med et opl\u00e6g eller som deltager - s\u00e5 er du velkommen, skriv til vadim.isakanov@gmail.com og p\u00e5 Telegram t.me\/vadimisakanov. <\/p>\n

<\/p>\n

Mit opl\u00e6g<\/h2>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

L\u00f8sning \"Bitrix i Kubernetes, version Southbridge 1.0\"<\/h2>\n

<\/p>\n

Jeg vil tale om vores l\u00f8sning i formatet \"for nybegyndere i Kubernetes\", hvordan det blev gjort p\u00e5 meetup'en. Men jeg antager, at du allerede kender til ordene Bitrix, Docker, Kubernetes, Ceph, i det mindste p\u00e5 niveau med artikler fra Wikipedia.<\/p>\n

<\/p>\n

Hvad findes der overhovedet af materialer om Bitrix i Kubernetes?<\/h4>\n

<\/p>\n

Der er meget lidt information p\u00e5 internettet om at k\u00f8re applikationer p\u00e5 Bitrix i Kubernetes.
\nJeg fandt kun disse materialer:<\/p>\n

<\/p>\n

Opl\u00e6g af Alexander Serbul, 1C-Bitrix, og Anton Tuzlukov fra Qsoft: <\/p>\n

\n

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

Jeg anbefaler at lytte til det.<\/p>\n

<\/p>\n

Udvikling af en egen l\u00f8sning fra brugerens side serkyron<\/a><\/noindex> p\u00e5 Habr\u00e9<\/a><\/noindex>.
\nJeg fandt ogs\u00e5 denne l\u00f8sning<\/a><\/noindex>.<\/p>\n

<\/p>\n

Og... ja, det var det.<\/p>\n

<\/p>\n

Jeg advarer om, at kvaliteten af l\u00f8sningerne i ovenst\u00e5ende links ikke er blevet kontrolleret \ud83d\ude42
\nForresten, mens jeg forberedte vores l\u00f8sning, talte jeg med Alexander Serbul, hans opl\u00e6g var endnu ikke tilg\u00e6ngeligt, derfor er der et punkt i mine slides, \"Bitrix bruger ikke Kubernetes\".<\/p>\n

<\/p>\n

Men der er mange f\u00e6rdige Docker-billeder til at k\u00f8re Bitrix i Docker allerede: https:\/\/hub.docker.com\/search?q=bitrix&type=image<\/a><\/noindex> <\/p>\n

<\/p>\n

Er dette tilstr\u00e6kkeligt til at skabe en fuldgyldig l\u00f8sning for Bitrix i Kubernetes?
\nNej. Der er mange problemer, der skal l\u00f8ses.<\/p>\n

<\/p>\n

Hvad er problemerne med Bitrix i Kubernetes?<\/h4>\n

<\/p>\n

Den f\u00f8rste \u2014 f\u00e6rdige billeder fra Dockerhub er ikke egnet til Kubernetes.<\/strong><\/p>\n

<\/p>\n

Hvis vi \u00f8nsker at bygge en mikrotjenestearkitektur (og i Kubernetes vil vi typisk gerne det), skal applikationen i Kubernetes opdeles i containere og sikre, at hver container udf\u00f8rer \u00e9n lille funktion (og g\u00f8r det godt). Hvorfor kun \u00e9n? Kort sagt \u2014 jo simplere, jo mere p\u00e5lideligt.
\nFor en l\u00e6ngere forklaring - se venligst denne artikel og video: https:\/\/habr.com\/ru\/company\/southbridge\/blog\/426637\/<\/a><\/noindex> <\/p>\n

<\/p>\n

Docker-billeder i Dockerhub er hovedsageligt bygget med princippet \"alt i \u00e9t\", s\u00e5 vi m\u00e5tte alligevel lave vores egen cykel og til og med skabe billeder fra bunden.<\/p>\n

<\/p>\n

Den anden \u2014 websitets kode \u00e6ndres fra administrationspanelet.<\/strong><\/p>\n

<\/p>\n

Vi har oprettet en ny sektion p\u00e5 hjemmesiden \u2013 koden er blevet opdateret (der er tilf\u00f8jet et bibliotek med navnet p\u00e5 den nye sektion).<\/p>\n

<\/p>\n

Vi har \u00e6ndret egenskaberne for komponenten fra adminpanelet \u2013 koden er \u00e6ndret.<\/p>\n

<\/p>\n

Kubernetes kan ikke arbejde med dette 'som standard'; containere skal v\u00e6re uforanderlige (Stateless).<\/p>\n

<\/p>\n

\u00c5rsag: hver container (pod) i klyngen h\u00e5ndterer kun en del af trafikken. Hvis man \u00e6ndrer koden kun i \u00e9n container (pod), vil der v\u00e6re forskellige versioner af koden i forskellige pods, og hjemmesiden vil opf\u00f8re sig forskelligt, hvilket betyder, at forskellige brugere vil se forskellige versioner af hjemmesiden. Det er ikke en holdbar l\u00f8sning.<\/p>\n

<\/p>\n

For det tredje \u2013 det er n\u00f8dvendigt at l\u00f8se sp\u00f8rgsm\u00e5let om deployment.<\/strong><\/p>\n

<\/p>\n

Hvis vi har et monolitisk system og \u00e9n 'klassisk' server, s\u00e5 er det ret simpelt: vi deployer en ny kodebase, udf\u00f8rer database-migration, og skifter trafikken til den nye version af koden. Skiftet sker straks.
\nHvis vores hjemmeside k\u00f8rer p\u00e5 Kubernetes, opdelt i mikrotjenester, og der er mange containere med kode \u2013 uh-oh. Vi skal samle containere med den nye version af koden, udskifte dem med de gamle, korrekt udf\u00f8re database-migration, og ideelt set g\u00f8re det usynligt for bes\u00f8gende. Heldigvis hj\u00e6lper Kubernetes os her ved at underst\u00f8tte en hel r\u00e6kke forskellige typer deployment.<\/p>\n

<\/p>\n

For det fjerde \u2013 det er n\u00f8dvendigt at l\u00f8se sp\u00f8rgsm\u00e5let om opbevaring af statiske filer.<\/strong><\/p>\n

<\/p>\n

Hvis din hjemmeside kun vejer \u2018kun\u2019 10 gigabyte, og du deployer den helt i containere, f\u00e5r du containere, der vejer 10 gigabyte, som vil blive deployet i en evighed.
\nDet er n\u00f8dvendigt at opbevare de 'tungeste' dele af hjemmesiden uden for containerne, og der opst\u00e5r sp\u00f8rgsm\u00e5let om, hvordan man korrekt g\u00f8r dette.<\/p>\n

<\/p>\n

Hvad der ikke er i vores l\u00f8sning.<\/h4>\n

<\/p>\n

Hele Bitrix-koden er ikke opdelt i mikro-funktioner\/mikrotjenester (s\u00e5dan at registrering er adskilt, internetbutiksmodulet er adskilt osv.). Vi opbevarer hele kodebasen i hver container.<\/p>\n

<\/p>\n

Vi gemmer ogs\u00e5 ikke databasen i Kubernetes (jeg har dog implementeret l\u00f8sninger med databasen i Kubernetes til udviklingsmilj\u00f8er, men ikke til produktion).<\/p>\n

<\/p>\n

Webstedets administratorer vil alligevel bem\u00e6rke, at webstedet k\u00f8rer i Kubernetes. 'Systemcheck'-funktionen fungerer ikke korrekt, og for at redigere koden p\u00e5 hjemmesiden fra adminpanelet skal man f\u00f8rst trykke p\u00e5 knappen 'Jeg vil redigere koden'.<\/p>\n

<\/p>\n

Vi har identificeret problemerne, vi er blevet enige om n\u00f8dvendigheden af at implementere mikrotjenester, og m\u00e5let er klart \u2014 at f\u00e5 et fungerende system til k\u00f8rsel af applikationer p\u00e5 Bitrix i Kubernetes, samtidig med at vi bevarer b\u00e5de Bitrix's funktioner og Kubernetes's fordele. Vi starter implementeringen.<\/p>\n

<\/p>\n

Arkitektur<\/h4>\n

<\/p>\n

Mange \"arbejds\" pods med webservere (workers).
\nEn pod med cron-jobs (af dem kun \u00e9n er obligatorisk).
\nEn upgrade pod til redigering af webstedskoden fra administrationspanelet (ogs\u00e5 obligatorisk kun \u00e9n).<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

<\/p>\n

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

<\/p>\n