MongoDB

Início
Versões
Imagens
Inicializando o banco
Rodando comando MongoDB em containers
Variáveis de Ambiente
Ponto de montagem de Volumes
Alterando senhas
Criando um banco a partir de um template
Usando replicação MongoDB
Criando o Deployment Config
Escalando o Cluster
Limitações

Início

O OpenShift fornece uma imagem Docker para rodar MongoDB. Esta imagem provê serviços de banco baseado no usuário e senha fornecidos pela configuração.

Versões

A versão atual que o OpenShift suporta do MongoDB é a 2.4, 2.6 e 3.2

Imagens

Estas imagens estão disponíveis na distribuição CentOS 7:

Imagens baseadas em CentOS 7

Esta imagem está disponível no DockerHub. Para fazer download:

$ docker pull openshift/mongodb-24-centos7

$ docker pull centos/mongodb-26-centos7

$ docker pull centos/mongodb-32-centos7

Para usar essa imagem, você pode acessa-las diretamente através desse registro de imagens, ou enviar para seu registro OpenShift Docker. Adicionalmente, você pode criar uma image stream que aponte para a imagem, no seu registro Docker ou numa localização externa. Os recursos do seu OpenShift podem agora fazer referencia ao ImageStream. Você pode encontrar exemplo de definições de image streams para todas as imagens do OpenShift.

Inicializando o banco

A primeira vez que você usa o volume compartilhar, a base é criada utilizando o usuário administrador. Depois disso o daemon do MongoDB inicia. Se você esta montando o volume em outro container, então a base, usuário da base e o usuário administrador não são criados e então o MongoDB inicia.

O comando a seguir cria um novo pod com o banco e o MongoDB executando no container:

$ oc new-app -e MONGODB_USER=<username>,MONGODB_PASSWORD=<password>,MONGODB_DATABASE=<database_name>,MONGODB_ADMIN_PASSWORD=<admin_password> centos/mongodb-26-centos7

Rodando comando MongoDB em containers

O OpenShift utiliza Software Collections(SCLs) para instalar e iniciar o MongoDB. Se você quer executar algum comando do MongoDB dentro de um container em execução(para debug), você deve executar usando o bash.

Para fazer isso, primeiro identifique o nome do pod que esta rodando o MongoDB. Por exemplo, você pode ver a lista de pods no seu projeto ao executar:

$ oc get pods

Então conecte no pod com o seguinte comando:

$ oc rsh <pod>

Quando você logar no container, a SCL é automaticamente ativada.

Você pode agora rodar o comando mongo a partir do bash para iniciar uma sessão interativa do MongoDB e executar operações do MongoDB. Exemplo, para alterar para a base sampledb e autenticar com o usuário da base:

bash-4.2$ mongo -u $MONGODB_USER -p $MONGODB_PASSWORD $MONGODB_DATABASE
MongoDB shell version: 2.4.9
connecting to: sampledb
>

Quando finalizado, pressione CTRL+D para fazer logout da sessão do MongoDB.

Variáveis de Ambiente

O usuário do MongoDB, senha, nome da base e senha do usuário admin devem ser configurados com as seguintes variáveis de ambiente:

Tabela 1. Variáveis de ambiente do MongoDB

Nome da Variável	Descrição
MONGODB_USER	Nome da conta de usuário a ser criado.
MONGODB_PASSWORD	Senha para o usuário acima.
MONGODB_DATABASE	Nome da base.
MONGODB_ADMIN_PASSWORD	Senha para o usuário admin.

Você deve especificar usuário, senha, nome da base e senha do usuário admin. Se você não especificar os quatro, o pod vai falhar para iniciar e o OpenShift vai ficar num loop tentando reiniciar.

O usuário do administrador é definido para admin e você deve especificar uma senha ao setar a variável de ambiente MONGODB_ADMIN_PASSWORD. Esse processo é feito durante a inicialização do banco.

As configurações do MongoDB podem ser definidas com as seguintes variáveis de ambiente:

Tabela 2. Configurações adicionais do MongoDB

Nome da Variável	Descrição	Default
MONGODB_NOPREALLOC	Desabilita prealocação de dados.	true
MONGODB_SMALLFILES	Configura o MongoDB para usar um o menor tamanho para os dados.	true
MONGODB_QUIET	Executa o MongoDB no modo quiet que tenta limitar a quantidade de output.	true

Ponto de montagem de Volumes

A imagem do MongoDB pode ser executada com volumes montados, para habilitar persistent storage para o banco:

/var/lib/mongodb - Este é o diretório onde o MongoDB armazena os arquivos do banco.

Alterando senhas

