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

En Cheli\u00e1binsk se llevan a cabo meetups para administradores de sistemas Sysadminka, y en el \u00faltimo de ellos hice una presentaci\u00f3n sobre nuestra soluci\u00f3n para ejecutar aplicaciones en 1C-Bitrix en Kubernetes.<\/p>\n

<\/p>\n

\u00bfBitrix, Kubernetes, Ceph: una combinaci\u00f3n excelente?<\/p>\n

<\/p>\n

Les contar\u00e9 c\u00f3mo reunimos todo esto en una soluci\u00f3n funcional.<\/p>\n

<\/p>\n

\u00a1Vamos!<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

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

El meetup tuvo lugar el 18 de abril en Cheli\u00e1binsk. Sobre nuestros meetups se puede leer en Timepad<\/a><\/noindex> y ver en YouTube<\/a><\/noindex>.<\/p>\n

<\/p>\n

Si quieren venir a nosotros como ponentes o como oyentes, \u00a1bienvenidos! Escriban a vadim.isakanov@gmail.com y en Telegram t.me\/vadimisakanov. <\/p>\n

<\/p>\n

Mi presentaci\u00f3n<\/h2>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

La soluci\u00f3n \u00abBitrix en Kubernetes, versi\u00f3n Southbridge 1.0\u00bb<\/h2>\n

<\/p>\n

Hablar\u00e9 de nuestra soluci\u00f3n en un formato \u00abpara principiantes en Kubernetes\u00bb, como se hizo en el meetup. Pero supongo que las palabras Bitrix, Docker, Kubernetes, Ceph les son familiares, al menos a nivel de art\u00edculos en Wikipedia.<\/p>\n

<\/p>\n

\u00bfQu\u00e9 hay disponible sobre Bitrix en Kubernetes?<\/h4>\n

<\/p>\n

En toda la Internet hay muy poca informaci\u00f3n sobre c\u00f3mo funcionan las aplicaciones en Bitrix en Kubernetes.
\nSolo encontr\u00e9 estos materiales:<\/p>\n

<\/p>\n

La presentaci\u00f3n de Alexander Serbul y Anton Tuzlukov de Qsoft: <\/p>\n

\n

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

Recomiendo escucharlo.<\/p>\n

<\/p>\n

Desarrollo de una soluci\u00f3n propia por el usuario serkyron<\/a><\/noindex> en Habr\u00e9<\/a><\/noindex>.
\nTambi\u00e9n encontr\u00e9 tal soluci\u00f3n<\/a><\/noindex>.<\/p>\n

<\/p>\n

Yyyy\u2026 en realidad, eso es todo.<\/p>\n

<\/p>\n

Aviso que no hemos comprobado la calidad de las soluciones en los enlaces anteriores \ud83d\ude42
\nPor cierto, al preparar nuestra soluci\u00f3n habl\u00e9 con Alexander Serbul, su presentaci\u00f3n a\u00fan no hab\u00eda sido publicada, por lo que en mis diapositivas hay un punto que dice \u00abBitrix no utiliza Kubernetes\u00bb.<\/p>\n

<\/p>\n

Pero ya hay muchas im\u00e1genes Docker listas para trabajar con Bitrix en Docker: https:\/\/hub.docker.com\/search?q=bitrix&type=image<\/a><\/noindex> <\/p>\n

<\/p>\n

\u00bfEs suficiente esto para crear una soluci\u00f3n completa para Bitrix en Kubernetes?
\nNo. Hay una gran cantidad de problemas que necesitan ser resueltos.<\/p>\n

<\/p>\n

\u00bfCu\u00e1les son los problemas con Bitrix en Kubernetes?<\/h4>\n

<\/p>\n

El primero: las im\u00e1genes listas de Dockerhub no son adecuadas para Kubernetes.<\/strong><\/p>\n

<\/p>\n

Si queremos construir una arquitectura de microservicios (y generalmente queremos en Kubernetes), la aplicaci\u00f3n en Kubernetes debe dividirse en contenedores y lograr que cada contenedor realice una peque\u00f1a funci\u00f3n (y lo haga bien). \u00bfPor qu\u00e9 solo una? En pocas palabras: cuanto m\u00e1s simple, m\u00e1s confiable.
\nSi quieren m\u00e1s informaci\u00f3n, por favor vean este art\u00edculo y video: https:\/\/habr.com\/ru\/company\/southbridge\/blog\/426637\/<\/a><\/noindex> <\/p>\n

<\/p>\n

Las im\u00e1genes Docker en Dockerhub est\u00e1n construidas principalmente bajo el principio de \u00abtodo en uno\u00bb, por eso tuvimos que crear nuestra propia soluci\u00f3n, incluso creando las im\u00e1genes desde cero.<\/p>\n

