Monitoramento é a ação de observar e verificar durante um período de tempo para ver como o que você está monitorando se desenvolve e executa. Você faz isso para poder fazer as alterações necessárias para garantir que as coisas funcionem corretamente. É essencial que os processos sejam monitorados para produzir bons insights sobre as atividades que estão sendo executadas para planejar, organizar e executar uma solução eficiente.
O Docker é um programa criado para funcionar como um construtor pronto para responder à pergunta “O software será executado na minha máquina?” Basicamente monta diferentes partes criando um modelo fácil de armazenar e transportar. O modelo, também conhecido como container, pode ser enviado para qualquer computador que tenha o Docker instalado.
Neste artigo seremos apresentados ao Docker, descrevendo algumas formas de configuração e comparando-as. Além disso, o PostgreSQL entra em ação, e vamos implantá-lo dentro de um contêiner Docker de maneira inteligente e, finalmente, veremos os benefícios que o ClusterControl pode fornecer, para monitorar as principais métricas sobre o PostgreSQL e o sistema operacional fora dele.
Visão geral do Docker
Quando o Docker é iniciado, ele cria uma nova conexão de rede para permitir a transmissão de dados entre dois endpoints, chamada bridge, e é aqui que os novos contêineres são mantidos por padrão.
A seguir, veremos detalhes sobre essa ponte e discutiremos por que não é uma boa ideia usá-la em produção.
$ docker network inspect bridge
Inspecionando a ponte padrão do Docker docker0. Observe as opções incorporadas, pois se você executar um container sem especificar a rede desejada, você concordará com isso.
Nesta conexão de rede padrão, perdemos algumas boas vantagens da rede, como DNS. Imagine que você deseja acessar o Google, qual endereço você prefere, www.google.com ou 172.217.165.4?
Não sei você, mas prefiro a escolha anterior e, para ser sincero, não digito o 'www.'.
Rede ponte definida pelo usuário
Portanto, queremos o DNS em nossa conexão de rede e o benefício do isolamento, porque imagine o cenário em que você implanta diferentes contêineres dentro da mesma rede.
Quando criamos um container Docker, podemos dar um nome a ele, ou o Docker faz isso para nós randomizando duas palavras conectadas por sublinhado, ou '_'.
Se não usarmos uma rede de ponte definida pelo usuário, no futuro pode haver um problema no meio dos endereços IP, porque claramente não somos máquinas, e lembre-se de que esses valores podem ser difíceis e propensos a erros.
Criar uma ponte personalizada ou uma rede de ponte definida pelo usuário é muito fácil.
Antes de criar o nosso primeiro, para entender melhor o processo, vamos abrir um novo terminal, digitar um comando Linux do pacote iproute2, e esquecê-lo agora.
$ ip monitor all
Inicializando um terminal para monitorar o tráfego de rede no Docker Host. Este terminal agora estará ouvindo a atividade da rede e exibindo lá.
Você já deve ter visto comandos como “ifconfig” ou “netstat” antes, e eu lhe digo que eles estão obsoletos desde 2001. O pacote net-tools ainda é amplamente utilizado, mas não é mais atualizado.
Agora é hora de criar nossa primeira rede personalizada, então abra outro terminal e digite:
$ docker network create --driver bridge br-db
Criando a rede de ponte definida pelo usuário "br-db". Essa mistura muito longa de letras e números é chamada de UUID, ou Universally Unique IDentifier. Está basicamente dizendo que a rede foi criada com sucesso.
O nome dado para nossa primeira rede criada manualmente foi “br-db”, e precisa estar no final do comando, mas antes disso, temos o argumento '“-driver”, e depois o valor “bridge” , Por quê?
Na Community Edition, o Docker fornece três drivers diferentes disponíveis:bridge, host e none. Na hora da criação, assim, o padrão é bridge e não precisa ser especificado, mas estamos aprendendo sobre isso.
Se você já fez tudo comigo, olhe para o outro terminal porque vou explicar o que está acontecendo para você.
O Docker criou a rede, chamada “br-db”, mas isso só é chamado assim por ele.
Do outro lado dessa ponte personalizada criada, há outra camada, o SO. O nome dado para a mesma rede bridge foi alterado e passa a ser uma representação da nomenclatura para bridge, “br”, seguido dos primeiros 12 caracteres do valor UUID acima, em vermelho.
Monitorando alterações de endereço IP do Docker. Com nossa nova conexão de rede, temos uma sub-rede, um gateway e uma transmissão.
O Gateway, como o nome sugere, é onde todo o tráfego de pacotes acontece entre os endpoints da bridge, e é chamado de “inet” para o SO como você pode ver.
Broadcast fica no último endereço IP e é responsável por enviar o mesmo tráfego de dados para todos os endereços IP da sub-rede quando necessário.
Eles estão sempre presentes nas conexões de rede, e é por isso que temos no início da saída, o valor “[ADDR]”. Este valor representa as mudanças de endereço IP e é como um evento sendo disparado para o monitoramento da atividade da rede, pois criamos uma nova conexão de rede!
Contêiner do Docker
Visite o Docker Hub e veja que o que existe é conhecido como Docker Image, e é basicamente o esqueleto do contêiner (modelo).
As imagens do Docker são geradas pelo Dockerfiles e contêm todas as informações necessárias para criar um contêiner, para facilitar a manutenção e a personalização.
Se você olhar com atenção no Docker Hub, é fácil ver que a imagem do PostgreSQL, chamada postgres, possui tags e versões diferentes, e se você não especificar uma delas será usado o padrão, o mais recente, mas talvez em no futuro, se você precisar de diferentes contêineres do PostgreSQL trabalhando juntos, você pode querer que eles estejam na mesma versão.
Vamos criar nosso primeiro container certo agora, lembre-se da necessidade do argumento '--network', ou ele será implantado na bridge padrão.
$ docker container run --name postgres-1 --network br-db -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6551:5432 -d postgres
Executando um contêiner PostgreSQL na rede "br-db". Novamente o UUID, sucesso, e no outro terminal, o que está acontecendo?
As mudanças na interface de rede são o evento que está acontecendo agora, ou simplesmente “[LINK]”. Qualquer coisa depois do “veth” você pode esquecer, acredite, o valor sempre muda quando o container é reiniciado ou algo semelhante acontece.
Monitorando alterações na interface de rede do Docker. A outra opção “-e POSTGRES_PASSWORD=?” significa Environment, e está disponível apenas ao executar contêineres PostgreSQL, está configurando a senha para a conta de superusuário no banco de dados, chamada postgres.
Publicar é o nome longo para o parâmetro “-p 6551:5432”, e basicamente está tornando a porta 6551 do sistema operacional vinculada bidirecionalmente à porta 5432 do contêiner.
Por último, mas não menos importante, é a opção Detach, “-d”, e o que ela faz é fazer com que o contêiner funcione independentemente deste terminal.
O nome da imagem do Docker deve estar no final, seguindo o mesmo padrão de criação da rede, tendo todos os argumentos e opções à esquerda, e no final o mais importante, neste caso, o nome da imagem.
Lembre-se que os containers são mantidos na sub-rede da rede, ficando nos endereços IP permitidos para cada um deles, e nunca estarão no primeiro ou no último endereço, pois o Gateway e o Broadcast estarão sempre lá.
Mostramos os detalhes da ponte criada, e agora serão exibidos por cada um dos endpoints esses detalhes mantidos por eles.
$ docker network inspect br-db
Inspecionando a interface de rede definida pelo usuário do Docker "br-db".$ brctl show
Exibindo informações sobre a rede de ponte definida pelo usuário pelo host do Docker. Como você pode ver, os nomes da rede e do container diferem, sendo o segundo reconhecido como uma interface pelo SO, chamado “veth768ff71”, e o nome original dado por nós “postgres-1” para o Docker.
No comando Docker é possível anotar o endereço IP do container criado anteriormente, a sub-rede correspondente ao que apareceu no outro terminal aberto momentos atrás, e por último as opções vazias para esta rede personalizada.
O comando do Linux “brctl show” faz parte do pacote bridge-utils e, como o nome sugere, sua finalidade é fornecer um conjunto de ferramentas para configurar e gerenciar as pontes Ethernet do Linux.
Outra rede de ponte personalizada
Discutiremos sobre o DNS em breve, mas foi muito bom tornar as coisas simples para nós no futuro. Ótimas configurações tendem a facilitar a vida do DBA no futuro.
Com as redes é a mesma coisa, então podemos alterar a forma como o SO reconhece o endereço da sub-rede e o nome da rede adicionando mais argumentos no momento da criação.
$ docker network create --driver bridge --subnet 172.23.0.0/16 -o “com.docker.network.bridge.name”=”bridge-host” bridge-docker
Criando uma interface de rede de ponte definida pelo usuário com opções personalizadas.$ ip route show
Exibindo a tabela de roteamento do Docker. Com este comando do Linux, podemos ver quase a mesma coisa que o outro comando anterior, mas agora em vez de listar as interfaces “veth” para cada rede, simplesmente temos este “linkdown” exibindo aquelas que estão vazias.
O endereço de sub-rede desejado foi especificado como argumento, e semelhante à opção Environment para a criação do container, para network temos o “-o” seguido do par de chave e valor. Neste caso, estamos dizendo ao Docker, para dizer ao SO, que ele deve chamar a rede como “bridge-host”.
A existência dessas três redes também pode ser verificada no Docker, basta digitar:
$ docker network ls
Exibindo interfaces de rede no Docker Engine. Agora já discutimos anteriormente que os valores desses “veth” para os containers não importam, e vou mostrar na prática.
O exercício consiste em verificar o valor atual, reiniciar o container e verificar novamente. Para isso, precisaremos de uma mistura de comandos do Linux usados anteriormente e do Docker, que são novos aqui, mas muito simples:
$ brctl show
$ docker container stop postgres-1
$ docker container start postgres-1
$ brctl show
Verificando como "iptables" torna os nomes de contêiner voláteis para o Docker Host. Quando o contêiner é interrompido, o endereço IP deve ser liberado para receber um novo, se necessário, e isso é um lembrete de como o DNS pode ser importante.
O SO dá esses nomes para as interfaces toda vez que um container está em um endereço IP, e eles são gerados usando o pacote iptables, que em breve será substituído pelo novo framework chamado nftables.
Não é recomendado alterar essas regras, mas existem ferramentas disponíveis para ajudar na visualização delas, se necessário, como o dockerveth.
Política de reinicialização de contêiner
Quando reiniciamos o programa Docker, ou mesmo o computador, as redes criadas por ele são mantidas no SO, mas vazias.
Os containers possuem o que é chamado de Container Restart Policy, e este é outro argumento muito importante especificado no momento da criação. PostgreSQL, como banco de dados de produção, sua disponibilidade é fundamental, e é assim que o Docker pode ajudar.
$ docker container run --name postgres-2 --network bridge-docker --restart always -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6552:5432 -d postgres
Especificando a política de reinicialização do contêiner no momento da criação. A menos que você o pare manualmente, este container “postgres-2” estará sempre disponível.
Para entender melhor, os containers rodando serão exibidos e o programa Docker reiniciado, então o primeiro passo novamente:
$ docker container ls
$ systemctl restart docker
$ docker container ls
Verificando a política de reinicialização do contêiner em "postgres-2". Apenas o container “postgres-2” está rodando, o outro container “postgres-1” não inicia sozinho. Mais informações sobre ele podem ser vistas na Documentação do Docker.
Sistema de nomes de domínio (DNS)
Um benefício da User-Defined Bridge Network é a organização, com certeza, pois podemos criar quantos quisermos para rodar novos containers e até conectar os antigos, mas outro benefício que não temos usando a bridge default do Docker, é DNS.
Quando os contêineres precisam se comunicar uns com os outros pode ser difícil para o DBA memorizar os endereços IP, e discutimos isso anteriormente mostrando o exemplo de www.google.com e 172.217.165.4. O DNS resolve esse problema perfeitamente, possibilitando a interação com os containers usando seus nomes dados no momento da criação por nós, como “postgres-2”, ao invés do endereço IP “172.23.0.2”.
Vamos ver como isso funciona. Vamos criar outro container apenas para fins de demonstração na mesma rede chamado “postgres-3”, então, instalaremos o pacote iputils-ping para transmitir os pacotes de dados para o container “postgres-2”, usando seu nome claro .
$ docker container run --name postgres-3 --network bridge-docker --restart always -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6553:5432 -d postgres
$ docker container exec -it postgres-3 bashPara melhor entendimento vamos separá-lo em partes, nas saídas a seguir, a seta azul indicará quando o comando é executado dentro de um container, e em vermelho, no SO.
Executando um contêiner temporário para testar o DNS fornecido pela Interface de rede da ponte definida pelo usuário.$ apt-get update && apt-get install -y iputils-ping
Instalando o pacote "iputils-ping" para testar o DNS.$ ping postgres-2
Mostrando o DNS funcionando com sucesso. Resumo
O PostgreSQL está rodando dentro do Docker, e sua disponibilidade já está garantida. Quando usados dentro de uma rede de ponte definida pelo usuário, os contêineres podem ser gerenciados mais facilmente com muitos benefícios, como DNS, endereços de sub-rede personalizados e nomes de SO para as redes.
Vimos detalhes sobre o Docker e a importância de estar ciente dos pacotes e estruturas atualizados no sistema operacional.
