Apresentando o MongoDB Enterprise Operator para Kubernetes e OpenShift
Avalie esse anúncio
Atualmente, mais equipes de DevOps estão aproveitando o poder da containerização e de tecnologias como Kubernetes e Red Hat OpenShift para gerenciar clusters de banco de dados em container. Para oferecer suporte às equipes que criam aplicativos nativos da cloud com Kubernetes e OpenShift, estamos introduzindo um Operador Kubernetes (beta) que se integra ao MongoDB Ops Manager, a plataforma de gerenciamento empresarial do MongoDB. O operador permite que um usuário implemente e gerencie clusters MongoDB a partir da API do Kubernetes, sem ter que configurá-los manualmente no Ops Manager.
Com esta integração do Kubernetes, você pode executar e distribuir cargas de trabalho de forma consistente e sem esforço onde quer que seja necessário, mantendo a mesma configuração de banco de dados em ambientes diferentes, tudo controlado com uma configuração simples e declarativa. As equipes de operações também podem oferecer aos desenvolvedores novos serviços, como o MongoDB-as-a-Service, que pode fornecer um banco de dados totalmente gerenciado, juntamente com outros produtos e serviços, gerenciados pelo Kubernetes e OpenShift.
Neste blog, abordaremos o seguinte:
- breve discussão sobre a volta do container
- Visão geral do MongoDB Ops Manager
- Como instalar e configurar o MongoDB Enterprise Operator para Kubernetes
- Solução de problemas
- Onde obter mais informações
Se você já visitou um porto marítimo internacional ou dirigiu por uma rodovia interestadual, pode ter visto grandes contêineres retangulares de metal, geralmente chamados de contêineres intermodais. Esses contêineres são projetados e construídos usando as mesmas especificações, embora o conteúdo dessas caixas possa variar muito. O design consistente não apenas permite que esses contêineres se movam livremente do navio, para o trem e para o caminhão, mas também permite esse movimento sem descarregar e recarregar o conteúdo da carga.
Esse mesmo conceito de container pode ser aplicado a aplicativos de software em que o aplicativo é o conteúdo do container juntamente com suas estruturas e bibliotecas de suporte. O container pode ser movido livremente de uma plataforma para outra sem interromper o aplicativo. Esse recurso facilita a transferência de um aplicativo de um servidor de datacenter local para um provedor de nuvem pública ou a criação rápida de ambientes de réplica para uso em desenvolvimento, teste e produção.
MongoDB 4. O 0 introduz o MongoDB Enterprise Operator para Kubernetes, que permite a um usuário implementar e gerenciar clusters MongoDB a partir da API Kubernetes, sem que o usuário tenha que se conectar diretamente ao Ops Manager ou Cloud Manager (a versão hospedada do Ops Manager, entregue como um serviço.
Embora o MongoDB seja totalmente compatível em um ambiente em contêiner, você precisa garantir que os benefícios obtidos com a containerização do banco de dados excedam o custo de gerenciamento da configuração. Como em qualquer carga de trabalho de banco de dados de produção, esses contêineres devem usar armazenamento persistente e exigirão configuração adicional, dependendo da tecnologia de contêiner subjacente usada. Para ajudar a facilitar o gerenciamento dos próprios containers, as equipes de DevOps estão aproveitando o poder das tecnologias de orquestração como Kubernetes e Red Hat OpenShift. Embora essas tecnologias sejam excelentes no gerenciamento de contêineres, elas não estão cientes das configurações específicas do aplicativo e das topologias de implantação, como conjuntos de réplicas do MongoDB e clusters sharded. Por esse motivo, o Kubernetes tem recursos e operadores personalizados que permitem que terceiros estendam a API do Kubernetes e habilitem sistemas com reconhecimento de aplicativos.
Mais tarde neste blog, você aprenderá como instalar e começar a usar o MongoDB Enterprise Operator for Kubernetes. Primeiro, vamos abordar o MongoDB Ops Manager, que é uma peça chave no gerenciamento eficiente do cluster MongoDB.
O MongoDB Ops Manager é uma plataforma de gerenciamento de classe empresarial para clusters MongoDB que você executa em sua própria infraestrutura. Os recursos do MongoDB Ops Manager incluem monitoramento, alertas, recuperação de desastres, dimensionamento, implantação e atualização de conjuntos de réplicas e clusters fragmentados e outros produtos MongoDB , como o BI Connector. Embora uma discussão completa sobre o MongoDB Ops Manager esteja fora do escopo deste blog, é importante entender os componentes básicos que compõem o MongoDB Ops Manager, pois eles serão usados pelo Operador Kubernetes para criar suas implementações.
Uma arquitetura simplificada do Ops Manager é mostrada na figura 2 abaixo. Observe que há outros agentes que o Ops Manager usa para oferecer suporte a recursos como backup, mas eles estão fora do escopo deste blog e não são exibidos. Para obter informações completas sobre a arquitetura do MongoDB Ops Manager, consulte a documentação online que está disponível no seguinte URL: https://docs.opsmanager.mongodb.com/current/
O HTTP Service MongoDB fornece um aplicativo da web para administração. Essas páginas são apenas um front-end para um conjunto robusto de REST API do MongoDB Ops Manager hospedadas no HTTP Service do MongoDB Ops Manager. É por meio dessas REST API que o Kubernetes interagirá com o MongoDB Ops Manager.
Com uma implantação típica do Ops Manager, há muitas opções de gerenciamento, incluindo atualizar o cluster para uma versão diferente, adicionar secundários a um conjunto de réplicas existente e converter um conjunto de réplicas existente em um cluster fragmentado. Então, como o MongoDB Ops Manager faz a atualização de cada nó de um cluster ou a criação de novas instâncias do mongod? Ele faz isso dependendo de um serviço instalado localmente chamado Ops Manager Automation Agent, que é executado em cada nó do MongoDB no cluster. Esse serviço leve está disponível em vários sistemas operacionais, portanto, independentemente de seus nós do MongoDB estarem sendo executados em um container Linux ou em uma máquina virtual Windows Server ou em um servidor PowerPC local, há um agente de automação disponível para essa plataforma. Os agentes de automação recebem instruções da REST API do MongoDB Ops Manager para executar trabalho no nó do cluster.
Quando o Ops Manager mostra estatísticas como tamanho do banco de dados e inserções por segundo, ele está recebendo essa telemetria dos nós individuais que executam o MongoDB. O Ops Manager depende do Agente de Monitoramento para se conectar aos seus processos MongoDB, coletar dados sobre o estado de sua implantação e enviar esses dados para o Ops Manager. Pode haver um ou mais agentes de monitoramento distribuídos em sua infraestrutura para fins de confiabilidade, mas apenas um agente primary por projeto do Ops Manager está coletando dados. O Ops Manager tem tudo a ver com automação e, assim que você tiver o agente de automação implantado, outros agentes de suporte, como o agente de monitoramento, serão implantados para você. No cenário em que o Kubernetes Operator emitiu um comando para implantar um novo MongoDB cluster em um novo projeto, o MongoDB Ops Manager se encarregará de implantar o agente de monitoramento nos container que executam seu novo MongoDB cluster.
O Ops Manager é parte integral da automatização de um cluster MongoDB com Kubernetes. Para começar, você precisará de acesso a um Ops Manager 4.0+ ambiente ou MongoDB Cloud Manager.
O MongoDB Enterprise Operator for Kubernetes é compatível com Kubernetes v1.9 e superior. Ele também foi testado com o Openshift versão 3.9. Você precisará de acesso a um ambiente Kubernetes. Se você não tiver acesso a um ambiente Kubernetes ou apenas quiser criar um ambiente de teste, pode usar o minikube, que implanta um cluster Kubernetes local de nó único em seu computador. Para obter informações adicionais e instruções de configuração, consulte a seguinte URL: https://kubernetes.io/docs/setup/minikube.
As seções a seguir abordarão a instalação e a configuração em três etapas do MongoDB Enterprise Operator for Kubernetes. A ordem de instalação será a seguinte:
- Etapa 1: Instalando o MongoDB Enterprise Operator por meio de um arquivo Helm ou yaml
- Etapa 2: Criando e aplicando um arquivo Kubernetes ConfigMap
- Etapa 3: Crie o objeto secreto do Kubernetes que armazenará a chave da API do Ops Manager
Para instalar o MongoDB Enterprise Operator for Kubernetes, você pode usar o helm, o gerenciador de pacotes do Kubernetes, ou passar um arquivo yaml para o kubectl. As instruções para ambos os métodos são as seguintes, escolha um e continue para a etapa 2.
Para instalar o operador via Helm:
Para instalar com Helm, primeiro você precisa clonar o repositório público https://github.com/mongodb/mongodb-enterprise-kubernetes.git
Mude os diretórios para a cópia local e execute o seguinte comando na linha de comando:
1 helm install helm_chart/ --name mongodb-enterprise
Para instalar o operador por meio de um arquivo yaml:
Execute o seguinte comando na linha de comando:
1 kubectl apply -f https://raw.githubusercontent.com/mongodb/mongodb-enterprise-kubernetes/master/mongodb-enterprise.yaml
Neste ponto, o MongoDB Enterprise Operator for Kubernetes está instalado e agora precisa ser configurado. Primeiro, devemos criar e aplicar um arquivo Kubernetes ConfigMap. Um arquivo Kubernetes ConfigMap contém pares de valores-chave de dados de configuração que podem ser consumidos em pods ou usados para armazenar dados de configuração. Nesse caso de uso, o arquivo ConfigMap armazenará informações de configuração sobre a implantação do Ops Manager que queremos usar.
Para que o operador Kubernetes saiba qual gerenciador de operações do MongoDB você deseja usar, você precisará obter algumas propriedades do console do gerenciador de operações do MongoDB e criar um arquivo ConfigMap. Essas propriedades são as seguintes:
- URL base: A URL do seu Ops Manager ou Cloud Manager.
- ID do Projeto: a ID de um projeto do Ops Manager no qual o Kubernetes Operator implantará.
- Usuário: um nome de usuário existente do MongoDB Ops Manager.
- Chave de API pública: usada pelo Operador do Kubernetes para se conectar ao endpoint da REST API do MongoDB Ops Manager.
- URL base: O Uri base é o URL do seu Ops Manager ou Cloud Manager.
Se você já sabe como obter esses bolsistas, copie-os e vá para a Etapa 3.
Nota: Se você estiver usando o Cloud Manager, o URL base é https://cloud.mongodb.com
Para obter a URL base no MongoDB Ops Manager, copie a URL usada para se conectar ao servidor do MongoDB Ops Manager a partir da barra de navegação do navegador. Deve ser algo semelhante a http://servername:8080. Você também pode executar o seguinte:
Faça login no Ops Manager e clique no botão Administrador. Em seguida, selecione o item de menu "Ops Manager Config". Você será presenteado com uma tela semelhante à figura abaixo:
Anote o valor exibido na caixa URL para acessar o Ops Manager. Observação: se você não tiver acesso ao menu suspenso Admin, você terá que copiar o URL usado para se conectar ao servidor do Ops Manager na barra de navegação do seu navegador.
ID do Projeto
A ID do projeto é a ID de um projeto do Ops Manager no qual o operador Kubernetes fará a implantação.
Um projeto do Ops Manager é uma organização lógica de clusters MongoDB e também fornece um limite de segurança. Um ou mais projetos fazem parte de uma organização do Ops Manager. Se você precisar criar uma Organização, clique em seu nome de usuário no lado superior direito da tela e selecione "Organizações". Em seguida, clique no botão "+ Nova organização" e forneça um nome para sua organização. Depois de ter uma Organização, você pode criar um Projeto.
Para criar um novo projeto, clique no nome da sua organização. Isso o levará à página Projetos e, a partir daqui, clique no botão " + Novo Projeto " e forneça um nome exclusivo para seu projeto. Se você não for um administrador do Ops Manager, talvez não tenha essa opção e precisará solicitar ao administrador para criar um projeto.
Depois que o projeto for criado, ou se você já tiver um projeto criado em seu nome por um administrador, poderá obter a ID do projeto clicando na opção de menu Configurações, conforme mostrado na figura abaixo.
Copiar a ID do Projeto.
Usuário
O usuário é um nome de usuário existente do Ops Manager.
Para ver a lista de usuários do Ops Manager, retorne ao projeto e clique no menu "Usuários e equipes". Você pode usar qualquer usuário do Ops Manager que tenha pelo menos acesso de Proprietário do Projeto. Se você quiser criar outro nome de usuário, clique no botão "Adicionar usuários e equipe", conforme mostrado na Figura 6.
Copie o e-mail do usuário que você gostaria que o operador Kubernetes usasse ao se conectar ao Ops Manager.
Chave de API pública
A chave de API do MongoDB Ops Manager é usada pelo operador Kubernetes para se conectar ao endpoint da REST API do MongoDB Ops Manager. Você pode criar uma chave de API clicando no seu nome de usuário no canto superior direito do console do Ops Manager e selecionando "Conta" no menu suspenso. Isso abrirá a página Configurações da conta, conforme mostrado na figura 7.
Clique na aba "Public API Access". Para criar uma nova chave de API, clique no botão "Gerar" e forneça uma descrição. Ao completar, você receberá uma chave de API, conforme mostrado na figura 8.
Não se esqueça de copiar a chave de API, pois ela será usada posteriormente como um valor em um arquivo de configuração. É importante copiar esse valor enquanto a caixa de diálogo estiver aberta, pois você não poderá lê-lo de volta depois de fechar a caixa de diálogo. Se você não tiver anotado o valor, precisará excluir a chave de API e criar uma nova.
Observação: se você estiver usando o MongoDB Cloud Manager ou tiver o Ops Manager implantado em uma rede segura, talvez seja necessário permitir o intervalo IP do cluster Kubernetes para que o operador possa fazer solicitações ao Ops Manager usando essa chave de API.
Agora que adquiriram as informações necessárias de configuração do Ops Manager, precisamos criar um arquivo Kubernetes ConfigMap para o Projeto Kubernetes. Para fazer isso, use um editor de texto de sua escolha e crie o seguinte arquivo yaml, substituindo os espaços reservados em branco pelos valores obtidos no console do Ops Manager. Para fins de amostra, podemos chamar esse arquivo de "my-project.yaml".
1 apiVersion: v1 2 kind: ConfigMap 3 metadata: 4 name: <<Name i.e. name of OpsManager Project>> 5 namespace: mongodb 6 data: 7 projectId: <<Project ID>> 8 baseUrl: <<OpsManager URL>>
figura 9: exemplo de arquivo ConfigMap
Observação: o formato do arquivo ConfigMap pode mudar ao longo do tempo à medida que recursos e capacidades são adicionados ao operador. Certifique-se de verificar a documentação do MongoDB se estiver tendo problemas para enviar o arquivo ConfigMap.
Depois de criar este arquivo, você pode aplicar o ConfigMap ao Kubernetes usando o seguinte comando:
1 kubectl apply -f my-project.yaml
Para que um usuário possa criar ou atualizar objetos em um projeto do Ops Manager, ele precisa de uma chave de API pública. No início desta seção, criamos uma nova chave de API e esperamos que você a tenha anotado. Esta chave de API será mantida pelo Kubernetes como um objeto secreto. Você pode criar este segredo com o seguinte comando:
1 kubectl -n mongodb create secret generic <<Name of credentials>> --from-literal="user=<<User>>" --from-literal="publicApiKey=<<public-api-key>>"
Certifique-se de substituir os valores da chave Usuário e API pública pelos valores obtidos no console do MongoDB Ops Manager. Você pode escolher qualquer nome para as credenciais - apenas anote-o, pois você precisará dele mais tarde quando começar a criar clusters MongoDB.
Agora estamos prontos para começar a implantar os MongoDB Clusters!
O Kubernetes pode implantar um MongoDB standalone, conjunto de réplicas ou um cluster fragmentado. Para implantar um conjunto de réplicas de nó 3 , crie o seguinte arquivo yaml:
1 apiVersion: mongodb.com/v1 2 kind: MongoDbReplicaSet 3 metadata: 4 name: <<Name of your new MongoDB replica set>> 5 namespace: mongodb 6 spec: 7 members: 3 8 version: 3.6.5 9 10 persistent: false 11 12 project: <<Name value specified in metadata.name of ConfigMap file>> 13 credentials: <<Name of credentials secret>>
Imagem 10: arquivo simple-rs.yaml descrevendo um conjunto de réplicas de três nós
O nome do seu novo cluster pode ser qualquer nome que você escolher. O nome do mapa de configuração do projeto do OpsManager e o nome do segredo das credenciais foram definidos anteriormente.
Para enviar a solicitação para o Kubernetes criar esse cluster, basta passar o nome do arquivo yaml que você criou para o seguinte comando kubectl:
1 kubectl apply -f simple-rs.yaml
Após alguns minutos, seu novo cluster aparecerá no Ops Manager, como mostrado na figura 11.
Observe que o Ops Manager instalou não apenas os agentes de automação nesses três contêineres que executam o MongoDB, ele também instalou os agentes de monitoramento e backup.
De que adiantaria um banco de dados se, a qualquer momento no container, seus dados também fossem para a sepultura? provavelmente não é uma boa situação e talvez uma em que ajustar o currículo também possa ser uma boa coisa a fazer. Até recentemente, a falta de armazenamento persistente e mapeamentos DNS consistentes eram os principais problemas na execução de bancos de dados em containers. Felizmente, trabalhos recentes no ecossistema do Kubernetes abordaram essa preocupação e novos recursos como
PersistentVolumes e StatefulSets emergiram, permitindo que você implemente bancos de dados como o MongoDB sem se preocupar com a perda de dados devido a falhas de hardware ou ao contêiner movido para outro lugar na seu centro de dados. É necessária uma configuração adicional de armazenamento no cluster Kubernetes antes de distribuir um cluster MongoDB que use armazenamento persistente. Em Kubernetes existem dois tipos de volumes persistentes: estáticos e dinâmicos. O Operador Kubernetes pode provisionar objetos MongoDB (ou seja, autônomo, conjunto de réplicas e clusters fragmentados) usando qualquer um dos tipos.A conexão com as implantações do MongoDB no Kubernetes não é diferente de outras topologias de implantação. No entanto, é provável que você precise abordar as especificidades de rede da sua configuração do Kubernetes. Para abstrair as informações específicas da implantação, como nomes de host e portas, da implantação do MongoDB, o Kubernetes Enterprise Operator for Kubernetes usa o Kubernetes Services.
Cada tipo de implantação MongoDB terá dois serviços Kubernetes gerados automaticamente durante o provisionamento. Por exemplo, suponha que tenhamos um único conjunto de réplicas de nós 3 chamado " my-replica-set ", então você pode enumerar os serviços usando a seguinte declaração:
1 kubectl get all -n mongodb --selector=app=my-replica-set-svc
Esta declaração produz os seguintes resultados:
1 NAME READY STATUS RESTARTS AGE 2 pod/my-replica-set-0 1/1 Running 0 29m 3 pod/my-replica-set-1 1/1 Running 0 29m 4 pod/my-replica-set-2 1/1 Running 0 29m 5 6 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 7 service/my-replica-set-svc ClusterIP None <none> 27017/TCP 29m 8 service/my-replica-set-svc-external NodePort 10.103.220.236 <none> 27017:30057/TCP 29m 9 10 NAME DESIRED CURRENT AGE 11 statefulset.apps/my-replica-set 3 3 29m
Observe a string anexada "-svc" ao nome do conjunto de réplicas.
O serviço com "-external" é um NodePort - o que significa que ele está exposto ao nome DNS geral do cluster na porta 30057.
Observação: se você estiver usando o Minikube, poderá obter o endereço IP do conjunto de réplicas em execução emitindo o seguinte:
1 minikube service list
Em nosso exemplo que usou minikube o conjunto de resultados continha as seguintes informações: mongodb my-replica-set-svc-external http://192.168.39.95:30057
Agora que sabemos o IP do nosso cluster MongoDB, podemos nos conectar usando o Mongo Shell ou qualquer aplicativo ou ferramenta que você queira usar.
Se você estiver tendo problemas para enviar uma implantação, leia os registros. Problemas como problemas de autenticação e outros problemas comuns podem ser facilmente detectados nos arquivos de log. Você pode visualizar os arquivos de log do MongoDB Enterprise Operator for Kubernetes por meio do seguinte comando:
1 kubectl logs -f deployment/mongodb-enterprise-operator -n mongodb
Você também pode usar o kubectl para ver os registros dos pods do banco de dados. Os principais processos de container estão continuamente seguindo os registros do agente de automação e podem ser vistos com a seguinte declaração:
1 kubectl logs <<name of pod>> -n mongodb
Observação: você pode enumerar a lista de pods usando
1 kubectl get pods -n mongodb
Outra técnica comum de solução de problemas é shell em um dos containers que executam o MongoDB. Aqui você pode usar ferramentas comuns do Linux para visualizar os processos, solucionar problemas ou até mesmo verificar conexões mongo shell (às vezes úteis para diagnosticar problemas de rede).
1 kubectl exec -it <<name of pod>> -n mongodb -- /bin/bash
Um exemplo de saída deste comando é o seguinte:
1 UID PID PPID C STIME TTY TIME CMD 2 mongodb 1 0 0 16:23 ? 00:00:00 /bin/sh -c supervisord -c /mongo 3 mongodb 6 1 0 16:23 ? 00:00:01 /usr/bin/python /usr/bin/supervi 4 mongodb 9 6 0 16:23 ? 00:00:00 bash /mongodb-automation/files/a 5 mongodb 25 9 0 16:23 ? 00:00:00 tail -n 1000 -F /var/log/mongodb 6 mongodb 26 1 4 16:23 ? 00:04:17 /mongodb-automation/files/mongod 7 mongodb 45 1 0 16:23 ? 00:00:01 /var/lib/mongodb-mms-automation/ 8 mongodb 56 1 0 16:23 ? 00:00:44 /var/lib/mongodb-mms-automation/ 9 mongodb 76 1 1 16:23 ? 00:01:23 /var/lib/mongodb-mms-automation/ 10 mongodb 8435 0 0 18:07 pts/0 00:00:00 /bin/bash
De dentro do container, podemos fazer uma conexão com o nó local do MongoDB facilmente executando o mongo shell por meio do seguinte comando:
1 /var/lib/mongodb-mms-automation/mongodb-linux-x86_64-3.6.5/bin/mongo --port 27017
Observação: a versão do agente de automação pode ser diferente de 3.6.5, certifique-se de verificar o caminho do diretório
Mais informações estarão disponíveis no site de documentação do MongoDB em um futuro próximo. Até lá, confira estes recursos para obter mais informações:
Para ver todas as práticas recomendadas de operações do MongoDB, baixe nosso whitepaper: https://www.mongodb.com/collateral/mongodb-operations-best-practices
Avalie esse anúncio