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

Em Chelyabinsk, ocorrem meetups para administradores de sistemas Sysadminka, e na \u00faltima reuni\u00e3o, fiz uma apresenta\u00e7\u00e3o sobre nossa solu\u00e7\u00e3o para rodar aplicativos no 1C-Bitrix no Kubernetes.<\/p>\n

<\/p>\n

Bitrix, Kubernetes, Ceph - uma combina\u00e7\u00e3o excelente?<\/p>\n

<\/p>\n

Vou explicar como montamos uma solu\u00e7\u00e3o funcional a partir de tudo isso.<\/p>\n

<\/p>\n

Vamos l\u00e1!<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

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

O meetup aconteceu em 18 de abril em Chelyabinsk. Voc\u00ea pode ler sobre nossos meetups em Timepad<\/a><\/noindex> e assistir no YouTube<\/a><\/noindex>.<\/p>\n

<\/p>\n

Se voc\u00ea quiser se juntar a n\u00f3s com uma apresenta\u00e7\u00e3o ou como ouvinte - fique \u00e0 vontade, escreva para vadim.isakanov@gmail.com e no Telegram t.me\/vadimisakanov. <\/p>\n

<\/p>\n

Minha apresenta\u00e7\u00e3o<\/h2>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

Solu\u00e7\u00e3o \u00abBitrix no Kubernetes, vers\u00e3o Southbridge 1.0\u00bb<\/h2>\n

<\/p>\n

Vou falar sobre nossa solu\u00e7\u00e3o no formato \u00abpara iniciantes no Kubernetes\u00bb, como foi feita no meetup. Mas presumo que voc\u00ea j\u00e1 conhece os termos Bitrix, Docker, Kubernetes, Ceph, pelo menos no n\u00edvel de artigos da Wikipedia.<\/p>\n

<\/p>\n

O que j\u00e1 existe sobre Bitrix no Kubernetes?<\/h4>\n

<\/p>\n

Na internet, h\u00e1 muito pouca informa\u00e7\u00e3o sobre como os aplicativos funcionam no Bitrix no Kubernetes.
\nEncontrei apenas esses materiais:<\/p>\n

<\/p>\n

Apresenta\u00e7\u00e3o de Alexander Serbul, 1C-Bitrix, e Anton Tuzlukov da Qsoft: <\/p>\n

\n

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

Recomendo ouvi-lo.<\/p>\n

<\/p>\n

Desenvolvimento de uma solu\u00e7\u00e3o pr\u00f3pria pelo usu\u00e1rio serkyron<\/a><\/noindex> no Habr<\/a><\/noindex>.
\nEncontrei ainda essa solu\u00e7\u00e3o<\/a><\/noindex>.<\/p>\n

<\/p>\n

E isso \u00e9 tudo.<\/p>\n

<\/p>\n

Aten\u00e7\u00e3o, n\u00e3o verificamos a qualidade das solu\u00e7\u00f5es nos links acima \ud83d\ude42
\nAli\u00e1s, ao preparar nossa solu\u00e7\u00e3o, conversei com Alexander Serbul, e na \u00e9poca, sua apresenta\u00e7\u00e3o ainda n\u00e3o existia, portanto, em meus slides, h\u00e1 um item que diz 'Bitrix n\u00e3o usa Kubernetes'.<\/p>\n

<\/p>\n

Mas j\u00e1 existem muitas imagens Docker prontas para uso do Bitrix no Docker: https:\/\/hub.docker.com\/search?q=bitrix&type=image<\/a><\/noindex> <\/p>\n

<\/p>\n

Isso \u00e9 suficiente para criar uma solu\u00e7\u00e3o completa para Bitrix no Kubernetes?
\nN\u00e3o. H\u00e1 uma s\u00e9rie de problemas que precisam ser resolvidos.<\/p>\n

<\/p>\n

Quais s\u00e3o os problemas com Bitrix no Kubernetes?<\/h4>\n

<\/p>\n

O primeiro - as imagens prontas do Dockerhub n\u00e3o s\u00e3o adequadas para Kubernetes<\/strong><\/p>\n

<\/p>\n

Se quisermos construir uma arquitetura de microsservi\u00e7os (e no Kubernetes geralmente queremos), precisamos dividir o aplicativo em cont\u00eaineres e garantir que cada cont\u00eainer execute uma \u00fanica fun\u00e7\u00e3o pequena (e fa\u00e7a isso bem). Por que apenas uma? Em resumo - quanto mais simples, mais confi\u00e1vel.
\nSe quiser mais detalhes - por favor, assista a este artigo e v\u00eddeo: https:\/\/habr.com\/ru\/company\/southbridge\/blog\/426637\/<\/a><\/noindex> <\/p>\n

<\/p>\n

As imagens Docker do Dockerhub s\u00e3o principalmente constru\u00eddas sob o princ\u00edpio 'tudo em um', por isso tivemos que realmente criar nossa pr\u00f3pria solu\u00e7\u00e3o e at\u00e9 fazer as imagens do zero.<\/p>\n