<\/p>\n

El segundo: el c\u00f3digo del sitio se corrige desde el panel de administraci\u00f3n.<\/strong><\/p>\n

<\/p>\n

Se cre\u00f3 una nueva secci\u00f3n en el sitio web: se actualiz\u00f3 el c\u00f3digo (se a\u00f1adi\u00f3 un directorio con el nombre de la nueva secci\u00f3n).<\/p>\n

<\/p>\n

Se cambiaron las propiedades del componente desde el panel de administraci\u00f3n: el c\u00f3digo cambi\u00f3.<\/p>\n

<\/p>\n

Kubernetes no puede trabajar con esto 'por defecto'; los contenedores deben ser inmutables (Stateless).<\/p>\n

<\/p>\n

Raz\u00f3n: cada contenedor (pod) en el cl\u00faster solo procesa una parte del tr\u00e1fico. Si se cambia el c\u00f3digo solo en un contenedor (pod), entonces en diferentes pods el c\u00f3digo ser\u00e1 diferente, el sitio funcionar\u00e1 de manera distinta y a diferentes usuarios se les mostrar\u00e1n diferentes versiones del sitio. As\u00ed no se puede vivir.<\/p>\n

<\/p>\n

Tercero: se debe resolver el problema del despliegue.<\/strong><\/p>\n

<\/p>\n

Si tenemos un monolito y un servidor 'cl\u00e1sico', todo es bastante simple: desplegamos una nueva base de c\u00f3digo, realizamos la migraci\u00f3n de la base de datos y cambiamos el tr\u00e1fico a la nueva versi\u00f3n del c\u00f3digo. El cambio ocurre de manera instant\u00e1nea.
\nSi nuestro sitio est\u00e1 en Kubernetes, descompuesto en microservicios y hay muchos contenedores con c\u00f3digo, oh. Necesitamos construir contenedores con la nueva versi\u00f3n del c\u00f3digo, desplegarlos en lugar de los antiguos, realizar correctamente la migraci\u00f3n de la base de datos, y en ideal hacerlo de manera invisible para los visitantes. Afortunadamente, Kubernetes nos ayuda en esto, apoyando una variedad de tipos de despliegue.<\/p>\n

<\/p>\n

Cuarto: se debe resolver el problema del almacenamiento de est\u00e1tica.<\/strong><\/p>\n

<\/p>\n

Si su sitio pesa 'solo' 10 gigabytes y lo despliega completamente en contenedores, obtendr\u00e1 contenedores de 10 gigabytes, que se desplegar\u00e1n eternamente.
\nEs necesario almacenar las partes 'm\u00e1s pesadas' del sitio fuera de los contenedores, y surge la pregunta de c\u00f3mo hacerlo correctamente.<\/p>\n

<\/p>\n

Lo que no est\u00e1 en nuestra soluci\u00f3n.<\/h4>\n

<\/p>\n

Todo el c\u00f3digo de Bitrix no est\u00e1 dividido en microfunciones\/microservicios (de tal manera que el registro sea separado, el m\u00f3dulo de la tienda en l\u00ednea sea separado, etc.). Almacenamos toda la base de c\u00f3digo en cada contenedor en su totalidad.<\/p>\n

<\/p>\n

La base no se almacena en Kubernetes (aunque he implementado soluciones con la base en Kubernetes para entornos de desarrolladores, pero no para producci\u00f3n).<\/p>\n

<\/p>\n

Los administradores del sitio notar\u00e1n que el sitio est\u00e1 funcionando en Kubernetes. La funci\u00f3n 'verificaci\u00f3n del sistema' no funciona correctamente; para editar el c\u00f3digo del sitio desde el panel de administraci\u00f3n, primero se debe presionar el bot\u00f3n 'quiero editar el c\u00f3digo'.<\/p>\n

<\/p>\n

Hemos resuelto los problemas, tenemos claridad sobre la necesidad de implementar microservicios, el objetivo est\u00e1 claro: crear un sistema funcional para ejecutar aplicaciones en Bitrix en Kubernetes, preservando tanto las capacidades de Bitrix como las ventajas de Kubernetes. Comenzamos la implementaci\u00f3n.<\/p>\n

<\/p>\n

Arquitectura<\/h4>\n

<\/p>\n

Muchos pods 'trabajadores' con servidor web.
\nUn pod para tareas programadas (debe haber solo uno).
\nUn pod de actualizaci\u00f3n para editar el c\u00f3digo del sitio desde el panel de administraci\u00f3n (tambi\u00e9n debe haber solo uno).<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

<\/p>\n

Estamos resolviendo cuestiones:<\/p>\n

<\/p>\n