Senhas são parte da configuração da imagem, portanto o único método de alterar senhas para o usuário do banco(MONGODB_USER) e usuário admin é ao alterar as variáveis de ambiente MONGODB_PASSWORD e MONGODB_ADMIN_PASSWORD respectivamente,

Você pode visualizar a senha atual ao ver o pod ou o deployment config no console web ou ao listar as variáveis de ambiente através da CLI:

$ oc env pod <pod_name> --list

Alterar a senha do banco através do comandos SQL ou qualquer outro meio que não seja através das variáveis de ambiente vai causar um erro de configuração entre os valores armazenados nas variáveis e as senhas atuais. Sempre que um container de banco for iniciado, ele reseta as senhas e define os valores setados nas variáveis de ambiente.

Para alterar estas senhas, atualize uma ou ambas das variáveis de ambiente designadas no deployment config, usando o comando oc env. Se múltiplos deployment configs utilizam estas variáveis, por exemplo no caso de uma aplicação criada a partir de um template, você deve atualizar as variáveis em cada deployment config para que as senhas sejam sincronizadas em todo lugas. Isso pode ser feito em um único comando:

$ oc env dc <dc_name> [<dc_name_2> ...] MONGODB_PASSWORD=<new_password> MONGODB_ADMIN_PASSWORD=<new_admin_password>

Dependendo da sua aplicação, talvez tenha outras variáveis de ambiente para senhas em outras partes da aplicação que também devem ser atualizadas. Exemplo, pode ter uma variável mais genérica DATABASE_USER em um pod front-end que deve sempre fazer um match com a senha do usuário do banco. Tenha certeza que as senhas foram sincronizadas em todas as variáveis de ambiente de suas aplicações, se não seus pods podem falhar numa trigger de redeploy.

Atualizar as variáveis de ambiente, acionam o redeployment do banco no servidor se você tiver uma trigger de alteração de configuração. Em outro caso, você deve iniciar manualmente um novo deployment para aplicar as alterações de senhas.

Para verificar se as novas senhas estão funcionando, primeiro abra uma sessão ao pod que esta rodando o MongoDB:

$ oc rsh <pod>

A partir do bash, verifique a nova senha do usuário:

bash-4.2$ mongo -u $MONGODB_USER -p <new_password> $MONGODB_DATABASE --eval "db.version()"

Se a senha foi alterada corretamente, você deve ver uma saída igual a essa:

MongoDB shell version: 2.6.9
connecting to: sampledb
2.6.9

Para verificar a nova senha do usuário admin:

bash-4.2$ mongo -u admin -p <new_admin_password> admin --eval "db.version()"

Se a senha foi alterada corretamente, você deve ver uma tabela igual a essa:

MongoDB shell version: 2.6.9
connecting to: sampledb
2.6.9

Criando um banco a partir de um template

O OpenShift fornece um template que torna mais fácil a tarefa de criar um novo serviço de banco. O template fornece parâmetros para definir todas as variáveis de ambiente(usuário, senha, nome da base, etc) com valores default incluindo a criação de senhas aleatórias. Também define o deployment config e o service.

Os templates do MongoDB devem ter sido registrados no projeto default do openshift pelo administrador do cluster durante o setup inicial. Veja carregando default image streams e templates para mais detalhes.

O template disponível:

mongodb-persistent utiliza um volume persistente para armazenar os dados do banco, o que significa que os dados vão sobreviver a um restart do pod. Usando volumes persistente requer que um pool seja definido no deployment do OpenShift.

Você pode encontrar instruções para instanciar templates nessa página.

Assim que você instanciou um serviço, você pode copiar o usuário, senha, nome da base e variáveis de ambiente dentro de um deployment config para outro componente que tenta acessar a base. Esse componente pode ser acessado pelo banco via service que foi definido.

Usando replicação MongoDB

O suporte de replicação fornecido pela imagem do MongoDB é experimental e deve ser usado com cautela.

Para utilizar esta feature, é necessário ter o CLI instalado na versão 1.4, que pode ser baixada neste link.

Para criar o cluster, basta instanciar o template abaixo:

$ oc new-app https://raw.githubusercontent.com/juniorjbn/mongodb-container/params/examples/petset/mongodb-petset-persistent.yaml

O template criará automaticamente um cluster com 3 instâncias, com 4GB de Ram, 1 core e discos de 5Gi. Para alterar basta clonar o repositório e alterar os parâmetros de "resources", caso tenha problemas ou dúvidas, entre em contato com suporte@getupcloud.com

Para listar os componentes:

   $ oc get pods -l name=mongodb
   NAME READY STATUS RESTARTS AGE
   mongodb-0 1/1 Running 0 6m
   mongodb-1 1/1 Running 0 4m
   mongodb-2 1/1 Running 0 4m

