{"id":8269,"date":"2020-04-13T13:02:17","date_gmt":"2020-04-13T20:02:17","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=8269"},"modified":"2025-06-13T21:33:16","modified_gmt":"2025-06-14T04:33:16","slug":"why-couchbase-is-the-best-nosql-option-for-red-hat-openshift","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/why-couchbase-is-the-best-nosql-option-for-red-hat-openshift\/","title":{"rendered":"Por que o Couchbase \u00e9 a melhor op\u00e7\u00e3o de NoSQL para o Red Hat OpenShift"},"content":{"rendered":"

A lideran\u00e7a da Red Hat no espa\u00e7o de orquestra\u00e7\u00e3o de cont\u00eaineres com o OpenShift reflete a lideran\u00e7a da Couchbase no espa\u00e7o de banco de dados em cont\u00eaineres com seu Autonomous Operator. Esse fato \u00e9 a base da parceria entre a Red Hat e a Couchbase. Eu trabalhei pessoalmente na parceria nos \u00faltimos dois anos. Gostaria de aproveitar esta oportunidade para discutir por que agora \u00e9 um \u00f3timo momento para executar o Couchbase no Red Hat OpenShift.<\/span><\/p>\n

O \"estado\" atual do Kubernetes<\/span><\/h2>\n

Antes de ingressar no Couchbase, trabalhei em uma empresa de monitoramento de SaaS. Trabalhar em uma empresa de monitoramento lhe d\u00e1 uma vis\u00e3o \u00fanica das tecnologias que seus clientes est\u00e3o usando. Em 2017, era poss\u00edvel ver o ponto de inflex\u00e3o do Kubernetes e do OpenShift nos pain\u00e9is de monitoramento dos nossos clientes. Ficou claro que o Red Hat OpenShift estava vencendo a guerra da orquestra\u00e7\u00e3o de cont\u00eaineres entre as grandes empresas. Mas havia uma coisa que voc\u00ea definitivamente n\u00e3o via: bancos de dados no Kubernetes. Especialmente na produ\u00e7\u00e3o. De fato, a execu\u00e7\u00e3o de qualquer carga de trabalho \"com estado\" no Kubernetes era considerada arriscada. A arquitetura t\u00edpica envolvia a execu\u00e7\u00e3o de suas cargas de trabalho sem estado no Kubernetes ou no OpenShift e a execu\u00e7\u00e3o de seus bancos de dados em outro lugar.<\/span><\/p>\n

Como qualquer engenheiro de banco de dados lhe dir\u00e1, gerenciar o estado em um aplicativo distribu\u00eddo<\/a> \u00e9 dif\u00edcil. Quando voc\u00ea adiciona v\u00e1rias camadas de abstra\u00e7\u00e3o e dimensionamento el\u00e1stico \u00e0 mistura, fica ainda mais dif\u00edcil. O Kubernetes \u00e9 e foi \u00f3timo no gerenciamento de recursos de computa\u00e7\u00e3o e mem\u00f3ria, mas o armazenamento n\u00e3o era algo gerenciado diretamente pelo Kubernetes. Em outras palavras, o Kubernetes e o OpenShift eram \u00f3timos para gerenciar cargas de trabalho sem estado, mas apenas algumas almas corajosas ousavam executar aplicativos persistentes e com estado diretamente no Kubernetes (ou seja, bancos de dados). <\/span>O padr\u00e3o t\u00edpico era hospedar seu banco de dados em outro lugar (veja \"Then\" no diagrama abaixo).<\/p>\n

\"\"<\/p>\n

 <\/p>\n

Armazenamento - Volumes persistentes<\/h4>\n

A comunidade queria resolver esse problema e <\/span>Volumes persistentes<\/span><\/a> foi um importante elemento de constru\u00e7\u00e3o. Os Volumes Persistentes (PVs) forneceram uma solu\u00e7\u00e3o para o gerenciamento e o isolamento do armazenamento na forma de uma API que suporta a conex\u00e3o de diferentes classes de armazenamento<\/a> para os pods em execu\u00e7\u00e3o. Os PVs t\u00eam um ciclo de vida independente de qualquer pod individual, o que permite que eles persistam seus dados mesmo depois que um pod \u00e9 destru\u00eddo. Isso significa que voc\u00ea n\u00e3o precisa se preocupar com a perda de dados em um cen\u00e1rio de desastre quando perde um banco de dados ou um n\u00f3 do OpenShift.<\/span><\/p>\n

V\u00e1rios fornecedores de armazenamento adicionaram suporte ao Kubernetes por meio da API Persistent Volumes, incluindo os provedores de nuvem e o parceiro Red Hat, Portworx<\/a>. Isso significa que voc\u00ea tem op\u00e7\u00f5es ao escolher seu armazenamento. Isso \u00e9 fundamental do ponto de vista de um fornecedor de banco de dados, em que a escolha do armazenamento correto pode ter um grande impacto no desempenho e na confiabilidade.<\/p>\n

 <\/p>\n

A estrutura do operador<\/h4>\n

A segunda grande inova\u00e7\u00e3o, que permitiu que o Couchbase se tornasse o l\u00edder em bancos de dados NoSQL no OpenShift, \u00e9 o<\/span>\u00a0o Estrutura do operador<\/a>. A Couchbase foi a primeira empresa de banco de dados NoSQL a fazer um investimento s\u00e9rio no desenvolvimento de um Operator (consulte \"Principais operadores de Kubernetes que avan\u00e7am no modelo de capacidade do operador<\/a>\"). Colaboramos com a equipe do CoreOS desde o in\u00edcio do desenvolvimento do Operator Framework. Hoje, os clientes do Couchbase podem contar com o Couchbase Autonomous Operator para gerenciar muitas das opera\u00e7\u00f5es de cluster, incluindo implanta\u00e7\u00e3o, dimensionamento, recupera\u00e7\u00e3o de desastres, atualiza\u00e7\u00f5es cont\u00ednuas e muito mais. Isso representa um enorme valor para os clientes do Couchbase e tamb\u00e9m est\u00e1 ajudando a impulsionar a ado\u00e7\u00e3o do OpenShift.<\/span><\/p>\n

Ent\u00e3o, o que \u00e9 um Operator? Esta cita\u00e7\u00e3o da equipe do Red Hat CoreOS resume melhor:<\/p>\n

\"<\/span>Conceitualmente, Um Operador pega o conhecimento operacional humano e o codifica em um software que \u00e9 mais facilmente empacotado e compartilhado com os consumidores<\/strong>. Pense em um Operador como uma extens\u00e3o da equipe de engenharia do fornecedor de software que vigia seu ambiente Kubernetes e usa seu estado atual para tomar decis\u00f5es em milissegundos. Os operadores seguem um modelo de maturidade que vai desde a funcionalidade b\u00e1sica at\u00e9 a l\u00f3gica espec\u00edfica de um aplicativo. Os operadores avan\u00e7ados s\u00e3o projetados para lidar com upgrades sem problemas, reagir a falhas automaticamente e n\u00e3o tomar atalhos, como pular um processo de backup de software para economizar tempo.\"<\/span><\/i><\/p>\n

https:\/\/coreos.com\/blog\/introducing-operator-framework<\/span><\/i><\/a><\/p>\n

Como o gerenciamento do estado distribu\u00eddo \u00e9 desafiador, e sistemas diferentes gerenciam o estado de forma diferente com base em detalhes de implementa\u00e7\u00e3o muito espec\u00edficos, nunca foi razo\u00e1vel esperar que a comunidade Kubernetes codificasse para todos os cen\u00e1rios poss\u00edveis que todo e qualquer aplicativo com estado poderia encontrar. <\/span>O Operator Framework permite que os desenvolvedores preencham essa lacuna e fa\u00e7am isso de uma forma que se encaixe no paradigma do Kubernetes. Por exemplo: Em um cen\u00e1rio de desastre, quando um n\u00f3 do OpenShift que executa um pod do Couchbase fica inativo, o Operador Aut\u00f4nomo do Couchbase restaurar\u00e1 o cluster de forma autom\u00e1tica e graciosa e reequilibrar\u00e1 seus dados sem nenhuma interrup\u00e7\u00e3o dos servi\u00e7os que usam o Couchbase. E, se voc\u00ea estiver usando Persistent Volumes, ele at\u00e9 mesmo reanexar\u00e1 o volume do pod perdido ao novo pod do Couchbase, acelerando consideravelmente o tempo necess\u00e1rio para reequilibrar os dados.<\/span><\/p>\n

\"\"<\/p>\n

Gerente do ciclo de vida do operador<\/h4>\n

\u00c0 medida que os operadores amadureceram, o mesmo aconteceu com as ferramentas que os cercam. O melhor exemplo \u00e9 o Gerente do ciclo de vida do operador (OLM)<\/a>. OLM estava em pr\u00e9-visualiza\u00e7\u00e3o t\u00e9cnica a partir do OpenShift 3.11. A partir do OpenShift 4, ele \u00e9 um recurso oficialmente suportado. Normalmente, a instala\u00e7\u00e3o de um Operator requer privil\u00e9gios de administrador de cluster e algumas etapas manuais, como a instala\u00e7\u00e3o de um Defini\u00e7\u00e3o de recursos personalizados<\/a>. O OLM automatiza a tarefa de instala\u00e7\u00e3o e tamb\u00e9m pode gerenciar atualiza\u00e7\u00f5es para voc\u00ea sem exigir privil\u00e9gios de administrador de cluster. O OLM se conecta diretamente ao OperatorHub<\/a> ou seja, \u00e0 medida que novas atualiza\u00e7\u00f5es de Operator forem lan\u00e7adas, elas aparecer\u00e3o no cat\u00e1logo do OperatorHub e poder\u00e3o ser instaladas por meio do OLM. Isso permite que os usu\u00e1rios encontrem o Operator de que precisam e o instalem com apenas alguns cliques.<\/p>\n

Um dos principais benef\u00edcios disso \u00e9 a produtividade do desenvolvedor. Ele oferece aos desenvolvedores \"Operadores como servi\u00e7o\" em seus ambientes de desenvolvimento OpenShift.<\/p>\n

\"\"<\/p>\n

Por que o Couchbase?<\/span><\/h2>\n

Nos \u00faltimos anos, o termo \"Cloud Native\" tornou-se parte da linguagem comum em tecnologia. Ele aparece com frequ\u00eancia principalmente no contexto das discuss\u00f5es sobre o Kubernetes e o OpenShift. O Kubernetes \u00e9 frequentemente posicionado como a plataforma para aplicativos nativos da nuvem. Cloud Native significa software projetado para aproveitar o modelo de computa\u00e7\u00e3o em nuvem. Na pr\u00e1tica, isso significa que os aplicativos se encaixam mais em um padr\u00e3o de arquitetura orientada a servi\u00e7os e microsservi\u00e7os (em oposi\u00e7\u00e3o a uma arquitetura monol\u00edtica), visam \u00e0 escala horizontal (em oposi\u00e7\u00e3o \u00e0 escala vertical) e podem ser executados em cont\u00eaineres relativamente leves. Isso representa um problema para os bancos de dados tradicionais relacionais (e alguns NoSQL), que seguem muito os padr\u00f5es monol\u00edticos e n\u00e3o foram projetados para escalonar horizontalmente da mesma forma que o Couchbase.<\/span><\/p>\n

\u00c9 nesse ponto que o Couchbase se destaca em rela\u00e7\u00e3o a outras op\u00e7\u00f5es. No in\u00edcio da vida do Couchbase, ele foi pressionado e desafiado a suportar cargas de trabalho em escala da Web em ambientes de nuvem por seus maiores usu\u00e1rios. Desde o in\u00edcio, o Couchbase adotou uma arquitetura que se assemelha ao que hoje chamamos de Cloud Native. No Couchbase, isso se reflete em nossa Dimensionamento multidimensional<\/a> capacidade.\u00a0<\/span>O dimensionamento multidimensional permite que cada um dos servi\u00e7os do Couchbase (dados, \u00edndice, consulta, an\u00e1lise, pesquisa de texto completo e eventos) seja dimensionado de forma independente, enquanto estiver on-line e atendendo ao tr\u00e1fego. \u00c9 exatamente assim que voc\u00ea deseja projetar um aplicativo com a nuvem nativa em mente.<\/span><\/p>\n

\"\"<\/p>\n

Al\u00e9m do dimensionamento multidimensional, outros recursos do Couchbase, como o armazenamento autom\u00e1tico e uma interface administrativa integrada e robusta, ajudam a facilitar a experi\u00eancia de gerenciamento das cargas de trabalho NoSQL no OpenShift.<\/p>\n

Para onde vamos a partir de agora<\/span><\/h2>\n

Operador aut\u00f4nomo do Couchbase 2.0 Beta<\/h4>\n

Nosso objetivo \u00e9 automatizar todas as pr\u00e1ticas recomendadas operacionais do Couchbase necess\u00e1rias para executar clusters com nosso Operador. <\/span>O objetivo final \u00e9 que nossos clientes e os clientes da Red Hat possam operar com efici\u00eancia seu pr\u00f3prio DBaaS do Couchbase em qualquer ambiente OpenShift na nuvem, no local ou em ambos. At\u00e9 mesmo a pr\u00f3pria oferta de DBaaS do Couchbase depende muito do Couchbase Autonomous Operator.<\/span><\/p>\n

Recentemente, lan\u00e7amos o Operador aut\u00f4nomo do Couchbase 2.0 Beta<\/a>. Embora continuemos a adicionar novos recursos ao pr\u00f3prio Operador, reconhecemos que o Couchbase \u00e9 apenas uma parte da infraestrutura. Na pr\u00e1tica, h\u00e1 outras fun\u00e7\u00f5es, como monitoramento de m\u00e9tricas e logs e seguran\u00e7a, que abrangem v\u00e1rias partes da infraestrutura. O Operator 2.0 inclui a integra\u00e7\u00e3o com o Couchbase Prometheus Exporter para coletar e expor as m\u00e9tricas do Couchbase Server. Isso significa que voc\u00ea pode monitorar o Couchbase junto com outros aplicativos no ambiente Ret Hat OpenShift.<\/p>\n

Habilitando cargas de trabalho de nuvem m\u00faltipla e h\u00edbrida<\/h4>\n

Eu seria negligente se n\u00e3o mencionasse outro recurso importante do Couchbase - o Replica\u00e7\u00e3o entre centros de dados (XDCR)<\/a>. O XDCR sempre foi um recurso popular do Couchbase. O motivo pelo qual ele \u00e9 importante nesse contexto \u00e9 sua fun\u00e7\u00e3o de permitir cargas de trabalho com estado em v\u00e1rias nuvens e na nuvem h\u00edbrida no OpenShift. O OpenShift j\u00e1 facilita a implanta\u00e7\u00e3o de aplicativos em diferentes nuvens e no local. Com o XDCR, voc\u00ea tamb\u00e9m pode obter a replica\u00e7\u00e3o de dados entre clusters do OpenShift. Nas pr\u00f3ximas semanas, n\u00f3s (Red Had e Couchbase) planejamos fornecer mais conte\u00fado e atualiza\u00e7\u00f5es sobre esse t\u00f3pico especificamente. Fique ligado!<\/p>\n

\"\"<\/p>\n

Recursos<\/h2>\n