<\/p>\n

O segundo - o c\u00f3digo do site \u00e9 ajustado do painel administrativo<\/strong><\/p>\n

<\/p>\n

Criamos uma nova se\u00e7\u00e3o no site - o c\u00f3digo foi atualizado (uma diret\u00f3rio com o nome da nova se\u00e7\u00e3o foi adicionado).<\/p>\n

<\/p>\n

Alteramos as propriedades do componente pelo painel de administra\u00e7\u00e3o - o c\u00f3digo foi alterado.<\/p>\n

<\/p>\n

Kubernetes n\u00e3o consegue trabalhar com isso 'por padr\u00e3o', os containers devem ser imut\u00e1veis (Stateless).<\/p>\n

<\/p>\n

Motivo: cada container (pod) no cluster processa apenas uma parte do tr\u00e1fego. Se o c\u00f3digo for alterado apenas em um container (pod), o c\u00f3digo ser\u00e1 diferente em diferentes pods, o site funcionar\u00e1 de forma diferente, e diferentes vers\u00f5es do site ser\u00e3o mostradas para os diferentes usu\u00e1rios. Isso n\u00e3o \u00e9 vi\u00e1vel.<\/p>\n

<\/p>\n

Terceiro - precisamos resolver a quest\u00e3o do deploy.<\/strong><\/p>\n

<\/p>\n

Se tivermos um monolito e um \u00fanico servidor 'cl\u00e1ssico', tudo \u00e9 bem simples: implementamos uma nova base de c\u00f3digo, realizamos a migra\u00e7\u00e3o do banco de dados, e redirecionamos o tr\u00e1fego para a nova vers\u00e3o do c\u00f3digo. A troca ocorre instantaneamente.
\nSe nosso site estiver no Kubernetes, dividido em microsservi\u00e7os, com muitos containers de c\u00f3digo - ai ai. Precisamos compilar containers com a nova vers\u00e3o do c\u00f3digo, substitu\u00ed-los pelos antigos, realizar a migra\u00e7\u00e3o do banco de dados corretamente e, idealmente, fazer isso sem que os visitantes percebam. Felizmente, o Kubernetes nos ajuda, suportando uma s\u00e9rie de diferentes tipos de deploy.<\/p>\n

<\/p>\n

Quarto - precisamos resolver a quest\u00e3o do armazenamento de arquivos est\u00e1ticos.<\/strong><\/p>\n

<\/p>\n

Se o seu site pesa 'apenas' 10 gigabytes e voc\u00ea o implementar completamente em containers, voc\u00ea ter\u00e1 containers pesando 10 gigabytes que levar\u00e3o uma eternidade para serem implantados.
\nPrecisamos armazenar as partes 'mais pesadas' do site fora dos containers, e surge a quest\u00e3o de como fazer isso corretamente.<\/p>\n

<\/p>\n

O que n\u00e3o est\u00e1 em nossa solu\u00e7\u00e3o.<\/h4>\n

<\/p>\n

Todo o c\u00f3digo do Bitrix n\u00e3o foi dividido em microfun\u00e7\u00f5es\/microsservi\u00e7os (como registro separado, m\u00f3dulo de e-commerce separado, etc.). Mantemos toda a base de c\u00f3digo em cada container na \u00edntegra.<\/p>\n

<\/p>\n

A base no Kubernetes tamb\u00e9m n\u00e3o \u00e9 armazenada (eu j\u00e1 implementei solu\u00e7\u00f5es com base no Kubernetes para ambientes de desenvolvimento, mas n\u00e3o para produ\u00e7\u00e3o).<\/p>\n

<\/p>\n

Os administradores do site ainda perceber\u00e3o que o site est\u00e1 rodando no Kubernetes. A fun\u00e7\u00e3o 'verifica\u00e7\u00e3o do sistema' n\u00e3o funciona corretamente, para editar o c\u00f3digo do site a partir do painel de administra\u00e7\u00e3o, \u00e9 necess\u00e1rio primeiro pressionar o bot\u00e3o 'quero editar o c\u00f3digo'.<\/p>\n

<\/p>\n

Resolvemos os problemas, entendemos a necessidade de implementar microservi\u00e7os, e o objetivo est\u00e1 claro \u2014 obter um sistema funcional para operar aplicativos no Bitrix em Kubernetes, preservando tanto as funcionalidades do Bitrix quanto as vantagens do Kubernetes. Vamos iniciar a implementa\u00e7\u00e3o.<\/p>\n

<\/p>\n

Arquitetura<\/h4>\n

<\/p>\n

Muitos pods 'worker' com servidor web.
\nUm pod com tarefas cron (obrigatoriamente apenas um).
\nUm pod de upgrade para edi\u00e7\u00e3o do c\u00f3digo do site a partir do painel de administra\u00e7\u00e3o (tamb\u00e9m obrigatoriamente apenas um).<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

<\/p>\n

Estamos resolvendo quest\u00f5es:<\/p>\n

<\/p>\n