Para ver os logs de um pod:

$ oc logs mongodb-0

Para acessar um dos pods:

$ oc rsh mongodb-0

E por fim, você poderá acessar o MongoDB a partir de qualquer um dos pods:

sh-4.2$ mongo $MONGODB_DATABASE -u $MONGODB_USER -p $MONGODB_PASSWORD
MongoDB shell version: 3.2.6
connecting to: sampledb
rs0:PRIMARY>

Exemplos de uso do MongoDB:

Configuração inicial: Cluster com 3 réplicas:

Depois de criar um cluster com este template, nós teremos 3 réplicas configuradas e prontas para usar, isso deve ser o bastante para a maioria dos casos de acordo com a documentação oficial.

Pode acontecer de um ou mais membros do cluster cair ou falhar com o passar do tempo. A plataforma cuidará de recuperá-los e reiniciando os container e reconfigurando o ReplicaSet.

Enquanto um membro do ReplicaSet estiver fora ou reiniciando, você poderá se deparar com um dos cenários abaixo:

Falha no membro primário (PRIMARY):

Neste caso, um novo membro será eleito como primário. Enquanto isso, as operações de leitura não serão afetadas, apenas escrita. Depois da eleição, leituras e escritas funcionarão sem problemas.

Falha no membro secundário (SECONDARY):

Leituras e escritas não serão afetadas. Dependendo do da configuração de opLogSize e da carga no cluster o membro não conseguirá reingressar no cluster, sendo necessária a intervenção manual de reingresso e sincronização dos dados.

Falha em dois membros de qualquer tipo:

Quando um membro de um cluster composto por 3 réplicas não consegue comunicar com qualquer outro membro, ele voltará assumir a primeira função em que foi iniciado. Neste caso, leituras poderão ser respondidas por membros "SECONDARY" e todas as gravações falharão. Assim que um ou mais membros estiver no ar, um novo "PRIMARY" será eleito e as gravações serão restabelecidas.

Falha em todos os membros:

Este é um caso extremo e claro, todas as operações vão falhar. Assim que um ou mais membros estiver disponível, a eleição definirá as funções de cada membro e as operações de escrita/leitura serão restabelecidas.

Escalando o Cluster

Adicionando membros no Cluster (Scale Up):

Um cluster MongoDB deve ser composto por um número ímpar de membros. Você deverá decidir qual o tamanho apropriado de acordo com a carga de trabalho. Para escalar o cluster, vamos utilizar o comando scale:

$ oc escale --replicas=5 petset/mongodb

Os novos containers serão iniciados e ingressados no cluster automaticamente.

Com um cluster de 5 membros, os cenários acima ainda são válidos, com a diferença de que agora o cluster suporta falha de 2 membros sem interromper a operação.

Nota: adicionar mais membros no cluster pode necessitar de intervenção manual. Se por exemplo a base de dados for maior que o parâmetro oplogSize, será necessário realizar a sincronia dos dados manualmente. Por favor consulte a documentação do MongoDB para maiores detalhes.

Removendo membros do Cluster (Scale Down):

Cabe a você decidir o melhor tamanho do cluster, isso quer dizer que um cluster pode ser alterado de 5 para 3 membros, bem como de 3 para 1.

Enquanto adicionar membros nem sempre requer intervenção manual, remover membros funciona de outra forma. Neste caso você precisará executar alguns procedimentos manualmente:

Para reduzir o tamanho do cluster:

$ oc scale --replicas=3 petset/mongodb

Note que se a nova quantidade de membros constituir na maioria dos membros do tamanho anterior por ex, de 5 para 3 é garantido que um novo "PRIMARY" seja eleito.

Por outro lado, alterando o tamanho para um número menor, o cluster entrará em modo "somente leitura", por exemplo, alterando o tamanho de 5 para 1.

A próximo passo é atualizar a configuração do replicaset e remover os membros que foram deletados. Esta operação pode ser melhorada no futuro, utilizando gatilhos de PreStop, que inspeciona o número de replicas e automaticamte as remove da configuração.

Finalmente, os volumes devem ser removidos, para maiores detalhes veja a documentação do PetSet.

Limitações:

Suporte apenas para MongoDB 3.2
É necessário alterar manualmente a configuração do ReplicaSet em caso de "scale down".
Alterar a senha de administrador é uma operação manual, você deverá modificar as variáveis de ambiente no PetSet e modificar a senha do MongoDB em cada um dos containers.
Não é possível alterar o tamanho dos containers, uma vez criado você precisará recriar o PetSet para alterar os limites de CPU e Memória.

Veja também as limitações do PetSet

Artigos nessa seção